ログメッセージ

項目一覧

Overview

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

Overview

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

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

設定されたでログを表示します。
getLog コマンドを実行します。
MongoDB Atlas を通じてログをダウンロードします。詳しくは、「ログのダウンロード」を参照してください。

構造化ログ

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", "svc": "R", "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",
  "svc": "R",
  "msg": "Listening on",
  "attr": {
    "address": "127.0.0.1"
  }
}

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

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

注意

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

JSON ログの出力形式

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

ログファイル
Syslog
stdout（標準出力）ログ出力先

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

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

{
  "t": <Datetime>, // timestamp
  "s": <String>, // severity
  "c": <String>, // component
  "id": <Integer>, // unique identifier
  "ctx": <String>, // context
  "svc": <String>, // service
  "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`	オブジェクト	One or more key-value pairs for additional log attributes. If a log message does not include any additional attributes, the `attr` object is omitted. Attribute values may be referenced by their key name in the `msg` message body, depending on the message. If necessary, the attributes are escaped according to the JSON specification.
`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 の置換文字で置き換えられます。

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

切り捨て

バージョン7.3で変更。

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

たとえば、次の JSON オブジェクトは、切り捨てられていない$inフィールドの5000要素を含むcommand属性を表します。

注意

サンプルログエントリは、読みやすいように再フォーマットされています。

{
  "command": {
    "find": "mycoll",
    "filter": {
      "value1": {
        "$in": [0, 1, 2, 3, ... 4999]
      },
      "value2": "foo"
              },
              "sort": { "value1": 1 },
              "lsid":{"id":{"$uuid":"80a99e49-a850-467b-a26d-aeb2d8b9f42b"}},
              "$db": "testdb"
        }
}

この例では、 $in配列は376番目の要素で切り捨てられています。これは、後続の要素を含む場合、 command属性のサイズがmaxLogSizeKBを超えるためです。 command属性の残りの部分は省略されます。切り捨てられたログエントリーは、次の出力のようになります。

{
  "t": { "$date": "2021-03-17T20:30:07.212+01:00" },
  "s": "I",
  "c": "COMMAND",
  "id": 51803,
  "ctx": "conn9",
  "msg": "Slow query",
  "attr": {
    "command": {
      "find": "mycoll",
      "filter": {
        "value1": {
          "$in": [ 0, 1, ..., 376 ] // Values in array omitted for brevity
        }
      }
    },
    ... // Other attr fields omitted for brevity
  },
  "truncated": {
    "command": {
      "truncated": {
        "filter": {
          "truncated": {
            "value1": {
              "truncated": {
                "$in": {
                  "truncated": {
                    "377": {
                      "type": "double",
                      "size": 8
                    }
                  },
                  "omitted": 4623
                }
              }
            }
          },
          "omitted": 1
        }
      },
      "omitted": 3
    }
  },
  "size": {
    "command": 21692
  }
}

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

切り捨てられた属性
切り捨てのトリガーとなった属性の特定のサブオブジェクト（該当する場合）
切り捨てられたフィールドのデータ type
切り捨てのトリガーとなる要素のsize （バイト単位）
切り捨てにより各サブオブジェクトの下でomittedであった要素の数

また、切り捨てられた属性を含むログエントリの末尾に、追加のsizeフィールドが含まれることがあります。このフィールドは、切り捨てられる前の属性の元のサイズを示しており、この場合は21692または約22 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", "svc": "R", "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", "svc": "R", "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", "svc": "R", "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", "svc": "R", "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", "svc": "R", "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", "svc": "R", "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"}}}

Pretty Printing（整形表示）

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（標準出力）のいずれかに出力できます。

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

構成ファイル

systemLog.destination オプションで file または syslogを指定

コマンドライン

mongodでファイルに出力する場合、--logpath オプション
mongod で syslog に出力する場合、--syslog オプション
mongosでファイルに出力する場合、--logpath オプション
mongos で syslog に出力する場合、--syslog オプション

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

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

構成ファイル

systemLog オプションリスト

コマンドライン

注意

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

ログメッセージのフィールドタイプ

タイムスタンプ

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

{
  "t": {
    "$date": "2020-05-01T15:16:17.180+00:00"
  },
  "s": "I",
  "c": "NETWORK",
  "id": 12345,
  "ctx": "listener",
  "svc": "R",
  "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",
  "svc": "R",
  "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",
  "svc": "R",
  "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パラメーターを設定します。

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", "svc": "R", "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", "svc": "R", "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` 冗長設定

すべてのコンポーネントのデフォルトのログレベルを構成するには、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` Parameter

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()`

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

db.setLogLevel(-1, "query")

値は mongosh から設定します。

[2]

( 1 、 2 、 3 、 4 、 5 ) replica setのセカンダリメンバーは、低速操作のしきい値よりも長い時間がかかるエントリをログにoplogするようになりました。これらの遅い oplog メッセージ:

diagnostic logのセカンダリに対してログに記録されます。
ログは、テキストapplied op: <oplog entry> took <num>msを含むREPLコンポーネントの下にあります。
ログレベルに依存しない（システムレベルでもコンポーネントレベルでも）
プロファイルレベルに依存しないでください。
slowOpSampleRateの影響を受けます。

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

低速操作のログ

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

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

planCacheShapeHash プランキャッシュクエリシェイプが同じスロークエリを特定するのに役立ちます。
MongoDB 8.0以降、既存のqueryHashフィールドの名前がplanCacheShapeHashに変更されます。以前のバージョンの MongoDB を使用している場合は、 planCacheShapeHashではなくqueryHashが表示されます。
planCacheKey 低速クエリのクエリプランキャッシュに関する詳細なインサイトを提供します。

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

MongoDB 6.2 以降では、低速操作ログメッセージに、クエリを実行したクエリエンジンを示す queryFramework フィールドが含まれます。

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

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

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

MongoDB 7.0 （および6.0.13以降）以降では、 5.0.24 ）、低速クエリログメッセージのtotalOplogSlotDurationMicrosは、書込み操作が storage engine の書込み (write) をコミットするためのコミットタイムスタンプを取得してから実際にコミットするまでの時間を示しています。 mongodは並列書込みをサポートします。ただし、書込み (write) 操作はコミットタイムスタンプとともに任意の順序でコミットされます。

例

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

書込み A とタイムスタンプ 1
書込み B とタイムスタンプ 2
書込み C とタイムスタンプ 3

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

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

MongoDB 8.0 以降では、クエリシェイプの queryShapeHash フィールドも、使用可能な場合、スロークエリログに含まれます。

MongoDB 8.0 以降でも、スロークエリの出力には、操作のキューに関する情報を含む queues ドキュメントが含まれます。queues フィールドの各キューには、対応するキューで操作が費やした合計累積時間（マイクロ秒単位）を含む totalTimeQueuedMicros フィールドが含まれています。

フィールドにログインしたシャードの待機時間`remoteOpWaitMillis`

バージョン 5.0 で追加

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

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

低速操作のログを構成する場合。
シャードまたはmongos上で結果をマージ

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

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

ログリダクション

Queryable Encryption におけるログのリダクション

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

Enterprise におけるログのリダクション

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.workingMillis>=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 によるフィルタリング

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

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

{"t":{"$date":"2020-06-01T13:06:59.027-0500"},"s":"I", "c":"NETWORK", "id":22943, "ctx":"listener", "svc": "R", "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", "svc": "R", "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",
  "svc": "R",
  "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",
  "svc": "R",
  "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"
      }
    }
  }
}

