クラスター障害検出（Cluster fault detection）

クラスタ障害検出

選出されたマスターは、クラスタ内の各ノードがまだ接続されており、正常であることを確認するために定期的にチェックを行います。クラスタ内の各ノードも、選出されたマスターの健康状態を定期的にチェックします。これらのチェックはそれぞれ フォロワーチェック と リーダーチェック として知られています。

Elasticsearchは、これらのチェックが時折失敗したりタイムアウトしたりしても、何のアクションも取らないことを許可します。ノードが故障していると見なされるのは、連続していくつかのチェックが失敗した後のみです。障害検出の動作は cluster.fault_detection.* 設定 で制御できます。

しかし、選出されたマスターがノードが切断されたことを検出した場合、この状況は即座の障害として扱われます。マスターはタイムアウトおよびリトライ設定値をバイパスし、ノードをクラスタから削除しようとします。同様に、ノードが選出されたマスターが切断されたことを検出した場合、この状況も即座の障害として扱われます。ノードはタイムアウトおよびリトライ設定をバイパスし、新しいマスターを見つけるか選出するために発見フェーズを再起動します。

さらに、各ノードは定期的に小さなファイルをディスクに書き込み、その後再び削除することでデータパスが正常であることを確認します。ノードがデータパスが正常でないことを発見した場合、そのノードはデータパスが回復するまでクラスタから削除されます。この動作は monitor.fs.health 設定 で制御できます。

選出されたマスターノードは、ノードが合理的な時間内に更新されたクラスタ状態を適用できない場合、クラスタからノードを削除します。タイムアウトは、クラスタ状態の更新の開始から2分にデフォルト設定されています。詳細な説明については クラスタ状態の公開 を参照してください。

不安定なクラスタのトラブルシューティング

通常、ノードは意図的にシャットダウンしない限り、クラスタを離れることはありません。ノードが予期せずクラスタを離れた場合、その原因に対処することが重要です。ノードが予期せず離れるクラスタは不安定であり、いくつかの問題を引き起こす可能性があります。例えば：

• クラスタの健康状態が黄色または赤色になる可能性があります。
• 一部のシャードが初期化中で、他のシャードが失敗する可能性があります。
• 検索、インデックス作成、および監視操作が失敗し、ログに例外が報告される可能性があります。
• .security インデックスが利用できなくなり、クラスタへのアクセスがブロックされる可能性があります。
• マスターが頻繁なクラスタ状態の更新により忙しく見える可能性があります。

この状態のクラスタをトラブルシューティングするには、まずクラスタに 安定したマスター がいることを確認してください。次に、他のすべての問題の前に、予期せずクラスタを離れたノードに焦点を当てます。クラスタに安定したマスターノードと安定したノードメンバーシップがない限り、他の問題を解決することはできません。

不安定なクラスタでは、診断および統計は通常役に立ちません。これらのツールは、特定の時点でのクラスタの状態のビューを提供するだけです。代わりに、クラスタのログを見て、時間の経過に伴う動作のパターンを確認してください。特に選出されたマスターのログに注目してください。ノードがクラスタを離れると、選出されたマスターのログには次のようなメッセージが含まれます（読みやすくするために改行を追加しています）：

テキスト

[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]

このメッセージは、選出されたマスターの NodeLeftExecutor (instance-0000000000) が 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]]

このメッセージは、選出されたマスターの NodeJoinExecutor (instance-0000000000) が 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 レベルで有効になっていること。

ノードは、選出されたマスターに従い始めたり停止したりするたびに master node changed を含むメッセージをログに記録します。これらのメッセージを使用して、各ノードのマスターの状態に対する見解を時間の経過とともに判断できます。

ノードが再起動すると、クラスタを離れ、その後再びクラスタに参加します。再参加すると、NodeJoinExecutor がノードが joining after restart であることを示す node-join タスクを処理したことをログに記録します。ノードが予期せず再起動している場合は、ノードのログを確認して、シャットダウンの理由を確認してください。

影響を受けたノードの ヘルス API も、状況に関する有用な情報を提供します。

ノードが再起動しなかった場合は、その離脱の理由をより詳しく調べる必要があります。各理由には異なるトラブルシューティング手順があり、以下に説明します。考えられる理由は3つあります：

• disconnected: マスターノードから削除されたノードへの接続が閉じられました。
• lagging: マスターがクラスタ状態の更新を公開しましたが、削除されたノードは許可されたタイムアウト内にそれを適用しませんでした。デフォルトでは、このタイムアウトは2分です。このメカニズムを制御する設定については、発見とクラスタ形成の設定 を参照してください。
• followers check retry count exceeded: マスターが削除されたノードに対して連続していくつかの健康チェックを送信しました。これらのチェックは拒否されたか、タイムアウトしました。デフォルトでは、各健康チェックは10秒後にタイムアウトし、Elasticsearchは3回連続して失敗した健康チェックの後にノードを削除します。このメカニズムを制御する設定については、発見とクラスタ形成の設定 を参照してください。

切断されたノードの診断

ノードは通常、シャットダウン時に理由 disconnected でクラスタを離れますが、再起動せずにクラスタに再参加する場合は、他に何らかの問題があります。

