Alibaba Cloud Elasticsearch は、クラスターのヘルスステータス、クエリ QPS、ノードの CPU 使用率、ディスク使用率など、実行中のクラスターの基本的な監視メトリクスを提供します。モニタリング詳細の表示方法、各メトリクスの意味、一般的な異常、および推奨されるアクションについて説明します。
監視の違い
クラスターの監視メトリクスが Kibana やサードパーティ製のツールと異なる場合があるのは、以下の理由によります。
-
サンプリング期間の違い:クラスターのモニタリングは、Kibana や他のツールとは異なるサンプリング期間を使用しているため、データに差異が生じます。
-
クリアルゴリズムの違い:クラスターの不安定性は、クラスターのモニタリングと Kibana の両方のデータ収集に影響します。例えば、クラスターのジッターにより、QPS メトリクスにスパイク、負の値、またはデータなしが表示されることがありますが、Kibana では同じ期間に空の値が表示されることがあります。
説明クラスターのモニタリングは、Kibana のモニタリングよりも多くのメトリクスを提供します。例えば、高度なモニタリングでは、各シャードのクエリ QPS、書き込み TPS、レイテンシーなどのシャードレベルのメトリクスを表示できますが、Kibana のモニタリングではクラスターレベルおよびノードレベルの集約メトリクスしか提供されません。モニタリング詳細を分析するには、クラスターのモニタリングと Kibana のモニタリングを併用してください。
-
データソースの違い:Kibana は Elasticsearch API からメトリクスを取得します。クラスターのモニタリングは、CPU 使用率、
load_1m、ディスク使用率などの一部のノードレベルのメトリクスを、基盤となるシステムインターフェイスから収集します。これらのメトリクスは、Elasticsearch プロセスだけでなく、システム全体のリソース使用量を反映します。
クラスターのモニタリング
Alibaba Cloud Elasticsearch コンソールにログインします。
左側のナビゲーションメニューで、Elasticsearch クラスターを選択します。
対象のクラスターに移動します。
上部のナビゲーションバーで、クラスターが属するリソースグループとクラスターが存在するリージョンを選択します。
Elasticsearch クラスターページで、対象のクラスターを見つけてその ID をクリックします。
-
左側のナビゲーションウィンドウで、を選択します。
-
モニタリング詳細を表示します。
-
基本的なモニタリングの詳細を表示
基本的なモニタリングタブで、グループ名と時間範囲を選択して、対応するモニタリング詳細を表示します。
説明-
カスタムをクリックして、カスタム時間範囲のモニタリング詳細を表示します。
-
モニタリングとアラート機能はデフォルトで有効になっています。クラスターモニタリングページで既存データを表示できます。データは 1 分の粒度で、30 日間保持されます。
-
基本的な監視メトリクスは、「基本的な監視メトリクスの概要」にリストされています。
-
-
基本的な監視メトリクス
次の表は、クラスターの基本的な監視メトリクスをリストしています。
実際の UI は異なる場合があります。
概要
|
メトリック名 |
説明 |
|
クラスターのヘルス状態を示します。値が |
|
|
自動バックアップ機能からのスナップショットのステータス。 値が |
|
|
クラスター内のノードの総数。 |
|
|
クラスター内の到達不能なノードの総数。 |
|
|
クラスター内のインデックスの数。 |
|
|
クラスター内のシャードの数。 |
|
|
クラスター内のプライマリシャードの数。 |
|
|
クラスター内のスロークエリの数。 |
|
|
1 秒あたりにクラスターに書き込まれるドキュメントの数。 |
|
|
クラスターの 1 秒あたりのクエリ数 (QPS)。値は、クエリ対象のインデックス内のプライマリシャードの数に依存します。 |
|
|
各ノードの CPU 使用率。 |
|
|
各ノードのヒープメモリ使用率。 |
|
|
各ノードのディスク使用率。ディスク使用率のアラートしきい値は |
|
|
各ノードの過去 |
|
|
各ノードのインバウンドデータレート。モニタリング期間:1 分。単位:KiB/秒。 |
|
|
各ノードのアウトバウンドデータレート。モニタリング期間:1 分。単位:KiB/秒。 |
|
|
各ノードのインバウンドネットワークパケット数。モニタリング期間:1 分。 |
|
|
各ノードからのアウトバウンドネットワークパケット数。モニタリング期間:1 分。 |
|
|
クライアントから各ノードへの TCP 接続数。 |
|
|
各ノードの I/O 使用率。 |
|
|
クラスター内の各ノードから 1 秒あたりに読み取られるデータ量。 |
|
|
クラスター内の各ノードに 1 秒あたりに書き込まれるデータ量。 |
|
|
クラスター内の各ノードで 1 秒あたりに完了した読み取りリクエストの数。 |
|
|
クラスター内の各ノードで 1 秒あたりに完了した書き込みリクエストの数。 |
クラスターメトリクス
|
メトリック名 |
説明 |
|
クラスターのヘルス状態を示します。値が |
|
|
クラスター内のノードの総数。 |
|
|
クラスター内の到達不能なノードの総数。 |
|
|
クラスター内のインデックスの数。 |
|
|
クラスター内のシャードの数。 |
|
|
クラスター内のプライマリシャードの数。 |
|
|
クラスター内のスロークエリの数。 |
|
|
|
|
|
自動バックアップ機能のスナップショットのステータス。値が |
|
|
1 秒あたりにクラスターに書き込まれるドキュメントの数。 |
|
|
クラスターの 1 秒あたりのクエリ数 (QPS)。値は、クエリ対象のインデックス内のプライマリシャードの数に依存します。 |
|
|
クラスター内の fielddata で使用されるヒープメモリ。使用量が多いと、fielddata サーキットブレーカーがトリガーされ、クラスターの安定性に影響を与える可能性があります。 |
インデックスメトリクス
|
メトリック名 |
説明 |
|
インデックスに対する 1 秒あたりの一括リクエスト数。 |
|
|
インデックスの 1 秒あたりのクエリ数 (QPS)。値は、クエリ対象のインデックス内のプライマリシャードの数に依存します。 |
|
|
インデックスの最大クエリリクエスト時間 (ミリ秒)。 |
ノードリソースメトリクス
|
メトリック名 |
説明 |
|
各ノードの CPU 使用率。CPU 使用率が高い、または 100% に近づくと、クラスターサービスに影響を与える可能性があります。 |
|
|
各ノードのヒープメモリ使用量。使用量が多い、またはラージオブジェクトがあると、パフォーマンスに影響を与え、自動 GC 操作をトリガーする可能性があります。 |
|
|
各ノードのディスク使用率。ディスク使用率のアラートしきい値は |
|
|
ノードのシステムメモリ使用量。 説明
このメトリックは、クラウドネイティブの新しいコントロールプレーン (v3) でのみサポートされています。 |
|
|
CPU が I/O 操作を待機している時間の割合。 説明
このメトリックは、クラウドネイティブの新しいコントロールプレーン (v3) でのみサポートされています。 |
|
|
各ノードの過去 |
|
|
ノード CPU 使用率_合計 (%) |
ノードの合計 CPU 使用率 (アイドル時間を除く)。これは、カーネルモード、ユーザーモード、および I/O 待機状態での CPU 使用率の合計です。 説明
このメトリックは、クラウドネイティブの新しいコントロールプレーン (v3) でのみサポートされています。 |
ノードネットワークメトリクス
|
メトリック名 |
説明 |
備考 |
|
クラスター内の各ノードのインバウンドデータレート。モニタリング期間:1 分。単位:KiB/秒。 |
N/A |
|
|
クラスター内の各ノードのアウトバウンドデータレート。モニタリング期間:1 分。単位:KiB/秒。 |
N/A |
|
|
ノードネットワーク帯域幅 (KiB/秒) = ノードネットワーク帯域幅_In (KiB/秒) + ノードネットワーク帯域幅_Out (KiB/秒)。 |
このメトリックは、クラウドネイティブの新しいコントロールプレーン (v3) でのみサポートされています。 |
|
|
ノードネットワーク帯域幅使用率 (%) = (ノードネットワーク帯域幅_入力 (KiB/秒) + ノードネットワーク帯域幅_出力 (KiB/秒)) / ノードネットワーク基本帯域幅 (Gbit/秒)。 |
このメトリックは、クラウドネイティブの新しいコントロールプレーン (v3) でのみサポートされています。 |
|
|
クライアントから各ノードへの TCP 接続数。 |
N/A |
|
|
ノードのネットワークパケット再送率。 |
このメトリックは、クラウドネイティブの新しいコントロールプレーン (v3) でのみサポートされています。 |
|
|
各ノードのインバウンドネットワークパケット数。モニタリング期間:1 分。 |
N/A |
|
|
各ノードからのアウトバウンドネットワークパケット数。モニタリング期間:1 分。 |
N/A |
|
|
ノードネットワークパケット (カウント) = ノードネットワークパケット_Out (カウント) + ノードネットワークパケット_In (カウント)。 |
このメトリックは、クラウドネイティブの新しいコントロールプレーン (v3) でのみサポートされています。 |
|
|
ノードネットワークパケット使用率 (%) = (ノードネットワークパケット_Out (カウント) + ノードネットワークパケット_In (カウント)) / ノードネットワークパケット送受信 PPS。 |
N/A |
ノードディスクメトリクス
|
メトリック名 |
説明 |
備考 |
|
クラスター内の各ノードから 1 秒あたりに読み取られるデータ量。 |
N/A |
|
|
クラスター内の各ノードに 1 秒あたりに書き込まれるデータ量。 |
N/A |
|
|
ディスク帯域幅 (MiB/秒) = ディスク帯域幅_読み取り (MiB/秒) + ディスク帯域幅_書き込み (MiB/秒)。 |
このメトリックは、クラウドネイティブの新しいコントロールプレーン (v3) でのみサポートされています。 |
|
|
ディスク帯域幅使用率_クラウドディスク (%) = (ディスク帯域幅_読み取り (MiB/秒) + ディスク帯域幅_書き込み (MiB/秒)) / ESSD の単一ディスクスループット (MiB/秒)。 |
このメトリックは、クラウドネイティブの新しいコントロールプレーン (v3) でのみサポートされています。ESSD の単一ディスクスループットについては、「ESSD」をご参照ください。 |
|
|
ディスク帯域幅使用率_ノード (%) = (ディスク帯域幅_読み取り (MiB/秒) + ディスク帯域幅_書き込み (MiB/秒)) / ノードの基本クラウドディスク帯域幅 (Gbit/秒)。 |
このメトリックは、クラウドネイティブの新しいコントロールプレーン (v3) でのみサポートされています。 |
|
|
各ノードの I/O 使用率。 |
N/A |
|
|
クラスター内の各ノードで 1 秒あたりに完了した読み取りリクエストの数。 |
N/A |
|
|
クラスター内の各ノードで 1 秒あたりに完了した書き込みリクエストの数。 |
N/A |
|
|
ディスク IOPS (カウント) = ディスク IOPS_読み取り (カウント) + ディスク IOPS_書き込み (カウント)。 |
このメトリックは、クラウドネイティブの新しいコントロールプレーン (v3) でのみサポートされています。 |
|
|
ディスク IOPS 使用率_クラウドディスク (%) = (ディスク IOPS_読み取り (カウント) + ディスク IOPS_書き込み (カウント)) / ESSD の単一ディスク IOPS。 |
このメトリックは、クラウドネイティブの新しいコントロールプレーン (v3) でのみサポートされています。ESSD の単一ディスクスループットについては、「ESSD」をご参照ください。 |
|
|
ディスク IOPS 使用率_ノード (%) = (ディスク IOPS_読み取り (カウント) + ディスク IOPS_書き込み (カウント)) / ノードの基本クラウドディスク IOPS。 |
このメトリックは、クラウドネイティブの新しいコントロールプレーン (v3) でのみサポートされています。 |
|
|
リクエストキューの平均長。 |
N/A |
ノード JVM メトリクス
|
メトリック名 |
説明 |
|
各ノードで使用される Old 世代のヒープメモリ。使用量が多い、またはラージオブジェクトがあると、パフォーマンスに影響を与え、ガベージコレクション (GC) をトリガーし、長時間の停止やフル GC を引き起こす可能性があります。 |
|
|
|
|
|
各ノードの Old 世代 GC イベント。Old 世代の使用量が多い、またはラージオブジェクトがあると、クラスターのパフォーマンスに影響を与え、自動 GC をトリガーする可能性があります。ラージオブジェクトの収集は、長時間の停止やフル GC を引き起こす可能性があります。 |
|
|
各ノードの Old 世代 GC に費やされた平均時間。Old 世代の使用量が多い、またはラージオブジェクトがあると、GC をトリガーし、ラージオブジェクトの収集は長時間の停止やフル GC を引き起こす可能性があります。 |
スレッドプールメトリクス
|
メトリック名 |
説明 |
|
検索スレッドプールで現在タスクを実行しているスレッド。 |
|
|
クラスターの検索スレッドプールで拒否されたリクエスト。 |
その他のメトリクス
|
メトリック名 |
説明 |
|
1 分間のクラスターのメインログ内の WARNING レベルのログエントリの総数。 |
非推奨のメトリクス
|
メトリック名 |
説明 |
|
クエリスレッドプールで拒否されたリクエスト。このメトリックは SearchThreadpoolRejectedV2 メトリックとは異なる方法で計算され、現在は非推奨です。代わりに SearchThreadpoolRejectedV2 を使用してください。 |
クラスターのステータス (値)
メトリックの説明
クラスターのヘルス状態を示します。値が 0.00 の場合はクラスターが正常であることを意味します。このメトリックに対してアラートを設定してください。詳細については、「クラスターアラートの設定」をご参照ください。次の表に、考えられる値を示します。
|
値 |
色 |
ステータス |
説明 |
|
0.00 |
緑 |
すべてのプライマリシャードとレプリカシャードが割り当てられています。 |
クラスター内のすべてのインデックスは正常で、未割り当てシャードはありません。 |
|
1.00 |
黄 |
すべてのプライマリシャードは割り当てられていますが、1 つ以上のレプリカシャードが割り当てられていません。 |
少なくとも 1 つのインデックスに未割り当てのレプリカシャードがあります。 |
|
2.00 |
赤 |
少なくとも 1 つのプライマリシャードが割り当てられていません。 |
少なくとも 1 つのインデックスに未割り当てのプライマリシャードがあり、一部のデータが利用できないことを意味します。 |
この表の色は、ご利用のインスタンスの 基本情報ページに表示されるクラスターのステータスに対応しています。
異常ステータスの原因
0.00 以外の値は、クラスターの異常なステータスを示します。一般的な原因:
-
1 つ以上のノードで CPU 使用率またはヒープメモリ使用量が高く、100% に達する可能性があります。
-
1 つ以上のノードでディスク使用率が高く、例えば 85% を超えています。
-
1 つ以上のノードで Load_1m が高い。
-
1 つ以上のインデックスのヘルスステータスが黄または赤である。
トラブルシューティングの推奨事項
-
Kibana コンソールの モニタリングページを確認するか、インスタンスログを表示して詳細を確認してください。例えば、インデックスがメモリを過剰に消費している場合は、不要なインデックスを削除します。
-
高いディスク使用率が異常ステータスの原因である場合は、「クラスターの高いディスク使用率と読み取り専用の問題のトラブルシューティングと解決」をご参照ください。
-
小規模なインスタンスタイプ (例:1 コア CPU と 2 GB メモリ) の場合は、まずクラスターをスペックアップして、CPU 対メモリ比が 1:4 のインスタンスタイプにしてください。ステータスが異常なままである場合は、上記の 2 つの推奨事項に従ってください。
スナップショットのステータス
説明
自動バックアップ機能のスナップショットのステータスを示します。値が 0 の場合はスナップショットが存在することを示します。
|
値 |
説明 |
|
0 |
スナップショットが存在します。 |
|
-1 |
スナップショットが存在しません。 |
|
1 |
スナップショットが進行中です。 |
|
2 |
スナップショットタスクが失敗しました。 |
異常ステータスの原因
値が 2 の場合は失敗を示します。一般的な原因:
-
1 つ以上のノードのディスク使用率が高いか、100% に近づいています。
-
クラスターが不健康です。
クラスターノード数
クラスター内のノードの総数。これを使用して、ノードのスケールが期待どおりであることを確認します。
切断されたノード数
切断されたノードの総数。切断されたノードは、シャードの再割り当てやクエリレイテンシーの増加を引き起こす可能性があります。
異常ステータスの原因
値が 0 より大きい場合は、1 つ以上のノードがクラスターから切断されていることを示します。一般的な原因:
-
ノードの CPU 使用率、ヒープメモリ使用量、またはディスク使用率が高く、100% に近づいているため、ノードがクラスターのハートビートに応答できません。
-
ネットワークパーティションまたはノードとマスターノード間の接続障害。
-
ノードプロセスがクラッシュしたか、メモリ不足 (OOM) エラーが発生したため、ノードがクラスターから離脱しました。
-
継続的なフル GC などの頻繁な JVM ガベージコレクションにより、ノードが切断されたとマークされるほど長く応答しなくなりました。
-
基盤となるホストの問題やノードの可用性に影響を与えたシステム変更イベントなどのシステムレベルの障害。
トラブルシューティングの推奨事項
-
Alibaba Cloud Elasticsearch コンソールの イベントセンターに移動し、システム変更および クラスター変更タブを確認して、変更イベントがノードの切断を引き起こしたかどうかを確認します。
-
クラスターモニタリングページで、切断期間中の各ノードの CPU 使用率、ヒープメモリ使用量、ディスク使用率、および Load_1m を確認して、リソースの枯渇を除外します。各メトリックの意味については、このトピックの対応するセクションをご参照ください。
-
Kibana コンソールの モニタリングページでクラスターのヘルスステータスを確認するか、インスタンスログを表示して、ノードが切断されている間に報告された特定のエラーを取得します。
-
ノードのネットワーク接続とセキュリティグループの構成を確認して、ルール変更がノード間の通信をブロックしていないことを確認します。
クラスターインデックス数
クラスター内のインデックスの数。インデックスが多すぎると、リソース競合 (メモリと CPU) を引き起こす可能性があります。
クラスターシャード数 (カウント)
クラスター内のシャードの数。シャードが多すぎると管理オーバーヘッドが増加し、少なすぎると負荷が不均等になりクエリパフォーマンスが低下します。
クラスタープライマリシャード数
クラスター内のプライマリシャードの数。プライマリシャードが少なすぎると、書き込みのボトルネックを引き起こす可能性があります。
クラスターのスロークエリ
クラスター内のスロークエリの数。これを使用して、複雑なクエリやインデックス設計の問題などのパフォーマンスボトルネックを特定します。
クラスター書き込み QPS (カウント/秒)
書き込み QPS の急激なスパイクは、高い CPU 使用率、ヒープメモリ使用量、またはノード負荷を引き起こし、クラスターのパフォーマンスを低下させる可能性があります。これらのスパイクは避けてください。
1 秒あたりにクラスターに書き込まれるドキュメントの数。次のように計算されます:
-
単一ドキュメントの書き込みリクエストは 1 とカウントされます。1 秒以内の複数のリクエストは合計されます。
-
_bulk API リクエストの場合、書き込み QPS はリクエスト内のドキュメントの総数に等しくなります。1 秒以内の複数の _bulk リクエストは合計されます。
クラスタークエリ QPS (カウント/秒)
クエリ QPS の急激なスパイクは避けてください。それらは高い CPU 使用率、ヒープメモリ使用量、または高い 1 分間の平均負荷を引き起こし、クラスターのパフォーマンスを低下させる可能性があります。
クラスターのクエリ QPS。値は、クエリ対象のインデックス内のプライマリシャードの数に依存します。
例えば、5 つのプライマリシャードを持つインデックスをクエリすると、5 つの個別のクエリとしてカウントされます。
クラスターのスロークエリレイテンシー分布
メトリックの説明
index.search.slowlog.query と index.search.slowlog.fetch エントリからのデータを集約します。クエリを実行時間 (took_millis) ごとに 1 秒間隔 (0~1秒、1~2秒、最大10秒) でグループ化します。スロークエリのしきい値は index.search.slowlog.threshold.xxx パラメーターで定義します。詳細については、「インデックステンプレートの設定」をご参照ください。
異常値の一般的な原因
特定の時間範囲でスロークエリが増加する場合、サービスの問題が存在する可能性があります。一般的な原因:
|
原因 |
説明 |
|
高い QPS |
Query QPS または 書き込み QPS の急激なスパイクまたは大幅な変動は、クラスターの負荷を増加させ、クエリの実行時間を長くします。 |
|
集約またはスクリプトクエリ |
集約クエリはリソースを大量に消費します。注意して使用してください。 |
|
数値フィールドに対する term クエリ |
数値フィールド (byte, short, integer, long) に対して多くの term クエリを実行すると、ドキュメント ID のビットセットの構築に時間がかかるため、遅くなることがあります。範囲クエリや集約が必要ない場合は、フィールドタイプを keyword に変更してください。 |
|
あいまい一致 |
ワイルドカード、正規表現、またはあいまいクエリは、転置インデックスの term リストをスキャンし、一致するドキュメント ID を収集するため、かなりのリソースを消費します。ストレステストを実行して、適切なクエリボリュームを決定してください。 |
|
少数の個別のスロークエリまたは書き込みリクエスト |
全体的な QPS の変動は軽微な場合があります。調査するには、クエリログページに移動し、スロー検索ログをクリックします。 |
|
クラスター内のインデックスまたはシャードの数が過剰 |
インデックスまたはシャードが多すぎると、CPU 使用率、ヒープメモリ使用量、または Load_1m が高くなり、全体的なクエリパフォーマンスが低下する可能性があります。 |
|
マージ操作 |
マージ操作は CPU を集中的に使用し、セグメント数の急激な減少を引き起こします。Kibana コンソールの各ノードの 概要ページでセグメント数を監視してください。 |
|
ガベージコレクション (GC) 操作 |
GC 操作、特にフル GC はメモリを解放しますが、CPU を消費するため、CPU 使用率のスパイクやクエリの遅延を引き起こします。 |
|
定期タスク |
データバックアップなどの定期タスクは、かなりの I/O リソースを消費し、クエリ速度に影響を与える可能性があります。 |
クラスター Fielddata メモリ使用量 (B)
説明
クラスター内の Fielddata で使用されるヒープメモリ。過剰な Fielddata 使用量は、サーキットブレーカーをトリガーし、クラスターの安定性に影響を与える可能性があります。
一般的な原因
高い Fielddata 使用量はヒープメモリを消費し、サービス例外を引き起こす可能性があります。一般的な原因:
-
string(Text) 型フィールドに対する頻繁なソートまたは集約操作。これらのクエリの Fielddata はデフォルトではクリアされません。代わりに数値フィールドタイプを使用してください。 -
Query QPS または 書き込み QPS トラフィックの急激なスパイクまたは大幅な変動。これにより、
Fielddataが頻繁にキャッシュにロードされます。 -
インデックスまたはシャードが多すぎると管理オーバーヘッドが増加し、高い CPU、
HeapMemory、またはLoad_1mにつながります。
一括書き込み TPS
説明
インデックスに対する 1 秒あたりの一括リクエスト数。
例外の一般的な原因
このメトリックは、以下の理由でデータが表示されない場合があります:
-
高いクラスター負荷がモニタリングデータ収集を妨げます。
-
モニタリングデータのプッシュが失敗しました。
IndexSearchQPS (カウント/秒)
説明
インデックスの 1 秒あたりのクエリ数 (QPS)。値は、クエリ対象のインデックス内のプライマリシャードの数に依存します。
例えば、5 つのプライマリシャードを持つインデックスをクエリすると、5 QPS としてカウントされます。
異常値の原因
このメトリックはデータが表示されないことがあります。一般的な理由:
-
高いクラスター負荷がモニタリングデータ収集を妨げる可能性があります。
-
モニタリングデータのプッシュが失敗しました。
IndexSearchQPS の急激なスパイクは、インデックスが高い CPU、ヒープメモリ、または Load_1m を引き起こし、クラスターの安定性に影響を与えていることを示している可能性があります。インデックスの最適化を検討してください。
IndexSearchDelayMax (ms)
インデックスの最大クエリ遅延 (ミリ秒)。
ノード CPU 使用率 (%)
メトリックの説明
各ノードの CPU 使用率。特に 100% に近い高い使用率は、クラスターサービスに影響を与える可能性があります。
例外の一般的な原因
スパイクまたは大幅な変動は、サービスの問題を示します。一般的な原因:
|
原因 |
説明 |
|
QPS |
Query QPS または 書き込み QPS トラフィックの急激なスパイクまたは大きな変動。 |
|
スロークエリまたは書き込みリクエスト |
QPS の変動は軽微な場合があります。調査するには、LogSearch ページに移動し、スロー検索ログをクリックします。 |
|
過剰なインデックスまたはシャード |
インデックスまたはシャードが多すぎると管理オーバーヘッドが増加し、高い CPU、ヒープメモリ、または Load_1m につながります。 |
|
クラスターのマージ操作 |
マージ操作は CPU を消費し、セグメント数の急激な減少を引き起こします。Kibana コンソールのノードの概要ページでセグメント数を確認してください。 |
|
GC 操作 |
GC 操作、特にフル GC はメモリを解放しますが、CPU を集中的に使用するため、CPU 使用率のスパイクを引き起こします。 |
|
定期タスク |
データバックアップやその他のカスタムジョブなどの定期タスクの実行は、リソースを大量に消費する可能性があります。 |
ノードの CPU 使用率には、システムレベルのプロセスと Elasticsearch タスクの両方からのリソース消費が含まれます。
ノードディスク使用率 (%)
各ノードのディスク使用率。ディスク使用率は 75% 未満に保ち、85% を超えないようにしてください。これらのしきい値を超えると、クラスターサービスに影響を与える可能性があります。
|
ディスク使用率 |
説明 |
|
>85% |
クラスターは、ノードへの新しいシャードの割り当てを防ぎます。 |
|
>90% |
クラスターは、ノードからディスク使用率の低い他のデータノードにシャードを再配置しようとします。 |
|
>95% |
Elasticsearch は、ノード上のすべてのインデックスに |
-
このメトリックに対してモニタリングアラートを設定してください。トリガーされた場合は、中断を防ぐために、速やかにディスクとノードをスケールアップするか、インデックスデータをクリアしてください。
-
ノードのディスク使用率には、システムレベルのプロセスと Elasticsearch タスクの両方で使用されるリソースが含まれます。
ノードヒープメモリ使用量 (ES サービス) (%)
説明
各ノードのヒープメモリ使用量。高い使用量やラージオブジェクトは、パフォーマンスに影響を与え、GC 操作をトリガーする可能性があります。
異常値の原因
急激なスパイクや大幅な変動は、多くの場合、サービスの異常を示します。一般的な原因:
|
原因 |
説明 |
|
QPS |
Query QPS または 書き込み QPS の急激なスパイクまたは大きな変動。 |
|
少数のスロークエリリクエスト |
QPS の変動は軽微な場合があります。調査するには、LogSearch ページの スロー検索ログを分析します。 |
|
多数のスロー書き込みリクエスト |
QPS は大幅な変動を示します。調査するには、LogSearch ページの スローインデックスログを分析します。 |
|
クラスターにインデックスが多すぎるか、シャードの総数が多い |
インデックスまたはシャードが多すぎると管理オーバーヘッドが増加し、高い CPU、ヒープメモリ、または Load_1m につながります。 |
|
マージ操作 |
マージ操作は CPU を集中的に使用し、セグメント数の急激な減少を引き起こします。Kibana コンソールのノードの 概要ページを確認してください。 |
|
GC 操作 |
フル GC などの GC 操作はメモリを解放しますが、CPU リソースを消費します。これにより、ヒープメモリ使用量が急激に減少する可能性があります。 |
|
定期タスク |
例えば、データバックアップやその他のカスタムタスク。 |
ノード Load_1m
説明
各ノードの 1 分間の平均負荷で、システムのワークロードを示します。正常な値は CPU コア数未満です。次の表は、シングルコアノードの値について説明しています。
|
ノード Load_1m |
説明 |
|
<1 |
リソースを待機しているプロセスはありません。 |
|
=1 |
システムは完全に利用されており、追加のプロセスに対応する容量はありません。 |
|
>1 |
プロセスはキューに入れられ、リソースを待機しています。 |
-
ノード load_1mメトリックには、システムレベルのプロセスと Elasticsearch タスクの両方からのリソース消費が含まれます。
-
ノード load_1mメトリックの変動は予想されます。より正確な分析のためには、Node CPU usageメトリックに注目してください。
異常の原因
CPU コア数を超える値は、システムの過負荷を示します。一般的な原因:
-
ノードの CPU 使用率またはヒープメモリ使用量が過度に高く、100% に達する可能性があります。
-
Query QPS または 書き込み QPS の急激なスパイクまたは大幅な増加。
-
高負荷なスロークエリ。
これらのログを分析するには、ログクエリページを使用してください。
ノード Load_1m メトリックには、システムレベルのプロセスと Elasticsearch タスクの両方からのリソース消費が含まれます。
ノードメモリ使用率_合計 (%)
ノードのシステムメモリ使用量。
ノード CPU IO 待機率 (%)
ノードの CPU が I/O 操作を待機している時間の割合。
ノードインバウンドパケット (カウント)
各ノードのインバウンドネットワークパケット数。モニタリングサイクル:1 分。
ノードネットワークパケットアウト (カウント)
各ノードから 1 分あたりに送信されるパケット数。
ノードインバウンド帯域幅 (KiB/秒)
各ノードのインバウンドデータレート。モニタリングサイクル:1 分。単位:KiB/秒。
ノードネットワーク帯域幅_出力 (KiB/秒)
各ノードのアウトバウンドネットワーク帯域幅 (KiB/秒)。毎分更新されます。
ノード TCP 接続数
説明
クライアントから各ノードへの確立された TCP 接続数。
異常の原因
クライアントが TCP 接続を速やかに解放しない場合に、スパイクが頻繁に発生します。アイドル接続を解放するためにクライアント側のポリシーを設定してください。
IOUtil (%)
説明
各ノードの I/O 使用率。
異常の原因
高いディスク使用率は読み書きの待機時間を増加させ、I/O 使用率のスパイクを最大 100% まで引き起こす可能性があります。ワークロードを分析し、クラスター構成のスペックアップを検討してください。
ノードネットワーク再送率 (%)
ノードによって再送されるネットワークパケットの割合。
ノードネットワーク帯域幅 (KiB/秒)
ノードネットワーク帯域幅_入力とノードネットワーク帯域幅_出力の合計。
ノードネットワーク帯域幅使用率 (%)
ノードネットワーク帯域幅使用率 (%) = (ノードネットワーク帯域幅_入力 (KiB/秒) + ノードネットワーク帯域幅_出力 (KiB/秒)) / ノードネットワーク基本帯域幅 (KiB/秒)。
ノードネットワークパケット (カウント)
ノードネットワークパケット_出力とノードネットワークパケット_入力の合計。
ノードネットワークパケット使用率 (%)
ノードネットワークパケット使用率 (%) = (ノードネットワークパケット_アウトバウンド (PPS) + ノードネットワークパケット_インバウンド (PPS)) / 1 秒あたりの最大ネットワークパケット数 (PPS)。
ディスク帯域幅読み取り (MiB/秒)
各ノードから 1 秒あたりに読み取られるデータ。
ディスク帯域幅_書き込み (MiB/秒)
各ノードの書き込み帯域幅。
ディスク読み取り IOPS
各ノードで 1 秒あたりに完了した読み取りリクエスト。
ディスク IOPS 書き込み
各ノードによって 1 秒あたりに完了した書き込みリクエスト。
平均リクエストキュー長
リクエストキューの平均長。
ディスク帯域幅 (MiB/秒)
ディスク帯域幅 (MiB/秒) = ディスク帯域幅_読み取り (MiB/秒) + ディスク帯域幅_書き込み (MiB/秒)。
クラウドディスク帯域幅使用率 (%)
ディスク帯域幅使用率_クラウドディスク (%) = (ディスク帯域幅_読み取り (MB/秒) + ディスク帯域幅_書き込み (MB/秒)) / 単一ディスクスループット (MB/秒)。
ディスク帯域幅使用率_ノード (%)
(ディスク帯域幅_読み取り (MiB/秒) + ディスク帯域幅_書き込み (MiB/秒)) / ディスク基本帯域幅 (Gbit/秒) として計算されます。すべての値を同じ単位に変換してください。
ディスク IOPS (カウント)
ディスク IOPS (カウント) = ディスク読み取り IOPS (カウント) + ディスク書き込み IOPS (カウント)。
ディスク IOPS 使用率 (クラウド) (%)
ディスク IOPS 使用率_ディスク (%) = (ディスク IOPS_読み取り (カウント) + ディスク IOPS_書き込み (カウント)) / 単一ディスク IOPS 容量。
ディスク IOPS 使用率_ノード (%)
ディスク IOPS 使用率_ノード (%) = (ディスク IOPS_読み取り (カウント) + ディスク IOPS_書き込み (カウント)) / クラウドディスク基本 IOPS
ノード Old 世代使用量 (B)
メトリックの説明
各ノードで使用される Old 世代のヒープメモリ。高い使用量やラージオブジェクトは、パフォーマンスに影響を与え、GC をトリガーし、長時間の停止やフル GC につながる可能性があります。
メトリックの異常の原因
急激なスパイクや大幅な変動は、多くの場合、サービス例外を示します。一般的な原因:
|
原因 |
説明 |
|
QPS |
Query QPS または 書き込み QPS の急激なスパイクまたは大幅な変動。 |
|
集約またはスクリプトクエリ |
集約クエリはリソースを大量に消費します。注意して使用してください。 |
|
数値フィールドに対する term クエリ |
数値フィールド (byte, short, integer, long) に対して多くの term クエリを実行すると、時間のかかるビットセット構築のため遅くなることがあります。範囲クエリや集約が必要ない場合は、フィールドタイプを keyword に変更してください。 |
|
あいまい一致 |
ワイルドカード、正規表現、またはあいまいクエリは、転置インデックスの term リストをスキャンし、一致するドキュメント ID を収集するため、かなりのリソースを消費します。ストレステストを実行して、適切なクエリボリュームを決定してください。 |
|
少数のスロークエリ |
QPS の変動は軽微な場合があります。調査するには、クエリログページに移動し、スロー検索ログをクリックします。 |
|
少数のスロー書き込みリクエスト |
QPS の変動は軽微な場合があります。調査するには、クエリログページに移動し、スローインデックスログをクリックします。 |
|
クラスター内のインデックスまたはシャードの数が過剰 |
インデックスまたはシャードが多すぎると、高い CPU、ヒープメモリ、または Load_1m を引き起こす可能性があります。 |
|
マージ操作 |
マージ操作は CPU を集中的に使用し、セグメント数の急激な減少を引き起こします。これを Kibana コンソールの各ノードの 概要ページで監視してください。 |
|
GC 操作 |
フル GC などの GC 操作はメモリを解放しますが、CPU リソースを消費します。これにより、ヒープメモリ使用量が急激に減少する可能性があります。 |
|
定期タスク |
データバックアップやその他のカスタムタスク。 |
フル GC 回数
頻繁なフル GC イベントは、クラスターのパフォーマンスを低下させる可能性があります。
説明
1 分あたりのクラスター内のフル GC イベントの数。
異常の原因
ゼロより大きい値は、サービス例外を示します。一般的な原因:
-
高いヒープメモリ使用量。
-
ラージオブジェクト。
ノード Old GC 回数
説明
各ノードの Old 世代 GC イベントをカウントします。高い使用量やラージオブジェクトは、自動 GC をトリガーし、長時間の停止やフル GC を引き起こす可能性があります。
基本モニタリングのフル GC メトリックはログから取得されますが、高度なモニタリングのメモリメトリックは ES エンジンによって収集されます。これらの異なるデータソースを考慮して、利用可能なすべてのメトリックを組み合わせてクラスターのパフォーマンスを評価してください。
一般的な原因
「ノード Old 世代使用量 (B)」をご参照ください。
ノード Old GC 持続時間 (ms)
メトリック
各ノードの Old 世代 GC の平均持続時間。高い Old 世代使用量やラージオブジェクトは GC をトリガーし、持続時間が長くなったり、フル GC を引き起こしたりする可能性があります。
異常値の原因
「JVMMemoryOldUsedBytes」をご参照ください。
検索スレッドプールのアクティブスレッド数 (カウント)
クラスターのクエリスレッドプール内のアクティブスレッド。
クエリスレッドプールで拒否されたリクエスト (カウント)
この非推奨のメトリックは、クラスターのクエリスレッドプールで拒否されたリクエストをカウントします。代わりに SearchThreadpoolRejectedV2 を使用してください。
拒否されたクエリリクエスト
クラスターのクエリスレッドプールで拒否されたリクエスト。スレッドプールがいっぱいになると、新しいクエリリクエストは拒否されます。
例外カウント
メトリックの説明
1 分間のクラスターログ内の警告レベルのログエントリの総数。
異常値の原因
0 以外の値は、サービス例外を示します。一般的な原因:
-
異常なクエリリクエスト。
-
異常な書き込みリクエスト。
-
Elasticsearch タスクのエラー。
-
ガベージコレクション操作。
トラブルシューティング
クエリログページに移動し、インスタンスログをクリックします。インスタンスログページで、例外の詳細を確認して根本原因を見つけます。
インスタンスログに GC レコードが含まれている場合、これらのレコードは NodeStatsExceptionLogCount メトリックにも含まれます。