Docs Menu
Docs Home
/
MongoDBマニュアル
/

ログ メッセージ

項目一覧

  • Overview
  • 構造化ログ
  • ログ メッセージのフィールド タイプ
  • 冗長レベル
  • ログ リダクション
  • 構造化ログメッセージの解析
  • ログメッセージの例
  • ログのダウンロード

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 があります。さまざまなフィールドの型については、「ログ メッセージのフィールドの型」セクションで詳しく説明します。

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

すべてのログ出力は 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

文字列

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

svc

文字列

ログ ステートメントが作成されたコンテキストでのサービスの名前。 S「シャード」の場合はR 、「ルーター」の場合は- 、「不明」または「なし」の場合は になります。

msg

文字列

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

attr

オブジェクト

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

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

tags

文字列の配列

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

truncated

オブジェクト

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

size

オブジェクト

メッセージフィールドと属性フィールドは、必要に応じてRelaxed Extended 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 ログ メッセージは、ファイルsyslogstdout(標準出力)のいずれかに出力できます。

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

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

ファイル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

バージョン4.2 以降、 MongoDBは特定の デバッグ冗長レベル を示します。例、冗長レベルが2 の場合、 MongoDBはD2 を示します。

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

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

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

{
"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 設定を使用します。

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パラメーターを設定します。

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は、ELECTIONINITSYNCREPL_HBROLLBACKコンポーネントの親コンポーネントです。

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設定を使用します。

STORAGEJOURNALRECOVERY の親コンポーネントです。

TXN

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

WRITE

update コマンドなどの書込み (write) 操作に関連するメッセージです。WRITE コンポーネントのログ レベルを指定するには、systemLog.component.write.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.verbosity1 に、systemLog.component.query.verbosity2 に、systemLog.component.storage.verbosity2 に、systemLog.component.storage.journal.verbosity1 に設定されます。

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

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

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

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

たとえば、次の例では、 default verbosity level1に、 query2に、 storage2に、 storage.journal1に設定します。

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]( 12345 ) replica setのセカンダリ メンバーは、低速操作のしきい値よりも長い時間がかかるエントリをログにoplogするようになりました。 これらの遅い oplog メッセージ:プロファイラーは遅い oplog エントリをキャプチャしません。

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

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

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

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

MongoDB 5.0 以降では、低速操作ログ メッセージにクライアントの IP アドレスを指定する remoteフィールドが含まれます。

次の出力例には、低速集計操作に関する情報が含まれています。

{"t":{"$date":"2020-05-20T20:10:08.731+00:00"},"s":"I", "c":"COMMAND", "id":51803, "ctx":"conn281","msg":"Slow query","attr":{"type":"command","ns":"stocks.trades","appName":"MongoDB Shell","command":{"aggregate":"trades","pipeline":[{"$project":{"ticker":1.0,"price":1.0,"priceGTE110":{"$gte":["$price",110.0]},"_id":0.0}},{"$sort":{"price":-1.0}}],"allowDiskUse":true,"cursor":{},"lsid":{"id":{"$uuid":"fa658f9e-9cd6-42d4-b1c8-c9160fabf2a2"}},"$clusterTime":{"clusterTime":{"$timestamp":{"t":1590005405,"i":1}},"signature":{"hash":{"$binary":{"base64":"AAAAAAAAAAAAAAAAAAAAAAAAAAA=","subType":"0"}},"keyId":0}},"$db":"test"},"planSummary":"COLLSCAN","cursorid":1912190691485054730,"keysExamined":0,"docsExamined":1000001,"hasSortStage":true,"usedDisk":true,"numYields":1002,"nreturned":101,"reslen":17738,"locks":{"ReplicationStateTransition":{"acquireCount":{"w":1119}},"Global":{"acquireCount":{"r":1119}},"Database":{"acquireCount":{"r":1119}},"Collection":{"acquireCount":{"r":1119}},"Mutex":{"acquireCount":{"r":117}}},"storage":{"data":{"bytesRead":232899899,"timeReadingMicros":186017},"timeWaitingMicros":{"cache":849}},"remote": "192.168.14.15:37666","protocol":"op_msg","durationMillis":22427}}

MongoDB 5.0.24以降、低速クエリ ログ メッセージのtotalOplogSlotDurationMicrosは、書込み操作が storage engine の書込み (write) をコミットするためのコミット タイムスタンプを取得してから実際にコミットするまでの時間を示しています。 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 はクエリが完了するまでにかかった合計時間です。具体的な説明は以下の通りです。

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

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

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,
...
}
...
}
}

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

{
"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 はそれぞれ 2294322944 です。次に、以下の 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": "2020-05-20T20:10:08.731+00:00"
},
"s": "I",
"c": "COMMAND",
"id": 51803,
"ctx": "conn281",
"msg": "Slow query",
"attr": {
"type": "command",
"ns": "stocks.trades",
"appName": "MongoDB Shell",
"command": {
"aggregate": "trades",
"pipeline": [
{
"$project": {
"ticker": 1,
"price": 1,
"priceGTE110": {
"$gte": [
"$price",
110
]
},
"_id": 0
}
},
{
"$sort": {
"price": -1
}
}
],
"allowDiskUse": true,
"cursor": {},
"lsid": {
"id": {
"$uuid": "fa658f9e-9cd6-42d4-b1c8-c9160fabf2a2"
}
},
"$clusterTime": {
"clusterTime": {
"$timestamp": {
"t": 1590005405,
"i": 1
}
},
"signature": {
"hash": {
"$binary": {
"base64": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=",
"subType": "0"
}
},
"keyId": 0
}
},
"$db": "test"
},
"planSummary": "COLLSCAN",
"cursorid": 1912190691485054700,
"keysExamined": 0,
"docsExamined": 1000001,
"hasSortStage": true,
"usedDisk": true,
"numYields": 1002,
"nreturned": 101,
"reslen": 17738,
"locks": {
"ReplicationStateTransition": {
"acquireCount": {
"w": 1119
}
},
"Global": {
"acquireCount": {
"r": 1119
}
},
"Database": {
"acquireCount": {
"r": 1119
}
},
"Collection": {
"acquireCount": {
"r": 1119
}
},
"Mutex": {
"acquireCount": {
"r": 117
}
}
},
"storage": {
"data": {
"bytesRead": 232899899,
"timeReadingMicros": 186017
},
"timeWaitingMicros": {
"cache": 849
}
},
"remote": "192.168.14.15:37666",
"protocol": "op_msg",
"durationMillis": 22427
}
}

以下は、属性オブジェクトの 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 で実行されるものとします。次のログ メッセージの例には、myViewresolvedViews フィールドが含まれています。

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

戻る

用語集