本文是ES官方文档关于集群节点发现与互联互通的问题排查指南内容，第二部分。
原文参考及相关内容：
英文原文（官网）
第一部分-（1）
已选出主节点但状态不稳定？
当一个节点赢得主节点选举时，它会在日志中记录一条包含 “elected-as-master” 的消息。如果这种情况重复发生，则说明当选为主节点的节点处于不稳定状态。在这种情况下，应重点关注来自主节点候选节点的日志，以了解为什么选举胜出者停止作为主节点并触发新一轮选举。
排查步骤
如果日志显示主节点由于超时或网络相关问题而不稳定，那么请按照以下方式缩小问题范围进行排查。
垃圾回收暂停
- 垃圾回收暂停会记录在Elasticsearch默认生成的GC日志中，同时也会通常被JvmMonitorService记录到主节点日志中。利用这些日志可以确认节点是否正在经历高堆内存使用率以及长时间的GC暂停。如果是这样的话，对于高堆内存使用率的排查指南提供了一些进一步调查的建议，但通常情况下，你需要在堆内存高使用率期间捕获堆转储，以便全面理解问题所在。
虚拟机暂停
- 虚拟机暂停同时也会影响同一主机上的其他进程。虚拟机暂停通常会导致系统时钟出现不连续性，Elasticsearch会在其日志中报告这一现象。如果你看到有证据表明其他进程在同一时间暂停运行，或者出现了意外的时钟不连续，那么应当对运行Elasticsearch的基础架构进行深入调查。
数据包捕获
- 数据包捕获将揭示系统级和网络级的故障，特别是在所有相关节点同时捕获网络流量时。你应该能够观察到节点间连接中的任何重传、丢包或其他延迟情况。
- 通过获取Elasticsearch主进程的堆栈转储（例如，使用jstack工具）或执行一段时间内的性能追踪（例如，使用Java Flight Recorder），可以识别出等待特定线程可用时的长时间等待。
节点热点线程API
- 节点热点线程API有时能提供有用的信息，但需注意该API在集群中的所有节点上都需要一定数量的transport_worker和generic线程。该API可能会受到你正试图诊断的问题的影响。相比之下，jstack更加可靠，因为它不需要任何JVM线程的支持。
参阅网络线程模型
- 参与发现和集群成员管理的线程主要是transport_worker和cluster_coordination线程，它们不应出现长时间等待的情况。在Elasticsearch日志中，尤其是来自org.elasticsearch.transport.InboundHandler的警告日志中，也可能存在有关线程长时间等待的证据。有关更多信息，请参阅网络线程模型文档。
