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

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

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

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

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

テキスト

  1. [2022-03-21T11:02:35,513][INFO ][o.e.c.c.NodeLeftExecutor] [instance-0000000000]
  2.    node-left: [{instance-0000000004}{bfcMDTiDRkietFb9v_di7w}{aNlyORLASam1ammv2DzYXA}{172.27.47.21}{172.27.47.21:19054}{m}]
  3.    with reason [disconnected]

このメッセージは、選出されたマスター（instance-0000000000）の NodeLeftExecutor が node-left タスクを処理し、削除されたノードとその削除理由を特定したことを示しています。ノードが再びクラスターに参加すると、選出されたマスターのログには次のようなメッセージが含まれます（読みやすくするために改行を追加しています）：

テキスト

  1. [2022-03-21T11:02:59,892][INFO ][o.e.c.c.NodeJoinExecutor] [instance-0000000000]
  2.    node-join: [{instance-0000000004}{bfcMDTiDRkietFb9v_di7w}{UNw_RuazQCSBskWZV8ID_w}{172.27.47.21}{172.27.47.21:19054}{m}]
  3.    with reason [joining after restart, removed [24s] ago with reason [disconnected]]

このメッセージは、選出されたマスター（instance-0000000000）の NodeJoinExecutor が node-join タスクを処理し、クラスターに追加されたノードとそのタスクの理由を特定したことを示しています。

他のノードも同様のメッセージをログに記録することがありますが、詳細は少なくなります：

テキスト

  1. [2020-01-29T11:02:36,985][INFO ][o.e.c.s.ClusterApplierService]
  2.    [instance-0000000001] removed {
  3.    {instance-0000000004}{bfcMDTiDRkietFb9v_di7w}{aNlyORLASam1ammv2DzYXA}{172.27.47.21}{172.27.47.21:19054}{m}
  4.    {tiebreaker-0000000003}{UNw_RuazQCSBskWZV8ID_w}{bltyVOQ-RNu20OQfTHSLtA}{172.27.161.154}{172.27.161.154:19251}{mv}
  5.    }, 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

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

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

遅延ノードの診断

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

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

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

Yaml

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

このロガーが有効になっていると、Elasticsearch は障害のあるノードで ノードのホットスレッド API を実行し、その結果を選出されたマスターのログに報告しようとします。結果は圧縮され、エンコードされ、切り分けられて切り捨てを避けるために分割されます：

テキスト

  1. [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...
  2. [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...
  3. [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+...
  4. [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...
  5. [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 系のシステムでは： 

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

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

ShardLockObtainFailedException の失敗の診断

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

シャードが遅くシャットダウンする理由に関する詳細情報を収集するには、次のロガーを構成します：

Yaml

  1. logger.org.elasticsearch.env.NodeEnvironment: DEBUG

このロガーが有効になっていると、Elasticsearch は ShardLockObtainFailedException に遭遇するたびに ノードのホットスレッド API を実行しようとします。結果は圧縮され、エンコードされ、切り分けられて切り捨てを避けるために分割されます：

テキスト

  1. [DEBUG][o.e.e.NodeEnvironment    ] [master] hot threads while failing to obtain shard lock for [index][0] [part 1]: H4sIAAAAAAAA/x...
  2. [DEBUG][o.e.e.NodeEnvironment    ] [master] hot threads while failing to obtain shard lock for [index][0] [part 2]: p7x3w1hmOQVtuV...
  3. [DEBUG][o.e.e.NodeEnvironment    ] [master] hot threads while failing to obtain shard lock for [index][0] [part 3]: v7uTboMGDbyOy+...
  4. [DEBUG][o.e.e.NodeEnvironment    ] [master] hot threads while failing to obtain shard lock for [index][0] [part 4]: 4tse0RnPnLeDNN...
  5. [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 系のシステムでは： 

  1. cat shardlock.log | sed -e 's/.*://' | base64 --decode | gzip --decompress

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

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

Elasticsearch ノードは、他のノードがクラスターを離れた場合にのみ、アウトバウンド接続を積極的に閉じます。不安定なクラスターのトラブルシューティングを参照して、この状況を特定し、トラブルシューティングする方法についての詳細情報を確認してください。アウトバウンド接続が他の理由で閉じられた場合、ノードは次のようなメッセージをログに記録します：

テキスト

  1. [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

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

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