ElasticsearchのStack MonitoringはElastic Stack（Elastic社が提供するElasticsearch、Kibana、Beas、 Logstash）を監視するための機能です。
監視対象となるElasticsearchのデプロイメントのログを監視用Elasticsearchのデプロイメントに送信することで、監視用デプロイメントのKibanaのStack monitoringから性能を監視することができるようになります。

今回はElasticsearch部分に限定して、Stack Monitoring画面にあるグラフでどのようなことが確認できるのかをまとめました。
以下のような形式でまとめています

• グラフのタイトル
  • 解説

Elasticsearchクラスターの全体的な健全性を示すメトリクスが表示されています。

• Search Rate(/s)
  • Search Rate(/s)は1秒あたりの検索リクエストの数を示しています。
    凡例のTotal Shardsは、プライマリシャードとレプリカシャードで実行されている検索リクエスト数を返しており、1つの検索リクエストは複数のシャードに対して実行される場合があるため注意が必要です。
    Search Rateの値が高いと、リソースの使用率上昇、レスポンスタイムの増加、スロットリングやリクエストの拒否などが発生し、システムに影響を与える可能性があります。
    
    
• Search Latency(ms)
  • Search Latency(ms)は検索の平均待ち時間を表示しています。
    凡例のSearch Latencyは全ての検索リクエストの実行にかかる時間を検索実行にかかる時間を送信された検索数で割った値で、プライマリシャードとレプリカシャード両方が考慮されています。
    Search Latencyの値が高いということは、ユーザーが検索結果を得るために長い時間がかかっているという事であり、システムのパフォーマンスが低下しているということになります。
    
    
• Indexing Rate(/s)
  • Indexing Rate(/s)は1秒あたりのインデックス操作の数を示しています。
    凡例のPrimary Shardsはプライマリシャードとレプリカシャードでインデックスされたドキュメントの数を、Primary Shardsはプライマリシャードでインデックスされたドキュメントの数を示しています。
    インデックスされるドキュメントの数が高いと、システムはより多くのデータを迅速に処理しているということになりますが、それと同時にシステムのリソースの使用率も上昇するため注意が必要です。
    
    
• Indexing Latency(ms)
  • Indexing Latency(ms)はインデックス操作の平均待ち時間を示しています。
    凡例のIndexing Latencyはドキュメントをインデックスする時間をインデックスされるドキュメントの数で割った値で、プライマリシャードのみ考慮しています。
    Indexing Latencyの値が高いということは、新たなデータが検索可能になるまでの時間が長くなってしまうという事であり、システムのパフォーマンスが低下しているということになります。

ここではノードごとのパフォーマンスが表示されています。

• JVM Heap(GB)
  • JVM HeapはElasitcsearchが使用しているメモリの状況を表示しています。
    凡例のMax HeapはElasitcsearch がJVMで利用可能なヒープメモリの量を、Used Heapは現在利用しているヒープメモリの量を示しています。
    Used Heapの値がMax Heapの値に近づくと、メモリ不足によるパフォーマンス低下やエラーが発生する場合があります。
    
    
• I/O Operations Rate(/s)
  • I/O Operations Rate(/s)は1秒あたりにElasticsearchがどれだけ入出力操作（I/O操作）を行っているかを表示しています。
    凡例のTokal I/Oはすべての入出力操作の件数を、Total Read I/Oは全ての読み取り操作の件数を、Total Write I/Oは全ての書き込み操作の件数を示しています。
    I/O Operations Rateの値が高いということは、システムのI/O性能が高いということではありますが、ストレージデバイスに対しての負荷が高いという事にもなります。
    
    
• CPU Utilization(%)
  • CPI Utilization(%)はElasticsearchがどれだけCPUリソースを使用しているかを表示しています。
    凡例のCPU UtilizationはCPUの使用時間をCPUクォータと比較した値を%で表示しており、もしCPUクォータが設定されていない場合はこのデータは表示されません。
    CPU utilizationの値が高いということはCPIリソースを多く使用しているということであるため、他のプロセスやアプリケーションのパフォーマンスに対して影響を与える可能性があります。
    
    
