DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

Elasticsearchクラスタ問題のデバッグに必須のツールとテクニック

cat API、allocation explain、ログ、ノード統計、シャードチェックを活用してElasticsearchクラスタの問題をデバッグします。

Elasticsearchクラスタ問題のデバッグに必須のツールとテクニック

Elasticsearchクラスタの問題は、通常、redまたはyellowのヘルスステータス、検索の遅延、書き込みの拒否、ノードのクラスタからの離脱として現れます。最速のデバッグ方法は、クラスタのヘルスから始めて、問題をシャード、ノード、割り当てルール、ログ、リソース負荷に絞り込むことです。

このガイドでは、最も頻繁に使用する組み込みツールについて説明します：_cat API、_cluster/allocation/explain、ノード統計、保留中のタスク、Elasticsearchログです。

Elasticsearchクラスタヘルスの理解

クラスタヘルスは最初のシグナルを提供します：

  • green：すべてのプライマリシャードとレプリカシャードが割り当てられています。
  • yellow：すべてのプライマリシャードは割り当てられていますが、1つ以上のレプリカシャードが割り当てられていません。
  • red：1つ以上のプライマリシャードが未割り当てであり、一部のデータが利用できません。

yellowクラスタは利用可能なプライマリシャードの読み取りと書き込みを提供できますが、冗長性が低下しています。redクラスタは影響を受けるプライマリシャードが利用できないため、即座の調査が必要です。

_cat APIから始める

_cat APIは、迅速な人間が読めるチェックのために設計されています。

curl -X GET "localhost:9200/_cat/health?v"
curl -X GET "localhost:9200/_cat/nodes?v&h=name,ip,heap.percent,ram.percent,cpu,disk.used_percent,load_1m,node.role"
curl -X GET "localhost:9200/_cat/shards?v"
curl -X GET "localhost:9200/_cat/indices?v"

_cat/healthを使用して全体的な状態を確認します。_cat/shardsを使用してUNASSIGNED、INITIALIZING、または繰り返し再配置されているシャードを見つけます。_cat/nodesを使用して特定のノードのヒープ、CPU、またはディスクの負荷を特定します。

redまたはyellowクラスタの場合、このコマンドで焦点を絞ったビューが得られます：

curl -X GET "localhost:9200/_cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node&s=state,index"

シャード割り当ての説明

シャードが未割り当ての場合、_cluster/allocation/explainはElasticsearchがそれを配置できない理由を教えてくれます。

curl -X GET "localhost:9200/_cluster/allocation/explain?pretty" \
  -H 'Content-Type: application/json' -d'
{
  "index": "my_index",
  "shard": 0,
  "primary": true
}'

また、Elasticsearchに見つかった最初の未割り当てシャードを説明させることもできます：

curl -X GET "localhost:9200/_cluster/allocation/explain?pretty" \
  -H 'Content-Type: application/json' -d'{}'

can_allocate、allocate_explanation、node_allocation_decisionsフィールドを読み取ります。一般的な原因には、ディスクのウォーターマーク、割り当てフィルタリング、ノードの欠落、互換性のないインデックス設定、要求されたレプリカ数に対してデータノードが少なすぎることが含まれます。

ノードとクラスタの統計を確認する

ヘルスがグリーンでも検索や書き込みが遅い場合は、リソースの負荷を確認します。

curl -X GET "localhost:9200/_nodes/stats/jvm,fs,os,process,thread_pool?pretty"
curl -X GET "localhost:9200/_cluster/stats?pretty"

高いJVMヒープ使用率、ディスク負荷、拒否された検索や書き込みタスク、および他のノードよりもはるかに高い負荷を持つノードを探します。単一の過負荷ノードは、ホットシャードを所有している場合、クラスタ全体を遅くする可能性があります。

スレッドプールの拒否については、次を使用します：

curl -X GET "localhost:9200/_cat/thread_pool/search,write?v&h=node_name,name,active,queue,rejected,completed"

拒否されたタスクは通常、ノードがリクエストレートに対応できなかったことを意味します。キューを増やす前に原因を修正します：クエリコストを削減し、シャードを分散し、ノードをスケールし、バルクインデックスを遅くします。

保留中のタスクとリカバリを確認する

クラスタ状態の変更が停滞しているように感じられる場合は、保留中のタスクを確認します：

curl -X GET "localhost:9200/_cluster/pending_tasks?pretty"

長いキューは、マスターノードの負荷、頻繁なマッピング更新、シャードの変動、または不安定なノードを示す可能性があります。

シャードの移動とリカバリについては、次を使用します：

curl -X GET "localhost:9200/_cat/recovery?v&active_only=true"

これにより、アクティブにリカバリしているクラスタと、割り当てルールやデータ欠落によってブロックされているクラスタを区別するのに役立ちます。

Elasticsearchログを読む

Elasticsearchログは、APIがほのめかすだけのことを説明することがよくあります。クラスタ内のランダムなノードだけでなく、影響を受けるノードのログを確認します。

次のようなメッセージを検索します：

  • master not discovered
  • flood-stage disk watermark
  • circuit_breaking_exception
  • rejected execution
  • failed to obtain node locks
  • shard failed

例えば、フラッドステージのディスクウォーターマークは、ディスク負荷が解消されるまで影響を受けるインデックスを読み取り専用に設定することで書き込みをブロックする可能性があります。ディスクを解放するか容量を追加した後、ディスクが満杯になった理由を理解した上で書き込みブロックを解除します：

curl -X PUT "localhost:9200/*/_settings?expand_wildcards=all" \
  -H 'Content-Type: application/json' -d'
{
  "index.blocks.read_only_allow_delete": null
}'

実用的なデバッグフロー

どこから始めればよいかわからない場合は、この順序を使用します：

  1. _cat/health?vを確認して、問題がクラスタ全体かどうかを確認します。
  2. _cat/shards?vを使用して、未割り当て、再配置中、またはホットシャードを見つけます。
  3. 未割り当てシャードに対して_cluster/allocation/explainを実行します。
  4. _cat/nodesでヒープ、CPU、ディスク、ノードロールを確認します。
  5. 割り当て、ディスク、JVM、サーキットブレーカーメッセージについてノードログを確認します。
  6. 問題がレイテンシまたはリクエスト拒否の場合は、ノード統計とスレッドプール統計を使用します。

重要なポイント

Elasticsearchのデバッグは、広範なヘルスチェックから問題の原因となっている正確なシャード、ノード、または設定に移行するときに最も効果的です。_cat/health、_cat/shards、allocation explainから始め、ログとノード統計を使用して根本原因を確認してから設定を変更します。