网络

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

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

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

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

每个 Elasticsearch 节点都有一个地址，客户端和其他节点可以使用该地址联系它，称为其发布地址。每个节点都有一个用于其 HTTP 接口的发布地址和一个用于其传输接口的发布地址。这两个地址可以是任何地址，并且不需要是主机上网络接口的地址。唯一的要求是每个节点都必须满足以下条件：

每个节点都必须有其自己不同的发布地址。

如果使用主机名指定传输发布地址，则 Elasticsearch 将在启动期间将此主机名解析为 IP 地址一次，并且其他节点将使用生成的 IP 地址，而不是再次自行解析该名称。您必须使用主机名，以便它可以解析的所有地址都是节点可以从所有其他节点访问的地址。为避免混淆，最简单的方法是使用解析为单个地址的主机名。

如果使用 特殊值指定传输发布地址，则 Elasticsearch 将在启动期间将此值解析为单个 IP 地址，并且其他节点将使用生成的 IP 地址，而不是再次自行解析该值。您必须使用一个值，以便它可以解析的所有地址都是节点可以从所有其他节点访问的地址。为避免混淆，最简单的方法是使用解析为单个地址的值。在具有多个网络接口的主机上，通常将 0.0.0.0 用作发布地址是错误的。

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

使用以下高级设置来独立于传输接口配置 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 和传输层上发出的各个请求。

resp = client.cluster.put_settings(
    persistent={
        "logger.org.elasticsearch.http.HttpTracer": "TRACE"
    },
)
print(resp)

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

const response = await client.cluster.putSettings({
  persistent: {
    "logger.org.elasticsearch.http.HttpTracer": "TRACE",
  },
});
console.log(response);

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

resp = client.cluster.put_settings(
    persistent={
        "http.tracer.include": "*",
        "http.tracer.exclude": ""
    },
)
print(resp)

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

const response = await client.cluster.putSettings({
  persistent: {
    "http.tracer.include": "*",
    "http.tracer.exclude": "",
  },
});
console.log(response);

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

resp = client.cluster.put_settings(
    persistent={
        "logger.org.elasticsearch.http.HttpTracer": "TRACE",
        "logger.org.elasticsearch.http.HttpBodyTracer": "TRACE"
    },
)
print(resp)

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

const response = await client.cluster.putSettings({
  persistent: {
    "logger.org.elasticsearch.http.HttpTracer": "TRACE",
    "logger.org.elasticsearch.http.HttpBodyTracer": "TRACE",
  },
});
console.log(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

resp = client.cluster.put_settings(
    persistent={
        "logger.org.elasticsearch.transport.TransportService.tracer": "TRACE"
    },
)
print(resp)

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

const response = await client.cluster.putSettings({
  persistent: {
    "logger.org.elasticsearch.transport.TransportService.tracer": "TRACE",
  },
});
console.log(response);

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

resp = client.cluster.put_settings(
    persistent={
        "transport.tracer.include": "*",
        "transport.tracer.exclude": "internal:coordination/fault_detection/*"
    },
)
print(resp)

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

const response = await client.cluster.putSettings({
  persistent: {
    "transport.tracer.include": "*",
    "transport.tracer.exclude": "internal:coordination/fault_detection/*",
  },
});
console.log(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 线程的证据。但是，如果 transport_worker 线程过于繁忙，则此 API 本身会发送网络消息，因此可能无法正常工作。更可靠的方法是使用 jstack 获取堆栈转储或使用 Java Flight Recorder 获取分析跟踪。这些工具独立于 JVM 正在执行的任何工作。

也可能从服务器日志中识别出某些延迟的原因。例如，请参阅以下记录器