mongot の推奨アラート

mongotプロセスが停止しています

mongot Prometheus メトリクスの取得に応答していません。検索とベクトル検索が正常に機能していません。

この状態についてアラートするには、次の PromQL 式を使用します。

up{job="mongot"} == 0

持続時間を 1 分に設定します。

短時間の不在は一時的なネットワークエラーである可能性があります。1 分以上の長時間の不在は停止時です。

mongotの実行方法に応じて、次のいずれかのコマンドを実行して、このアラートに対応します。

• Kubernetes を使用する配置の場合は、kubectl get pods を実行します。

• systemd を使用する配置の場合は、systemctl status mongot を実行します。

• Docker を使用する配置の場合は、docker ps を実行します。

クラッシュの原因はログで確認します。トラブルシューティングの手順については、mongot ログと FTDC を参照してください。

クラッシュループ

プロセスが繰り返し再起動しています。配置が不安定です。

この状態についてアラートするには、次の PromQL 式を使用します。

changes(mongot_process_start_time_seconds[10m]) > 3

10 分以内に 3 回以上再起動すると、クラッシュループになります。クラッシュループは一時的な障害ではなく、対処する必要があります。

次のアクションを実行して、このアラートに応答します。

• 最近のクラッシュウィンドウからログを取得する。

• 停止したポッドまたはプロセスを検査できるように、自動再起動を一時停止します。

• FTDC キャプチャを開きます。

レプリケーションラグが際限なく増大しています

mongot mongod に追いついていけません。検索結果は次第に古くなっていきます。レプリケーションラグが修正されないままにされると、カーソルが oplog から外れ、完全な再同期が強制されます。

この状態についてアラートするには、次の PromQL 式のいずれかを使用します。

max(mongot_index_stats_indexing_replicationLagMs) > 60000

または、絶対階層に達する前に増加値値を捕捉するには、次のようにします。

deriv(max(mongot_index_stats_indexing_replicationLagMs)[15m:1m]) > 500

このメトリクスはインデックスごとで、単位はミリ秒です。PromQL でメトリクを 1000 で分割しないでください。安定状態のラグは 1 秒未満です。キャッチアップシナリオの場合は、1 分のラグは許容されます。着実に増加するラグは警報条件です。

mongot_index_stats_* ファミリのメトリクスは、少なくとも 1 つの検索インデックスが存在すると、1 度だけ表示されます。インデックスのない新しい配置では、シリーズがまだ存在していないため、このアラートは表示されません。これは予期される動作です。

次のアクションを実行して、このアラートに応答します。

• mongod の書き込みレートに急増がないかチェックします。

• mongotのCPUおよびディスクI/Oに飽和状態がないか確認してください。

ガイダンスについては、mongot のメトリクス参照を参照してください。

同期の例外の発生

mongot 同期中にエラーが発生しています。例外が繰り返されたため、再同期を実行します。再同期中、インデックスは一時的に利用できないか、古い状態になっています。

この状態についてアラートを発生させるには、次の PromQL 式のいずれかを使用します。

同期中のエラーに基づいてアラートを行うには、次を使用します。

increase(mongot_index_stats_indexing_steadyStateExceptions_total[10m]) > 0

最初の同期例外を捕捉するには、次を使用します。

increase(mongot_index_stats_indexing_initialSyncExceptions_total[10m]) > 0

本番環境での安定状態の例外は問題です。oplog がロールオーバーしたか、つまり mongod oplog が小さすぎるか mongot が速度が遅すぎるか、またはダウンストリームでエラーが発生しました。

次のアクションを実行して、このアラートに応答します。

• 例外の周辺の mongot ログをキャプチャします。

• mongod oplogサイズを確認します。

• FTDC キャプチャをただちに開きます。後になってから根本原因を特定するのは困難です。

ヒープの消耗が迫っています

JVM ヒープが限界に近づいています。OutOfMemoryError が発生しようとしています。

この状態についてアラートするには、次の PromQL 式を使用します。

sum(mongot_jvm_memory_used_bytes{area="heap"})
  / sum(mongot_jvm_memory_max_bytes{area="heap"} > 0) > 0.85

持続時間を5分に設定します。

ヒープ使用量が 85% を超えて持続すると問題が発生する可能性があります。次の割り当ての急増により、メモリ不足エラーが発生する可能性があります。mongot はデフォルトで、Garbage-First (G1) Garbage Collection を使用します。次の式は、上記の PromQL 式のより正確な GC 後バージョンです。

