排查不稳定的集群
edit排查不稳定的集群
edit通常情况下，节点只有在被有意关闭时才会离开集群。如果一个节点意外离开集群，重要的是要解决其原因。一个节点意外离开的集群是不稳定的，可能会引发多个问题。例如：
- 集群健康状态可能为黄色或红色。
- 一些分片将处于初始化状态，而其他分片可能失败。
- 搜索、索引和监控操作可能会失败，并在日志中报告异常。
-
.security索引可能不可用，阻止访问集群。 - 由于频繁的集群状态更新，主节点可能显得繁忙。
要排查处于此状态的集群问题，首先确保集群有一个稳定的Master。接下来，重点关注那些意外离开集群的节点，在所有其他问题之前。在集群拥有稳定的Master节点和稳定的节点成员之前，无法解决其他问题。
诊断和统计信息通常在不稳定集群中没有用处。这些工具只能提供集群在某一时刻的状态视图。相反，查看集群日志以了解一段时间内的行为模式。特别关注来自当选主节点的日志。当一个节点离开集群时，当选主节点的日志会包含类似这样的消息（添加了换行符以使其更易读）：
[2022-03-21T11:02:35,513][INFO ][o.e.c.c.NodeLeftExecutor] [instance-0000000000]
node-left: [{instance-0000000004}{bfcMDTiDRkietFb9v_di7w}{aNlyORLASam1ammv2DzYXA}{172.27.47.21}{172.27.47.21:19054}{m}]
with reason [disconnected]
此消息表示在当选的主节点（instance-0000000000）上的NodeLeftExecutor处理了一个node-left任务，识别了被移除的节点及其被移除的原因。当节点重新加入集群时，当选主节点的日志中将包含类似这样的消息（为了便于阅读，添加了换行符）：
[2022-03-21T11:02:59,892][INFO ][o.e.c.c.NodeJoinExecutor] [instance-0000000000]
node-join: [{instance-0000000004}{bfcMDTiDRkietFb9v_di7w}{UNw_RuazQCSBskWZV8ID_w}{172.27.47.21}{172.27.47.21:19054}{m}]
with reason [joining after restart, removed [24s] ago with reason [disconnected]]
此消息表示，在当选的主节点（instance-0000000000）上的NodeJoinExecutor处理了一个node-join任务，识别了添加到集群的节点以及任务的原因。
其他节点可能会记录类似的消息，但报告的细节较少：
[2020-01-29T11:02:36,985][INFO ][o.e.c.s.ClusterApplierService]
[instance-0000000001] removed {
{instance-0000000004}{bfcMDTiDRkietFb9v_di7w}{aNlyORLASam1ammv2DzYXA}{172.27.47.21}{172.27.47.21:19054}{m}
{tiebreaker-0000000003}{UNw_RuazQCSBskWZV8ID_w}{bltyVOQ-RNu20OQfTHSLtA}{172.27.161.154}{172.27.161.154:19251}{mv}
}, term: 14, version: 1653415, reason: Publication{term=14, version=1653415}
这些消息对于故障排除并不是特别有用，因此请关注来自NodeLeftExecutor和NodeJoinExecutor的消息，这些消息仅在当选的主节点上发出，并且包含更多详细信息。如果你没有看到来自NodeLeftExecutor和NodeJoinExecutor的消息，请检查以下内容：
- 您正在查看当选主节点的日志。
- 日志涵盖了正确的时间段。
-
日志记录在
INFO级别启用。
节点在启动或停止跟随选举出的主节点时，也会记录一条包含主节点已更改的消息。您可以使用这些消息来确定每个节点随时间对主节点状态的看法。
如果一个节点重新启动，它将离开集群，然后再次加入集群。
当它重新加入时，NodeJoinExecutor 将记录它处理了一个
node-join 任务，表明该节点正在 重新启动后加入。如果一个节点意外地重新启动，请查看该节点的日志以了解其关闭的原因。
受影响节点上的Health API也会提供一些关于当前情况的有用信息。
如果节点没有重新启动，那么你应该更仔细地查看其离开的原因。每个原因都有不同的故障排除步骤，如下所述。有三种可能的原因：
诊断断开连接的节点
edit节点通常在关闭时以原因 disconnected 离开集群，但如果它们在未重启的情况下重新加入集群，则存在其他问题。
Elasticsearch 设计为在相当可靠的网络上运行。它在节点之间打开多个 TCP 连接，并期望这些连接保持打开状态永远。如果连接关闭，Elasticsearch 将尝试重新连接，因此偶尔的网络波动可能会导致一些正在进行的操作失败，但通常对集群的影响有限。相比之下，反复断开的连接将严重影响其运行。
从当选的主节点到集群中每个其他节点的连接特别重要。当选的主节点永远不会自发关闭其与其他节点的出站连接。同样，一旦入站连接完全建立，节点永远不会自发关闭它，除非节点正在关闭。
如果你看到一个节点意外地以断开连接的原因离开集群，那么除了Elasticsearch之外的其他因素可能导致了连接关闭。一个常见的原因是防火墙配置错误，导致不正确的超时或其他与Elasticsearch不兼容的策略。这也可能是由于一般的连接问题引起的，例如由于硬件故障或网络拥塞导致的丢包。如果你是一个高级用户，可以配置以下日志记录器以获取有关网络异常的更详细信息：
logger.org.elasticsearch.transport.TcpTransport: DEBUG logger.org.elasticsearch.xpack.core.security.transport.netty4.SecurityNetty4Transport: DEBUG
如果这些日志没有显示足够的信息来诊断问题，请同时从不稳定连接的两端节点获取数据包捕获，并将其与这些节点的Elasticsearch日志一起分析，以确定节点之间的流量是否被网络中的另一台设备中断。
诊断滞后节点
editElasticsearch 需要每个节点合理快速地处理集群状态更新。如果一个节点处理集群状态更新花费太长时间，可能会对集群造成损害。主节点将移除这些节点，并给出 lagging 原因。有关控制此机制的设置信息，请参阅 发现和集群形成设置。
滞后通常是由被移除节点上的性能问题引起的。然而，节点也可能由于严重的网络延迟而滞后。为了排除网络延迟，请确保net.ipv4.tcp_retries2已正确配置。包含warn threshold的日志消息可能会提供更多关于根本原因的信息。
如果你是一个高级用户，你可以通过配置以下日志记录器来获取更多关于节点在被移除时正在做什么的详细信息：
logger.org.elasticsearch.cluster.coordination.LagDetector: DEBUG
当此日志记录器启用时，Elasticsearch 将尝试在故障节点上运行 Nodes hot threads API，并在选举出的主节点的日志中报告结果。结果会被压缩、编码并分割成多个块，以避免截断：
[DEBUG][o.e.c.c.LagDetector ] [master] hot threads from node [{node}{g3cCUaMDQJmQ2ZLtjr-3dg}{10.0.0.1:9300}] lagging at version [183619] despite commit of cluster state version [183620] [part 1]: H4sIAAAAAAAA/x...
[DEBUG][o.e.c.c.LagDetector ] [master] hot threads from node [{node}{g3cCUaMDQJmQ2ZLtjr-3dg}{10.0.0.1:9300}] lagging at version [183619] despite commit of cluster state version [183620] [part 2]: p7x3w1hmOQVtuV...
[DEBUG][o.e.c.c.LagDetector ] [master] hot threads from node [{node}{g3cCUaMDQJmQ2ZLtjr-3dg}{10.0.0.1:9300}] lagging at version [183619] despite commit of cluster state version [183620] [part 3]: v7uTboMGDbyOy+...
[DEBUG][o.e.c.c.LagDetector ] [master] hot threads from node [{node}{g3cCUaMDQJmQ2ZLtjr-3dg}{10.0.0.1:9300}] lagging at version [183619] despite commit of cluster state version [183620] [part 4]: 4tse0RnPnLeDNN...
[DEBUG][o.e.c.c.LagDetector ] [master] hot threads from node [{node}{g3cCUaMDQJmQ2ZLtjr-3dg}{10.0.0.1:9300}] lagging at version [183619] despite commit of cluster state version [183620] (gzip compressed, base64-encoded, and split into 4 parts on preceding log lines)
要重建输出，请对数据进行base64解码并使用gzip进行解压缩。例如，在类Unix系统上：
cat lagdetector.log | sed -e 's/.*://' | base64 --decode | gzip --decompress
诊断follower check retry count exceeded节点
edit节点有时会因为原因 follower check retry count exceeded 在关闭时离开集群，但如果它们在不重启的情况下重新加入集群，那么就存在其他问题。
Elasticsearch 需要每个节点成功且合理快速地响应网络消息。如果一个节点拒绝请求或根本不响应，那么它可能对集群有害。如果连续多次检查失败，主节点将移除该节点，原因代码为 follower check retry count exceeded，并在 node-left 消息中指示连续失败检查的数量以及超时的检查数量。有关控制此机制的设置信息，请参阅 发现和集群形成设置。
超时和失败可能是由于网络延迟或受影响节点上的性能问题引起的。确保 net.ipv4.tcp_retries2 已正确配置，以消除网络延迟作为此类不稳定的潜在原因。包含 warn threshold 的日志消息可能会提供有关不稳定原因的进一步线索。
如果最后一次检查因异常失败，则报告该异常，并且通常指示需要解决的问题。如果任何检查超时，则按如下方式缩小问题范围。
-
GC暂停记录在Elasticsearch默认发出的GC日志中，并且通常也记录在主节点日志中的
JvmMonitorService中。使用这些日志来确认节点是否正在经历高堆使用率和长时间的GC暂停。如果是这样，高堆使用率的故障排除指南有一些进一步调查的建议，但通常您需要捕获堆转储和垃圾收集器日志在高堆使用率期间以全面了解问题。 - VM暂停也会影响同一主机上的其他进程。VM暂停通常会导致系统时钟的不连续性，Elasticsearch将在其日志中报告。如果您看到其他进程在同一时间暂停的证据，或意外的时钟不连续性，请调查您运行Elasticsearch的基础设施。
- 数据包捕获将揭示系统级和网络级的故障，特别是如果您同时在选定的主节点和故障节点捕获网络流量，并将其与这些节点的Elasticsearch日志一起分析。用于跟随者检查的连接不用于任何其他流量，因此即使在使用TLS的情况下，也可以仅从流量模式中轻松识别：几乎每秒都会有几百分之一的数据包在两个方向上发送，首先是主节点的请求，然后是跟随者的响应。您应该能够观察到任何重传、丢包或其他延迟。
-
可以通过在相关日志消息之前的几秒钟内获取主Elasticsearch进程的堆栈转储（例如，使用
jstack）或分析跟踪（例如，使用Java Flight Recorder）来识别特定线程长时间等待的情况。节点热点线程 API 有时会提供有用的信息，但请记住，此 API 还需要集群中所有节点上的多个
transport_worker和generic线程。该 API 可能会受到您正在尝试诊断的问题的影响。jstack更为可靠，因为它不需要任何 JVM 线程。参与发现和集群成员关系的线程主要是
transport_worker和cluster_coordination线程，这些线程永远不应该有长时间的等待。在 Elasticsearch 日志中也可能有长时间等待线程的证据，特别是查看来自org.elasticsearch.transport.InboundHandler的警告日志。更多信息请参见 网络线程模型。
默认情况下，跟随者检查将在30秒后超时，因此如果节点离开是不可预测的，则每15秒捕获一次堆栈转储，以确保在正确的时间至少捕获了一次堆栈转储。
诊断 ShardLockObtainFailedException 失败
edit如果一个节点离开并重新加入集群，Elasticsearch 通常会关闭并重新初始化其分片。如果分片没有足够快地关闭，Elasticsearch 可能会由于 ShardLockObtainFailedException 而无法重新初始化它们。
要收集更多关于分片关闭缓慢原因的信息，请配置以下日志记录器：
logger.org.elasticsearch.env.NodeEnvironment: DEBUG
当此日志记录器启用时，Elasticsearch 将在遇到 ShardLockObtainFailedException 时尝试运行
Nodes hot threads API。结果会被压缩、编码并分割成多个块以避免截断：
[DEBUG][o.e.e.NodeEnvironment ] [master] hot threads while failing to obtain shard lock for [index][0] [part 1]: H4sIAAAAAAAA/x... [DEBUG][o.e.e.NodeEnvironment ] [master] hot threads while failing to obtain shard lock for [index][0] [part 2]: p7x3w1hmOQVtuV... [DEBUG][o.e.e.NodeEnvironment ] [master] hot threads while failing to obtain shard lock for [index][0] [part 3]: v7uTboMGDbyOy+... [DEBUG][o.e.e.NodeEnvironment ] [master] hot threads while failing to obtain shard lock for [index][0] [part 4]: 4tse0RnPnLeDNN... [DEBUG][o.e.e.NodeEnvironment ] [master] hot threads while failing to obtain shard lock for [index][0] (gzip compressed, base64-encoded, and split into 4 parts on preceding log lines)
要重建输出，请对数据进行base64解码并使用gzip进行解压缩。例如，在类Unix系统上：
cat shardlock.log | sed -e 's/.*://' | base64 --decode | gzip --decompress
诊断其他网络断开问题
editElasticsearch 设计为在相当可靠的网络上运行。它在节点之间打开多个 TCP 连接，并期望这些连接保持打开状态永远。如果连接关闭，Elasticsearch 将尝试重新连接，因此偶尔的网络波动可能会导致一些正在进行的操作失败，但通常对集群的影响有限。相比之下，反复断开的连接将严重影响其运行。
Elasticsearch节点只有在另一个节点离开集群时才会主动关闭与该节点的出站连接。有关识别和排查这种情况的更多信息，请参阅排查不稳定的集群。如果由于其他原因关闭了出站连接，节点将记录如下消息：
[INFO ][o.e.t.ClusterConnectionManager] [node-1] transport connection to [{node-2}{g3cCUaMDQJmQ2ZLtjr-3dg}{10.0.0.1:9300}] closed by remote
同样地，一旦入站连接完全建立，节点不会自发关闭它，除非节点正在关闭。
因此，如果你看到一个节点报告与另一个节点的连接意外关闭，那么除了Elasticsearch之外，很可能是其他原因导致了连接关闭。一个常见的原因是配置错误的防火墙，其超时设置不当或存在与Elasticsearch不兼容的策略。这也可能是由于一般的连接性问题引起的，例如由于硬件故障或网络拥塞导致的丢包。如果你是一个高级用户，可以配置以下日志记录器以获取有关网络异常的更详细信息：
logger.org.elasticsearch.transport.TcpTransport: DEBUG logger.org.elasticsearch.xpack.core.security.transport.netty4.SecurityNetty4Transport: DEBUG
如果这些日志没有显示足够的信息来诊断问题，请同时从不稳定连接的两端节点获取数据包捕获，并将其与这些节点的Elasticsearch日志一起分析，以确定节点之间的流量是否被网络中的另一台设备中断。