/ /

mongot ログと FTDC

mongot MongoDB Search と MongoDB ベクトル検索の問題の診断に役立つ 2 つのオンホスト診断サーフェースを公開します。

ログ: 警告やエラーを含むmongotのアクティビティの人間が読み取れるレコード。
FTDC (Full Time Diagnostic Data Capture): 毎秒詳細な内部状態をキャプチャするバイナリ診断ストリームで、サポートの引き継ぎを目的としています。

ログを使用して事故を調査し、MongoDB Supportケースを準備する際に両方のサーフェースをキャプチャします。

ログ

mongot ログには、警告やエラーを含むプロセスアクティビティが記録されます。ログを使用して、スタートアップが完了したことを確認し、安定状態の健康状態をモニターし、障害を調査します。

ログの送信先

mongot がログを書き込む場所は、配置の種類によって異なります。

配置タイプ	デフォルトの宛先
Linux tarball	`stdout` `mongot` YAML 構成で `logging.logPath` を設定した場合は `stderr` またはファイル。
コンテナ	`stdout` および `stderr`。`docker logs <container>` を使用してログを検索します。
`atlas-local`	`stdout` とコンテナ内の `stderr`。`docker logs` を使用してログを検索します。
Kubernetes 演算子	`stdout` およびポッドの `stderr`。`kubectl logs <pod>` を使用してログを取得し、クラスターログプラットフォームに転送します。

ログの冗長度

mongot 構成ファイルで指定された logging.verbosity オプションは、次のレベルを受け入れます。

レベル	使用ケース
`DEBUG`	特定の障害を調査する場合。このレベルは日単位ではなく時単位で維持します。
`ERROR`	`WARN` の問題のコンテキストが失われるため、本番環境に適していることはほとんどありません。
`INFO`	デフォルト.本番に適しています。
`TRACE`	エンジニアリングとサポートのみの詳細な調査。非常に冗長です。
`WARN`	ログのボリュームを削減し、エラーについて分離したアラートを設定する必要がある場合。

mongot スタートアップ時の冗長を読み取ります。変更するには、mongotを再起動します。

ログ形式

mongot 構造化された JSON ログを出力します。1 行に 1 つの JSON オブジェクトが含まれます。この形式により、mongot ログは mongod 構造化ログ形式と一致します。

各mongotログエントリには、t、s、svc、ctx、n、msg、および任意のattrなどのフィールドが含まれます。例:

{"t":"2026-06-22T14:03:41.582+0000","s":"INFO","svc":"MONGOT","ctx":"indexing-lifecycle-0","n":"com.xgen.mongot.replication.mongodb.initialsync.BufferlessInitialSyncManager","msg":"Beginning initial sync.","attr":{"startTime":"2026-06-22T14:03:41.582+0000","indexGenerationId":"6857f3b6e4b04c2a9d1f0a12-f6-u0-a0"}}

各ログオブジェクトには、次のフィールドが含まれます。

フィールド	説明
`t`	UTC と ISO-8601 形式のタイムスタンプ。
`s`	重大度。`TRACE`、`DEBUG`、`INFO`、`WARN`、`ERROR` のいずれか。
`svc`	`MONGOT`など、エントリを出力したサービス。
`ctx`	スレッドやタスク名などの実行コンテキスト。
`n`	ロガー名。
`msg`	人間が読み取れるメッセージ。
`attr`	任意イベント固有の構造化された属性（`startTime`、`numQueued`、`indexGenerationId`など）。`mongot`は、null 値と空の値を省略します。

スタートアップで注目すべき点

健康な mongot スタートアップでは、デフォルトの INFO 冗長で識別可能なイベントのシーケンスが出力されます。特定の文字列ではなく、これらのイベントを探してください。

イベント	メッセージテキスト
インデックスの最初の同期が開始されます	`Beginning initial sync.` `BufferlessInitialSyncManager`から、`attr.startTime`と`attr.indexGenerationId`を使用します。
最初の同期キューのアクティビティ	`Queued initial syncs.` `InitialSyncQueue` から `attr.numQueued` を使用して。
スタートアップ時のディスクベースの再起動チェック	`Replication URIs unavailable, skipping disk-based restart check` `DefaultConfigManager`からを使用します。レプリケーションの接続中に一時的に予想されます。
shutdown	`Shutting down.` `DefaultConfigManager` からのグレースフルシャットダウン時。

スタートアップ時に追加の情報行が表示されます。前述のイベントは、検証のための負荷の高いイベントです。

次の指示は、スタートアップが完了しなかったことを示しています。