mongot_jvm_gc_live_data_size_bytes
  / mongot_jvm_gc_max_data_size_bytes > 0.85

アクティブなインデックスの作成操作とクエリロードを確認して、このアラートに対応します。大型インデックスが構築中の場合、構築が完了すると、状態が解決される可能性があります。そうでない場合は、-Xmxヒープ設定を増やすか、同時操作の数を減らします。

ディスクの入りと mongot の自己保護カスケード

mongot dataPath ボリュームのディスク使用量に3つのスレッショルドを強制します。これらのスレッショルドは、mongot バイナリで強制されます。モニタリングの有無にかかわらず、スレッショルドは有効になります。オンコールエンジニアがカスケードを確認し、最終スレッショルドが超えられる前に対処できるよう、3つのスレッショルドすべてでアラートを設定します。

このアラートには 3 つのルールがあります。各スレッショルドで重大度がエスカレートされます。

次の PromQL 式を使用してこれらの状況をアラートする。

85％ - チケットレベル：

(1 - mongot_system_disk_space_data_path_free_bytes
     / mongot_system_disk_space_data_path_total_bytes) >= 0.85

90% — ページ レベル:

(1 - mongot_system_disk_space_data_path_free_bytes
     / mongot_system_disk_space_data_path_total_bytes) >= 0.90

95% — ページ レベル (停止時):

(1 - mongot_system_disk_space_data_path_free_bytes
     / mongot_system_disk_space_data_path_total_bytes) >= 0.95

mongot /metrics エンドポイントは _free_bytes と _total_bytes を公開します。使用割合を 1 - free/total として計算します。

次のアクションを実行して、このアラートに応答します。

• 85％の時点で、検索インデックスマネジメントAPIを使用して未使用のインデックスを監査するおよび削除します。dataPath 配下のファイルを手動で削除しないでください。ディスク使用率が85％を下回るまで、新しいインデックスはビルドされません。

• 90% で、クラスターがレプリケーション無効状態にあることを操作チームまたは SRE チームにアラートします。未使用のインデックスを削除するか、ストレージを拡張してレプリケーションを復元します。

• 95% の場合：これは停止時です。ディスクの空き容量を増やしてから mongot を再起動します。ディスクが解放されるまで、mongot はクリーンに再起動することを拒否します。

持続的なクエリレイテンシの劣化

ユーザーの検索が遅い。

この状態についてアラートするには、次の PromQL 式のいずれかを使用します。

クロスインデックス:

max(mongot_command_searchCommandTotalLatency_seconds{quantile="0.99"})
  > <your-SLO-threshold>

インデックスごとの内訳:

max(mongot_index_stats_query_searchResultBatchLatencies_seconds{quantile="0.99"})
  by (indexId_logString) > <your-SLO-threshold>

スレッショルドはサービスレベル目標によって異なります。一般的な開始点は、$search で 500 ミリ秒で 99 パーセンタイル、$vectorSearch で 1 秒です。これらのシリーズは、ヒストグラムではなく、事前に焼き仕上げた quantile ラベルの要約です。

次の項目を調査して、このアラートに応答します。

• エキスキューターキューの深さ。

• JVM ガベージ コレクションの一時停止時間。

• ボトルネックを特定するためのストレージ IOPS。

エクゼキュータプールの飽和

ワーカーが飽和し、タスクがキューに入っています。クエリのレイテンシが増加しようとしています。

この状態についてアラートするには、次の PromQL 式を使用します。

max({__name__=~"mongot_.+_executor_queued_tasks"}) > 10

持続時間を5分に設定します。

負荷のスパイク時には、短いキューが発生するのは正常です。キューが持続する場合は、ワーカーのキャパシティーが不足しています。一般的なホットスポットプールは次のとおりです。

• mongot_decoding_executor

• mongot_change_stream_sync_dispatcher_executor

• mongot_indexing_work_executor

• mongot_indexing_lifecycle_executor

• mongot_index_commit_executor

インデックスの作成作業は、複数の特化されたプールに分割されます。統合されたmongot_indexing_executorはありません。

キューに入っているプールを特定して、このアラートに応答します。

topk(5, sum by (__name__) ({__name__=~"mongot_.+_executor_queued_tasks"}))

スケールアップするか、プールサイズを増やします。キューの深さの増加により、クエリのレイテンシが上昇する前に早期警告が提供されます。

ストレージのお知らせ: 持続的な IOPS

ストレージ ボリュームが飽和に近づいています。Lucene のレイテンシは、ディスクによる制約が増えています。

この状態についてアラートするには、次の PromQL 式を使用します。

