故障排查发现
edit故障排查发现
edit在大多数情况下，发现和选举过程很快完成，主节点长时间保持选举状态。
如果您的集群没有稳定的Master节点，其许多功能将无法正常工作，Elasticsearch会向客户端和日志中报告错误。在解决这些其他问题之前，您必须修复Master节点的稳定性。在没有选举出Master节点或选举出的Master节点不稳定的情况下，无法解决任何其他问题。
如果您的集群有一个稳定的Master节点，但某些节点无法发现或加入它，这些节点将向客户端和日志中报告错误。在解决其他问题之前，您必须解决阻止这些节点加入集群的障碍。在这些节点无法加入集群的情况下，无法解决它们报告的任何其他问题。
如果集群在几秒钟内没有选出主节点，主节点不稳定，或者某些节点无法发现或加入稳定的主节点，那么 Elasticsearch 将在其日志中记录信息，解释原因。如果问题持续超过几分钟，Elasticsearch 将在其日志中记录更多信息。为了正确排查发现和选举问题，请收集并分析所有节点至少五分钟的日志。
以下部分描述了一些常见的发现和选举问题。
未选举出主节点
edit当一个节点赢得主节点选举时，它会记录一条包含elected-as-master的消息，所有节点都会记录一条包含master node changed的消息，以标识新当选的主节点。
如果没有选出的主节点且没有节点能够赢得选举，所有节点将使用名为
org.elasticsearch.cluster.coordination.ClusterFormationFailureHelper 的记录器反复记录有关问题的消息。默认情况下，这种情况每10秒发生一次。
主节点选举仅涉及有资格成为主节点的节点，因此在这种情况下，请将注意力集中在这些有资格成为主节点的节点上。这些节点的日志将指示主节点选举的要求，例如发现一组特定的节点。这些节点上的Health API也将提供有关情况的实用信息。
如果日志或健康报告显示 Elasticsearch 无法发现足够多的节点来形成一个仲裁，您必须解决阻止 Elasticsearch 发现缺失节点的原因。这些缺失的节点是重建集群元数据所必需的。没有集群元数据，集群中的数据将毫无意义。集群元数据存储在集群中一部分有资格成为主节点的节点上。如果无法发现仲裁，那么缺失的节点就是持有集群元数据的节点。
确保有足够的节点运行以形成法定人数，并且每个节点都可以通过网络与其他节点通信。如果选举问题持续超过几分钟，Elasticsearch 将报告有关网络连接的更多详细信息。如果您无法启动足够的节点以形成法定人数，请启动一个新集群并从最近的快照恢复数据。有关更多信息，请参阅 基于法定人数的决策。
如果日志或健康报告显示Elasticsearch 已经发现了一个可能的节点仲裁，集群无法选举主节点的典型原因是其中一个节点无法发现仲裁。检查其他有资格成为主节点的日志，确保它们都发现了足够的节点来形成仲裁。
如果日志显示由于超时或网络相关问题导致发现或主选举失败，请按以下步骤缩小问题范围。
-
GC暂停记录在Elasticsearch默认发出的GC日志中，并且通常也记录在主节点日志中的
JvmMonitorService中。使用这些日志来确认节点是否正在经历高堆使用率和长时间的GC暂停。如果是这样，高堆使用率的故障排除指南有一些进一步调查的建议，但通常您需要捕获堆转储和垃圾收集器日志在高堆使用率期间以全面了解问题。 - VM暂停也会影响同一主机上的其他进程。VM暂停通常会导致系统时钟的不连续性，Elasticsearch将在其日志中报告。如果您看到其他进程在同一时间暂停的证据，或意外的时钟不连续性，请调查您运行Elasticsearch的基础设施。
- 数据包捕获将揭示系统级和网络级的故障，特别是如果您同时在所有相关节点上捕获网络流量，并将其与这些节点的Elasticsearch日志一起分析。您应该能够观察到节点之间连接上的任何重传、丢包或其他延迟。
-
可以通过在相关日志消息之前的几秒钟内获取主Elasticsearch进程的堆栈转储（例如，使用
jstack）或分析跟踪（例如，使用Java Flight Recorder）来识别特定线程长时间等待的情况。节点热点线程 API 有时会提供有用的信息，但请记住，此 API 还需要集群中所有节点上的多个
transport_worker和generic线程。该 API 可能会受到您正在尝试诊断的问题的影响。jstack更为可靠，因为它不需要任何 JVM 线程。参与发现和集群成员关系的线程主要是
transport_worker和cluster_coordination线程，这些线程永远不应该有长时间的等待。在 Elasticsearch 日志中也可能有长时间等待线程的证据，特别是查看来自org.elasticsearch.transport.InboundHandler的警告日志。更多信息请参见 网络线程模型。
主节点已选举但不稳定
edit当一个节点赢得主节点选举时，它会记录一条包含elected-as-master的消息。如果这种情况反复发生，说明当选的主节点是不稳定的。在这种情况下，重点关注有资格成为主节点的节点的日志，以了解为什么选举的获胜者停止成为主节点并触发另一次选举。如果日志表明主节点不稳定是由于超时或网络相关问题，那么可以按照以下步骤缩小问题范围。
-
GC暂停记录在Elasticsearch默认发出的GC日志中，并且通常也记录在主节点日志中的
JvmMonitorService中。使用这些日志来确认节点是否正在经历高堆使用率和长时间的GC暂停。如果是这样，高堆使用率的故障排除指南有一些进一步调查的建议，但通常您需要捕获堆转储和垃圾收集器日志在高堆使用率期间以全面了解问题。 - VM暂停也会影响同一主机上的其他进程。VM暂停通常会导致系统时钟的不连续性，Elasticsearch将在其日志中报告这一点。如果您看到其他进程在同一时间暂停的证据，或意外的时钟不连续性，请调查您运行Elasticsearch的基础设施。
- 数据包捕获将揭示系统级和网络级的故障，特别是如果您同时在所有相关节点上捕获网络流量，并将其与这些节点的Elasticsearch日志一起分析。您应该能够观察到节点之间连接上的任何重传、丢包或其他延迟。
-
可以通过在相关日志消息之前的几秒钟内获取主Elasticsearch进程的堆栈转储（例如，使用
jstack）或分析跟踪（例如，使用Java Flight Recorder）来识别特定线程长时间等待的情况。节点热点线程 API 有时会提供有用的信息，但请记住，此 API 还需要集群中所有节点上的多个
transport_worker和generic线程。该 API 可能会受到您正在尝试诊断的问题的影响。jstack更为可靠，因为它不需要任何 JVM 线程。参与发现和集群成员关系的线程主要是
transport_worker和cluster_coordination线程，这些线程永远不应该有长时间的等待。在 Elasticsearch 日志中也可能有长时间等待线程的证据，特别是查看来自org.elasticsearch.transport.InboundHandler的警告日志。更多信息请参见 网络线程模型。
节点无法发现或加入稳定的主节点
edit如果存在一个稳定的选举出来的主节点，但某个节点无法发现或加入其集群，它将使用ClusterFormationFailureHelper记录器反复记录有关问题的消息。受影响的节点上的Health API也将提供有关情况的实用信息。受影响的节点和选举出来的主节点上的其他日志消息可能会提供有关问题的更多信息。如果日志表明节点由于超时或网络相关问题而无法发现或加入集群，则按以下步骤缩小问题范围。
-
GC暂停记录在Elasticsearch默认发出的GC日志中，并且通常也记录在主节点日志中的
JvmMonitorService中。使用这些日志来确认节点是否正在经历高堆使用率和长时间的GC暂停。如果是这样，高堆使用率的故障排除指南有一些进一步调查的建议，但通常您需要捕获堆转储和垃圾收集器日志在高堆使用率期间以全面了解问题。 - VM暂停也会影响同一主机上的其他进程。VM暂停通常会导致系统时钟的不连续性，Elasticsearch将在其日志中报告。如果您看到其他进程在同一时间暂停的证据，或意外的时钟不连续性，请调查您运行Elasticsearch的基础设施。
- 数据包捕获将揭示系统级和网络级的故障，特别是如果您同时在所有相关节点上捕获网络流量，并将其与这些节点的Elasticsearch日志一起分析。您应该能够观察到节点之间连接上的任何重传、丢包或其他延迟。
-
可以通过在相关日志消息之前的几秒钟内获取主Elasticsearch进程的堆栈转储（例如，使用
jstack）或分析跟踪（例如，使用Java Flight Recorder）来识别特定线程长时间等待的情况。节点热点线程 API 有时会提供有用的信息，但请记住，此 API 还需要集群中所有节点上的多个
transport_worker和generic线程。该 API 可能会受到您正在尝试诊断的问题的影响。jstack更为可靠，因为它不需要任何 JVM 线程。参与发现和集群成员关系的线程主要是
transport_worker和cluster_coordination线程，这些线程永远不应该有长时间的等待。在 Elasticsearch 日志中也可能有长时间等待线程的证据，特别是查看来自org.elasticsearch.transport.InboundHandler的警告日志。更多信息请参见 网络线程模型。
节点加入集群并再次离开
edit如果一个节点加入集群，但Elasticsearch判定其为故障节点，那么它将被再次从集群中移除。更多信息请参见排查不稳定的集群。