网络

大多数用户只需要配置以下网络设置。

您可以将 Elasticsearch 配置为使用以下特殊值自动确定其地址。在配置 network.host、network.bind_host、network.publish_host 以及 HTTP 和传输接口的相应设置时，请使用这些值。

Elasticsearch 将网络地址用于两种不同的目的，称为绑定和发布。大多数节点将对所有内容使用相同的地址，但更复杂的设置可能需要为不同的目的配置不同的地址。

当 Elasticsearch 等应用程序希望接收网络通信时，它必须向操作系统指示它应该接收其流量的地址。这称为*绑定*到这些地址。如果需要，Elasticsearch 可以绑定到多个地址，但大多数节点只绑定到一个地址。只有当 Elasticsearch 在具有该地址的网络接口的主机上运行时，它才能绑定到该地址。如有必要，您可以将传输和 HTTP 接口配置为绑定到不同的地址。

每个 Elasticsearch 节点都有一个地址，客户端和其他节点可以通过该地址与其联系，称为其*发布地址*。每个节点的 HTTP 接口和传输接口各有一个发布地址。这两个地址可以是任何地址，不需要是主机上网络接口的地址。唯一的要求是每个节点必须

如果您使用主机名指定传输发布地址，则 Elasticsearch 将在启动期间将此主机名解析为 IP 地址一次，其他节点将使用生成的 IP 地址，而不是自己再次解析该名称。为避免混淆，请使用在所有网络位置都解析为节点地址的主机名。

这些高级设置允许您绑定到多个地址，或者使用不同的地址进行绑定和发布。在大多数情况下不需要它们，如果您能够使用 常用的设置，则不应使用它们。

使用以下高级设置可以独立于 传输接口 配置 HTTP 接口。您还可以使用 网络设置 同时配置两个接口。

使用以下高级设置可以独立于 HTTP 接口 配置传输接口。使用 网络设置 可以同时配置这两个接口。

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

使用以下高级设置可以独立于 传输接口 配置远程集群接口（基于 API 密钥的模型）。您还可以使用 网络设置 同时配置这两个接口。

您可以跟踪在 HTTP 和传输层上发出的各个请求。

response = client.cluster.put_settings(
  body: {
    persistent: {
      "logger.org.elasticsearch.http.HttpTracer": 'TRACE'
    }
  }
)
puts response

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

response = client.cluster.put_settings(
  body: {
    persistent: {
      'http.tracer.include' => '*',
      'http.tracer.exclude' => ''
    }
  }
)
puts response

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

response = client.cluster.put_settings(
  body: {
    persistent: {
      "logger.org.elasticsearch.http.HttpTracer": 'TRACE',
      "logger.org.elasticsearch.http.HttpBodyTracer": 'TRACE'
    }
  }
)
puts response

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

[TRACE][o.e.h.HttpBodyTracer     ] [master] [276] response body [part 1]: H4sIAAAAAAAA/9...
[TRACE][o.e.h.HttpBodyTracer     ] [master] [276] response body [part 2]: 2oJ93QyYLWWhcD...
[TRACE][o.e.h.HttpBodyTracer     ] [master] [276] response body (gzip compressed, base64-encoded, and split into 2 parts on preceding log lines)

cat httptrace.log | sed -e 's/.*://' | base64 --decode | gzip --decompress

response = client.cluster.put_settings(
  body: {
    persistent: {
      "logger.org.elasticsearch.transport.TransportService.tracer": 'TRACE'
    }
  }
)
puts response

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

response = client.cluster.put_settings(
  body: {
    persistent: {
      'transport.tracer.include' => '*',
      'transport.tracer.exclude' => 'internal:coordination/fault_detection/*'
    }
  }
)
puts response

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

本节介绍 Elasticsearch 中网络子系统使用的线程模型。使用 Elasticsearch 不需要这些信息，但对于诊断集群中网络问题的高级用户来说，这些信息可能很有用。

Elasticsearch 节点通过一组 TCP 通道进行通信，这些通道共同构成一个传输连接。Elasticsearch 客户端通过 HTTP 与集群通信，HTTP 也使用一个或多个 TCP 通道。这些 TCP 通道中的每一个都由节点中 transport_worker 线程中的一个线程拥有。此拥有线程在通道打开时选择，并在通道的整个生命周期内保持不变。