rate(mongot_system_disk_reads_events{name="<dataPath device>"}[5m]) > 1000

期間を 15 分に設定します。

1、000 IOPSスレッショルドは、ストレージクラスの推奨フラグです。ただし、厳密な制限ではありません。適切な数値は、デバイスによって異なります。dfを使用するか、mongot_system_disk_*ラベル値を調査することで、dataPathデバイスを識別します。

このアラートに対しては、マージまたは最初の同期が進行中かどうかを確認して応答します。高い IOPS レベルが維持される場合、ストレージ クラスのサイズが不十分である可能性が高いです。ストレージ構成を再検討します。

ストレージに関するアドバイザリー: ページフォールト率

OS は、インデックス ページがキャッシュから追い出されているため、ディスクから繰り返しページングしています。メモリは制約であり、ストレージ キャパシティーは制約ではありません。

この状態についてアラートするには、次の PromQL 式を使用します。

rate(mongot_system_process_majorPageFaults_operations[5m]) > 1000

1、000 メジャー障害/秒は、クリティカルパス上のメモリプレッシャの標準スレッショルドです。持続的な IOPS とともに、これはワーキングセットに対するメモリの不足のシグナルです。

Lucene はインデックス ファイルをメモリマップするため、メモリを追加してこのアラートに応答します。

インデックスの作成の失敗がゼロ以外

特定のインデックスでは、重大なインデックスの作成に失敗しました。

この状態についてアラートするには、次の PromQL 式のいずれかを使用します。

increase(mongot_lifecycle_failedInitializationIndexes_total[10m]) > 0

または:

increase(mongot_indexing_steadyStateChangeStream_unexpectedBatchFailures_total[10m]) > 0

または:

increase(mongot_index_stats_indexing_invalidGeometryField_total[10m]) > 0

これらのカウンターは、通常の負荷では増加しません。増加は、次のようなデータの問題を示します。

• マッピングのバースト。

• サイズが大きすぎるドキュメント。

• 無効なドキュメント。

これらのカウンターが増加すると、コードパスの問題が示される可能性もあります。

次のアクションを実行して、このアラートに応答します。

• 影響を受けたインデックスと理由のラベルを調査します。

• 基礎の例外については mongot ログを確認します。

埋め込みチャンネルの中断

自動埋め込みで問題が発生しています。影響を受けたインデックスでの新しいドキュメントのインデックスの作成プロセスが停滞します。

この状態についてアラートするには、次の PromQL 式のいずれかを使用します。

increase(mongot_indexing_steadyStateChangeStream_rescheduledEmbeddingGetMores_total[10m]) > 0

または:

increase(mongot_initialsync_queue_requeuedEmbeddingInitialSyncs_total[10m]) > 0

持続的な再スケジューリングまたは再キュー入れは、埋め込みパスがクリーンにドレインされていないことを示しています。一般的な原因は次のとおりです。

• An invalid API key.

• アクセスできないネットワークのエンドポイントとなる接続されたデバイス。

• Voyage AIレート制限。

次のアクションを実行して、このアラートに応答します。

• 埋め込みエンドポイントに対するHTTPエラーについて mongot ログを確認します。

• API キーの有効性と接続性を確認します。

• Voyage AI の状態を確認します。

強制インデックスステータス遷移

1 つ以上のインデックスが STEADY 状態から復旧、ステール、または失敗状態に移行しました。

この状態についてアラートするには、次の PromQL 式を使用します。

count by (status) (mongot_index_stats_indexStatusCode{status!="STEADY"} == 1) > 0

配置中の数秒間の RECOVERING_TRANSIENT の単一インデックスは正常です。次のいずれかの状態でゼロより大きい持続カウントは問題を示します。

• FAILED.

• RECOVERING_NON_TRANSIENT.

• STALE.

影響を受けた indexId_logString を特定し、対応する mongot ログ行を確認することで、このアラートに対応します。

FTDC 実行者の失敗

診断キャプチャ パイプラインが失敗しています。mongot はその他は正常ですが、そのノードの可視性が失われています。

この状態についてアラートするには、次の PromQL 式を使用します。

mongot_mongot_ftdc_executor_failure_total > 0

持続時間を5分に設定します。

配置でこのメトリクスが公開されている場合は、ダウンストリームの可視性が劣化していることを示す重大なシグナルとして扱ってください。

mongot を再起動することで、このアラートに対応します。

ヒープ使用率（GC 書き込み後）

このメトリクスは、ガーベージ コレクション後のヒープ使用率の経時変化を示します。

