発見のトラブルシューティング（Troubleshooting discovery）

トラブルシューティングの発見

ほとんどの場合、発見と選挙プロセスは迅速に完了し、マスターノードは長期間選出されたままとなります。

クラスターに安定したマスターがない場合、その多くの機能は正しく動作せず、Elasticsearchはクライアントやログにエラーを報告します。これらの他の問題に対処する前に、マスターノードの不安定さを修正する必要があります。選出されたマスターノードがないか、選出されたマスターノードが不安定な場合、他の問題を解決することはできません。

クラスターに安定したマスターがあるが、いくつかのノードがそれを発見または参加できない場合、これらのノードはクライアントやログにエラーを報告します。これらのノードがクラスターに参加できない障害を解決する必要があります。他の問題を解決することはできません。

クラスターに選出されたマスターノードが数秒以上存在しない場合、マスターが不安定であるか、いくつかのノードが安定したマスターを発見または参加できない場合、Elasticsearchはその理由を説明する情報をログに記録します。問題が数分以上続く場合、Elasticsearchは追加の情報をログに記録します。発見と選挙の問題を適切にトラブルシューティングするには、すべてのノードから少なくとも5分間のログを収集して分析してください。

以下のセクションでは、一般的な発見と選挙の問題について説明します。

マスターが選出されていない

ノードがマスター選挙に勝利すると、elected-as-masterを含むメッセージがログに記録され、すべてのノードは新しく選出されたマスターノードを特定するmaster node changedを含むメッセージをログに記録します。

選出されたマスターノードがなく、どのノードも選挙に勝てない場合、すべてのノードはorg.elasticsearch.cluster.coordination.ClusterFormationFailureHelperというロガーを使用して問題に関するメッセージを繰り返しログに記録します。デフォルトでは、これは10秒ごとに発生します。

マスター選挙はマスター資格のあるノードのみを含むため、この状況ではマスター資格のあるノードに注意を集中してください。これらのノードのログは、特定のノードセットの発見など、マスター選挙の要件を示します。これらのノードのHealth APIも状況に関する有用な情報を提供します。

ログやヘルスレポートがElasticsearchが過半数を形成するために十分なノードを発見できないことを示している場合、Elasticsearchが欠落しているノードを発見できない理由に対処する必要があります。欠落しているノードはクラスターのメタデータを再構築するために必要です。クラスターのメタデータがなければ、クラスター内のデータは無意味です。クラスターのメタデータは、クラスター内のマスター資格のあるノードのサブセットに保存されます。過半数が発見できない場合、欠落しているノードはクラスターのメタデータを保持しているノードです。

過半数を形成するために十分なノードが稼働していることを確認し、すべてのノードがネットワークを介して他のすべてのノードと通信できることを確認してください。選挙の問題が数分以上続く場合、Elasticsearchはネットワーク接続に関する追加の詳細を報告します。過半数を形成するために十分なノードを起動できない場合は、新しいクラスターを起動し、最近のスナップショットからデータを復元してください。過半数に基づく意思決定を参照して、詳細情報を取得してください。

ログやヘルスレポートがElasticsearchが可能な過半数のノードを発見したことを示している場合、クラスターがマスターを選出できない一般的な理由は、他のノードの1つが過半数を発見できないことです。他のマスター資格のあるノードのログを確認し、すべてのノードが過半数を形成するために十分なノードを発見していることを確認してください。

ログがタイムアウトやネットワーク関連の問題により発見またはマスター選挙が失敗していることを示唆している場合、次のように問題を絞り込んでください。

• 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からの警告ログを見て、スレッドの長い待機の証拠があるかもしれません。ネットワーキングスレッドモデルを参照して、詳細情報を取得してください。

マスターが選出されているが不安定

ノードがマスター選挙に勝利すると、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からの警告ログを見て、スレッドの長い待機の証拠があるかもしれません。ネットワーキングスレッドモデルを参照して、詳細情報を取得してください。

ノードが安定したマスターを発見または参加できない

安定した選出されたマスターがあるが、ノードがそのクラスターを発見または参加できない場合、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からの警告ログを見て、スレッドの長い待機の証拠があるかもしれません。ネットワーキングスレッドモデルを参照して、詳細情報を取得してください。

ノードがクラスターに参加して再び離脱する

ノードがクラスターに参加するが、Elasticsearchがそれを故障と判断した場合、再びクラスターから削除されます。不安定なクラスターのトラブルシューティングを参照して、詳細情報を取得してください。