每个 transport_worker 线程都全权负责通过其拥有的通道发送和接收数据。此外，每个 http 和传输服务器套接字都分配给一个 transport_worker 线程。该工作线程负责接受到其拥有的服务器套接字的新传入连接。

如果 Elasticsearch 中的某个线程想要通过特定通道发送数据，它会将数据传递给拥有该通道的 transport_worker 线程以进行实际传输。

通常，transport_worker 线程不会完全处理它们接收到的消息。相反，它们将执行少量初步处理，然后将消息调度（移交）给不同的 线程池 以进行其余处理。例如，批量消息被调度到 write 线程池，搜索被调度到 search 线程池之一，而对统计信息和其他管理任务的请求大多被调度到 management 线程池。但是，在某些情况下，消息的处理预计会非常快，以至于 Elasticsearch 会在 transport_worker 线程上完成所有处理，而不是将其调度到其他地方的开销。

默认情况下，每个 CPU 对应一个 transport_worker 线程。相比之下，有时可能有数万个 TCP 通道。如果数据到达 TCP 通道，并且其拥有的 transport_worker 线程正忙，则在该线程完成其正在执行的任何操作之前，不会处理该数据。同样，在拥有该通道的 transport_worker 线程空闲之前，不会通过该通道发送传出数据。这意味着我们需要每个 transport_worker 线程都经常处于空闲状态。空闲的 transport_worker 在堆栈转储中看起来像这样：

"elasticsearch[instance-0000000004][transport_worker][T#1]" #32 daemon prio=5 os_prio=0 cpu=9645.94ms elapsed=501.63s tid=0x00007fb83b6307f0 nid=0x1c4 runnable  [0x00007fb7b8ffe000]
   java.lang.Thread.State: RUNNABLE
	at sun.nio.ch.EPoll.wait([email protected]/Native Method)
	at sun.nio.ch.EPollSelectorImpl.doSelect([email protected]/EPollSelectorImpl.java:118)
	at sun.nio.ch.SelectorImpl.lockAndDoSelect([email protected]/SelectorImpl.java:129)
	- locked <0x00000000c443c518> (a sun.nio.ch.Util$2)
	- locked <0x00000000c38f7700> (a sun.nio.ch.EPollSelectorImpl)
	at sun.nio.ch.SelectorImpl.select([email protected]/SelectorImpl.java:146)
	at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:813)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at java.lang.Thread.run([email protected]/Thread.java:833)

在 节点热点线程 API 中，空闲的 transport_worker 线程报告如下：

   0.0% [cpu=0.0%, idle=100.0%] (500ms out of 500ms) cpu usage by thread 'elasticsearch[instance-0000000004][transport_worker][T#1]'
     10/10 snapshots sharing following 9 elements
       [email protected]/sun.nio.ch.EPoll.wait(Native Method)
       [email protected]/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:118)
       [email protected]/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:129)
       [email protected]/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:146)
       io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:813)
       io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
       io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
       io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
       [email protected]/java.lang.Thread.run(Thread.java:833)

请注意，transport_worker 线程应始终处于 RUNNABLE 状态，即使在等待输入时也是如此，因为它们在本地 EPoll#wait 方法中阻塞。idle= 时间表示线程花费在等待输入上的时间比例，而 cpu= 时间表示线程花费在处理已接收输入上的时间比例。

如果 transport_worker 线程不经常处于空闲状态，则可能会积压大量工作。这可能会导致处理其拥有的通道上的消息延迟。很难准确预测哪些工作会延迟：

如果积压的工作太多，某些消息可能会延迟几秒钟。该节点甚至可能 无法通过其运行状况检查 并从集群中删除。有时，您可以使用 节点热点线程 API 找到 transport_worker 线程繁忙的证据。但是，此 API 本身也会发送网络消息，因此如果 transport_worker 线程太忙，则可能无法正常工作。使用 jstack 获取堆栈转储或使用 Java Flight Recorder 获取分析跟踪更为可靠。这些工具独立于 JVM 正在执行的任何工作。

还可以从服务器日志中识别出一些延迟原因，特别是查看来自 org.elasticsearch.transport.InboundHandler 和 org.elasticsearch.transport.OutboundHandler 的警告。来自 InboundHandler 的有关长时间处理的警告尤其表明线程行为不正确，而 OutboundHandler 报告的传输时间包括等待网络拥塞的时间，并且 transport_worker 线程在此期间可以自由执行其他工作。