この状態についてアラートするには、次の PromQL 式を使用します。

sum(mongot_jvm_gc_live_data_size_bytes) / sum(mongot_jvm_gc_max_data_size_bytes)

メトリクスが何週も上昇している場合は、調査してこのアラートに対応します。

GC 一時停止時間

このメトリクスは、コレクター間で最近発生した最悪の一時停止を示します。

この状態についてアラートするには、次の PromQL 式を使用します。

max(mongot_jvm_gc_pause_seconds_max)

このメトリクスが 100 ms を超えて持続する場合は、調査してこのアラートに応答します。

ファイル記述子を開く

メトリクスには、オープンファイルディスクリプタのソフト制限に対するヘッドルームが表示されます。

この状態についてアラートするには、次の PromQL 式を使用します。

mongot_process_*

このアラートに対して、このメトリクスが 80% を超えているかどうかを調査して対処します。

カーソル タイムアウト

このメトリクスは、タイムアウトを過ぎてカーソルを保持しているクライアントの数を示します。

この状態についてアラートするには、次の PromQL 式を使用します。

rate(mongot_cursorManager_trackedCursors[5m])

このメトリクスについては、アラートのスレッショールドを設定する必要はありません。純粋な情報です。

接続プール待機

このメトリクスは、接続を待機しているスレッドの数を示します。

この状態についてアラートするには、次の PromQL 式を使用します。

mongot_mongoClient_connectionPool_connectionsCheckedOut approaching _maxSize

メトリクスが持続していてゼロより大きい場合は、調査してこのアラートに対応します。

ディスクの空き容量の割合

このメトリクスはストレージ キャパシティーを示します。

この状態についてアラートするには、次の PromQL 式を使用します。

mongot_system_disk_space_data_path_free_bytes / mongot_system_disk_space_data_path_total_bytes

このメトリクスが 30%未満になった場合は、ストレージを増やすための計画について話し合いをすることをお勧めします。

Search Availability Below 70%

Use the following metrics:

• envoy_mongorpc_grpc_transcode_request_failed_total

• envoy_mongorpc_grpc_transcode_request_total

• mongot_index_stats_query_internallyFailedQueries_total

Calculate availability using the following:

1 - (Envoy failed requests + mongot internal failures) / Envoy total requests

Treat a sustained value below 0.70 as a high-severity alert.

High Request-Failure Rate

Use envoy_mongorpc_grpc_transcode_request_failed_total and envoy_mongorpc_grpc_transcode_request_total. Alert when the following ratio is greater than 0.10 on at least 20% of active instances with more than 1 QPS, and at least 10 instances meet the QPS condition:

rate(envoy_mongorpc_grpc_transcode_request_failed_total[5m])
/ rate(envoy_mongorpc_grpc_transcode_request_total[5m]) > 0.10

Too Few xDS Connections

Use envoy_cluster_upstream_rq_active{envoy_cluster_name="xds_cluster"} to identify Envoys with no active xDS upstream requests. Alert when fewer than 70% of Search Envoy instances are connected to the Search xDS server.

Short-Lived Envoy Instances

Use envoy_server_uptime. Treat envoy_server_uptime < 1800 as an instance-level signal and alert when more than 20% of Envoy instances meet the condition. Treat this as a supporting signal because small regions can produce false positives.

mongot Process Silence

Use mongot_process_uptime_seconds. Alert when absent_over_time(mongot_process_uptime_seconds[15m]) is true for an instance that is expected to be running and scraped.

Low Data-Path Disk Space

Use mongot_system_disk_space_data_path_free_bytes and mongot_system_disk_space_data_path_total_bytes. Alert when:

mongot_system_disk_space_data_path_free_bytes
/ mongot_system_disk_space_data_path_total_bytes < 0.10

Correlate this alert with replication pause, stale-index, and process-crash signals.

Replication Lag

Use mongot_index_stats_indexing_replicationLagMs. Treat a maximum lag above 1800000 milliseconds (30 minutes) and rising as an early warning. Escalate above 7200000 milliseconds (2 hours) when the value continues to rise.

Fleet-Wide Native Memory Pressure

Use mongot_system_memory_phys_inUse_bytes, mongot_jvm_memory_used_bytes{area="heap"}, and mongot_system_memory_phys_total_bytes to calculate memory outside the JVM heap. Investigate when more than 5% of mongot instances exceed 50% native-memory usage for 55 minutes.

These thresholds are runbook starting points. Tune them for the size and workload of your deployment, and publish each alert only when the corresponding metric is available.