本文の内容は、2023年5月5日にJAVIER MARTÍNEZ が投稿したブログ（https://sysdig.com/blog/elasticsearch-monitoring）を元に日本語に翻訳・再構成した内容となっております。
Elasticsearchのモニタリングの旅は、その挙動を正しく可視化し、透明性を得るために重要です。
Elasticsearch は最も利用されている検索・分析エンジンです。スケーラビリティと冗長性の両方を備え、高可用性もある、検索を提供します。2023年現在、あらゆる規模や背景を持つ6万社以上の企業が、分析、ロギング、ビジネス情報のような多様なデータを追跡するための検索ソリューションとして使用しています。
Elastic searchは、データをJSONドキュメントで配布し、そのデータを複数のシャードにインデックスすることで、高可用性、高速検索、冗長性の機能を提供します。
この記事では、Elasticsearchエクスポーターが提供する最も重要なPrometheusのメトリクスを評価します。
Elasticsearchシステムを監視する際に、どのような点に着目すべきかを学ぶことができます：
- PrometheusでElasticsearchの監視を始める方法
- Elasticsearch で Golden Signals を監視する方法
- インフラメトリクスを監視する方法
- インデックスパフォーマンスを監視する方法
- 検索パフォーマンスを監視する方法
- クラスターのパフォーマンスを監視する方法
- 高度な監視と次のステップ
PrometheusでElasticSearchの監視を始める方法
いつものように、Elasticsearchを使ったPrometheusモニタリングの旅を始める最も簡単な方法は、PromCat.ioを使って最適な設定、ダッシュボード、およびアラートを見つけることです。PromcatのElasticsearchセットアップガイドには、Prometheusに自動的にスクレイプされる一連のアウトオブボックスメトリクスを持つElasticsearchエクスポーターが含まれています。また、Elasticsearchの監視をすぐに開始できるように、キュレーションされたアラートとダッシュボードのコレクションが含まれています。
これらのメトリクスをNode Exporterと組み合わせることで、インフラストラクチャーに対するより多くのインサイトを得ることができます。また、Kubernetes上でElasticsearchを運用している場合、KSMやCAdvisorを使ってKubernetesのメトリクスとElasticsearchのメトリクスを組み合わせることができます。
Elasticsearch で Golden Signals を監視する方法
重要なメトリクスを最低限確認するために、いわゆるゴールデンシグナルのチェックを忘れないようにしましょう：
- エラー
- トラフィック
- サチュレーション
- レイテンシー
これらは、ブラックボックス・モニタリング（システムで何が起きているのかにのみ焦点を当て、なぜ起きているのかは考えない）を行うために、システムで探すべき必須メトリクスをまとめたものです。言い換えれば、ゴールデンシグナルは、現在の問題に対する解決策ではなく、症状を測定することになります。これは、Elasticsearchのモニタリングダッシュボードを作成するための良い出発点になるかもしれません。
エラー
elasticsearch_cluster_health_status
Elasticsearchにおけるクラスターの健全性は、以下のようにグリーン、イエロー、レッドの色で測定されます：
- グリーン： データの整合性が正しく、シャードが欠落していない。
- イエロー： 少なくとも1つのシャードが欠落しているが、レプリカによりデータの整合性は保たれている。
- レッド： プライマリシャードが欠落または未割り当てで、データ損失が発生しています。
elasticsearch_cluster_health_status を使えば、特定のクラスター上の Elasticsearch データの現状を素早く確認することができます。データの整合性が失われた実際の原因を調べることはできませんが、さらなる問題を防ぐために行動する必要があることだけは覚えておいてください。
トラフィック
elasticsearch_indices_search_query_total
このメトリクスは、検索クエリーの総実行回数を表すカウンターで、これだけでは数値としてあまり情報を得ることはできません。
トラフィックの急激な変化や急増を検出するために、 rate() や irate() を使用することも検討してみてください。Prometheusのクエリーについては、PromQL入門ガイドで詳しく解説しています。
サチュレーション
詳細なサチュレーション解析については、「Elasticsearchのインフラメトリクスを監視する方法」の項をご確認ください。
レイテンシー
詳細なレイテンシー分析については、「Elasticsearchのインデックスパフォーマンスを監視する方法」の項をご確認ください。
Elasticsearch のインフラメトリクスを監視する方法
インフラストラクチャー・モニタリングは、システムのサーバーやノードの全体的なパフォーマンスを追跡することに焦点を当てています。同様のクラウドアプリケーションと同様に、ほとんどの労力は CPU と Memory の消費量の監視に費やされることになります。
Elasticsearch の CPU を監視する
elasticsearch_process_cpu_percent
これは、Elasticsearchプロセスの現在のCPU使用率パーセント（0-100）を測定するために使用されるゲージメトリクスです。複数のElasticsearchノードを運用している可能性が高いので、それぞれを個別に追跡する必要があります。
elasticsearch_indices_store_throttle_time_seconds_total
インデックスストアとしてファイルシステムを使用している場合、入出力操作に一定レベルの遅延が発生することが予想されます。このメトリクスは、Elasticsearchのインデックスストアがどの程度スロットルされているかを表しています。
これは合計秒数しか集計されないカウンターメトリクスなので、どれくらい突然変化しているかの評価には rate や irate を使うことを検討してください。
Elasticsearch JVMメモリの監視
Elasticsearch は、Java で構築された Lucene をベースにしています。つまり、Java Virtual Machine (JVM) のメモリを監視することは、システム全体の現在の使用状況を把握するために非常に重要です。
elasticsearch_jvm_memory_used_bytes
このメトリクスは、各領域のメモリ使用量をバイト単位で表すゲージです。
Elasticsearchのインデックスパフォーマンスを監視する方法
ElasticSearch のインデックスは、データを論理的な名前空間として分割します。Elasticsearch は、ドキュメントをできるだけ速く検索するためにインデックスを作成します。
新しいインデックスが作成されるたびに、そのインデックスのシャード数とレプリカ数を定義することができます：
{
"settings": {
"number_of_shards": 1,
"number_of_replicas": 1
}
}Code language: JSON / JSON with Comments (json)
elasticsearch_indices_indexing_index_time_seconds_total
このメトリクスは、インデックス作成に費やした累積秒数のカウンターです。このメトリクスは Elasticsearch のインデックス作成性能の非常におおよその見当をつけることができます。
このメトリクスを elasticsearch_indices_indexing_total で割ると、オペレーションごとの平均インデックス作成時間が得られます。
elasticsearch_indices_refresh_time_seconds_total
インデックスが検索可能になるためには、Elasticsearchはリフレッシュを実行する必要があります。これは index.refresh_interval という設定項目で設定され、デフォルトでは 1 分に設定されています。
このメトリクス elasticsearch_indices_refresh_time_seconds_total は、Elasticsearch のリフレッシュに費やされた総時間を示すカウンターです。
平均的なリフレッシュ時間を測定したい場合は、このメトリクスをelasticsearch_indices_refresh_totalで割るとよいでしょう。
Elasticsearchの検索パフォーマンスを監視する方法
Elasticsearch はほぼ瞬時のクエリー速度を約束しますが、現実の世界ではそうでないと感じることがあるかもしれません。シャードの数、選択したストレージソリューション、キャッシュの構成が検索パフォーマンスに影響を与える可能性があり、現在の動作がどうなっているかを追跡することが重要です。
さらに、ワイルドカード、結合、検索されるフィールドの数は、検索クエリーの全体的な処理時間に大きく影響します。
elasticsearch_indices_search_fetch_time_seconds
検索結果のフェッチに費やされた秒数の合計を集約したカウンターメトリクスです。
オペレーションごとの平均フェッチ時間を取得したい場合は、結果を elasticsearch_indices_search_fetch_totalで割るだけです。
Elasticsearch クラスターのパフォーマンスを監視する方法
通常のクラウド要件とは別に、Elasticsearchのシステムを見ておきましょう：
- シャードの数
- レプリカの数
目安としては、シャード数とヒープ領域のGBの比率は20以下であるべきです。
監視専用の別のクラスターを持つことが推奨されています。
elasticsearch_cluster_health_active_shards
このメトリクスは、すべてのクラスターからアクティブなシャード（プライマリとレプリカの両方）の数を示すゲージです。
elasticsearch_cluster_health_relocating_shards
Elasticsearch は、バランシングや現在の使用状況に基づいて、ノード間でシャードを動的に移動させます。このメトリクスを使うと、この移動がいつ行われるかをコントロールすることができます。
高度な監視
Prometheusエクスポーターは、モニタリングの旅を始めるのに十分な関連性のある、アウトオブボックスのメトリクスセットを提供してくれることを覚えておいてください。しかし、本当の挑戦は、アプリケーションに合わせた独自のカスタムメトリクスを作成するステップを踏んだときにやってきます。
REST API
さらに、ElasticsearchはREST APIを提供しており、よりきめ細かい監視を行うために問い合わせることができます。
VisualVM
Java VisualVMプロジェクトは、MemoryとCPUを監視するための高度なダッシュボードです。プロセスやスレッドの利用状況だけでなく、高度なリソースの視覚化も特徴です。
ダッシュボードをダウンロードする
本記事で見たメトリクスを含むダッシュボードは、Promcatの公式ページからダウンロードできます。
以上、GrafanaやSysdig Monitorのソリューションに簡単に統合できるメトリクスを厳選してご紹介しました。
まとめ
Elasticsearchは、高可用性、高スケーラビリティ、冗長性による分散機能を特徴とする、最も重要な検索エンジンの1つです。
PrometheusのElasticsearchエクスポーターを使用すると、重要なメトリクスを自動的に直接受け取ることができ、簡単にモニタリングの旅を始めることができます。
他の多くのアプリケーションと同様に、システムのサチュレーションを理解するためには、CPU、およびメモリが重要です。現在のCPUスロットリングとJVMのメモリ処理について認識しておく必要があります。
最後に、監視と可視化の課題を真に理解するためには、インデックスや検索機能といったElasticsearchの特殊性を深く掘り下げることが重要です。
Sysdig Monitorを使って、Elasticsearchのリソースをワンクリックで監視
ワンクリックでキュレーションされたダッシュボードやメトリックスを入手しましょう！