• System Load
  • System LoadはElasticsearchが動作しているシステムの負荷状況を表示しています。
    凡例の1mは、過去1分間の平均ロードを示しています。ロードとは実行待ち状態にあるプロセスやタスクのことを指しています。
    System Loadの値が高いと、システムが過負荷状態になっている可能性があります。
    
    
• Latency(ms)
  • Latency(ms)はElasticsearchの検索とインデックス操作の平均待ち時間を表示しています。
    凡例のSearchはElasticsearch OverviewのSearch Latency(ms)と同じように計算された値であり、IndexingもElasticsearch OverviewのIndexing Latency(ms)と同じように計算された値です。
    検索やインデックス操作の待ち時間が長いと、システムのパフォーマンスが低下している可能性があります。
    
    
• Segment Count
  • Segment Countはプライマリシャードとレプリカシャードの最大セグメント数を示しています。
    Elasitcsearchでは、インデックスは複数のシャードに分割され、さらにその書くシャードは複数のセグメントに分割されます。
    セグメントは一度書き込まれると変更されず、新しいデータがインデックスに追加されると、新しいセグメントが作成されます。定期的に既存のセグメントが結合されて大きなセグメントが作成され、この流れをセグメントマージと呼びます。
    Segment Countの値が大きいと、Elasticsearchのセグメントマージの頻度が上がり、それによってCPUやディスクI/Oの負荷が増加し、それによって検索やインデックス操作などのパフォーマンスに影響を与える可能性があります。

• GC Rate
  • GC RateはGCの回数を表示しています。
    凡例のYoungとOldはそれぞれ若い世代のGCと古い時代のGCの回数を指しています。
    GCとはJavaで不要になったメモリを自動的に解放するプロセスのことです。
    若い世代のGCは通常高速であるため、アプリケーションのパフォーマンスには大きな影響は与えませんが、古い世代のGCは実行に時間がかかるため、古い世代のGCは頻繁に発生するとパフォーマンスに影響を与える可能性があります。
    GC Rateはメモリ管理のパフォーマンスのメトリクスであるため、この値が高いとElasitcsearchでパフォーマンスが低下している可能性があります。
    
    
• GC Duration(ms)
  • GC Duration(ms)はGC実行に費やされた時間を示しています。
    凡例のYoungとOldはそれぞれ若い世代のGCと古い時代のGCで費やされた時間を指しています。
    GC Durationはメモリ管理のパフォーマンスのメトリクスであるため、この値が高いと、Elasticsearchのパフォーマンスが低下している可能性があります。
    
    
