DevOpsナレッジハブ
DevOpsナレッジハブ

効果的なトラブルシューティングのためのElasticsearchログ分析

ログ分析を習得することで、効率的なElasticsearchのトラブルシューティングを可能にします。このガイドでは、Elasticsearchログの構造、ログレベル（ERROR、WARN、INFO）を用いた問題の優先順位付けの方法、一般的な問題診断の実践例を詳しく解説します。専用のスローログを使って、クラスター起動失敗、メモリサーキットブレーカー例外、シャード割り当て問題、パフォーマンスのボトルネックに関連する重要なパターンを特定する方法を学びましょう。複雑な分散システムの問題に迅速な解決策を求める運用チームや管理者にとって必読のガイドです。

40 ビュー

トラブルシューティングを効果的に行うためのElasticsearchログの一般的な分析

Elasticsearchは強力な分散検索・分析エンジンですが、その複雑さゆえに、問題が発生した際に根本原因を診断するのは困難な場合があります。効果的なトラブルシューティングに最も重要なツールは、Elasticsearchのログファイルです。これらのログはシステムの運用日誌として機能し、正常な起動シーケンスや定期的なクラスタメンテナンスから、メモリ回路遮断器の作動やシャード割り当ての失敗といった重大な障害まで、あらゆることを記録します。

健全でパフォーマンスの高いクラスタを維持するためには、これらのログを読み解き、解釈する技術を習得することが不可欠です。本ガイドでは、Elasticsearchのログ構造の理解、重要なメッセージの特定、およびログ分析を使用して、クラスタの健全性問題、リソース制約、パフォーマンスのボトルネックを含む一般的な運用上の問題を迅速に突き止め、解決するための包括的なアプローチを提供します。

1. Elasticsearchのログ構造の理解

Elasticsearchは、ログ記録にApache Log4j 2フレームワークを使用しています。デフォルトでは、ログはファイルに書き込まれ、多くの場合、機械による解析を容易にするためにJSON形式になりますが、設定によってはプレーンテキストも一般的です。

デフォルトのログの場所

主要なログファイルは、インストール方法（例：RPM/DEBパッケージ、Docker、ZIPファイル）に応じて、通常以下の場所にあります。

インストールタイプ 一般的なログパス
RPM/DEB (Linux) /var/log/elasticsearch/
Docker コンテナ標準出力 (stdout/stderr)
ZIP/Tarball $ES_HOME/logs/

ログエントリの構成要素

各ログエントリ、特にJSON形式のものは、コンテキストにとって重要ないくつかの主要フィールドを含んでいます。

  • @timestamp: イベントが発生した時刻。
  • level: イベントの重大度（例：INFO、WARN、ERROR）。
  • component: メッセージを生成したElasticsearchの特定のクラスまたはサービス（例：o.e.c.c.ClusterService、o.e.n.Node）。これにより、責任のあるサブシステムを絞り込むのに役立ちます。
  • cluster.uuid: ログが属するクラスタを識別します。
  • node.name: ログを生成したノードを識別します。
  • message: イベントの説明。
{
  "@timestamp": "2024-01-15T10:30:00.123Z",
  "level": "WARN",
  "component": "o.e.c.r.a.DiskThresholdMonitor",
  "cluster.uuid": "abcde12345",
  "node.name": "es-node-01",
  "message": "high disk watermark [90%] exceeded on [es-node-01]"
}

2. ログレベルによるトラブルシューティングの優先順位付け

levelフィールドを解釈することが、問題の優先順位を付けるための最も速い方法です。通常は、WARNおよびERRORメッセージに焦点を当てるようにログをフィルタリングする必要があります。

レベル 説明 処置の優先度
ERROR サービスの中断やデータ損失につながる重大な障害（例：ノードシャットダウン、主要なシャード障害）。 直ちに
WARN 監視が必要な潜在的な問題や状態（例：非推奨の設定、ディスク容量不足、回路遮断器の限界値への接近）。 高
INFO 一般的な運用メッセージ（例：ノード起動、インデックス作成、シャード割り当て完了）。 低/監視
DEBUG/TRACE 詳細な診断や開発時のみに使用される、非常に冗長なロギング。 該当なし (デバッグ中の場合を除く)

ベストプラクティス: 運用中のクラスタでロギングをDEBUGまたはTRACEに設定したままにしないでください。これによりディスク容量が急速に消費され、パフォーマンスのオーバーヘッドが発生する可能性があります。

3. ログを通じた一般的なシナリオのトラブルシューティング

Elasticsearchのログは、さまざまな種類の障害に対する直接的な指標を提供します。ここでは、異なるシナリオで注意すべき重要なログパターンをいくつか紹介します。

3.1. クラスタの起動と健全性の問題

ノードがクラスタに参加できない場合、またはクラスタが赤/黄色のままである場合は、起動シーケンス中に生成されたログを確認してください。

A. ブートストラップチェックの失敗

Elasticsearchは起動時に必須のブートストラップチェック（例：十分なメモリ、ファイルディスクリプタ、仮想メモリの確保）を実行します。これらが失敗すると、ノードは直ちにシャットダウンします。

ログパターン: bootstrap checks failedメッセージを探します。

[2024-01-15T10:00:00,123][ERROR][o.e.b.BootstrapCheck$Bootstrap] [es-node-01] bootstrap checks failed
[2024-01-15T10:00:00,124][ERROR][o.e.b.BootstrapCheck$Bootstrap] [es-node-01] max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]

B. ネットワークバインディングとディスカバリの失敗