低速操作

MongoDB 8 . 0 以降では、低速操作は、操作の合計レイテンシではなく、MongoDB でその操作にかかった時間に基づいてログに記録されます。

低速オペレーションログのメトリクスを使用して、ライフサイクルのどの操作に時間がかかったかを特定できます。これにより、パフォーマンスの向上が可能か識別できます。

次のログメッセージの例では、次のようになります。

クエリの実行中にリソースが待機していた時間は、次のメトリクスに表示されます。
- queues.execution.totalTimeQueuedMicros
- timeAcquiringMicros
workingMillis は、MongoDB で操作にかかった時間です。
durationMillis は、操作の合計レイテンシです。

{
   "t":{
      "$date":"2024-06-01T13:24:10.034+00:00"
   },
   "s":"I",
   "c":"COMMAND",
   "id":51803,
   "ctx":"conn3",
   "msg":"Slow query",
   "attr":{
      "type":"command",
      "isFromUserConnection":true,
      "ns":"db.coll",
      "collectionType":"normal",
      "appName":"MongoDB Shell",
      "command":{
         "find":"coll",
         "filter":{
            "b":-1
         },
         "sort":{
            "splitPoint":1
         },
         "readConcern":{ },
         "$db":"db"
      },
      "planSummary":"COLLSCAN",
      "planningTimeMicros":87,
      "keysExamined":0,
      "docsExamined":20889,
      "hasSortStage":true,
      "nBatches":1,
      "cursorExhausted":true,
      "numYields":164,
      "nreturned":99,
      "planCacheShapeHash":"9C05019A",
      "planCacheKey":"C41063D6",
      "queryFramework":"classic",
      "reslen":96,
      "locks":{
         "ReplicationStateTransition":{
            "acquireCount":{
               "w":3
            }
         },
         "Global":{
            "acquireCount":{
               "r":327,
               "w":1
            }
         },
         "Database":{
            "acquireCount":{
               "r":1
            },
            "acquireWaitCount":{
               "r":1
            },
            "timeAcquiringMicros":{
               "r":2814
            }
         },
         "Collection":{
            "acquireCount":{
               "w":1
            }
         }
      },
      "flowControl":{
         "acquireCount":1,
         "acquireWaitCount":1,
         "timeAcquiringMicros":8387
      },
      "readConcern":{
         "level":"local",
         "provenance":"implicitDefault"
      },
      "storage":{ },
      "cpuNanos":20987385,
      "remote":"127.0.0.1:47150",
      "protocol":"op_msg",
      "queues":{
         "ingress":{
            "admissions":7,
            "totalTimeQueuedMicros":0
         },
         "execution":{
            "admissions":328,
            "totalTimeQueuedMicros":2109
         }
      },
      "workingMillis":89,
      "durationMillis":101
   }
}

