AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
See how MongoDB 9.0 delivers up to 2x higher throughput.
MongoDB Branding Shape
Register now >
Docs Menu

ログ メッセージ

MongoDB は、着信接続、実行されたコマンド、発生した問題などのエントリを含む、イベントの実行中のログを通常の操作の一部として保持します。一般的に、ログ メッセージは、問題の診断、デプロイのモニタリング、パフォーマンスの調整に役立ちます。

ログ メッセージを取得するには、次のいずれかの方法を使用できます。

mongod / mongosインスタンスはすべてのログ メッセージを構造化された JSON 形式で出力します。 Log entries are written as a series of key-value pairs, where each key indicates a log message field type, such as "severity", and each corresponding value records the associated logging information for that field type, such as "informational". Previously, log entries were output as plaintext.

例

以下に、MongoDB ログファイルに表示される JSON 形式のログ メッセージの例を示します。

{"t":{"$date":"2020-05-01T15:16:17.180+00:00"},"s":"I", "c":"NETWORK", "id":12345, "ctx":"listener", "msg":"Listening on","attr":{"address":"127.0.0.1"}}

JSON ログ エントリーは、読みやすくするためにpretty- printすることができます。 以下は、同じログ エントリーのpretty-printed です。

{
"t": {
"$date": "2020-05-01T15:16:17.180+00:00"
},
"s": "I",
"c": "NETWORK",
"id": 12345,
"ctx": "listener",
"msg": "Listening on",
"attr": {
"address": "127.0.0.1"
}
}

たとえば、このログ エントリでは、重大度を表すキー s には、"情報" を表す値 I があり、コンポーネントを表すキー c には、この特定のメッセージの原因が "ネットワーク" コンポーネントであることを示す値 NETWORK があります。さまざまなフィールドの型については、「ログ メッセージのフィールドの型」セクションで詳しく説明します。

キーと値のペアによる構造化されたロギングにより、自動ツールやログ取り込みサービスによる効率的な解析が可能になり、プログラムによるログ メッセージの検索と分析が容易になります。構造化ログ メッセージの分析例については、「構造化ログ メッセージの解析」セクションを参照してください。

注意

mongod は、ログファイルに書き込みを行えない場合、終了します。mongod がログファイルに確実に書き込みを行えるようにするには、ログ ボリューム内にディスクの空き領域があり、ログがローテーションされていることを確認します。

すべてのログ出力は JSON 形式で送信されます。以下は送信先の例です。

getLog コマンドによる出力も JSON 形式です。

各ログ エントリの出力は、Relaxed Extended JSON v2.0 仕様に準拠した自己完結型の JSON オブジェクトで、レイアウトとフィールド順序は以下の通りです。

{
"t": <Datetime>, // timestamp
"s": <String>, // severity
"c": <String>, // component
"id": <Integer>, // unique identifier
"ctx": <String>, // context
"msg": <String>, // message body
"attr": <Object> // additional attributes (optional)
"tags": <Array of strings> // tags (optional)
"truncated": <Object> // truncation info (if truncated)
"size": <Object> // original size of entry (if truncated)
}

フィールドの説明

フィールド名
タイプ
説明

t

日時

ISO-8601形式のログ メッセージのタイムスタンプ。例については、「タイムスタンプ」を参照してください。

s

文字列

ログ・メッセージの短い重大度コードです。例については、「重大度」を参照してください。

c

文字列

ログ メッセージの完全なコンポーネント string です。 例については、「コンポーネント 」を参照してください。

id

整数

ログ ステートメントのユニークな識別子です。例については、「既知のログ ID によるフィルタリング」を参照してください。

ctx

文字列

ログ ステートメントを生成したスレッド名

msg

文字列

サーバーまたはドライバーから渡されたログ出力メッセージ。 必要に応じて、メッセージは JSON 仕様に従ってエスケープされます。

attr

オブジェクト

追加のログ属性の 1 つ以上のキーと値のペア。ログ メッセージに追加の属性が含まれていない場合、attr オブジェクトは省略されます。

属性値は、メッセージに応じて、msg メッセージ本文内のキー名で参照される場合があります。必要に応じて、属性は JSON 仕様に従ってエスケープされます。

tags

文字列の配列

ログ ステートメントに適用可能なタグを表す文字列。たとえば、["startupWarnings"] 。

truncated

オブジェクト

該当する場合、ログ メッセージの切り捨てに関する情報。切り捨てられた attr 属性がログ エントリに少なくとも 1 つある場合にのみ含まれます。

size

オブジェクト

ログ エントリが切り捨てられた場合の元のサイズです。切り捨てられた attr 属性がログ エントリに少なくとも 1 つある場合にのみ含まれます。

メッセージ フィールドと属性フィールドは、必要に応じて緩和 拡張 JSON v2.0 の仕様に従って制御文字をエスケープします。

表現された文字
エスケープ シーケンス

