ES的集群节点发现故障排除指南（3）- end

本文是ES官方文档关于集群节点发现与互联互通的问题排查指南内容，第三部分，结束。

原文参考及相关内容：

英文原文（官网）

第一部分-（1）

第二部分-（2）

节点无法发现或加入稳定的主节点

如果存在一个稳定选举出的主节点，但某个节点无法发现或加入其集群，它将反复使用ClusterFormationFailureHelper记录器记录关于此问题的日志消息。受影响的节点上的Health API也将提供有关此情况的有用信息。受影响的节点和已选举出的主节点上的其他日志消息可能提供有关问题的额外信息。如果日志表明节点由于超时或网络相关问题而无法发现或加入集群，请按以下方式缩小问题范围：

GC暂停

GC暂停会记录在Elasticsearch默认输出的GC日志中，也通常记录在主节点日志中的JvmMonitorService中。使用这些日志来确认节点是否因长时间的GC暂停而经历了高堆内存使用。如果是这样，高堆内存使用问题的故障排除指南中提供了一些建议，以便进行进一步调查，但通常你需要在高堆内存使用期间捕获堆转储以完全理解问题。

VM暂停

VM暂停也会影响同一主机上的其他进程。VM暂停通常还会导致系统时钟出现不连续，Elasticsearch将在其日志中报告这一点。如果你看到其他进程同时暂停的证据，或意外的时钟不连续，请调查你运行Elasticsearch的基础架构。

数据包捕获

数据包捕获将揭示系统级和网络级故障，特别是如果你在所有相关节点上同时捕获网络流量的话。你应该能够观察到节点之间连接上的任何重传、数据包丢失或其他延迟。

可以通过获取主Elasticsearch进程的堆栈转储（例如，使用jstack）或分析跟踪（例如，使用Java Flight Recorder）来识别特定线程可用前的长时间等待，这应在相关日志消息出现前的几秒钟内进行。

节点热线程API

节点热线程API有时会提供有用的信息，但请注意，该API还需要集群中所有节点的多个transport_worker线程和通用线程。API可能会受到你正在尝试诊断的问题的影响。相比之下，jstack更为可靠，因为它不需要任何JVM线程。

涉及发现和集群成员身份的线程主要是transport_worker和cluster_coordination线程，这些线程不应该有长时间的等待。在Elasticsearch日志中，特别是在org.elasticsearch.transport.InboundHandler的警告日志中，也可能有线程长时间等待的证据。如需更多信息，请参阅网络线程模型。