Redクラスターステータスの解決：Elasticsearchトラブルシューティングガイド

Red Elasticsearchクラスターステータスは、少なくとも1つのプライマリシャードが割り当てられていないことを意味します。それが重要なポイントです。一部のデータが利用できなくなり、影響を受けるインデックスに対する検索は部分的な結果や失敗を返す可能性があり、それらのシャードへの書き込みは正常に進みません。

Yellowは異なります：プライマリは割り当てられていますが、1つ以上のレプリカが割り当てられていません。Yellowも冗長性が低下するため注意が必要ですが、Redはインシデントです。データを削除したり、手動でシャードを再ルーティングしたりしてはいけません。まず、どのプライマリが割り当てられていないのか、そしてElasticsearchがなぜその割り当てを拒否するのかを特定します。

Elasticsearchクラスターヘルスの理解

Elasticsearchは、クラスターのステータスとシャード割り当てのスナップショットを提供するCluster Health APIを提供します。このAPIは、ヘルス問題を診断するための主要なツールです。

GET _cluster/health

このコマンドの出力には、statusフィールドが含まれ、green、yellow、またはredのいずれかになります。また、アクティブおよび未割り当てのシャードの数に関する情報も提供します。

• Green：すべてのプライマリおよびレプリカシャードが割り当てられ、正常に機能しています。
• Yellow：すべてのプライマリシャードが割り当てられていますが、一部のレプリカシャードが未割り当てです。
• Red：1つ以上のプライマリシャードが未割り当てであり、それらのシャードのデータが利用できなくなります。

インシデント発生時には、より詳細なヘルスコールを使用します：

GET _cluster/health?level=indices

次に、未割り当てのシャードをリストします：

GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node&s=state,index

Red/Yellowステータスの一般的な原因とトラブルシューティング手順

クラスターがgreenでない場合、調査を開始します。以下は、未割り当てシャードの最も一般的な原因とその対処方法です：

1. ディスク容量不足

Elasticsearchには、ディスクフルによるデータ破損を防ぐためのセーフガードがあります。ノードのディスク容量が不足すると、新しいシャードの割り当てや既存のシャードのリカバリが妨げられます。

診断：

• 各ノードのディスク使用量を確認します。
• Cluster Allocation Explain APIを使用して、シャードが未割り当てである理由を理解します。

GET _cluster/allocation/explain

このAPIは詳細な理由を提供し、多くの場合、ディスクウォーターマークを指摘します。

解決策：

• ディスク容量を解放する： 古いインデックスを削除する、データを別の階層に移動する、または容量を追加します。アクティブなインデックスをフォースマージすることは、迅速なディスク容量の修正にはならず、インシデント中に重いI/Oを追加する可能性があります。
• ディスク容量を追加する： ノードのストレージ容量を増やします。
• ディスクウォーターマークを設定する： 現在の値が環境に適していない場合にのみ、cluster.routing.allocation.disk.watermark.low、high、およびflood_stageを調整します。ウォーターマークを引き上げると時間を稼げますが、実際の容量問題を隠す可能性もあります。

2. ノードがクラスターから離脱した（ノード退避）

ノードは、ネットワークの問題、クラッシュ、または意図的な削除によりクラスターを離れることがあります。シャード（特にプライマリシャード）を保持するノードが離脱すると、それらのシャードは未割り当てになります。

診断：

• 最近離脱したノードについてクラスターログを確認します。
• ノード間のネットワーク接続を監視します。
• すべてのノードが相互に検出可能であることを確認します。discovery.seed_hosts、トランスポート接続、およびクラスターログを確認します。既存の形成されたクラスターに一般的な修正としてcluster.initial_master_nodesを再導入しないでください。

解決策：

• ノードを再起動する： ノードがクラッシュしたか応答しなくなった場合は、再起動を試みます。
• ネットワーク問題に対処する： ノード間のネットワーク接続の問題を解決します。
• ノードを再追加する： ノードが意図的に削除された場合は、クラスターに再参加する前に正しく設定されていることを確認します。

3. シャード割り当てフィルタリングとアウェアネス

不適切に設定されたシャード割り当てルールにより、シャードが利用可能なノードに割り当てられないことがあります。

診断：

• cluster.routing.allocation.*設定、特にcluster.routing.allocation.include、exclude、およびrequireフィルターを確認します。
• ゾーンまたはラックアウェアネスを使用している場合は、cluster.routing.allocation.awareness.attributesを確認します。

解決策：

• 割り当てフィルターを調整する： シャードが適切なノードに割り当てられるようにフィルターを変更します。
• アウェアネス属性を修正する： 使用する場合、ノードがアウェアネス属性で正しくタグ付けされていること、および割り当てルールがこれらを尊重していることを確認します。

4. 割り当てのためのディスク容量不足（インデックス作成後）

ディスクがいっぱいでなくても、Elasticsearchは割り当て後にディスクが高ウォーターマークを超えると予測した場合、シャードの割り当てを防ぐことがあります。これはディスクウォーターマークに関連していますが、特に新しい割り当てに影響します。