• JVM Heap(GB
  • JVM HeapはElasitcsearchが使用しているメモリの状況を表示しています。
    Elasticsearch nodes->OverviewのJVM Heap(GB)と同じものです。
    
    
• CPU Utilization(%)
  • CPI Utilization(%)はElasticsearchがどれだけCPUリソースを使用しているかを表示しています。
    Elasticsearch nodes->OverviewのCPU Utilizationと同じものです。
    
    
• Index Memory - Lucene(KB)
  • Index Memory - Lucene(KB)はElasticsearchのインデックス操作のメモリ使用量を示すメトリクスです。
    凡例のFixed BitsetsはFixed Bit Setsによって使用されるヒープメモリを、Version Mapはバージョニングによって使用されるヒープメモリを指しています。
    Fix Bit Setsは、Luceneがネストされたドキュメントの検索を最適化するために利用しているデータ構造で、特定のドキュメントが特定のクエリにマッチするかどうかを高速に判断するための物です。
    バージョニングは、ドキュメントの更新と削除を管理するために利用されるもので、各ドキュメントの現在のバージョンを追跡するためのVersion Mapというデータ構造が使われています。
    Index Memory - Luceneの値が高いとメモリ不足によるパフォーマンスに影響を与える可能性があります。
    
    
• Index Memory - Elasticsearch(MB)
  • Index Memory - Elasticsearch(MB)はインデックス操作のメモリ使用量を示すメトリクスです。
    凡例のQuery Cache、Request Cache、Fielddata、Index Writerはそれぞれ以下の場合に使用されるヒープメモリを指しています。
    • Query Cache：Elasticsearchが同じクエリが再実行された時に高速な応答を行うためにクエリ結果をキャッシュする
    • Request Cache：Elasticsearchが同じ検索リクエストが再実行された時に高速な応答を提供するためにクエリ結果をキャッシュする
    • Fielddata：Elasticsearchがテキストフィールドのソートや主計を行うためにfielddataという構造を使用する
    • Index Writer：Elasticsearchが新しいドキュメントをインデックスするためにIndex Writerというコンポーネントを使用する
    • Index Memory - Elasticsearch(MB)の値が高いとメモリ不足によるパフォーマンスに影響を与える可能性があります。

• Indexing Time(ms)
  • Indexing Time(ms)はインデックス操作の時間に関して表示しています。
    凡例のIndex Timeはインデックス操作に費やされた時間、Index Throtling Timeはインデックスのスロットリングに費やされた時間を表示しています。
    Indexing Time(ms)の値が高い場合、Elasitcsearchのパフォーマンスが低下している可能性があります。
    
    
• Request Rate
  • Request Rateはリクエストの数を示しています。
    凡例のSearch Totalはシャードごとにカウントした検索操作の数を、Indexing Totalはインデックス操作の数を指しています。
    
    
• Indexing Threads
  • Indexing ThreadsはElasticsearchの書き込み操作とその処理能力を示しています。
    凡例のWrite Queueはキュー内のインデックス、バルク、及び書き込み操作の数を、Write Rejectionはキューが満杯の時に拒否されたインデックス、バルク、及び書き込み操作の数を指しています。
    Write Queueの値が高い場合はElasticsearchが大量の書き込み操作をしていること、Write Rejectionsの値が高い場合にはElasticsearchが大量の書き込み操作を処理できずに拒否していることが分かります。
    キューが頻繁に満杯になると、新しい操作が拒否され、システムのパフォーマンスに影響を与える可能性があります。
    
    
• Read Threads
  • Read ThreadsはElasticsearchの読み込み操作（検索とGET）とその処理能力を示しています。
    凡例のSearch Queueはキュー内の検索操作の数、Search Rejectionsはキューが満杯の時に拒否された検索操作の数、GET Queueはキュー内のGET操作の数、GET Rejectionsはキューが満杯の時に拒否されたGET操作の数を表示しています。
    キューが頻繁に満杯になると、新しい操作が拒否され、システムのパフォーマンスに影響を与える可能性があります。
    
    
• Cgroup CPU Performance(ns)
  • Cgroup CPU Performance(ns)は、Linuxのcgroupという機能を用いて、特定のプロセスグループのCPU使用状況を監視するためのメトリクスです。ここでのcgroupは、CPUを特定のプロセスグループに割り当てるための物です。
    凡例のCgroup Usageはcgoupがどれだけの時間CPUを使用しているのか、Cgroup Throttlingはcgoupが割り当てられたCPU時間を超えて使用しようとした時の時間をナノ秒単位でレポートします。
    Cgroup Throttlingが高いとCPUリソースが不足している可能性があります。
    
    
• Cgroup CFS Stats
  • Cgroup CFS StatsはLinuxのcgoupとCFSという機能を用いて特定のプロセスグループのCPUスケジューリング状況を監視するためのメトリクスです。
    凡例のCgroup Elapsed Periodsは、CFSがプロセスをスケジューリングするための期間の数を示し、Cgroup Throttled CountはcgourpによってCPUがスロットリングされた回数を示しています。
    スロットリングはcgoupが割り当てられたCPU時間を超えて使用しようとしたときに発生するものであり、この値が高いとCPUリソースが不足している可能性があります。
    
    
• Latency(ms)
  • Latency(ms)はElasticsearchの検索とインデックス操作の平均待ち時間を表示しています。
    Elasticsearch nodes->OverviewのLatency(ms)と同じものです。

ElasticsearchのStack Monitoring画面にあるElasticsearch OverviewやElasticsearch nodesのグラフからどのようなことが読み取れるかをまとめてみました。
今回の調査を生かして今後の運用で「こんな障害が起きる時にはこのグラフの値が高くなる！」などを見つけていきたいと思います。
読んでいただきありがとうございました。

（石川）