引用符(")

\"

Backslash (\)

\\

バックスペース(0x08)

\b

フォームフィード(0x0C)

\f

改行(0x0A)

\n

キャリッジ リターン(0x0D)

\r

Horizontal tab (0x09)

\t

上記に記載されていない制御文字は \uXXXX でエスケープされます(XXXX は 16 進数で表された Unicode コードポイントです)。UTF-8 エンコーディングが無効なバイトは、\ufffd で表される Unicode の置換文字で置き換えられます。

メッセージのエスケープの例は、例のセクションに記載されています。

maxLogSizeKB で定義された最大サイズ(デフォルト: 10 KB)を超えた属性は切り捨てられます。切り捨てられた属性では、設定された制限を超えるログデータは省略されますが、引き続きエントリを解析可能な状態に保つために、エントリの JSON 形式は保持されます。

以下は、属性が切り捨てられたログエントリーの例です。

{"t":{"$date":"2020-05-19T18:12:05.702+00:00"},"s":"I", "c":"SHARDING", "id":22104, "ctx":"conn33",
"msg":"Received splitChunk request","attr":{"request":{"splitChunk":"config.system.sessions",
"from":"production-shard1","keyPattern":{"_id":1},"epoch":{"$oid":"5ec42172996456771753a59e"},
"shardVersion":[{"$timestamp":{"t":1,"i":0}},{"$oid":"5ec42172996456771753a59e"}],"min":{"_id":{"$minKey":1}},
"max":{"_id":{"$maxKey":1}},"splitKeys":[{"_id":{"id":{"$uuid":"00400000-0000-0000-0000-000000000000"}}},
{"_id":{"id":{"$uuid":"00800000-0000-0000-0000-000000000000"}}},
...
{"_id":{"id":{"$uuid":"26c00000-0000-0000-0000-000000000000"}}},{"_id":{}}]}},
"truncated":{"request":{"splitKeys":{"155":{"_id":{"id":{"type":"binData","size":21}}}}}},
"size":{"request":46328}}

この例では、request 属性は切り捨てられ、切り捨てのトリガーとなったサブフィールド _id の特定のインスタンス(属性が maxLogSizeKB をオーバーランする原因となった)は、データなしで{"_id":{}} として出力され、request 属性の残りの部分は省略されます。

切り捨てられた属性が 1 つ以上含まれているログエントリには、ログエントリ内で切り捨てられた各属性に関して以下の情報を提供する truncated オブジェクトが含まれます。

  • 切り捨てられた属性

  • 切り捨てのトリガーとなった属性の特定のサブオブジェクト(該当する場合)

  • 切り捨てられたフィールドのデータ type

  • 切り捨てられたフィールドの size

また、切り捨てられた属性を含むログエントリの末尾に、size フィールドが追加されることがあります。このフィールドは、切り捨てられる前の属性の元のサイズを示しており、この場合は 46328 または約 46 KB です。この末尾に追加される size フィールドは、このフィールドが truncated オブジェクトの size フィールドと異なる場合にのみ表示されます。つまり、上の例のように、属性のオブジェクト全体のサイズと、切り捨てられたサブオブジェクトのサイズが異なる場合に表示されるということです。

ファイルまたは Syslog のログの送信先に出力する場合、等幅フォントで表示した際の読みやすさを高めるために、重大度、コンテキスト、ID の各フィールドの後にパディングが追加されます。

以下は、このパディングを示す MongoDB ログファイルの抜粋です。

{"t":{"$date":"2020-05-18T20:18:12.724+00:00"},"s":"I", "c":"CONTROL", "id":23285, "ctx":"main","msg":"Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'"}
{"t":{"$date":"2020-05-18T20:18:12.734+00:00"},"s":"W", "c":"ASIO", "id":22601, "ctx":"main","msg":"No TransportLayer configured during NetworkInterface startup"}
{"t":{"$date":"2020-05-18T20:18:12.734+00:00"},"s":"I", "c":"NETWORK", "id":4648601, "ctx":"main","msg":"Implicit TCP FastOpen unavailable. If TCP FastOpen is required, set tcpFastOpenServer, tcpFastOpenClient, and tcpFastOpenQueueSize."}
{"t":{"$date":"2020-05-18T20:18:12.814+00:00"},"s":"I", "c":"STORAGE", "id":4615611, "ctx":"initandlisten","msg":"MongoDB starting","attr":{"pid":10111,"port":27001,"dbPath":"/var/lib/mongo","architecture":"64-bit","host":"centos8"}}
{"t":{"$date":"2020-05-18T20:18:12.814+00:00"},"s":"I", "c":"CONTROL", "id":23403, "ctx":"initandlisten","msg":"Build Info","attr":{"buildInfo":{"version":"4.4.0","gitVersion":"328c35e4b883540675fb4b626c53a08f74e43cf0","openSSLVersion":"OpenSSL 1.1.1c FIPS 28 May 2019","modules":[],"allocator":"tcmalloc","environment":{"distmod":"rhel80","distarch":"x86_64","target_arch":"x86_64"}}}}
{"t":{"$date":"2020-05-18T20:18:12.814+00:00"},"s":"I", "c":"CONTROL", "id":51765, "ctx":"initandlisten","msg":"Operating System","attr":{"os":{"name":"CentOS Linux release 8.0.1905 (Core) ","version":"Kernel 4.18.0-80.11.2.el8_0.x86_64"}}}

MongoDB 構造化ロギングを使用する際には、サードパーティの jq コマンドライン ユーティリティを利用して、ログ エントリを簡単にプリティプリントし、強力なキーベースのマッチングとフィルタリングを実行できます。

jq はオープンソースの JSON パーサーで、Linux、Windows、macOS で利用できます。

次のように、jq を使用してログ エントリーを pretty-print できます。

  • ログファイル全体をpretty-printする

    cat mongod.log | jq
  • 最新のログ エントリーをpretty-printする

    cat mongod.log | tail -1 | jq

MongoDB 構造化ログのその他の例については、「構造化ログ メッセージの解析 」セクションを参照してください。

MongoDB ログ メッセージは、ファイル、syslog、stdout(標準出力)のいずれかに出力できます。

ログの出力先を設定するには、構成ファイルまたはコマンドラインで以下のいずれかの設定を使用します。

構成ファイル
コマンドライン

ファイルかsyslogのどちらかを指定しない場合、すべてのログ出力が stdout に送信されます。

以下で、ログ設定とオプションの全リストを参照できます。

構成ファイル
コマンドライン

注意

ファイルや syslog のログの保存先を使用していない場合に起こった起動時の致命的なエラーや、ログ設定の誤りに関連するメッセージなど、stderr(標準エラー)に送信されるエラー メッセージは、ログ出力先の設定の影響を受けず、プレーンテキスト形式で stderr に出力されます。

タイムスタンプ フィールド タイプは、ログに記録されたイベントが発生した正確な日時を示します。

{
"t": {
"$date": "2020-05-01T15:16:17.180+00:00"
},
"s": "I",
"c": "NETWORK",
"id": 12345,
"ctx": "listener",
"msg": "Listening on",
"attr": {
"address": "127.0.0.1"
}
}

ファイル または syslog [1] にログを記録する場合、タイムスタンプのデフォルト形式は iso8601-local です。タイムスタンプの形式を変更するには、--timeStampFormat ランタイム オプションか、systemLog.timeStampFormat 設定を使用します。

タイムスタンプ フィールドでフィルタリングするログ解析の例については、「日付範囲によるフィルタリング」を参照してください。

注意

ctime タイムスタンプ形式はサポートされなくなりました。

[1] syslog にログを記録する場合、タイムスタンプは MongoDB によりメッセージが発行されたときではなく、syslog デーモンによりメッセージが記録されたときに生成されます。そのため、特にシステムの負荷が高い場合に、ログ エントリのタイムスタンプが不正確になることがあります。

重大度フィールド タイプは、ログに記録されたイベントに関する重大度レベルを示します。

{
"t": {
"$date": "2020-05-01T15:16:17.180+00:00"
},
"s": "I",
"c": "NETWORK",
"id": 12345,
"ctx": "listener",
"msg": "Listening on",
"attr": {
"address": "127.0.0.1"
}
}

重大度レベルは、「致命的」(最も重大) から「デバッグ」(最も軽微) までの範囲です。

レベル
説明

F

致命的

E

エラー

エラーのログの詳細については、エラー コードを参照してください。

W

警告

I

情報、冗長レベル 0

D1 - D5

デバッグ、冗長レベル > 0

MongoDB は特定のデバッグ冗長レベルを示します。たとえば、冗長レベルが 2 の場合、MongoDB は D2 を示します。

以前のバージョンでは、MongoDB のログメッセージでは、デバッグの冗長レベルにすべて D が指定されていました。

さまざまなコンポーネントの冗長レベルを指定して、MongoDB が出力する情報メッセージとデバッグメッセージの量を決定できます。これらのレベルを超える重大度カテゴリは常に表示されます。[2] 冗長レベルを設定するには、「ログの冗長レベルの設定」を参照してください。

コンポーネント フィールド タイプは、NETWORK や COMMAND など、ログに記録されたイベントが属するカテゴリを示します。

{
"t": {
"$date": "2020-05-01T15:16:17.180+00:00"
},
"s": "I",
"c": "NETWORK",
"id": 12345,
"ctx": "listener",
"msg": "Listening on",
"attr": {
"address": "127.0.0.1"
}
}

各コンポーネントは、独自の冗長フィルターを介して個別に設定できます。使用可能なコンポーネントは次のとおりです。

ACCESS

認証などのアクセス制御に関連するメッセージです。ACCESS コンポーネントのログ レベルを指定するには、systemLog.component.accessControl.verbosity 設定を使用します。

ASSERT

アサーションは、操作がエラーを返したときにトリガーされます。デフォルトの冗長レベルは 0 です。ただし、エラーを返す操作をシステム ログに含めるには、冗長設定が少なくとも 1 である必要があります。ACCESS コンポーネントのログレベルを指定するには、assert 設定を使用します。

COMMAND

データベース コマンドに関連するメッセージです(countなど)。COMMANDコンポーネントのログ レベルを指定するには、systemLog.component.command.verbosity 設定を使用します。

CONTROL

初期化などの制御アクティビティに関連するメッセージです。CONTROL コンポーネントのログ レベルを指定するには、systemLog.component.control.verbosity 設定を使用します。

ELECTION

レプリカセットの選挙に特に関連するメッセージです。ELECTIONコンポーネントのログ レベルを指定するには、systemLog.component.replication.election.verbosityパラメーターを設定します。

REPL は、ELECTION の親コンポーネントです。systemLog.component.replication.election.verbosityが設定されていない場合、MongoDB は REPL の冗長レベルを ELECTION コンポーネントに対して使用します。

FTDC

サーバー統計やステータス メッセージなど、診断データ コレクション メカニズムに関連するメッセージです。FTDC コンポーネントのログ レベルを指定するには、systemLog.component.ftdc.verbosity 設定を使用します。

GEO

GeoJSON の形状の検証など、地理空間の形状の解析に関連するメッセージです。GEOコンポーネントのログ レベルを指定するには、systemLog.component.geo.verbosityパラメーターを設定します。

INDEX

インデックスの作成など、インデックス関連の操作に関連するメッセージです。INDEXコンポーネントのログ レベルを指定するには、systemLog.component.index.verbosityパラメーターを設定します。

INITSYNC

最初の同期操作に関連するメッセージです。INITSYNCコンポーネントのログ レベルを指定するには、systemLog.component.replication.initialSync.verbosityパラメーターを設定します。

REPL は、INITSYNC の親コンポーネントです。systemLog.component.replication.initialSync.verbosityが設定されていない場合、MongoDB は REPL の冗長レベルを INITSYNC コンポーネントに対して使用します。

JOURNAL

ストレージ ジャーナリング アクティビティに特に関連するメッセージです。JOURNAL コンポーネントのログ レベルを指定するには、systemLog.component.storage.journal.verbosity 設定を使用します。

STORAGE は、JOURNAL の親コンポーネントです。systemLog.component.storage.journal.verbosityが設定されていない場合、MongoDB は STORAGE の冗長レベルを JOURNAL コンポーネントに対して使用します。

NETWORK

接続の受け入れなど、ネットワーク アクティビティに関連するメッセージです。NETWORKコンポーネントのログ レベルを指定するには、systemLog.component.network.verbosityパラメーターを設定します。

QUERY

クエリ プランナーのアクティビティなど、クエリに関連するメッセージです。QUERYコンポーネントのログ レベルを指定するには、systemLog.component.query.verbosityパラメーターを設定します。

QUERYSTATS

$queryStats操作に関連するメッセージです。 QUERYSTATSコンポーネントのログ レベルを指定するには、 systemLog.component.queryStats.verbosityパラメーターを設定します。

RECOVERY

ストレージの復旧活動に関連するメッセージです。RECOVERY コンポーネントのログ レベルを指定するには、systemLog.component.storage.recovery.verbosity 設定を使用します。

STORAGE は、RECOVERY の親コンポーネントです。systemLog.component.storage.recovery.verbosityが設定されていない場合、MongoDB は STORAGE の冗長レベルを RECOVERY コンポーネントに対して使用します。

REPL

最初の同期、ハートビート、定常状態のレプリケーション、ロールバックなど、レプリカセットに関連するメッセージです。[2] REPLコンポーネントのログ レベルを指定するには、systemLog.component.replication.verbosityパラメーターを設定します。

REPLは、ELECTION、INITSYNC、REPL_HB 、ROLLBACKコンポーネントの親コンポーネントです。

REPL_HB

レプリカセットのハートビートに特に関連するメッセージです。REPL_HBコンポーネントのログ レベルを指定するには、systemLog.component.replication.heartbeats.verbosityパラメーターを設定します。

REPL は、REPL_HB の親コンポーネントです。systemLog.component.replication.heartbeats.verbosityが設定されていない場合、MongoDB は REPL の冗長レベルを REPL_HB コンポーネントに対して使用します。

ROLLBACK

ロールバック操作に関連するメッセージです。ROLLBACKコンポーネントのログ レベルを指定するには、systemLog.component.replication.rollback.verbosityパラメーターを設定します。

REPL は、ROLLBACK の親コンポーネントです。systemLog.component.replication.rollback.verbosityが設定されていない場合、MongoDB は REPL の冗長レベルを ROLLBACK コンポーネントに対して使用します。

SHARDING

シャーディング アクティビティに関連するメッセージですmongosの起動など) SHARDINGコンポーネントのログ レベルを指定するには、 systemLog.component.sharding.verbosity設定を使用します。