診断：

• _cluster/allocation/explain APIがここで非常に役立ちます。
• 利用可能な空き容量と予想されるシャードのサイズを確認します。

解決策：

• 一般的なディスク容量の問題と同様に：容量を解放する、ストレージを追加する、またはウォーターマークを慎重に調整します。

5. シャードサイズとノード容量

非常に大きなシャードや多数のシャードは、ノードリソース（CPU、メモリ）に負担をかけ、割り当てに影響を与える可能性があります。また、ノードがシャード制限（cluster.routing.allocation.total_shards_per_node）に達した場合、新しいシャードはそのノードに割り当てられません。

診断：

• シャードサイズを確認します（GET _cat/shards?v）。
• ノードリソース使用率（CPU、メモリ）を監視します。
• cluster.routing.allocation.total_shards_per_node設定を確認します。

解決策：

• シャード負荷を減らす： 将来のインデックスについては、シャードが管理可能なサイズ範囲に収まるようにロールオーバーとシャード数を調整します。既存のインデックスについては、クラスターが作業を処理するのに十分安定した後にのみ、reindex、shrink、またはsplitを使用します。
• ノード容量を増やす： より強力なノード、またはより多くのメモリ/CPUを備えたノードを追加します。
• シャード制限を調整する： 必要であり、十分なリソースがある場合は、cluster.routing.allocation.total_shards_per_nodeを増やします。

6. マスターノードの問題

不安定なマスターノードは、シャード割り当ての問題を引き起こす可能性があります。マスターが利用できないか、その職務を実行できない場合、シャードが未割り当てになることがあります。

診断：

• マスター関連のエラーや警告についてクラスターログを確認します。
• スプリットブレインシナリオを避けるために、マスター候補ノードが奇数個（通常3または5）あることを確認します。
• マスター候補ノードがマスターを選出できることを確認します。

解決策：

• マスターを安定させる： マスター候補ノードが正常で、十分なリソースがあり、適切に接続されていることを確認します。
• ブートストラップ履歴を確認する： cluster.initial_master_nodesは最初のクラスター形成のみに使用します。ブートストラップ後は、ノード設定から削除し、ログ、トランスポートネットワーキング、および投票設定を通じてマスターの不安定性をトラブルシューティングします。

_cluster/allocation/explainを使用した高度なトラブルシューティング

_cluster/allocation/explain APIは、特定のシャードが未割り当てである理由を理解するための最も強力なツールです。

例：

GET _cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": true
}

これにより、my-indexのプライマリシャード0を割り当てられない理由を説明する詳細なJSON出力が返されます。未割り当ての理由（例：DISK_THRESHOLD、NODE_LEFT、NO_VALID_SHARD_COPY）をリストするdecidersなどのフィールドを探します。

Yellowクラスターステータスの解決

Yellowステータスは、プライマリシャードは割り当てられているが、レプリカは割り当てられていないことを意味します。これは主にデータの冗長性とフォールトトレランスに影響します。

一般的な原因：

• ノード不足： インデックスに必要な数のレプリカを収容するのに十分なノードがありません。
• シャード割り当てフィルタリング： Redステータスと同様に、フィルターがレプリカの割り当てを妨げている可能性があります。
• ディスク容量の制約： ノードにはプライマリシャード用の十分な容量があっても、特にディスクウォーターマークがアクティブな場合、レプリカ用の十分な容量がない可能性があります。

解決策：

• ノードを追加する： クラスター内のノード数を増やします。
• レプリカ数を調整する： フォールトトレランスがすべてのインデックスにとって重要でない場合は、インデックスごとのレプリカ数（index.number_of_replicas）を減らします。
• 割り当て設定を確認する： レプリカシャードが利用可能なノードに割り当てられることを許可していることを確認します。

クラスターヘルスを維持するためのベストプラクティス

• ディスク使用量を監視する： すべてのノードのディスク容量を積極的に監視し、アラートを設定します。
• クラスターを適切なサイズにする： データ量とクエリ負荷に対して十分なノードとリソースがあることを確認します。
• シャード管理： シャードサイズを推奨範囲内に保ち、過剰なシャーディングを避けます。
• 定期的にクラスターヘルスを確認する： ルーチンモニタリングの一部としてGET _cluster/healthとGET _cluster/allocation/explainを使用します。
• 変更をテストする： 割り当て設定やディスクウォーターマークに重要な変更を加える前に、ステージング環境でテストします。

割り当てデサイダーがわかれば、通常は道筋が明確です。ディスクしきい値は容量の問題を意味します。NODE_LEFTは、欠落しているノードをリカバリまたは交換することを意味します。NO_VALID_SHARD_COPYは、スナップショットの復元、またはElasticsearchの文書化された安全でないリカバリ手順を使用した意図的なデータ損失の決定が必要になる可能性があることを意味します。最後のケースは、バックアップを最初に確認した上でゆっくりと処理する必要があります。なぜなら、クラスターをRedから救うコマンドは、欠落したプライマリの最新データの永久的な損失を確認することにもなり得るからです。