インジケーター	アクション
クラスターにインデックスされたコレクションがあるにもかかわらず、`Beginning initial sync.` イベントは表示されません。`mongot` は最初の同期ステージに達していません。	ログの前の方で認証またはレプリケーション URI エラーを探します。
`Beginning initial sync.` イベントの後に `Exception requiring resync` または `InitialSyncException` が続きます。同期は開始されましたが失敗しました。	対処するには、自己管理型 mongot 配置のトラブルシューティング。を参照してください。
`Replication URIs unavailable, skipping disk-based restart check` メッセージが数秒以上繰り返されます。`mongot` は `mongod` の構成を待機しています。	`mongod` `mongotHost` パラメータを確認します。

安定状態で注意する点

安定状態では、正常なログはほとんど出力されません。マージやFTDCティックなどのバックグラウンドタスクからの定期的な情報メッセージ、および一時的なクライアントの動作に対するための時々のWARNエントリが出力されることが予想されます。ERRORまたはExceptionエントリが出力されることはありません。

次の定常状態のログパターンには注意が必要です。

パターン	意味
`Exception requiring resync occurred during steady state replication` (`SteadyStateException`)	`mongot` oplog 内の位置を失い、再同期しています。`mongod` oplog が小さすぎるか、`mongot` の速度が遅すぎるために oplog がロールオーバーしたか、ダウンストリームエラーが発生したかのいずれかです。サポートのために周辺 5 分間をキャプチャします。
`CollectionScan died due to position in capped collection being deleted` (`CappedPositionLost`, error 136)	oplog は `mongot` が追いつく前にロールオーバーしました。`mongod` oplog サイズを増やすか、上流の低速 `mongot` の原因を修正するか、またはその両方を行います。
`Dropping all pooled connections to <host>:<port> due to ShutdownInProgress`	`mongod`の再起動中は通常です。対応する`mongod`の再起動がないのに頻繁に繰り返し発生する場合は、接続プールの問題があることを示します。
ドキュメントマッピングの爆発	インデックスでは、フィールドが多すぎるドキュメントが検出されました。これは、ダイナミックマッピングがオンになっていて、ドキュメントに任意のキーが含まれている場合によく発生します。インデックスが停滞するか、`mongot` のメモリが不足する可能性があります。

これらのパターンを修復手順にマップするには、自己管理型 mongot 配置のトラブルシューティングを参照してください。

ログの検索

mongotログは JSON であるため、jqはログを検索するのに最も自然なツールです。次の例は一般的なクエリを示しています。

# All errors
jq 'select(.s == "ERROR")' mongot.log
# Initial sync activity
jq 'select(.msg | startswith("Beginning initial sync"))' mongot.log
# Replication or sync from specific loggers
jq 'select(.n | test("BufferlessInitialSyncManager|InitialSyncQueue|InitialSyncManager"))' mongot.log
# Resync events
jq 'select(.msg | test("requiring resync|InitialSyncException|SteadyStateException"))' mongot.log
# Connection-pool churn
jq 'select(.msg | test("Dropping all pooled connections|ShutdownInProgress"))' mongot.log
# Embedding-related entries
jq 'select(.msg | test("embedding|voyage"; "i"))' mongot.log

JSON は単一行であるため、grep も機能します。

grep '"s":"ERROR"' mongot.log
grep '"msg":"Beginning initial sync\.' mongot.log
grep -E '"n":"[^"]*(BufferlessInitialSyncManager|InitialSyncQueue)' mongot.log

Elasticsearch、Splunk、DataDogなどのログプラットフォームの場合は、テキストではなく、s:ERROR、n:<logger>、またはattr.<key>でフィルターします。フィールドは安定していますが、フルテキストのパターンはリリース間で移動する可能性があります。

複数の mongot インスタンスを実行する配置の場合は、インスタンス識別子をログ転送タグに含めて、インスタンスでフィルターできるようにします。

ログ分析のヒント

mongotログを分析する際は、次の点に留意してください。

ログには、メッセージ内にインデックス名が常に含まれるとは限りません。インデックスの作成の失敗の場合、関連するログ行は同じロガーコンテキストの前後の複数行に表示される可能性があります。1 行ではなく、ウィンドウをキャプチャします。
同じ時間内の mongot ログと mongod ログを交叉参照します。多くの mongot エラーは mongod イベントのダウンストリームです。
MongoDB Supportケースを開く場合は、フィルターされたERROR行のセットではなく、完全なログファイルまたは幅広い時間ウィンドウを送信してください。

FTDC

FTDC は、詳細な内部状態を毎秒ディスクにキャプチャするバイナリ診断ストリームです。FTDC は、MongoDB テクニカルサービスチームが mongot の問題を診断するために使用する正規アーティファクトです。

FTDC に含まれるもの