STORAGE

fsync コマンドに関係するプロセスなど、ストレージ アクティビティに関連するメッセージです。STORAGE コンポーネントのログ レベルを指定するには、systemLog.component.storage.verbosity設定を使用します。

STORAGE は JOURNAL と RECOVERY の親コンポーネントです。

TXN

マルチドキュメントトランザクションに関連するメッセージです。TXN コンポーネントのログ レベルを指定するには、systemLog.component.transaction.verbosity 設定を使用します。

WRITE

update コマンドなどの書込み (write) 操作に関連するメッセージです。WRITE コンポーネントのログ レベルを指定するには、systemLog.component.write.verbosity設定を使用します。

WT

バージョン5.3の新機能。

WiredTiger ストレージ エンジンに関連するメッセージです。WT コンポーネントのログ レベルを指定するには、systemLog.component.storage.wt.verbosity 設定を使用します。

WTBACKUP

バージョン5.3の新機能。

WiredTiger ストレージ エンジンによって実行されるバックアップ操作に関連するメッセージです。WTBACKUPコンポーネントのログ レベルを指定するには、systemLog.component.storage.wt.wtBackup.verbosity設定を使用します。

WTCHKPT

バージョン5.3の新機能。

WiredTiger ストレージ エンジンによって実行されるチェックポイント操作に関連するメッセージです。WTCHKPT コンポーネントのログ レベルを指定するには、systemLog.component.storage.wt.wtCheckpoint.verbosity 設定を使用します。

