mongot Lucene をベースとし、JVM でホストされるメモリマップ型サーチエンジンです。mongod とは異なる操作特性を持っています。
ストレージに対するレイテンシの影響。ランダム読み取りディスクのレイテンシは、クエリとインデックスの作成のパフォーマンスに直接影響します。ストレージ クラスは、配置に対する最も影響の大きい決定の1つです。
メモリマップインデックスアクセス。ファイルシステムキャッシュの負荷は、クエリレイテンシと非線形的に相関します。メモリの小さな不足は、大きなレイテンシの劣化を引き起こします。
レプリケーション駆動。
mongotmongodストリームの変更のダウンストリームコンシューマーです。レプリケーションラグ、oplog の読み取り、および接続の健康状態はすべてインデックスの新鮮さに影響します。複数のワークロードフェーズ。最初の同期、マージ、安定状態のレプリケーション、およびクエリは、それぞれが異なるリソースに負荷をかけます。あるフェーズでは健全であるシグナルが、別のフェーズでは問題を示す可能性があります。
シグナルカテゴリ
カテゴリ | 内容 |
|---|---|
健康 |
|
複製 |
|
インデックスの作成 | mongot プロセスがインデックスを構築および維持しているかどうか、マージが進行しているかどうか、および最初の同期が進行しているかどうか。 |
クエリ |
|
実行プール | スレッド プールの使用率とキューの深さ。ここでの飽和は、クエリのレイテンシ劣化を予測します。 |
JVM | JVM 上のヒープ、ガーベージ コレクション、およびスレッドに関連するメトリクス。 |
システム | CPU、メモリ、ディスク I/O、ネットワークに関連するメトリクス。プロセスまたはコンテナレベルです。 |
ストレージ | IOPS、ページフォールト率、空き容量に関連するメトリクス。 |
埋め込み | 自動埋め込みが有効になっている場合のVoyage AIエンドポイントに対するスループットとエラー率。 |
mongot の主なシグナル
これらがモニターするための主要なシグナルです。モニターできるシグナルがいくつかだけの場合は、これらから始めてください。
ヘルスとプロセス ステータス
mongotプロセスが稼働しているかどうか。再起動中のmongotはトラフィックを処理できません。クラッシュ ループは、mongotの可用性に問題があることを示します。ヘルスが
SERVING状態に達したかどうか。初期化を開始したものの完了しなかったmongotは、クエリに応答できません。
クエリのレイテンシ
$searchと$vectorSearch.の 50 パーセンタイル (p50) および 99 パーセンタイル (p99) のクエリレイテンシ。mongotの配置は、ストレージまたはメモリの負荷の下で非線形的に劣化する傾向があるため、p99 に特に注意してください。p99 は p50 よりも早く問題を明らかにします。createSearchIndex、getSearchIndexes、$listSearchIndexes集計ステージなどのインデックスマネジメントリクエストのレイテンシ。これらのリクエストのスパイクは、mongotがビジーであるか、mongodからアクセスできないことを示している可能性があります。
Replication Lag
mongod から最後に適用された変更イベントからの時間。このシグナルは、
mongot_index_stats_indexing_replicationLagMs(インデックスごと、ミリ秒)として直接公開されます。サブ秒から数秒までの小さな定常状態のラグは正常です。ただし、ラグが増えるとmongotは追いついていけなくなります。ラグが持続すると、最終的に oplog から外れて再同期が強制されます。再同期は、インデックスの完全な再構築が必要になるため、ラグそのものよりもはるかに悪いです。インデックスの完全な再構築は、計算コストが高く、時間がかかります。mongot_index_stats_*メトリクスは検索インデックスごとに出力され、少なくとも 1 つのインデックスが存在すると表示されます。インデックスのない新規配置では、レプリケーションラグ シリーズはゼロではなく、表示されません。これは正常です。
インデックスの作成の進捗状況
アクティブなインデックス作成操作およびその状態 (
PENDING,BUILDING,READY,FAILED)。ハングしたビルドは、リソースの消耗かデータの問題のいずれかを示します。スループットを統合する。マージはバックグラウンドの作業です。マージが遅れると、クエリのレイテンシが上がります。
エクゼキュータプールの飽和
クエリ実行エンジンとインデックスの作成実行エンジンのキューの深さ。持続的な非ゼロキューの深さは、飽和とクエリがワーカースレッドを待っていることを示します。これは、レイテンシが上昇することを示する早期警告です。
JVM ヘルス
ガーベージ コレクション後のヒープ使用率。ガーベージ コレクション後にヒープが常に85%を超えると、
OutOfMemoryErrorエラーが発生する可能性があります。ガベージ コレクションの一時停止時間。長い GC の一時停止は、クエリのレイテンシの急増に直接的につながります。
ストレージの負荷
デバイスの安全な操作点を超える持続的なディスク IOPS は、ストレージがボトルネックであることを示しています。ストレージクラスのアドバイザリースレッショルドは、フラグとして 1,000 持続的な IOPS です。詳細については、「mongot のストレージクラスの推奨事項」を参照してください。
ページ フォールト率。1、000/s を超える持続的な検索ページ フォールトは、OS がキャッシュからではなく、ディスクからインデックス ページを繰り返し取得していることを示します。IOPS が上昇すると、これはクリティカル パス上のメモリの圧力の標準的なシグナルです。
インデックスボリュームの空きディスク容量
mongot dataPath ボリュームの空き容量が 20% 未満になると、可用性の問題が発生する可能性があります。マージには、ライブ インデックスのフットプリントを超えるディスク スペースが必要になる場合があります。ボリュームのサイズが不十分な場合、シレント フェイルアが発生する可能性があります。
ヘルシーシグナル
安定状態の健全なmongot配置には、次のシグナルがあります。
プロセスは稼働しており、正常性は
SERVINGです。レプリケーションラグは常に 1 秒未満です。
クエリ p99 のレイテンシは日を通じて安定しており、上昇していません。
エキスキューター プール キューの深さは常にゼロに近い値です。
JVM のポスト GC ヒープは、設定された最大値を大幅に下回っています。
インデックスの作成操作は予想される時間内に終了し、
READYで完了します。既知の無害なメッセージ以外のエラーは mongot ログにはありません。
これらがすべて真である場合、配置は正常とみなされます。ズレがある場合は、詳細なメトリクスについて調査するための関連ページを参照してください。
Atlas と自己管理型の可視性
Atlas ユーザーは、次のものを持っています。
Atlas Search メトリクス UI。
キュレーションされたするどかのスレッショルドに対する MongoDB マネージドアラート。
mongotFTDC とログに直接アクセスできる Atlas サポート。
自己管理型ユーザーは、次のようになっています。
エクスポートするように構成したメトリクスとログ
mongot。接続するアラートプラットフォーム。
サポートが必要な場合は、FTDC のキャプチャと MongoDB サポートへの転送の責任。
自己管理型ユーザーは、本番環境に移行する前にモニタリングを設定する必要があります。