効果的なトラブルシューティングのためのElasticsearchログ分析
Elasticsearchのログ分析を使用して、クラスタの健全性、ディスク、メモリ、シャードリカバリ、スロークエリの問題をより迅速に診断します。
効果的なトラブルシューティングのための一般的なElasticsearchログ分析
Elasticsearchのログ分析は、通常、赤いクラスタ、失敗したインデックスリクエスト、または遅い検索の苦情を説明する最も速い方法です。クラスタに複数のノードがある場合、ログはどのノードが最初の障害を確認したか、どのコンポーネントが反応したか、問題がディスク、メモリ、ディスカバリ、セキュリティ、またはシャードリカバリのいずれであるかを示します。
このガイドでは、ノイズを追いかけずにElasticsearchログを読む方法を示します。ログが通常どこにあるか、どのフィールドが重要か、一般的な障害メッセージの意味、およびメインサーバーログからスローログや割り当てAPIに切り替えるタイミングを学びます。
Elasticsearchログ構造の理解
Elasticsearchはログ記録にLog4j 2を使用します。パッケージインストールでは、通常/var/log/elasticsearch/の下にログファイルを書き込みます。コンテナ化されたデプロイメントでは、多くの場合、コンテナランタイムまたはログエージェントが収集する標準出力にログを送信します。バージョンとlog4j2.propertiesによっては、プレーンテキストログ、JSONログ、またはその両方が表示される場合があります。
| インストールタイプ | 一般的なログパス |
|---|---|
| RPM/DEB Linuxパッケージ | /var/log/elasticsearch/ |
| Docker | コンテナ標準出力 |
| ZIPまたはtarball | $ES_HOME/logs/ |
一般的なファイルには、メインサーバーログ、非推奨ログ、スローログ、およびセキュリティ監査が有効な場合は監査ログが含まれます。
JSONログエントリには通常、次のようなフィールドが含まれます。
@timestamp: イベントが発生した時刻。level:INFO、WARN、ERRORなどの重大度。component: メッセージをログに記録したElasticsearchクラスまたはサブシステム。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]"
}
ログレベルによるメッセージの優先順位付け
最初にWARNとERRORをフィルタリングし、次に同じタイムスタンプの周辺で検索を広げます。最初のERRORの前の行は、最終的なスタックトレースよりも原因を説明していることがよくあります。
| レベル | 通常の意味 | 最初のアクション |
|---|---|---|
ERROR |
リクエスト、シャード、ノード、またはサブシステムが失敗しました。 | すぐに調査します。 |
WARN |
Elasticsearchがリスクのある状態を検出しました。 | 障害になる前に確認します。 |
INFO |
通常のライフサイクルアクティビティ。 | 警告とエラーのコンテキストに使用します。 |
DEBUG / TRACE |
詳細な診断情報。 | 必要な場合にのみ一時的に有効にします。 |
本番ノードをDEBUGまたはTRACEのままにしないでください。詳細なログ記録はディスクをすぐに消費し、回避可能なオーバーヘッドを追加する可能性があります。
一般的なログパターンのトラブルシューティング
Elasticsearchログが1つの明確な文で「根本原因はXです」と述べることはほとんどありません。パターンを探します：最初の警告、コンポーネント名、影響を受けるインデックスまたはシャード、およびそれに続く繰り返しメッセージ。
ブートストラップチェックの失敗
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]
ホスト設定を修正し、ノードを再起動し、起動ログがノードがクラスタに参加するポイントに達することを確認します。
ネットワークバインディングとディスカバリの失敗
ノードが起動してもクラスタに参加しない場合は、BindException、master not discovered、discovery、cluster.initial_master_nodesを検索します。BindExceptionは通常、アドレスまたはポートの競合を示します。ディスカバリメッセージは、多くの場合、不正なシードホスト、ブロックされたトランスポートポート9300、クラスタ名の不一致、またはノードが相互に信頼するのを妨げるセキュリティ設定を指します。
サーキットブレーカ例外
サーキットブレーカは、メモリを過剰に使用するリクエストを停止します。失敗したリクエストはエラーを返しますが、ノードは稼働し続けるはずです。
CircuitBreakingExceptionまたはData too largeを検索します：
[2024-01-15T11:45:20,500][WARN][o.e.c.c.CircuitBreakerService] [es-node-02]
CircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [123456789b], which is larger than the limit of [500mb]
一般的な原因には、大規模な集計、多くのフィールドを返すリクエスト、大量のバルクインデックス、またはテキストフィールドにロードされたフィールドデータが含まれます。リクエストパターンを特定し、リクエストサイズを減らし、マッピングを修正するか、容量を追加します。
ガベージコレクションの警告
メインのElasticsearchログは、長いJVMガベージコレクションの一時停止を報告する場合があります。gc、JvmGcMonitorService、overheadを検索します。負荷スパイク中のいくつかの警告は正常な場合があります。検索レイテンシの上昇と組み合わされた繰り返しの警告は、通常、ヒープが圧力下にあることを意味します。
シャードリカバリと破損
シャードの割り当てに失敗した場合、またはノードが不良なローカルシャードコピーを検出した場合、Elasticsearchはインデックスとシャード番号をログに記録します。
shard failed、failed shard、failed to recover、または影響を受けるインデックス名を検索します：
[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
メッセージが破損に言及している場合は、手動でファイルを削除しないでください。ログを保存し、有効なレプリカが存在するかどうかを確認し、データパスを直接編集するのではなく、ElasticsearchのリカバリツールとAPIを使用します。
ディスクウォーターマーク
Elasticsearchは、ノードがディスクウォーターマークを超えたときにシャード割り当て動作を変更します。DiskThresholdMonitor、low disk watermark、high disk watermark、またはflood-stage disk watermarkを検索します。デフォルトはバージョンと構成によって異なる場合があるため、行動する前にクラスタ設定を確認します：
GET /_cluster/settings?include_defaults=true&filter_path=**.disk.watermark*
フラッドステージイベント後にインデックスが読み取り専用になった場合は、最初にディスク容量を解放します。次に、ノードがウォーターマークを安全に下回った後にのみブロックを削除します：
PUT /my-index/_settings
{
"index.blocks.read_only_allow_delete": null
}
パフォーマンス問題へのスローログの使用
遅い検索やインデックス操作の場合、メインサーバーログは広すぎることがよくあります。スローログは、構成されたしきい値を超える操作を追跡します。インデックス設定APIを使用して、インデックスごとに構成します。
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"
}
スローログは、構成に含まれている場合、インデックス、シャード、経過時間、およびリクエストソースを示します。これらを使用して、繰り返される高コストのクエリ、広い日付範囲、ワイルドカードが多い検索、および効率的な集計のためにマッピングされていないフィールドの集計を特定します。
実践的なレビューワークフロー
ユーザーから見える症状から始めて、逆方向に作業します：
- クラスタの健全性と影響を受けるインデックスを確認します。
- インシデント時刻の前後の
WARNおよびERRORログを検索します。 node.nameとcluster.uuidを使用してノード間でログを比較します。- 最終的な例外だけでなく、最初の繰り返し警告に従います。
- 次に、対象を絞ったAPIを使用します：未割り当てシャードの場合は割り当て説明、遅いリクエストの場合はスローログ、リソースプレッシャーの場合はノード統計。
たとえば、Kibanaが赤いインデックスを表示している場合、最初に未割り当てのシャードを見つけ、次にそのインデックスとシャード番号のログを検索します。ログがディスクウォーターマークに言及している場合は、再ルーティングする前にディスクプレッシャーを修正します。ノードが見つからないと記載されている場合は、リスクの高い割り当てコマンドを検討する前に、そのノードをリカバリするか、スナップショットから復元します。
まとめ
すべてのElasticsearchインシデントは、最も大きな最終的なスタックトレースではなく、最初の関連する警告またはエラーを見つけることから始めます。ノード、ディスカバリ、ディスク、メモリ、およびシャードの障害にはメインログを使用します。クラスタは正常であるが、特定の検索またはインデックスワークロードが遅い場合はスローログを使用します。