WTCMPCT

バージョン5.3の新機能。

WiredTiger ストレージ エンジンによって実行される圧縮操作に関連するメッセージです。WTCMPCT コンポーネントのログ レベルを指定するには、systemLog.component.storage.wt.wtCompact.verbosity 設定を使用します。

WTEVICT

バージョン5.3の新機能。

WiredTiger ストレージ エンジンによって実行されるメモリ解放操作に関連するメッセージです。WTEVICT コンポーネントのログ レベルを指定するには、systemLog.component.storage.wt.wtEviction.verbosity 設定を使用します。

WTHS

バージョン5.3の新機能。

WiredTiger ストレージ エンジンの履歴ストアに関連するメッセージです。WTHS コンポーネントのログ レベルを指定するには、systemLog.component.storage.wt.wtHS.verbosity 設定を使用します。

WTRECOV

バージョン5.3の新機能。

WiredTiger storage engine によって実行されたリカバリ操作に関連するメッセージ。WTRECOV コンポーネントのログ レベルを指定するには、systemLog.component.storage.wt.wtRecovery.verbosity 設定を使用します。

WTRTS

バージョン5.3の新機能。

WiredTiger storage engine によって実行される安定状態へのロールバック(RTS)操作に関連するメッセージ。WTRTS コンポーネントのログ レベルを指定するには、systemLog.component.storage.wt.wtRTS.verbosity 設定を使用します。

WTSLVG

バージョン5.3の新機能。

WiredTiger storage engineによって実行されるサルベージ操作に関連するメッセージ。WTSLVG コンポーネントのログ レベルを指定するには、systemLog.component.storage.wt.wtSalvage.verbosity 設定を使用します。

WTTS

バージョン5.3の新機能。

WiredTiger storage engineで使用されるタイムスタンプに関連するメッセージ。WTTS コンポーネントのログ レベルを指定するには、systemLog.component.storage.wt.wtTimestamp.verbosity 設定を使用します。

WTTXN

バージョン5.3の新機能。

WiredTigerstorage engine によって実行されたトランザクションに関連するメッセージ。WTTXN コンポーネントのログ レベルを指定するには、systemLog.component.storage.wt.wtTransaction.verbosity 設定を使用します。

WTVRFY

バージョン5.3の新機能。

WiredTiger storage engine によって実行された検証操作に関連するメッセージ。WTVRFY コンポーネントのログ レベルを指定するには、systemLog.component.storage.wt.wtVerify.verbosity 設定を使用します。

WTWRTLOG

バージョン5.3の新機能。

WiredTiger storage engineによって実行されるログ書込み (write) 操作に関連するメッセージ。WTWRTLOG コンポーネントのログ レベルを指定するには、systemLog.component.storage.wt.wtWriteLog.verbosity 設定を使用します。

-

名前付きコンポーネントに関連付けられていないメッセージです。名前のないコンポーネントには、systemLog.verbosity 設定で指定されたデフォルトのログ レベルが適用されます。systemLog.verbosity設定は、名前付きコンポーネントと名前のないコンポーネント両方のデフォルト設定です。

コンポーネント フィールドでフィルタリングするログ解析の例については、「コンポーネントによるフィルタリング」を参照してください。

MongoDB ドライバーとクライアント アプリケーション(mongosh を含む)には、サーバーへの接続時に識別情報を送信する機能があります。接続が確立されると、接続が切断されて再確立されない限り、クライアントは識別情報を再度送信しません。

この識別情報は、ログエントリーの属性フィールドに含まれています。具体的にどのような情報が含まれるかは、クライアントによって異なります。

以下は、mongosh 接続から送信されたクライアント データ ドキュメントを含むサンプル ログ メッセージです。 クライアント データは、属性フィールドのdocオブジェクトに含まれています。