MongoDB 8.0以降、既存のqueryHashフィールドの名前がplanCacheShapeHashに変更されます。以前のバージョンの MongoDB を使用している場合は、 planCacheShapeHashではなくqueryHashが表示されます。

エスケープ

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

{
  "t": {
    "$date": "2020-05-20T19:11:09.268+00:00"
  },
  "s": "I",
  "c": "REPL",
  "id": 21752,
  "ctx": "ReplCoord-0",
  "svc": "R",
  "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",
   "svc": "R",
   "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,
         "planCacheShapeHash": "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",
         "workingMillis": 0,
         "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",
   "svc": "R",
   "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",
   "svc": "R",
   "msg": "Acquired connection for remote operation and completed writing to wire",
   "attr": {
      "durationMicros": 1683
   }
}

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

フィールド	説明
`durationMicros`	サーバー接続の取得から、ネットワーク経由でサーバーに送信するバイトの書き込みまでの操作待機時間（マイクロ秒単位）。

キャッシュの更新時間

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

catalogCacheDatabaseLookupDurationMillis
catalogCacheCollectionLookupDurationMillis
databaseVersionRefreshDurationMillis
shardVersionRefreshMillis

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

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

catalogCacheDatabaseLookupDurationMillis
catalogCacheCollectionLookupDurationMillis
catalogCacheIndexLookupDurationMillis

{
  "t": {
    "$date": "2023-03-17T09:47:55.929+00:00"
  },
  "s": "I",
  "c": "COMMAND",
  "id": 51803,
  "ctx": "conn14",
  "svc": "R",
  "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,
    "workingMillis": 20334,
    "durationMillis": 20334
  }
}

Linux Syslog の制限事項

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

ログのダウンロード

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

戻る

用語集

制限としきい値

Overview

構造化ログ

例

注意

JSON ログの出力形式

エスケープ

切り捨て

注意

パディング

Pretty Printing（整形表示）

ログ メッセージの送信先設定

注意

ログ メッセージのフィールド タイプ

タイムスタンプ

注意

重大度

コンポーネント

クライアント データ

冗長レベル

現状のログ冗長レベルの表示

ログの冗長レベルの構成

systemLog 冗長設定

logComponentVerbosity Parameter

db.setLogLevel()

低速操作のログ

例

フィールドにログインしたシャードの待機時間remoteOpWaitMillis

ログ リダクション

Queryable Encryption におけるログのリダクション

Enterprise におけるログのリダクション

構造化ログメッセージの解析

ログ解析の例

ユニーク メッセージの集計

接続のモニタリング

ドライバー接続の分析

クライアント タイプの分析

低速クエリの分析

コンポーネントによるフィルタリング

既知のログ ID によるフィルタリング

日付範囲によるフィルタリング

ログ取り込みサービス

ログメッセージの例

起動時の警告

クライアント接続

低速操作

エスケープ

ビュー

承認

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

接続取得からワイヤ ログ メッセージ

キャッシュの更新時間

Linux Syslog の制限事項

ログのダウンロード

ログメッセージの送信先設定

ログメッセージのフィールドタイプ

クライアントデータ

`systemLog` 冗長設定

`logComponentVerbosity` Parameter

`db.setLogLevel()`

フィールドにログインしたシャードの待機時間`remoteOpWaitMillis`

ログリダクション

ユニークメッセージの集計

クライアントタイプの分析

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

接続取得からワイヤログメッセージ