トラブルシューティング: Elasticsearchクラスターのヘルスステータスを確認・解釈する
Elasticsearchは堅牢で分散型の検索・分析エンジンですが、その分散型という性質上、データの整合性と高可用性を確保するために常時監視が必要です。管理における最初で最も重要なステップは、クラスターのヘルスステータスを確認することです。正常なステータスは、すべてのプライマリおよびレプリカデータセグメント（シャード）がノードに正しく割り当てられ、稼働していることを保証します。
このガイドでは、不可欠な_cat/health APIを使用してクラスターのヘルスを確認する実践的なアプローチを提供します。色分けされたステータス（グリーン、イエロー、レッド）の解釈方法を詳述し、一般的な不安定性の問題を診断・解決するための具体的な手順を提供することで、管理者がクラスターの最適なパフォーマンスを迅速に回復できるよう支援します。
Elasticsearchのヘルスステータスを理解する
Elasticsearchは、クラスターのインデックスとシャードの運用ステータスを伝えるために、シンプルな信号機のような色分けシステムを使用しています。このステータスは、プライマリシャードとレプリカシャードの両方の割り当て状態を反映しています。
3つのコアヘルスステート
| ステータス | 意味 | データ可用性 | 冗長性 | 必要なアクション |
|---|---|---|---|---|
| グリーン | すべてのプライマリシャードとレプリカシャードが割り当てられ、稼働しています。 | 100%利用可能 | 完全 | モニタリングのみ |
| イエロー | すべてのプライマリシャードは割り当てられていますが、1つ以上のレプリカシャードが割り当てられていません。 | 100%利用可能 | 損なわれている | レプリカ割り当ての調査/解決 |
| レッド | 1つ以上のプライマリシャードが割り当てられていません。 | 部分的または完全なデータ損失/利用不可 | 重度に損なわれている | 即時介入 |
_cat/healthでクラスターのヘルスを確認する
_cat APIは、迅速で人間が読める診断のために設計されています。_cat/healthエンドポイントは、クラスターの現在の状態の概要を把握する最も速い方法です。
基本コマンド
このコマンドは、cURL、Kibana Dev Toolsコンソール、または任意のHTTPクライアントを使用して実行できます。
# cURLを使用 (人間が読める形式)
curl -X GET "localhost:9200/_cat/health?v&pretty"
_cat/health出力の解釈
正常なクエリは、主要なメトリックを含むテーブルを返します。
| 列 | 説明 |
|---|---|
epoch |
リクエストが実行された時刻（Unixタイムスタンプ）。 |
timestamp |
時刻（HH:MM:SS形式）。 |
cluster |
クラスターの名前。 |
status |
重要な色インジケーター（グリーン、イエロー、またはレッド）。 |
node.total |
現在クラスターに参加しているノードの総数。 |
node.data |
クラスター内のデータノードの数。 |
shards |
アクティブであるべきシャード（プライマリ + レプリカ）の総数。 |
pri |
プライマリシャードの総数。 |
relo |
現在ノード間で再配置中のシャードの数。 |
init |
初期化中のシャードの数。 |
unassign |
現在割り当てられていないシャードの数。 |
正常な（グリーン）クラスターの例:
epoch timestamp cluster status node.total node.data shards pri relo init unassign
1678886400 10:30:00 my-cluster-dev green 3 3 30 15 0 0 0
ステータス診断: イエロー
クラスターがイエローステータスを報告する場合、それはすべてのデータが技術的に利用可能（すべてのプライマリシャードが割り当てられている）であっても、定義された冗長性レベルが満たされていないことを意味します。1つ以上のレプリカシャードが割り当てられなかったということです。
イエロー状態の一般的な原因
- ノード損失（一時的）: レプリカシャードをホストしていたデータノードがオフラインになった。Elasticsearchは、そのノードが復帰するか、新しいノードが参加するのを待ってから、再割り当てを試みます。
- ノード不足: 2つのレプリカ（合計3つのデータコピー）が必要なのに、データノードが2つしかない場合、3つ目のコピーを配置できないため、別のノードが追加されるまで永続的なイエローステータスになります。
- 割り当て遅延: ノード障害発生後、ノードがすぐに復帰した場合の即時かつコストのかかる再バランスを防ぐために、レプリカ割り当てを遅延させるようにクラスターが構成されている。
- ディスク容量の制約: ノードがレプリカシャードをホストするのに十分なディスク容量を持っていない場合があります。
イエロー状態の具体的な手順
-
割り当てられていないシャードを確認する:
_cat/shardsAPIを使用して、どのシャードが割り当てられておらず（u）、なぜ待機しているのかを特定します。bash curl -X GET "localhost:9200/_cat/shards?v" -
Allocation Explain APIを使用する: 特定のシャードが割り当てられていない詳細な診断には、Allocation Explain APIを使用します。下記の
index_nameとshard_idは、_cat/shardsで見つかった実際の値に置き換えてください。bash curl -X GET "localhost:9200/_cluster/allocation/explain?pretty" -H 'Content-Type: application/json' -d' { "index": "index_name", "shard": 0, "primary": false } 'CLUSTER_REBALANCE_ALLOCATION_DELAYやNO_VALID_TARGET_NODEのような理由について、unassigned_infoとdecisionsフィールドを特に確認してください. -
ノード数と構成を確認する: データノードの数が、必要なレプリカ数プラス1（Nレプリカ + 1プライマリ）以上であることを確認します。
ヒント: ノードでの既知の短期メンテナンスが原因でクラスターがイエローになっている場合は、一時的に無視できることが多いですが、冗長性なしで実行されていることを認識しておいてください。
ステータス診断: レッド
レッドステータスはクリティカルであり、1つ以上のプライマリシャードが割り当てられていないことを示します。これは、そのシャードに格納されているデータが、インデックス作成または検索に完全に利用できないことを意味します。
レッド状態の一般的な原因
- 大規模なノード障害: プライマリノードが障害を起こし、データが破損しているか、残りのクラスター全体で完全に利用できないために、他のノードがプライマリの役割を引き継ぐことができなかった。
- ディスク破損/障害: プライマリシャードを含むストレージデバイスが障害を起こし、昇格させるレプリカが存在しない。
- インデックス設定の問題: ファイルシステムレベルでのインデックスファイルの誤った構成または不適切な削除。
レッド状態の即時介入
クラスターがレッド状態のときに手動復旧を試みる前に、必ずスナップショット経由でクラスターをバックアップしてください。
-
すぐにログを確認する: マスターノードと、障害を起こしたプライマリシャードをホストしていたノードのログを確認し、正確な例外またはクラッシュ理由（しばしばディスク障害またはメモリ不足エラーに関連）を特定します。
-
障害のあるインデックスを特定する:
_cat/shardsを使用して、割り当てられていないプライマリ（p）に関連するインデックスを見つけます。```bash
状態が'UNASSIGNED'でプライマリが'p'の行を探す
curl -X GET "localhost:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason"
``` -
強制再ルーティングを試みる（危険 - 最終手段として使用）: データがノードのいずれかに存在すると確信している場合（例: ノードが復帰したがルーティングが修正されていない）、手動での再ルーティングを試みることができます。これは、プライマリシャードが永久に失われ、正常なノードに新しい空のプライマリを強制的に割り当てることにした場合に、よく使用されます。
```bash
注意: このコマンドは誤って使用するとデータ損失につながる可能性があります。
これは、空のプライマリシャードをノードに割り当て、インデックスを正常とマークします。
curl -X POST "localhost:9200/_cluster/reroute?pretty" -H 'Content-Type: application/json' -d'
{
"commands" : [
{
"allocate_empty_primary" : {
"index" : "failed_index_name",
"shard" : 0,
"node" : "target_node_name",
"accept_data_loss" : true
}
}
]
}
'
``` -
スナップショットから復元する: 障害を起こしたプライマリシャードが復旧できない場合、データの整合性を復元する唯一の安全な方法は、最も最近の成功したスナップショットから影響を受けたインデックスを復元することです。
高度な診断: クラスター設定
管理上の操作や事前に構成された運用上の保護策により、クラスターのステータスがレッドまたはイエローになる場合があります。
クラスタールーティング割り当ての確認
_cluster/settings APIを使用すると、シャードの自動割り当てが明示的に無効になっていないかを確認できます。これにより、クラスターが自己修復できなくなります。
# 現在のクラスター設定を取得
curl -X GET "localhost:9200/_cluster/settings?include_defaults=true&pretty"
特に以下の設定を確認してください。
{
"persistent": {
"cluster": {
"routing": {
"allocation": {
"enable": "none"
}
}
}
}
}
cluster.routing.allocation.enableがnone（またはprimaries）に設定されている場合、Elasticsearchはシャードを割り当てず、クラスターを現在の状態（おそらくイエローまたはレッド）にロックします。
割り当ての再有効化
通常のシャード割り当てを復元するには、設定をallに更新します。
curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
{
"persistent": {
"cluster.routing.allocation.enable": "all"
}
}
'
結論
Elasticsearchクラスターのヘルスステータスを解釈することは、あらゆる管理者にとって基本的なスキルです。_cat/health APIは、データの運用上の整合性に関する即時の洞察を提供します。グリーンステータスが目標ですが、イエローは冗長性が低下していること、レッドはデータが利用できないことを意味することを理解することで、_cat/shardsやAllocation Explain APIのような二次的なツールを使用して、正確かつ迅速なトラブルシューティングが可能になります。定期的な監視とプロアクティブなスナップショット取得は、クリティカルなクラスター障害に対する最善の防御策であり続けます。