{"t":{"$date":"2020-05-20T16:21:31.561+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn202","msg":"client metadata","attr":{"remote":"127.0.0.1:37106","client":"conn202","doc":{"application":{"name":"MongoDB Shell"},"driver":{"name":"MongoDB Internal Client","version":"4.4.0"},"os":{"type":"Linux","name":"CentOS Linux release 8.0.1905 (Core) ","architecture":"x86_64","version":"Kernel 4.18.0-80.11.2.el8_0.x86_64"}}}}

レプリカセットのセカンダリがプライマリへの接続を開始すると、同様のデータが送信されます。以下は、この接続開始を含むサンプル ログ メッセージです。クライアント データは、属性フィールド内の doc オブジェクトに含まれています。

{"t":{"$date":"2020-05-20T16:33:40.595+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn214","msg":"client metadata","attr":{"remote":"127.0.0.1:37176","client":"conn214","doc":{"driver":{"name":"NetworkInterfaceTL","version":"4.4.0"},"os":{"type":"Linux","name":"CentOS Linux release 8.0.1905 (Core) ","architecture":"x86_64","version":"Kernel 4.18.0-80.11.2.el8_0.x86_64"}}}}

クライアント データを示す わかりやすい 例 については、「 例 」のセクション を参照してください。

クライアント情報と必須フィールドの説明については、「 MongoDB ハンドシェイク仕様」を参照してください。

ログの冗長レベルを指定することで、MongoDB が出力するログ メッセージの量を増減できます。冗長レベルは、すべてのコンポーネントに対してまとめて調整することも、特定の名前付きコンポーネントに対して個別に調整することもできます。

冗長度は、重大度カテゴリが情報およびデバッグのログ エントリにのみ影響します。これらのレベルを超える重大度カテゴリは常に表示されます。

冗長レベルの値を高く設定してデバッグや開発用に冗長なログを表示したり、低く設定して検証済みの本番環境でログへの書込みを最小限に抑えたりできます[2]。

現状の冗長レベルを表示するには、db.getLogComponents() メソッドを使用します。

db.getLogComponents()

出力は次のようになります。

{
"verbosity" : 0,
"accessControl" : {
"verbosity" : -1
},
"command" : {
"verbosity" : -1
},
...
"storage" : {
"verbosity" : -1,
"recovery" : {
"verbosity" : -1
},
"journal" : {
"verbosity" : -1
}
},
...

最初のverbosity エントリはすべてのコンポーネントの親の冗長レベルですが、それに続く accessControl などの個々の名前付きコンポーネントは、そのコンポーネントの特定の冗長レベルを示し、設定されている場合はその特定のコンポーネントのグローバル冗長レベルを上書きします。

-1 値は、コンポーネントが親の冗長レベルを持っている場合はそれを継承し(上記の recovery と同様、storage から継承)、継承しない場合はグローバル冗長レベル(command と同様)を継承することを示します。冗長レベルの継承関係は、コンポーネント セクションに示されます。

冗長レベルは、systemLog.verbosity および systemLog.component.<name>.verbosity 設定、logComponentVerbosity パラメータ、db.setLogLevel() メソッドのいずれかを使用して構成できます[2]。

すべてのコンポーネントのデフォルトのログ レベルを構成するには、systemLog.verbosity 設定を使用します。特定のコンポーネントのレベルを構成するには、systemLog.component.<name>.verbosity 設定を使用します。

たとえば、次の構成では、systemLog.verbosity が 1 に、systemLog.component.query.verbosity が 2 に、systemLog.component.storage.verbosity が 2 に、systemLog.component.storage.journal.verbosity が 1 に設定されます。

systemLog:
verbosity: 1
component:
query:
verbosity: 2
storage:
verbosity: 2
journal:
verbosity: 1

これらの値は、mongod または mongos インスタンスの構成ファイルかコマンド ラインで に設定します。

構成で明示的に指定されていないすべてのコンポーネントの冗長レベルは -1 です。つまり、親がある場合は親の冗長レベルを継承し、ない場合はグローバル冗長レベル(systemLog.verbosity)を使用します。

logComponentVerbosity パラメーターを設定するには、変更する冗長設定を含むドキュメントを渡します。

たとえば、次の例では、 default verbosity levelを1に、 queryを2に、 storageを2に、 storage.journalを1に設定します。

db.adminCommand( {
setParameter: 1,
logComponentVerbosity: {
verbosity: 1,
query: {
verbosity: 2
},
storage: {
verbosity: 2,
journal: {
verbosity: 1
}
}
}
} )

値は mongosh から設定します。

単一のコンポーネント ログ レベルを更新するには、db.setLogLevel() メソッドを使用します。コンポーネントには、0 から 5 までの冗長レベルを指定できます。また、親の冗長度を継承するには、-1 を指定します。たとえば、次の例では systemLog.component.query.verbosity をその親の冗長度(デフォルトの冗長度)に設定しています。

db.setLogLevel(-1, "query")

値は mongosh から設定します。

[2](1, 2, 3, 4)

replica setのセカンダリ メンバーは、適用に低速操作しきい値よりも長い時間がかかるoplogをログに記録するようになりました。 これらの遅い oplog メッセージ:

  • ログは、テキストapplied op: <oplog entry> took <num>msを含むREPLコンポーネントの下にあります。

  • ログレベルに依存しない(システムレベルでもコンポーネントレベルでも)

  • プロファイル レベルに依存しないでください。

  • slowOpSampleRateの影響を受けます。

プロファイラーは遅い oplog エントリをキャプチャしません。

クライアント操作(クエリなど)は、処理時間が低速操作しきい値を超えた場合、またはログの冗長レベルが 1 以上の場合にログに表示されます。[2] これらのログエントリには、操作に関連付けられた完全なコマンドオブジェクトが含まれます。

プロファイラー エントリと読み取り操作および書込み (write) 操作の診断ログ メッセージ(mongod/mongos ログ メッセージなど)には次のものが含まれます。

  • queryHash 同じクエリ形状を持つ低速クエリの特定に役立ちます。

  • planCacheKey 低速クエリのクエリプラン キャッシュに関する詳細なインサイトを提供します。

重要

1つの操作で、複数のエントリが記録される場合があります。たとえば、一括書き込み操作で複数の書き込みが低速操作のしきい値を超えた場合、それぞれの低速書き込みは個別にログに記録されます。

次の表は、スロー クエリのログに対する変更を一覧表示しています。

MongoDB バージョン
変更点

6.1

6.2

低速オペレーションログメッセージには、クエリを実行したクエリエンジンを示す queryFramework フィールドが含まれます。

  • queryFramework: "classic" は、クラシック エンジンでクエリが実行されたことを示します。

  • queryFramework: "sbe" はスロットベースのクエリ実行エンジンでクエリが実行されたことを示します。

6.3

低速操作ログメッセージとデータベースプロファイラーのエントリには、クエリ操作にかかった合計 CPU 時間をナノ秒単位で指定する cpuNanos フィールドが含まれています。cpuNanos フィールドは Linux システムでのみ使用できます。

7.0(および 6.0.13、5.0.24)

スロークエリログメッセージの totalOplogSlotDurationMicros は、書き込み操作がストレージエンジンの書き込みをコミットするためのコミットタイムスタンプを取得してから、実際にコミットするまでの時間を示しています。mongod は並列書き込みをサポートします。ただし、書込み (write) 操作はコミット タイムスタンプとともに任意の順序でコミットされます。

例えば、次のコミット タイムスタンプを持つ書き込みについて考えてみましょう。

  • 書込み A とタイムスタンプ 1

  • 書込み B とタイムスタンプ 2

  • 書込み C とタイムスタンプ 3

書込み B が タイムスタンプ 2 で最初にコミットするとします。レプリケーションは書込み A がコミットするまで一時停止します。レプリケーションでレプリカセットのセカンダリに oplog をコピーするには、書込み A の oplog エントリとタイムスタンプ 1 が必要なためです。

低速操作のログ エントリのわかりやすい例については、「ログ メッセージの例」を参照してください。

バージョン 5.0 の新機能。

MongoDB 5.0 以降では、remoteOpWaitMillis ログ フィールドを使用して、シャードから結果を受信するまでの待機時間(ミリ秒単位)を取得できます。

remoteOpWaitMillis は次の場合にのみログに記録されます。

低速クエリの原因がマージ操作かシャードの問題かを判断するには、ログ内の durationMillis 時間フィールドと remoteOpWaitMillis の時間フィールドを比較します。durationMillis はクエリが完了するまでにかかった合計時間です。具体的な説明は以下の通りです。

  • durationMillis が remoteOpWaitMillis よりわずかに長い場合、ほとんどの時間はシャード応答の待機に費やされたことになります。たとえば、durationMillis が 17 で、remoteOpWaitMillis が 15 の場合が挙げられます。

  • durationMillis が remoteOpWaitMillis よりもかなり長い場合、ほとんどの時間はマージを実行することに費やされたことになります。たとえば、durationMillis が 100 で、remoteOpWaitMillis が 15 の場合が挙げられます。

Queryable Encryption の使用中は、暗号化されたコレクションに対する CRUD 操作は低速クエリのログから省略されます。詳しくは、「Queryable Encryption のリダクション」を参照してください。

MongoDB AtlasおよびMongoDB Enterpriseでのみ利用可能

redactClientLogData を使用して実行中の mongod または mongos は、特定のログ イベントに付随するすべてのメッセージを、ログに記録する前にレダクションします。そのため、そのイベントに関連するメタデータ、ソース ファイル、行番号のみがログに記録されます。redactClientLogData は、診断に役立つ詳細情報を犠牲にして、機密情報の可能性がある情報がシステム ログに入力されるのを防ぎます。

たとえば、次の操作は、ログ リダクションなしで実行されている mongod にドキュメントを挿入します。mongod では、ログの冗長レベルは 1 に設定されています。

db.clients.insertOne( { "name" : "Joe", "PII" : "Sensitive Information" } )

この操作により、以下のログ イベントが発生します。

{
"t": { "$date": "2024-07-19T15:36:55.024-07:00" },
"s": "I",
"c": "COMMAND",
...
"attr": {
"type": "command",
...
"appName": "mongosh 2.2.10",
"command": {
"insert": "clients",
"documents": [
{
"name": "Joe",
"PII": "Sensitive Information",
"_id": { "$oid": "669aea8792c7fd822d3e1d8c" }
}
],
"ordered": true,
...
}
...
}
}

ともに実行されている mongod と redactClientLogData が、同じ挿入操作を実行すると、次のログ イベントが生成されます。

{
"t": { "$date": "2024-07-19T15:36:55.024-07:00" },
"s": "I",
"c": "COMMAND",
...
"attr": {
"type": "command",
...
"appName": "mongosh 2.2.10",
"command": {
"insert": "###",
"documents": [
{
"name": "###",
"PII": "###",
"_id": "###"
}
],
"ordered": "###",
...
}
...
}
}

規制要件への準拠に、redactClientLogData をを保存時の暗号化および TLS/SSL(トランスポート暗号化)と組み合わせて使用することが役立ちます。

ログ解析とは、プログラムによってログファイルを検索し、分析することで、多くの場合自動的に行われます。構造化ログの導入により、ログ解析の難易度が下がり、効果が向上しました。以下は、その例です。

  • ログ メッセージ フィールドはキーと値のペアとして表示されます。ログ・パーサーは、結果を効率的にフィルタリングするために、特定のキーでクエリを実行できます。

  • ログメッセージのメッセージ構造は、常に同じです。ログ パーサーは、あらゆるログメッセージから確実に情報を抽出できます。情報が欠落している場合や形式が異なる場合にコーディングが必要になることはありません。

次の例は、MongoDB の JSON ログ出力を扱う際の一般的なログ解析ワークフローです。

MongoDB 構造化ロギングを使用する際には、サードパーティの jq コマンドライン ユーティリティを利用して、ログ エントリを簡単にプリティプリントし、強力なキーベースのマッチングとフィルタリングを実行できます。

jq はオープンソースの JSON パーサーで、Linux、Windows、macOS で利用できます。

これらの例では、ログ解析を簡略化するために jq を使用しています。

特定のログファイル内のユニーク メッセージを出現頻度順に上位 10 件表示しています。

jq -r ".msg" /var/log/mongodb/mongod.log | sort | uniq -c | sort -rn | head -10

リモート クライアント接続は、属性オブジェクト内の「remote」キーの下のログに表示されます。次の例では、ログファイル全体のすべてのユニーク接続をカウントし、発生回数を降順に表示しています。

jq -r '.attr.remote' /var/log/mongodb/mongod.log | grep -v 'null' | sort | uniq -c | sort -r

同じ IP アドレスによる接続でも、異なるポートを経由する接続は、このコマンドでは異なる接続として扱われます。出力を IP アドレスのみを考慮したものに限るには、以下のように変更します。

jq -r '.attr.remote' /var/log/mongodb/mongod.log | grep -v 'null' | awk -F':' '{print $1}' | sort | uniq -c | sort -r

次の例では、すべてのリモート MongoDB ドライバー接続をカウントし、発生回数の降順で各ドライバーの種類とバージョンを表示します。

jq -cr '.attr.doc.driver' /var/log/mongodb/mongod.log | grep -v null | sort | uniq -c | sort -rn

次の例では、報告されたリモート MongoDB ドライバー接続とクライアント アプリケーション(mongosh を含む)のクライアント データを分析し、接続しているユニークなオペレーティング システムの種類ごとに、頻度順で合計を出力します。

jq -r '.attr.doc.os.type' /var/log/mongodb/mongod.log | grep -v null | sort | uniq -c | sort -rn

このログフィールドで報告されている「Darwin」という文字列は、macOS クライアントを示しています。

低速操作のログ記録を有効にすると、次の例では、さらなる分析のために、2000 ミリ秒以上かかった低速操作のみが返されます。

jq 'select(.attr.durationMillis>=2000)' /var/log/mongodb/mongod.log

この例に示されている jq フィルターの詳細については、「jq ドキュメント」を参照してください。

ログ コンポーネント(JSON ログ出力形式の 3 番目のフィールド)は、特定のログ メッセージが属する一般的なカテゴリを示します。コンポーネントによるフィルタリングは、ログ メッセージを解析して関連するイベントを探す際の出発点として最適です。

次の例では、コンポーネントタイプREPLのログ メッセージのみを出力します。

jq 'select(.c=="REPL")' /var/log/mongodb/mongod.log

次の例では、コンポーネントタイプ REPL 以外のすべてのログ メッセージを出力します。

jq 'select(.c!="REPL")' /var/log/mongodb/mongod.log

次の例では、コンポーネントタイプ REPL またはストレージのログ メッセージを出力します。

jq 'select( .c as $c | ["REPL", "STORAGE"] | index($c) )' /var/log/mongodb/mongod.log

この例に示されている jq フィルターの詳細については、「jq ドキュメント」を参照してください。

ログ ID(JSON ログ出力形式の 5 番目のフィールド)は特定のログ イベントにマッピングされ、MongoDB のリリースが変わっても安定した状態が維持されます。

たとえば、次の 2 つのログ イベントは、クライアント接続の後に切断が行われたことを示しています。

{"t":{"$date":"2020-06-01T13:06:59.027-0500"},"s":"I", "c":"NETWORK", "id":22943,"ctx":"listener","msg":"connection accepted from {session_remote} #{session_id} ({connectionCount}{word} now open)","attr":{"session_remote":"127.0.0.1:61298","session_id":164,"connectionCount":11,"word":" connections"}}
{"t":{"$date":"2020-06-01T13:07:03.490-0500"},"s":"I", "c":"NETWORK", "id":22944,"ctx":"conn157","msg":"end connection {remote} ({connectionCount}{word} now open)","attr":{"remote":"127.0.0.1:61298","connectionCount":10,"word":" connections"}}

これら 2 つのエントリのログ ID はそれぞれ 22943 と 22944 です。次に、以下の jq 構文を使用してログ出力をフィルタリングしてこれらのログ ID のみを表示することで、実質的にクライアント接続アクティビティのみを表示できます。

jq 'select( .id as $id | [22943, 22944] | index($id) )' /var/log/mongodb/mongod.log

この例に示されている jq フィルターの詳細については、「jq ドキュメント」を参照してください。

タイムスタンプ フィールドでログ出力をフィルタリングして、返ってきたログエントリを特定の日付範囲に制限することで、ログ出力をさらに絞り込むことができます。たとえば、次の例では、2020 年 4 月 15 日に発生したすべてのログ エントリが返されます。

jq 'select(.t["$date"] >= "2020-04-15T00:00:00.000" and .t["$date"] <= "2020-04-15T23:59:59.999")' /var/log/mongodb/mongod.log

この構文には、タイムゾーンオフセットを除いた、ミリ秒単位の完全なタイムスタンプが含まれることに注意してください。

日付範囲によるフィルタリングを上記の例と組み合わせることで、週次レポートや年ごとのサマリーなどを作成できます。次の構文は、前出の「接続モニタリング」の例を拡大して、結果を 2020 年 5 月の結果に限定したものです。

jq 'select(.t["$date"] >= "2020-05-01T00:00:00.000" and .t["$date"] <= "2020-05-31T23:59:59.999" and .attr.remote)' /var/log/mongodb/mongod.log

この例に示されている jq フィルターの詳細については、「jq ドキュメント」を参照してください。

ログ取り込みサービスは、ログファイルを通常は分散システムのクラスターから取り込んで集約し、そのデータを中央ロケーションで継続的に分析するサードパーティ製プロダクトです。

JSON ログ形式を使用すると、ログの取り込みサービスおよび分析サービスを使用する際の柔軟性が向上します。一般的に、プレーンテキストのログは、これらの製品で使用する前に何らかの変換を必要とするのに対し、JSON ファイルは、サービスにによってはそのまま使用できます。さらに、JSON 形式のログでは、キー値構造により、関心のあるフィールドを特定してインポートし、残りを省略できるため、これらのサービスでフィルタリングを実行する際、より詳細な制御が可能です。

詳しくは、お客様のサードパーティ製ログ取り込みサービスで提供されているドキュメントを参照してください。

以下は、JSON 形式で出力されたログ メッセージの例です。

これらのログ メッセージは、便宜上、 pretty-printed 形式で表示されます。

以下は、起動時の警告の例です。

{
"t": {
"$date": "2020-05-20T19:17:06.188+00:00"
},
"s": "W",
"c": "CONTROL",
"id": 22120,
"ctx": "initandlisten",
"msg": "Access control is not enabled for the database. Read and write access to data and configuration is unrestricted",
"tags": [
"startupWarnings"
]
}

以下は、クライアント データを含むクライアント接続の例です。

{
"t": {
"$date": "2020-05-20T19:18:40.604+00:00"
},
"s": "I",
"c": "NETWORK",
"id": 51800,
"ctx": "conn281",
"msg": "client metadata",
"attr": {
"remote": "192.168.14.15:37666",
"client": "conn281",
"doc": {
"application": {
"name": "MongoDB Shell"
},
"driver": {
"name": "MongoDB Internal Client",
"version": "4.4.0"
},
"os": {
"type": "Linux",
"name": "CentOS Linux release 8.0.1905 (Core) ",
"architecture": "x86_64",
"version": "Kernel 4.18.0-80.11.2.el8_0.x86_64"
}
}
}
}

以下は低速操作メッセージの例です。

{
"t": {
"$date": "2023-05-24T13:46:27.853+00:00"
},
"s": "I",
"c": "COMMAND",
"id": 51803,
"ctx": "conn3",
"msg": "Slow query",
"attr": {
"type": "command",
"ns": "db.coll",
"appName": "MongoDB Shell",
"command": {
"find": "coll",
"filter": {
"b": -1
},
"lsid": {
"id": {
"$uuid": "5d50b19c-8559-420a-a122-8834e012274a"
}
},
"$db": "db"
},
"planSummary": "COLLSCAN",
"planningTimeMicros": 228,
"keysExamined": 0,
"docsExamined": 232922,
"fromPlanCache": true,
"nBatches": 1,
"cursorExhausted": true,
"numYields": 232,
"nreturned": 0,
"queryHash": "9C05019A",
"planCacheKey": "C41063D6",
"queryFramework": "sbe",
"reslen": 96,
"locks": {
"FeatureCompatibilityVersion": {
"acquireCount": {
"r": 233
}
},
"Global": {
"acquireCount": {
"r": 233
}
}
},
"storage": {},
"cpuNanos": 111410254,
"remote": "127.0.0.1:47150",
"protocol": "op_msg",
"durationMillis": 111
}
}

以下は、属性オブジェクトの setName フィールドに表示されている、文字のエスケープの例です。

{
"t": {
"$date": "2020-05-20T19:11:09.268+00:00"
},
"s": "I",
"c": "REPL",
"id": 21752,
"ctx": "ReplCoord-0",
"msg": "Scheduling remote command request",
"attr": {
"context": "vote request",
"request": "RemoteCommand 229 -- target:localhost:27003 db:admin cmd:{ replSetRequestVotes: 1, setName: \"my-replica-name\", dryRun: true, term: 3, candidateIndex: 0, configVersion: 2, configTerm: 3, lastAppliedOpTime: { ts: Timestamp(1589915409, 1), t: 3 } }"
}
}

MongoDB5 .0 以降、ビューに対する低速クエリのログ メッセージには、ビューの詳細を含む resolvedViews フィールドが含まれます。

"resolvedViews": [ {
"viewNamespace": <String>, // namespace and view name
"dependencyChain": <Array of strings>, // view name and collection
"resolvedPipeline": <Array of documents> // aggregation pipeline for view
} ]

以下の例では、test データベースを使用して、myCollection 内のドキュメントを firstName フィールドでソートする myView という名前のビューを作成します。

use test
db.createView( "myView", "myCollection", [ { $sort: { "firstName" : 1 } } ] )

低速クエリが myView で実行されるものとします。次のログ メッセージの例には、myView の resolvedViews フィールドが含まれています。

{
"t": {
"$date": "2021-09-30T17:53:54.646+00:00"
},
"s": "I",
"c": "COMMAND",
"id": 51803,
"ctx": "conn249",
"msg": "Slow query",
"attr": {
"type": "command",
"ns": "test.myView",
"appName": "MongoDB Shell",
"command": {
"find": "myView",
"filter": {},
"lsid": {
"id": { "$uuid": "ad176471-60e5-4e82-b977-156a9970d30f" }
},
"$db": "test"
},
"planSummary":"COLLSCAN",
"resolvedViews": [ {
"viewNamespace": "test.myView",
"dependencyChain": [ "myView", "myCollection" ],
"resolvedPipeline": [ { "$sort": { "firstName": 1 } } ]
} ],
"keysExamined": 0,
"docsExamined": 1,
"hasSortStage": true,
"cursorExhausted": true,
"numYields": 0,
"nreturned": 1,
"queryHash": "3344645B",
"planCacheKey": "1D3DE690",
"queryFramework": "classic"
"reslen": 134,
"locks": { "ParallelBatchWriterMode": { "acquireCount": { "r": 1 } },
"ReplicationStateTransition": { "acquireCount": { "w": 1 } },
"Global": { "acquireCount": { "r": 4 } },
"Database": { "acquireCount": {"r": 1 } },
"Collection": { "acquireCount": { "r": 1 } },
"Mutex": { "acquireCount": { "r": 4 } } },
"storage": {},
"remote": "127.0.0.1:34868",
"protocol": "op_msg",
"durationMillis": 0
}
}
}

MongoDB 5 . 0以降では、低速クエリのログ メッセージにsystem.profile.authorizationセクションが含まれます。これらのメトリクスは、ユーザー承認キャッシュの競合が原因でリクエストが遅延しているかを判断するのに役立ちます。

"authorization": {
"startedUserCacheAcquisitionAttempts": 1,
"completedUserCacheAcquisitionAttempts": 1,
"userCacheWaitTimeMicros": 508
},

MongoDB 6.3 以降では、操作応答の送信時間がslowms のしきい値オプションを超えると、ログにメッセージが追加されます。

このメッセージはセッション ワークフロー ログ メッセージと呼ばれ、データベースセッションで操作を実行するためのさまざまな時間が含まれます。

セッション ワークフロー ログ メッセージの例

{
"t": {
"$date": "2022-12-14T17:22:44.233+00:00"
},
"s": "I",
"c": "EXECUTOR",
"id": 6983000,
"ctx": "conn1",
"msg": "Slow network response send time",
"attr": {
"elapsed": {
"totalMillis": 109,
"activeMillis": 30,
"receiveWorkMillis": 2,
"processWorkMillis": 10,
"sendResponseMillis": 22,
"yieldMillis": 15,
"finalizeMillis": 30
}
}
}

時間はミリ秒単位です。

sendResponseMillis が slowms しきい値オプションを超えると、セッション ワークフロー メッセージがログに追加されます。

フィールド
説明

totalMillis

セッション内で操作を実行するのにかかる合計時間。これには、メッセージを受信するまでの待機時間も含まれます。

activeMillis

メッセージを受信してから、そのメッセージに関連した操作が完了するまでの時間。応答の送信とクリーンアップの実行にかかる時間も含みます。

receivedWorkMillis

ネットワーク経由で操作情報を受信するまでの時間。

processWorkMillis

操作を処理し、応答を作成する時間。

sendResponseMillis

応答を送信する時間。

yieldMillis

ワーカー スレッドが解放されてから、再び使用されるまでの時間。

finalize

セッション ワークフローを終了して閉じるまでの時間。

MongoDB 6.3 以降では、サーバー接続の取得からネットワーク経由でサーバーに送信するバイトの書き込みまでの操作待機時間が 1 ミリ秒を超えると、ログにメッセージが追加されます。

デフォルトでは、メッセージは "I" 情報レベルでログに記録され、ログ メッセージが多くなりすぎるのを避けるために最大で 1 秒に 1 回ログに記録されます。ログ メッセージをすべて取得する必要がある場合は、ログ レベルをデバッグに変更してください。

操作待機時間が 1 ミリ秒を超え、直近 1 秒以内にメッセージが情報レベルでログに記録された場合、次のメッセージはデバッグ レベルでログに記録されます。それ以外の場合、次のメッセージは情報レベルでログに記録されます。

ログメッセージの例

{
"t": {
"$date":"2023-01-31T15:22:29.473+00:00"
},
"s": "I",
"c": "NETWORK",
"id": 6496702,
"ctx": "ReplicaSetMonitor-TaskExecutor",
"msg": "Acquired connection for remote operation and completed writing to wire",
"attr": {
"durationMicros": 1683
}
}

以下の表では、attr 内の durationMicros フィールドを説明しています。

フィールド
説明

durationMicros

サーバー接続の取得から、ネットワーク経由でサーバーに送信するバイトの書き込みまでの操作待機時間(マイクロ秒単位)。

注意

キャッシュ更新ログ フィールドはシャーディングされたクラスターに特有で、mongos ルーターによって生成されたログにのみ表示されます。シャーディングされていないレプリカセットまたはスタンドアロンの配置では利用できません。

MongoDB 6 . 1 以降では、低速クエリのログ メッセージには、以下のキャッシュ更新時間フィールドが含まれます。

フィールド
説明

catalogCacheDatabaseLookupDurationMillis

データベースメタデータのカタログキャッシュからメタデータを検索する時間(ミリ秒)。

catalogCacheCollectionLookupDurationMillis

コレクションメタデータのカタログキャッシュからメタデータを検索する時間(ミリ秒)。

databaseVersionRefreshDurationMillis

movePrimary、createDatabase、およびdropDatabase などの操作のデータベースメタデータを更新する時間(ミリ秒)。

shardVersionRefreshMillis

シャード バージョン操作 のキャッシュを更新する頻度を指定する時間(ミリ秒単位)。

MongoDB 7 . 0 以降では、低速クエリのログ メッセージには、操作がインデックス キャッシュから情報を取得するためにかかった時間を示す catalogCacheIndexLookupDurationMillis フィールドも含まれます。このリリースではまた、shardVersionRefreshMillis フィールドの名前が placementVersionRefreshDurationMillis に変更されます。

placementVersionRefreshDurationMillis は、次のような操作のキャッシュを更新する時間です。

以下の例には、次のアイテムが含まれます。

  • catalogCacheDatabaseLookupDurationMillis

  • catalogCacheCollectionLookupDurationMillis

  • catalogCacheIndexLookupDurationMillis

{
"t": {
"$date": "2023-03-17T09:47:55.929+00:00"
},
"s": "I",
"c": "COMMAND",
"id": 51803,
"ctx": "conn14",
"msg": "Slow query",
"attr": {
"type": "command",
"ns": "db.coll",
"appName": "MongoDB Shell",
"command": {
"insert": "coll",
"ordered": true,
"lsid": {
"id": {
"$uuid": "5d50b19c-8559-420a-a122-8834e012274a"
}
},
"$clusterTime": {
"clusterTime": {
"$timestamp": {
"t": 1679046398,
"i": 8
}
},
"signature": {
"hash": {
"$binary": {
"base64": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=",
"subType": "0"
}
},
"keyId": 0
}
},
"$db": "db"
},
"catalogCacheDatabaseLookupDurationMillis": 19,
"catalogCacheCollectionLookupDurationMillis": 68,
"catalogCacheIndexLookupDurationMillis": 16026,
"nShards": 1,
"ninserted": 1,
"numYields": 232,
"reslen": 96,
"readConcern": {
"level": "local",
"provenance": "implicitDefault",
},
"cpuNanos": 29640339,
"remote": "127.0.0.1:48510",
"protocol": "op_msg",
"remoteOpWaitMillis": 4078,
"durationMillis": 20334
}
}

Linux システムでは、メッセージは Linux 構成ファイル /etc/systemd/journald.conf で定義されたルールに従います。デフォルトでは、ログ メッセージのバーストの上限は 30 秒間に 1,000 メッセージです。表示されるメッセージ数を増やすには、/etc/systemd/journald.conf の RateLimitBurst パラメータを増やします。

MongoDB Atlas を使用して、データベース配置で選択したホスト名またはプロセスのログを含む zip ファイルをダウンロードできます。詳しくは、「MongoDB ログの表示とダウンロード」を参照してください。