ノードが必要なポートにバインドできない、または他のクラスタメンバーを見つけられない問題。

ログパターン: BindExceptionまたはDiscovery failureを探します。

3.2. リソース管理（メモリとJVM）

メモリ関連の問題は、断続的なパフォーマンスの低下やノードの不安定性として現れることがよくあります。ログはJVMの健全性を追跡するために不可欠です。

A. 回路遮断器の例外

回路遮断器は、設定されたメモリ制限を超える操作を停止することにより、リソースの枯渇を防ぎます。これが作動すると、操作はすぐに失敗しますが、ノードは安定した状態を保ちます。

ログパターン: CircuitBreakerExceptionまたはData too largeを検索します。

[2024-01-15T11:45:20,500][WARN][o.e.c.c.CircuitBreakerService] [es-node-02] \nCircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [123456789b], which is larger than the limit of [100.0/500mb]

B. JVMガベージコレクション（GC）の問題

詳細なGCログは別になることが多いですが、メインのElasticsearchログには、高いGCアクティビティや長いGCポーズ（ストップ・ザ・ワールドイベント）が報告されることがあります。

ログパターン: 長いポーズに関するWARNまたはERRORメッセージが表示される場合は、GCの参照を探します。

3.3. インデックス作成とシャードの失敗

インデックス作成の失敗やデータの破損は、シャード障害イベントを引き起こすことがよくあります。

A. シャードの割り当てと失敗

シャードの割り当てに失敗した場合、またはノードがローカルシャードコピーの破損を検出した場合、それがログに記録されます。

ログパターン: shard failedまたはfailed to recoveryを検索します。

[2024-01-15T12:05:10,999][ERROR][o.e.i.e.Engine] [es-node-03] [my_index][2] fatal error in engine loop
java.io.IOException: Corrupt index files, checksum mismatch

B. ディスクウォーターマーク

Elasticsearchはディスク容量を監視し、特定のウォーターマークに達すると書き込みを防止します。これにより、インデックス作成の失敗を引き起こす可能性があります。

ログパターン: DiskThresholdMonitorの警告を探します。これらは通常、85%（low）または90%（high）の使用率を示します。

4. スローログによるパフォーマンスチューニング

パフォーマンス分析、特に遅いクエリやインデックス作成操作の場合、メインのクラスタログだけでは不十分なことがよくあります。Elasticsearchは専用のスローログを利用します。

スローログは、定義された時間閾値を超える操作を追跡します。これらは、elasticsearch.ymlでの静的設定、またはインデックス設定APIを介した動的設定によって明示的に設定する必要があります。

動的なスローログの閾値の設定

インデックス作成フェーズと検索フェーズで異なる閾値を設定できます。次の例では、特定のインデックスに対する検索クエリのWARN閾値を1秒に設定しています。

PUT /my_index/_settings
{
  "index.search.slowlog.threshold.query.warn": "1s",
  "index.search.slowlog.threshold.query.info": "500ms",
  "index.indexing.slowlog.threshold.index.warn": "1s"
}

スローログエントリの解釈

スローログは、クエリの実行に関する詳細情報（特定のインデックス/シャード、かかった時間、クエリの内容そのもの）を提供します。これにより、ユーザーは非効率なクエリや複雑な集計を特定できます。

探すべき主要なメトリクス:

  • took: 操作にかかった合計時間。
  • source: クエリまたはインデックス操作の完全なテキスト。
  • id: 検索コンテキストID。

5. ログ分析のベストプラクティス

効果的なトラブルシューティングは、どこを見るべきかを知るだけでなく、体系的なアプローチを必要とします。

A. ログを一元化する

分散環境では、多数のノードのログを手動で精査するのは非現実的です。Logstash、Filebeat、または専用のロギングサービスなどの一元化されたロギングツールを使用して、ログを単一のElasticsearchインデックス（しばしば「ロギングクラスタ」と呼ばれる）に集約します。これにより、すべてのノードのイベントを同時に検索、フィルタリング、関連付けることができます。

B. ノード間でイベントを関連付ける

@timestampフィールドとcluster.uuidフィールドを使用して、関連するイベントを探します。node-Aでシャードが失敗した場合、そのノードではERRORとして記録されるかもしれませんが、node-Bで実行されているクラスタマネージャは、その後のシャードの再割り当ての試みについてINFOまたはWARNを記録します。

C. 反復的なパターンに注意する

同じ警告やエラーメッセージが急速に繰り返されている（「ログストーム」）場合、これはリソースを大量に消費する継続的な障害ループを示していることがよくあります。例えば、利用できないポートへのバインドを繰り返し試みるプロセスや、持続的な過負荷による継続的な回路遮断器の作動などです。これらのパターンは直ちな調査を必要とします。

D. WARNメッセージを無視しない

警告は、将来の壊滅的な障害の早期指標となることがよくあります。例えば、非推奨の設定やメモリ使用量の低さに関するWARNメッセージが繰り返し表示された場合は、ERRORレベルの障害にエスカレートする前に、積極的に対処する必要があります。

結論

Elasticsearchのログは非常に貴重なリソースであり、症状に対する一時的な修正を超えて、クラスタの不安定性やパフォーマンス低下の根本原因を診断するために必要な本質的なコンテキストを提供します。標準的なログ構造を理解し、重大度に基づいてメッセージの優先順位を付け、パフォーマンスチューニングのためにスローログを具体的に活用することにより、管理者はダウンタイムを大幅に削減し、堅牢なクラスタ健全性を維持することができます。