FTDC サンプルには、Prometheus メトリクスと同じカテゴリのデータと、mongot が外部に公開しない内部状態が含まれます。

ヒープ、ガーベージコレクション、スレッドなどを含むプロセスと JVM の状態
インデックスごとのインデックスの作成統計
演算子ごとのクエリレイテンシ
レプリケーション状態と oplog の位置
エキスキュータープール状態
Lucene のマージとキャッシュの状態
構成とライフサイクルイベント
接続プールの状態

FTDC ファイルのロケーション

デフォルトでは、mongot は <storage.dataPath>/diagnostic.data/ に FTDC ファイルを書き込みます。これは mongod が <storage.dbPath>/diagnostic.data/ で使用するのと同じ規約です。

storage.dataPath が /var/lib/mongot に設定されている mongot インスタンスの場合、FTDC ファイルは /var/lib/mongot/diagnostic.data/ にあります。

mongot タイムスタンプ付きのファイルに名前を付け、自動的にローテートします。ファイルサイズは通常、次のとおりです。

1 ファイルあたり数百 KB
負荷時に 1 時間あたり複数のファイル
ロードに応じて、mongot インスタンスあたり 1 日に約 1 GB

ディスク上の FTDC アーカイブディレクトリの合計サイズは advancedConfigs.ftdc.directorySizeMb によって制限されます。

重要

mongot FTDC ファイルを自動的にローテートします。インシデント中に FTDC ファイルを手動で削除しないでください。MongoDB Support チームは、問題の診断時に FTDC ファイルを要求します。

FTDC の構成

FTDC はデフォルトで有効になっています。デフォルトを上書きするには、mongot YAML 構成の advancedConfigs.ftdc ブロックの下に次のオプションを設定します。

オプション	default	説明
`enabled`	`true`	FTDC を有効にします。`false` の場合、`mongot` は FTDC データをキャプチャしません。
`directorySizeMb`	`100`	FTDC アーカイブディレクトリの合計サイズの最大値（メガバイト）。`10`以上かつ`fileSizeMb`より大きい値である必要があります。
`fileSizeMb`	`10`	個別の FTDC アーカイブファイルの最大サイズ（メガバイト）。`1` 以上かつ `directorySizeMb` 未満である必要があります。
`collectionPeriodMillis`	`1000`	`mongot`がFTDCにメトリクスを収集する間隔をミリ秒単位で指定します。最低でも `100` である必要があります。

ほとんどの配置では、デフォルトが適切です。特定のディスク使用要件がある場合にのみ上書きします。これらの設定の詳細については、詳細 FTDC 設定を参照してください。

サポートの FTDC をキャプチャする

MongoDB サポートでケースを開く場合は、問題の期間を含む影響を受けた mongot インスタンスの diagnostic.data/ ディレクトリ全体を送信します。ディレクトリをバンドルして圧縮します。

Linux tarball 配置の場合は、ディレクトリをバンドルします。

tar -czf mongot-ftdc-$(hostname)-$(date -u +%Y%m%dT%H%M%S).tar.gz <dataPath>/diagnostic.data/

コンテナ配置の場合は、まずコンテナからディレクトリをコピーします。

docker cp <container>:/<dataPath>/diagnostic.data ./mongot-ftdc
tar -czf mongot-ftdc.tar.gz ./mongot-ftdc

Kubernetes Operator の配置の場合は、まずディレクトリをポッドからコピーします。

kubectl cp <namespace>/<pod>:<dataPath>/diagnostic.data ./mongot-ftdc
tar -czf mongot-ftdc.tar.gz ./mongot-ftdc

サポートケースには、次の項目を含めます。

FTDCバンドル。
同じ時間ウィンドウをカバーする mongot ログファイルと、その 1 時間前のバッファー。
プライマリ上の同じウィンドウをカバーする mongod ログファイル。
mongot バージョン、mongod バージョン、およびある場合は Kubernetes 演算子バージョン。
問題を最初に観測した時のタイムスタンプ。
その時の配置、トラフィック、アップグレードなど、配置で変更された内容の説明。

FTDC 内の機密データ

FTDC には、生のドキュメントデータやユーザークエリ文字列ではなく、操作メトリクスと内部状態が含まれています。FTDC は、通常、無傷化せずに MongoDB Support に送信しても安全です。コンプライアンスポリシーがより厳しい場合は、キャプチャされたフィールドを送信する前にセキュリティチームと共に検討してください。

ログについては同じことはありません。ログ行には、ログレベルに応じて、クエリテキスト、ドキュメント識別子、またはその他のアプリケーションレベルのデータが含まれる可能性があります。制限のあるコンプライアンス環境下でログファイルを送信する前に、ログファイルを検討します。

戻る

mongot メトリクス参照

推奨アラート