Networking

These special values yield both IPv4 and IPv6 addresses by default, but you can also add an :ipv4 or :ipv6 suffix to limit them to just IPv4 or IPv6 addresses respectively. For example, network.host: "_en0:ipv4_" would set this node’s addresses to the IPv4 addresses of interface en0.

The most common configuration is for Elasticsearch to bind to a single address at which it is accessible to clients and other nodes. In this configuration you should just set network.host to that address. You should not separately set any bind or publish addresses, nor should you separately configure the addresses for the HTTP or transport interfaces.

Use the advanced network settings if you wish to bind Elasticsearch to multiple addresses, or to publish a different address from the addresses to which you are binding. Set network.bind_host to the bind addresses, and network.publish_host to the address at which this node is exposed. In complex configurations, you can configure these addresses differently for the HTTP and transport interfaces.

Use the following settings to control the low-level parameters of the TCP connections used by the HTTP and transport interfaces.

Elasticsearch allows you to bind to multiple ports on different interfaces by the use of transport profiles. See this example configuration

transport.profiles.default.port: 9300-9400
transport.profiles.default.bind_host: 10.0.0.1
transport.profiles.client.port: 9500-9600
transport.profiles.client.bind_host: 192.168.0.1
transport.profiles.dmz.port: 9700-9800
transport.profiles.dmz.bind_host: 172.16.1.2

The default profile is special. It is used as a fallback for any other profiles, if those do not have a specific configuration setting set, and is how this node connects to other nodes in the cluster. Other profiles can have any name and can be used to set up specific endpoints for incoming connections.

The following parameters can be configured on each transport profile, as in the example above:

Profiles also support all the other transport settings specified in the transport settings section, and use these as defaults. For example, transport.profiles.client.tcp.reuse_address can be explicitly configured, and defaults otherwise to transport.tcp.reuse_address.

A transport connection between two nodes is made up of a number of long-lived TCP connections, some of which may be idle for an extended period of time. Nonetheless, Elasticsearch requires these connections to remain open, and it can disrupt the operation of your cluster if any inter-node connections are closed by an external influence such as a firewall. It is important to configure your network to preserve long-lived idle connections between Elasticsearch nodes, for instance by leaving *.tcp.keep_alive enabled and ensuring that the keepalive interval is shorter than any timeout that might cause idle connections to be closed, or by setting transport.ping_schedule if keepalives cannot be configured. Devices which drop connections when they reach a certain age are a common source of problems to Elasticsearch clusters, and must not be used.

By default, the transport.compress setting is false and network-level request compression is disabled between nodes in the cluster. This default normally makes sense for local cluster communication as compression has a noticeable CPU cost and local clusters tend to be set up with fast network connections between nodes.

The transport.compress configuration option indexing_data will only compress requests that relate to the transport of raw indexing source data between nodes. This option primarily compresses data sent during ingest, ccr, and shard recovery.

The transport.compress setting always configures local cluster request compression and is the fallback setting for remote cluster request compression. If you want to configure remote request compression differently than local request compression, you can set it on a per-remote cluster basis using the cluster.remote.${cluster_alias}.transport.compress setting.

The compression settings do not configure compression for responses. Elasticsearch will compress a response if the inbound request was compressed—​even when compression is not enabled. Similarly, Elasticsearch will not compress a response if the inbound request was uncompressed—​even when compression is enabled. The compression scheme used to compress a response will be the same scheme the remote node used to compress the request.

The HTTP layer has a dedicated tracer that logs incoming requests and the corresponding outgoing responses. Activate the tracer by setting the level of the org.elasticsearch.http.HttpTracer logger to TRACE:

PUT _cluster/settings
{
   "persistent" : {
      "logger.org.elasticsearch.http.HttpTracer" : "TRACE"
   }
}

You can also control which URIs will be traced, using a set of include and exclude wildcard patterns. By default every request will be traced.

PUT _cluster/settings
{
   "persistent" : {
      "http.tracer.include" : "*",
      "http.tracer.exclude" : ""
   }
}

The transport layer has a dedicated tracer that logs incoming and outgoing requests and responses. Activate the tracer by setting the level of the org.elasticsearch.transport.TransportService.tracer logger to TRACE:

PUT _cluster/settings
{
   "persistent" : {
      "logger.org.elasticsearch.transport.TransportService.tracer" : "TRACE"
   }
}

You can also control which actions will be traced, using a set of include and exclude wildcard patterns. By default every request will be traced except for fault detection pings:

PUT _cluster/settings
{
   "persistent" : {
      "transport.tracer.include" : "*",
      "transport.tracer.exclude" : "internal:coordination/fault_detection/*"
   }
}