Elasticsearchは、かなり信頼性の高いネットワークで動作するように設計されています。ノード間にいくつかのTCP接続を開き、これらの接続が 永遠に 開いたままであることを期待しています。接続が閉じられた場合、Elasticsearchは再接続を試みるため、時折のブリップは一部の進行中の操作を失敗させる可能性がありますが、クラスタへの影響は限られています。対照的に、繰り返し切断される接続は、その操作に深刻な影響を与えます。

選出されたマスターノードからクラスタ内の他のすべてのノードへの接続は特に重要です。選出されたマスターは、他のノードへのアウトバウンド接続を自発的に閉じることはありません。同様に、一度インバウンド接続が完全に確立されると、ノードはシャットダウンしない限り、それを自発的に閉じることはありません。

ノードが理由 disconnected で予期せずクラスタを離れた場合、Elasticsearch以外の何かが接続を閉じた可能性があります。一般的な原因は、不適切なタイムアウトを持つ誤設定されたファイアウォールや、Elasticsearchと互換性のない 他のポリシーです。また、故障したハードウェアやネットワークの混雑によるパケットロスなど、一般的な接続の問題が原因である可能性もあります。高度なユーザーであれば、次のロガーを設定して、ネットワーク例外に関する詳細情報を取得できます：

Yaml

logger.org.elasticsearch.transport.TcpTransport: DEBUG
logger.org.elasticsearch.xpack.core.security.transport.netty4.SecurityNetty4Transport: DEBUG

これらのログに問題を診断するのに十分な情報が表示されない場合は、不安定な接続の両端にあるノードから同時にパケットキャプチャを取得し、それを使用してそのノードのElasticsearchログと分析して、ノード間のトラフィックがネットワーク上の別のデバイスによって中断されているかどうかを確認してください。

遅延ノードの診断

Elasticsearchは、すべてのノードがクラスタ状態の更新を合理的に迅速に処理することを必要とします。ノードがクラスタ状態の更新を処理するのに時間がかかりすぎると、クラスタにとって有害です。マスターは、理由 lagging でこれらのノードを削除します。このメカニズムを制御する設定については、発見とクラスタ形成の設定 を参照してください。

遅延は通常、削除されたノードのパフォーマンスの問題によって引き起こされます。ただし、ノードは深刻なネットワーク遅延のために遅延することもあります。ネットワーク遅延を除外するために、net.ipv4.tcp_retries2 が 適切に設定されていること を確認してください。 warn threshold を含むログメッセージは、根本的な原因に関するさらなる情報を提供する可能性があります。

高度なユーザーであれば、削除されたときにノードが何をしていたかに関する詳細情報を取得するために、次のロガーを設定できます：

Yaml

logger.org.elasticsearch.cluster.coordination.LagDetector: DEBUG

このロガーが有効になっていると、Elasticsearchは故障したノードで ノードのホットスレッド 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 でクラスタを離れますが、再起動せずにクラスタに再参加する場合は、他に何らかの問題があります。

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 を使用して）または、関連するログメッセージの数秒前にプロファイリングトレースを取得することで特定できます。
  ノードのホットスレッド API は時々有用な情報を提供しますが、このAPIはクラスタ内のすべてのノードにわたっていくつかの transport_worker および generic スレッドを必要とすることを考慮してください。このAPIは、診断しようとしている問題の影響を受ける可能性があります。 jstack は、JVMスレッドを必要としないため、はるかに信頼性があります。
  発見とクラスタメンバーシップに関与するスレッドは主に transport_worker および cluster_coordination スレッドであり、これらは長い待機があってはなりません。Elasticsearchのログには、特に org.elasticsearch.transport.InboundHandler からの警告ログを見て、スレッドの長い待機の証拠があるかもしれません。ネットワーキングスレッディングモデル についての詳細は、こちらを参照してください。

デフォルトでは、フォローチェックは30秒後にタイムアウトするため、ノードの離脱が予測不可能な場合は、少なくとも1つのスタックダンプが適切なタイミングで取得されるように、15秒ごとにスタックダンプをキャプチャしてください。

ShardLockObtainFailedExceptionの失敗の診断

ノードがクラスタを離れ、再参加すると、Elasticsearchは通常、シャードをシャットダウンして再初期化します。シャードが十分に早くシャットダウンしない場合、Elasticsearchは ShardLockObtainFailedException によりそれらを再初期化できない可能性があります。

シャードが遅くシャットダウンする理由に関する詳細情報を収集するには、次のロガーを設定してください：

Yaml

logger.org.elasticsearch.env.NodeEnvironment: DEBUG

このロガーが有効になっていると、Elasticsearchは ShardLockObtainFailedException に遭遇するたびに ノードのホットスレッド 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

他のネットワーク切断の診断

Elasticsearchは、かなり信頼性の高いネットワークで動作するように設計されています。ノード間にいくつかの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と互換性のない 他のポリシーです。また、故障したハードウェアやネットワークの混雑によるパケットロスなど、一般的な接続の問題が原因である可能性もあります。高度なユーザーであれば、次のロガーを設定して、ネットワーク例外に関する詳細情報を取得できます：

Yaml

logger.org.elasticsearch.transport.TcpTransport: DEBUG
logger.org.elasticsearch.xpack.core.security.transport.netty4.SecurityNetty4Transport: DEBUG

これらのログに問題を診断するのに十分な情報が表示されない場合は、不安定な接続の両端にあるノードから同時にパケットキャプチャを取得し、それを使用してそのノードのElasticsearchログと分析して、ノード間のトラフィックがネットワーク上の別のデバイスによって中断されているかどうかを確認してください。