> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Log Messages ## Overview As part of normal operation, MongoDB maintains a running log of events, including entries such as incoming connections, commands run, and issues encountered. Log messages help diagnose issues, monitor your deployment, and tune performance. To get your log messages, you can use any of the following methods: - View logs in your configured [log destination.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-destinations) - Run the [`getLog`](https://www.mongodb.com/docs/manual/reference/command/getLog.md#mongodb-dbcommand-dbcmd.getLog) command. - Download logs through [MongoDB Atlas](https://www.mongodb.com/docs/atlas/). To learn more, see [Download Your Logs.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-atlas) ## Structured Logging [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) / [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instances output all log messages in [structured JSON format](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-json-output-format). 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. **Example:** The following is an example log message in JSON format as it would appear in the MongoDB log file: ```javascript {"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 log entries can be [pretty-printed](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-pretty-printing) for readability. Here is the same log entry pretty-printed: ```javascript { "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" } } ``` In this log entry, for example, the key `s`, representing [severity](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-severity-levels), has a corresponding value of `I`, representing "Informational", and the key `c`, representing [component](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-components), has a corresponding value of `NETWORK`, indicating that the "network" component was responsible for this particular message. The various field types are presented in detail in the [Log Message Field Types](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-field-types) section. Structured logging with key-value pairs allows for efficient parsing by automated tools or log ingestion services, and makes programmatic search and analysis of log messages easier to perform. Examples of analyzing structured log messages can be found in the [Parsing Structured Log Messages](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-parsing) section. **Note:** The `mongod` quits if it's unable to write to the log file. To ensure that `mongod` can write to the log file, verify that the log volume has space on the disk and the logs are rotated. ### JSON Log Output Format All log output is in JSON format including output sent to: - Log file - Syslog - Stdout (standard out) [log destinations](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-destinations) Output from the [`getLog`](https://www.mongodb.com/docs/manual/reference/command/getLog.md#mongodb-dbcommand-dbcmd.getLog) command is also in JSON format. Each log entry is output as a self-contained JSON object which follows the [Relaxed Extended JSON v2.0](https://www.mongodb.com/docs/manual/reference/mongodb-extended-json.md#std-label-mongodb-extended-json-v2) specification, and has the following layout and field order: ```javascript { "t": , // timestamp "s": , // severity "c": , // component "id": , // unique identifier "ctx": , // context "svc": , // service "msg": , // message body "attr": , // additional attributes (optional) "tags": , // tags (optional) "truncated": , // truncation info (if truncated) "size": // original size of entry (if truncated) } ``` Field descriptions: | Field Name | Type | Description | | --- | --- | --- | | `t` | Datetime | Timestamp of the log message in ISO-8601 format. For an example, see [Timestamp.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-timestamp) | | `s` | String | Short severity code of the log message. For an example, see [Severity.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-severity-levels) | | `c` | String | Full component string for the log message. For an example, see [Components.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-components) | | `id` | Integer | Unique identifier for the log statement. For an example, see [Filtering by Known Log ID.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-parsing-example-filter-id) | | `ctx` | String | Name of the thread that caused the log statement. | | `svc` | String | Name of the service in whose context the log statement was made. Will be `S` for "shard", `R` "router", or `-` for "unknown" or "none". | | `msg` | String | Log output message passed from the server or driver. If necessary, the message is [escaped](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-json-escaping) according to the JSON specification. | | `attr` | Object | One or more key-value pairs for additional log attributes. If alog 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. When required,attributes are [escaped](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-json-escaping)according to the JSON specification. | | `tags` | Array of strings | Strings representing any tags applicable to the log statement. For example, `["startupWarnings"]`. | | `truncated` | Object | Information about the [log message truncation](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-truncation), if applicable. Only included if the log entry contains at least one truncated `attr` attribute. | | `size` | Object | Original size of a log entry if it has been [truncated](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-truncation). Only included if the log entry contains at least one truncated `attr` attribute. | #### Escaping The **message** and **attributes** fields escape control characters according to the Relaxed Extended JSON v2.0 specification: | Character Represented | Escape Sequence | | --- | --- | | Quotation Mark (`"`) | `\"` | | Backslash (`\`) | `\\` | | Backspace (`0x08`) | `\b` | | Formfeed (`0x0C`) | `\f` | | Newline (`0x0A`) | `\n` | | Carriage return (`0x0D`) | `\r` | | Horizontal tab (`0x09`) | `\t` | Control characters not listed above are escaped with `\uXXXX` where "XXXX" is the unicode codepoint in hexadecimal. Bytes with invalid UTF-8 encoding are replaced with the unicode replacement character represented by `\ufffd`. An example of message escaping is provided in the [examples section.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-json-examples) #### Truncation **Changed in version 7.3** Any **attributes** that exceed the maximum size defined with [`maxLogSizeKB`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.maxLogSizeKB) (default: 10 KB) are truncated. Truncated attributes omit log data beyond the configured limit, but retain the JSON formatting of the entry to ensure that the entry remains parsable. For example, the following JSON object represents a `command` attribute that contains 5000 elements in the `$in` field without truncation. **Note:** The example log entries are reformatted for readability. ```javascript { "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 this example, the `$in` array is truncated at the 376th element because the size of the `command` attribute would exceed [`maxLogSizeKB`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.maxLogSizeKB) if it included the subsequent elements. The remainder of the `command` attribute is omitted. The truncated log entry resembles the following output: ```javascript { "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 } } ``` Log entries containing one or more truncated attributes include nested `truncated` objects, which provide the following information for each truncated attribute in the log entry: - The attribute that was truncated - The specific sub-object of that attribute that triggered truncation, if applicable - The data `type` of the truncated field - The `size`, in bytes, of the element that triggers truncation - The number of elements that were `omitted` under each sub-object due to truncation Log entries with truncated attributes may also include an additional `size` field at the end of the entry which indicates the original size of the attribute before truncation, in this case `21692` or about 22KB. This final `size` field is only shown if it is different from the `size` field in the `truncated` object. #### Padding When output to the *file* or the *syslog* log destinations, padding is added after the **severity**, **context**, and **id** fields to increase readability when viewed with a fixed-width font. The following MongoDB log file excerpt demonstrates this padding: ```javascript {"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 When working with MongoDB structured logging, you can use the third-party [jq command-line utility](https://stedolan.github.io/jq/) for easy pretty-printing of log entries, and powerful key-based matching and filtering. `jq` is an open-source JSON parser, and is available for Linux, Windows, and macOS. You can use `jq` to pretty-print log entries as follows: - Pretty-print the entire log file: ```javascript cat mongod.log | jq ``` - Pretty-print the most recent log entry: ```javascript cat mongod.log | tail -1 | jq ``` More examples of working with MongoDB structured logs are available in the [Parsing Structured Log Messages](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-parsing) section. ### Configuring Log Message Destinations MongoDB log messages can be output to *file*, *syslog*, or *stdout* (standard output). To configure the log output destination, use one of the following settings, either in the [configuration file](https://www.mongodb.com/docs/manual/reference/configuration-options.md#std-label-configuration-options) or on the command-line: **Configuration file:** - The [`systemLog.destination`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.destination) option for *file* or *syslog* **Command-line:** - the [`--logpath`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--logpath) option for [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) for *file* - the [`--syslog`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--syslog) option for [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) for *syslog* - the [`--logpath`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#std-option-mongos.--logpath) option for [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) for *file* - the [`--syslog`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#std-option-mongos.--syslog) option for [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) for *syslog* Not specifying either *file* or *syslog* sends all logging output to *stdout*. For the full list of logging settings and options see: **Configuration file:** - [systemLog options list](https://www.mongodb.com/docs/manual/reference/configuration-options.md#std-label-systemlog-options) **Command-line:** - [Log options list](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-label-mongod-log-options-section) for [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) - [Log options list](https://www.mongodb.com/docs/manual/reference/program/mongos.md#std-label-mongos-log-options-section) for [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) **Note:** Error messages sent to `stderr` (standard error), such as fatal errors during startup when not using the *file* or *syslog* log destinations, or messages having to do with misconfigured logging settings, are not affected by the log output destination setting, and are printed to `stderr` in plaintext format. ## Log Message Field Types ### Timestamp The timestamp field type indicates the precise date and time at which the logged event occurred. ```javascript { "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" } } ``` When logging to *file* or to *syslog* , the default format for the timestamp is `iso8601-local`. To modify the timestamp format, use the [`--timeStampFormat`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--timeStampFormat) runtime option or the [`systemLog.timeStampFormat`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.timeStampFormat) setting. See [Filtering by Date Range](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-parsing-example-filter-timestamp) for log parsing examples that filter on the timestamp field. **Note:** The `ctime` timestamp format is no longer supported. If logging to *syslog*, the `syslog` daemon generates timestamps when it logs a message, not when MongoDB issues the message. This can lead to misleading timestamps for log entries, especially when the system is under heavy load. ### Severity The severity field type indicates the severity level associated with the logged event. ```javascript { "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" } } ``` Severity levels range from "Fatal" (most severe) to "Debug" (least severe): | Level | Description | | --- | --- | | `F` | Fatal | | `E` | Error For more information on error logging, see [Error Codes.](https://www.mongodb.com/docs/manual/reference/error-codes.md#std-label-server-error-codes) | | `W` | Warning | | `I` | Informational, for [verbosity level](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-configure-verbosity) `0` | | `D1` - `D5` | Debug, for [verbosity levels](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-configure-verbosity) > `0` MongoDB indicates the specific [debug verbosity level](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-configure-verbosity). For example, if verbosity level is 2, MongoDB indicates `D2`. In previous versions, MongoDB log messages specified `D` for all debug verbosity levels. | You can specify the verbosity level of various components to determine the amount of **Informational** and **Debug** messages MongoDB outputs. Severity categories above these levels are always shown. To set verbosity levels, see [Configure Log Verbosity Levels.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-configure-verbosity) ### Components The component field type indicates the category a logged event is a member of, such as **NETWORK** or **COMMAND**. ```javascript { "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" } } ``` Each component is individually configurable through its own [verbosity filter](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-configure-verbosity). The available components are as follows: Messages related to access control, such as authentication. To specify the log level for [`ACCESS`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-ACCESS) components, use the [`systemLog.component.accessControl.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.accessControl.verbosity) setting. An assertion is triggered when an operation returns an error. The default verbosity level is `0`. However, the verbosity setting must be at least `1` in order for operations that return errors to be included in the system logs. To specify the log level for [`ACCESS`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-ACCESS) components, use the [`assert`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.assert.verbosity) setting. Messages related to [database commands](https://www.mongodb.com/docs/manual/reference/command.md#std-label-database-commands), such as [`count`](https://www.mongodb.com/docs/manual/reference/command/count.md#mongodb-dbcommand-dbcmd.count). To specify the log level for [`COMMAND`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-COMMAND) components, use the [`systemLog.component.command.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.command.verbosity) setting. Messages related to control activities, such as initialization. To specify the log level for [`CONTROL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-CONTROL) components, use the [`systemLog.component.control.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.control.verbosity) setting. Messages related specifically to replica set elections. To specify the log level for [`ELECTION`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-ELECTION) components, set the [`systemLog.component.replication.election.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.replication.election.verbosity) parameter. [`REPL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL) is the parent component of [`ELECTION`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-ELECTION). If [`systemLog.component.replication.election.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.replication.election.verbosity) is unset, MongoDB uses the [`REPL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL) verbosity level for [`ELECTION`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-ELECTION) components. Messages related to the diagnostic data collection mechanism, such as server statistics and status messages. To specify the log level for [`FTDC`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-FTDC) components, use the [`systemLog.component.ftdc.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.ftdc.verbosity) setting. Messages related to the parsing of geospatial shapes, such as verifying the GeoJSON shapes. To specify the log level for [`GEO`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-GEO) components, set the [`systemLog.component.geo.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.geo.verbosity) parameter. Messages related to indexing operations, such as creating indexes. To specify the log level for [`INDEX`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-INDEX) components, set the [`systemLog.component.index.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.index.verbosity) parameter. Messages related to initial sync operation. To specify the log level for [`INITSYNC`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-INITSYNC) components, set the [`systemLog.component.replication.initialSync.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.replication.initialSync.verbosity) parameter. [`REPL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL) is the parent component of [`INITSYNC`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-INITSYNC). If [`systemLog.component.replication.initialSync.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.replication.initialSync.verbosity) is unset, MongoDB uses the [`REPL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL) verbosity level for [`INITSYNC`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-INITSYNC) components. Messages related specifically to storage journaling activities. To specify the log level for [`JOURNAL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-JOURNAL) components, use the [`systemLog.component.storage.journal.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.journal.verbosity) setting. [`STORAGE`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-STORAGE) is the parent component of [`JOURNAL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-JOURNAL). If [`systemLog.component.storage.journal.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.journal.verbosity) is unset, MongoDB uses the [`STORAGE`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-STORAGE) verbosity level for [`JOURNAL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-JOURNAL) components. Messages related to network activities, such as accepting connections. To specify the log level for [`NETWORK`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-NETWORK) components, set the [`systemLog.component.network.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.network.verbosity) parameter. Messages related to queries, including query planner activities. To specify the log level for [`QUERY`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-QUERY) components, set the [`systemLog.component.query.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.query.verbosity) parameter. Messages related to [`$queryStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/queryStats.md#mongodb-pipeline-pipe.-queryStats) operations. To specify the log level for `QUERYSTATS` components, set the [`systemLog.component.queryStats.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.queryStats.verbosity) parameter. Messages related to storage recovery activities. To specify the log level for [`RECOVERY`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-RECOVERY) components, use the [`systemLog.component.storage.recovery.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.recovery.verbosity) setting. [`STORAGE`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-STORAGE) is the parent component of [`RECOVERY`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-RECOVERY). If [`systemLog.component.storage.recovery.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.recovery.verbosity) is unset, MongoDB uses the [`STORAGE`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-STORAGE) verbosity level for [`RECOVERY`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-RECOVERY) components. **New in version 8.0** Messages related to [rejected query operations.](https://www.mongodb.com/docs/manual/tutorial/operation-rejection-filters.md#std-label-operation-rejection-filters) To specify the log level for `REJECTED` component messages, set the [`systemLog.component.query.rejected.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.query.rejected.verbosity) parameter. MongoDB only logs the `REJECTED` component messages if the verbosity level is set to at least `2`. The parent component for `REJECTED` is [`QUERY`.](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-QUERY) Messages related to replica sets, such as initial sync, heartbeats, steady state replication, and rollback. To specify the log level for [`REPL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL) components, set the [`systemLog.component.replication.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.replication.verbosity) parameter. [`REPL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL) is the parent component of the [`ELECTION`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-ELECTION), [`INITSYNC`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-INITSYNC), [`REPL_HB`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL_HB), and [`ROLLBACK`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-ROLLBACK) components. Messages related specifically to replica set heartbeats. To specify the log level for [`REPL_HB`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL_HB) components, set the [`systemLog.component.replication.heartbeats.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.replication.heartbeats.verbosity) parameter. [`REPL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL) is the parent component of [`REPL_HB`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL_HB). If [`systemLog.component.replication.heartbeats.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.replication.heartbeats.verbosity) is unset, MongoDB uses the [`REPL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL) verbosity level for [`REPL_HB`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL_HB) components. Messages related to [rollback](https://www.mongodb.com/docs/manual/core/replica-set-rollbacks.md#std-label-replica-set-rollbacks) operations. To specify the log level for [`ROLLBACK`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-ROLLBACK) components, set the [`systemLog.component.replication.rollback.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.replication.rollback.verbosity) parameter. [`REPL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL) is the parent component of [`ROLLBACK`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-ROLLBACK). If [`systemLog.component.replication.rollback.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.replication.rollback.verbosity) is unset, MongoDB uses the [`REPL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL) verbosity level for [`ROLLBACK`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-ROLLBACK) components. Messages related to sharding activities, such as the startup of the [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos). To specify the log level for [`SHARDING`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-SHARDING) components, use the [`systemLog.component.sharding.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.sharding.verbosity) setting. Messages related to storage activities, such as processes involved in the [`fsync`](https://www.mongodb.com/docs/manual/reference/command/fsync.md#mongodb-dbcommand-dbcmd.fsync) command. To specify the log level for [`STORAGE`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-STORAGE) components, use the [`systemLog.component.storage.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.verbosity) setting. [`STORAGE`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-STORAGE) is the parent component of [`JOURNAL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-JOURNAL) and [`RECOVERY`.](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-RECOVERY) Messages related to [multi-document transactions](https://www.mongodb.com/docs/manual/core/transactions.md#std-label-transactions). To specify the log level for [`TXN`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-TXN) components, use the [`systemLog.component.transaction.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.transaction.verbosity) setting. Messages related to write operations, such as [`update`](https://www.mongodb.com/docs/manual/reference/command/update.md#mongodb-dbcommand-dbcmd.update) commands. To specify the log level for [`WRITE`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-WRITE) components, use the [`systemLog.component.write.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.write.verbosity) setting. **New in version 5.3** Messages related to the [WiredTiger](https://www.mongodb.com/docs/manual/core/wiredtiger.md#std-label-storage-wiredtiger) storage engine. To specify the log level for [`WT`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-WT) components, use the [`systemLog.component.storage.wt.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.wt.verbosity) setting. **New in version 5.3** Messages related to backup operations performed by the [WiredTiger](https://www.mongodb.com/docs/manual/core/wiredtiger.md#std-label-storage-wiredtiger) storage engine. To specify the log level for the [`WTBACKUP`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-WTBACKUP) components, use the [`systemLog.component.storage.wt.wtBackup.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.wt.wtBackup.verbosity) setting. **New in version 5.3** Messages related to checkpoint operations performed by the [WiredTiger](https://www.mongodb.com/docs/manual/core/wiredtiger.md#std-label-storage-wiredtiger) storage engine. To specify the log level for [`WTCHKPT`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-WTCHKPT) components, use the [`systemLog.component.storage.wt.wtCheckpoint.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.wt.wtCheckpoint.verbosity) setting. **New in version 5.3** Messages related to compaction operations performed by the [WiredTiger](https://www.mongodb.com/docs/manual/core/wiredtiger.md#std-label-storage-wiredtiger) storage engine. To specify the log level for [`WTCMPCT`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-WTCMPCT) components, use the [`systemLog.component.storage.wt.wtCompact.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.wt.wtCompact.verbosity) setting. **New in version 5.3** Messages related to eviction operations performed by the [WiredTiger](https://www.mongodb.com/docs/manual/core/wiredtiger.md#std-label-storage-wiredtiger) storage engine. To specify the log level for [`WTEVICT`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-WTEVICT) components, use the [`systemLog.component.storage.wt.wtEviction.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.wt.wtEviction.verbosity) setting. **New in version 5.3** Messages related to the history store of the [WiredTiger](https://www.mongodb.com/docs/manual/core/wiredtiger.md#std-label-storage-wiredtiger) storage engine. To specify the log level for [`WTHS`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-WTHS) components, use the [`systemLog.component.storage.wt.wtHS.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.wt.wtHS.verbosity) setting. **New in version 5.3** Messages related to recovery operations performed by the [WiredTiger](https://www.mongodb.com/docs/manual/core/wiredtiger.md#std-label-storage-wiredtiger) storage engine. To specify the log level for [`WTRECOV`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-WTRECOV) components, use the [`systemLog.component.storage.wt.wtRecovery.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.wt.wtRecovery.verbosity) setting. **New in version 5.3** Messages related to rollback to stable (RTS) operations performed by the [WiredTiger](https://www.mongodb.com/docs/manual/core/wiredtiger.md#std-label-storage-wiredtiger) storage engine. To specify the log level for [`WTRTS`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-WTRTS) components, use the [`systemLog.component.storage.wt.wtRTS.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.wt.wtRTS.verbosity) setting. **New in version 5.3** Messages related to salvage operations performed by the [WiredTiger](https://www.mongodb.com/docs/manual/core/wiredtiger.md#std-label-storage-wiredtiger) storage engine. To specify the log level for [`WTSLVG`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-WTSLVG) components, use the [`systemLog.component.storage.wt.wtSalvage.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.wt.wtSalvage.verbosity) setting. **New in version 5.3** Messages related to timestamps used by the [WiredTiger](https://www.mongodb.com/docs/manual/core/wiredtiger.md#std-label-storage-wiredtiger) storage engine. To specify the log level for [`WTTS`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-WTTS) components, use the [`systemLog.component.storage.wt.wtTimestamp.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.wt.wtTimestamp.verbosity) setting. **New in version 5.3** Messages related to transactions performed by the [WiredTiger](https://www.mongodb.com/docs/manual/core/wiredtiger.md#std-label-storage-wiredtiger) storage engine. To specify the log level for [`WTTXN`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-WTTXN) components, use the [`systemLog.component.storage.wt.wtTransaction.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.wt.wtTransaction.verbosity) setting. **New in version 5.3** Messages related to verification operations performed by the [WiredTiger](https://www.mongodb.com/docs/manual/core/wiredtiger.md#std-label-storage-wiredtiger) storage engine. To specify the log level for [`WTVRFY`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-WTVRFY) components, use the [`systemLog.component.storage.wt.wtVerify.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.wt.wtVerify.verbosity) setting. **New in version 5.3** Messages related to log write operations performed by the [WiredTiger](https://www.mongodb.com/docs/manual/core/wiredtiger.md#std-label-storage-wiredtiger) storage engine. To specify the log level for [`WTWRTLOG`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-WTWRTLOG) components, use the [`systemLog.component.storage.wt.wtWriteLog.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.wt.wtWriteLog.verbosity) setting. Messages not associated with a named component. Unnamed components have the default log level specified in the [`systemLog.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.verbosity) setting. The [`systemLog.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.verbosity) setting is the default setting for both named and unnamed components. See [Filtering by Component](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-parsing-example-filter-component) for log parsing examples that filter on the component field. ### Client Data [MongoDB Drivers](https://www.mongodb.com/docs/drivers/) and client applications (including [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh)) can send identifying information at the time of connection to the server. After the connection is established, the client does not send the identifying information again unless the connection is dropped and reestablished. This identifying information is contained in the **attributes** field of the log entry. The exact information included varies by client. Below is a sample log message containing the client data document as transmitted from a [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh) connection. The client data is contained in the `doc` object in the **attributes** field: ```javascript {"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"}}}} ``` When secondary members of a [replica set](https://www.mongodb.com/docs/manual/core/replica-set-members.md#std-label-replica-set-members) initiate a connection to a primary, they send similar data. A sample log message containing this initiation connection might appear as follows. The client data is contained in the `doc` object in the **attributes** field: ```javascript {"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"}}}} ``` See the [examples section](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-json-examples) for a [pretty-printed](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-pretty-printing) example showing client data. For a complete description of client information and required fields, see the [MongoDB Handshake specification](https://github.com/mongodb/specifications/blob/master/source/mongodb-handshake/handshake.rst). ## Verbosity Levels You can specify the logging verbosity level to increase or decrease the amount of log messages MongoDB outputs. Verbosity levels can be adjusted for all components together, or for specific [named components](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-components) individually. Verbosity affects log entries in the [severity](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-severity-levels) categories **Informational** and **Debug** only. Severity categories above these levels are always shown. You might set verbosity levels to a high value to show detailed logging for debugging or development, or to a low value to minimize writes to the log on a vetted production deployment. ### View Current Log Verbosity Level To view the current verbosity levels, use the [`db.getLogComponents()`](https://www.mongodb.com/docs/manual/reference/method/db.getLogComponents.md#mongodb-method-db.getLogComponents) method: ```javascript db.getLogComponents() ``` Your output might resemble the following: ```javascript { "verbosity" : 0, "accessControl" : { "verbosity" : -1 }, "command" : { "verbosity" : -1 }, ... "storage" : { "verbosity" : -1, "recovery" : { "verbosity" : -1 }, "journal" : { "verbosity" : -1 } }, ... ``` The initial `verbosity` entry is the parent verbosity level for all components, while the individual [named components](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-components) that follow, such as `accessControl`, indicate the specific verbosity level for that component, overriding the global verbosity level for that particular component if set. A value of `-1`, indicates that the component inherits the verbosity level of their parent, if they have one (as with `recovery` above, inheriting from `storage`), or the global verbosity level if they do not (as with `command`). Inheritance relationships for verbosity levels are indicated in the [components section.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-components) ### Configure Log Verbosity Levels You can configure the verbosity level using: the [`systemLog.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.verbosity) and `systemLog.component..verbosity` settings, the [`logComponentVerbosity`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.logComponentVerbosity) parameter, or the [`db.setLogLevel()`](https://www.mongodb.com/docs/manual/reference/method/db.setLogLevel.md#mongodb-method-db.setLogLevel) method. #### `systemLog` Verbosity Settings To configure the default log level for all [components](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-components), use the [`systemLog.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.verbosity) setting. To configure the level of specific components, use the `systemLog.component..verbosity` settings. For example, the following configuration sets the [`systemLog.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.verbosity) to `1`, the [`systemLog.component.query.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.query.verbosity) to `2`, the [`systemLog.component.storage.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.verbosity) to `2`, and the [`systemLog.component.storage.journal.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.journal.verbosity) to `1`: ```javascript systemLog: verbosity: 1 component: query: verbosity: 2 storage: verbosity: 2 journal: verbosity: 1 ``` You would set these values in the [configuration file](https://www.mongodb.com/docs/manual/reference/configuration-options.md#std-label-configuration-options) or on the command line for your [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) or [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instance. All components not specified explicitly in the configuration have a verbosity level of `-1`, indicating that they inherit the verbosity level of their parent, if they have one, or the global verbosity level ([`systemLog.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.verbosity)) if they do not. #### `logComponentVerbosity` Parameter To set the [`logComponentVerbosity`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.logComponentVerbosity) parameter, pass a document with the verbosity settings to change. For example, the following sets the [`default verbosity level`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.verbosity) to `1`, the [`query`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.query.verbosity) to `2`, the [`storage`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.verbosity) to `2`, and the [`storage.journal`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.storage.journal.verbosity) to `1`. ```javascript db.adminCommand( { setParameter: 1, logComponentVerbosity: { verbosity: 1, query: { verbosity: 2 }, storage: { verbosity: 2, journal: { verbosity: 1 } } } } ) ``` You would set these values from [`mongosh`.](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh) #### `db.setLogLevel()` Use the [`db.setLogLevel()`](https://www.mongodb.com/docs/manual/reference/method/db.setLogLevel.md#mongodb-method-db.setLogLevel) method to update a single component log level. For a component, you can specify verbosity level of `0` to `5`, or you can specify `-1` to inherit the verbosity of the parent. For example, the following sets the [`systemLog.component.query.verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.component.query.verbosity) to its parent verbosity (i.e. default verbosity): ```javascript db.setLogLevel(-1, "query") ``` You would set this value from [`mongosh`.](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh) Secondary members of a replica set now [log oplog entries](https://www.mongodb.com/docs/manual/core/replica-set-oplog.md#std-label-slow-oplog-application) that take longer than the slow operation threshold to apply. These slow oplog messages: - Are logged for the secondaries in the [`diagnostic log`.](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--logpath) - Are logged under the [`REPL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL) component with the text `applied op: took ms`. - Do not depend on the log levels (either at the system or component level) - Do not depend on the profiling level. - Are affected by [`slowOpSampleRate`.](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-operationProfiling.slowOpSampleRate) The profiler does not capture slow oplog entries. ### Logging Slow Operations Client operations (such as queries) appear in the log if their duration exceeds the [slow operation threshold](https://www.mongodb.com/docs/manual/reference/command/profile.md#std-label-slowms-threshold-option) or when the [log verbosity level](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-verbosity-levels) is at least 1. These log entries include the full command object associated with the operation. The [profiler entries](https://www.mongodb.com/docs/manual/tutorial/manage-the-database-profiler.md#std-label-database-profiler) and the [diagnostic log messages (i.e. mongod/mongos logmessages)](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-slow-ops) for read/write operations include: - `planCacheShapeHash` to help identify slow queries with the same [plan cache query shape.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-plan-cache-query-shape) Starting in MongoDB 8.0, the existing `queryHash` field is duplicated in a new field named `planCacheShapeHash`. If you're using an earlier MongoDB version, you'll only see the `queryHash` field. Future MongoDB versions will remove the deprecated `queryHash` field, and you'll need to use the `planCacheShapeHash` field instead. - `planCacheKey` to provide more insight into the [query plan cache](https://www.mongodb.com/docs/manual/core/query-plans.md) for slow queries. **Important:** A single operation may log more than one entry. For example, if more than one write in a [bulk write operation](https://www.mongodb.com/docs/manual/core/bulk-write-operations.md#std-label-bulk-write-operations) exceeds the slow operation threshold, each slow write is logged separately. #### Version-Specific Changes The following table lists the changes to logging slow queries. | **MongoDB Version** | **Changes** | | --- | --- | | 6.1 | Slow operation log messages include [cache refresh time fields.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-cache-refresh-times) | | 6.2 | Slow operation log messages include a `queryFramework` field that indicates which query engine executed the query: `queryFramework: "classic"` indicates that the classic engine executed the query.; `queryFramework: "sbe"` indicates that the slot-based query execution engine executed the query. | | 6.3 | Slow operation log messages and [database profiler](https://www.mongodb.com/docs/manual/reference/database-profiler.md#std-label-profiler) entries include a `cpuNanos` field that specifies the total CPU time spent by a query operation in nanoseconds. The `cpuNanos` field is only available on Linux systems. | | 7.0 (and 6.0.13, 5.0.24) | The `totalOplogSlotDurationMicros` in the slow query log message shows the time between a write operation getting a commit timestamp to commit the storage engine writes and actually committing. `mongod` supports parallel writes. However, it commits write operations with commit timestamps in any order. For example, consider the following writes with commit timestamps: writeA with Timestamp1; writeB with Timestamp2; writeC with Timestamp3 Suppose writeB commits first at Timestamp2. Replication is paused until writeA commits because writeA's oplog entry with Timestamp1 is required for replication to copy the oplog to secondary replica set members. | | 8.0 | The slow query output includes a `queues` document that contains information about the operation's [queues](https://www.mongodb.com/docs/manual/reference/command/serverStatus.md#std-label-server-status-queues). Each queue in the `queues` field contains a `totalTimeQueuedMicros` field that contains the total cumulative time in microseconds that the operation spent in the corresponding queue. The `queryShapeHash` field for a [query shape](https://www.mongodb.com/docs/manual/core/query-shapes.md#std-label-query-shapes) is also included in the slow query log when available. If a command with a specific query shape is [rejected](https://www.mongodb.com/docs/manual/tutorial/operation-rejection-filters.md#std-label-operation-rejection-filters), MongoDB logs a message that states the query command was rejected. The message contains the query namespace, `queryShapeHash`, and the command with the rejected query. MongoDB only logs the message if the log verbosity level is set to at least `2`. | | 8.1 | Slow query log messages contain new metrics if the query execution writes temporary files to disk. These metrics are prefixed by the query execution stage that caused the query to exceed the memory limit. For example, `sortSpills` indicates the number of times that the sort stage of query execution wrote temporary files to disk. `Spills` indicates the number of times the corresponding query execution stage wrote temporary files to disk.; `SpilledBytes` indicates the size, in bytes, of the memory released by writing temporary files to disk.; `SpilledDataStorageSize` indicates the size, in bytes, of disk space used for temporary files.; `SpilledRecords` indicates the number of records written to temporary files on disk. For more information on writing temporary files to disk, see [`allowDiskUse()`.](https://www.mongodb.com/docs/manual/reference/method/cursor.allowDiskUse.md#mongodb-method-cursor.allowDiskUse) | | 8.3 | Slow query log entries have an optional `originalQueryShapeHash` field that contains that query shape of the following operations that originate on the [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#std-program-mongos) : [`find`](https://www.mongodb.com/docs/manual/reference/command/find.md#mongodb-dbcommand-dbcmd.find); [`aggregate`](https://www.mongodb.com/docs/manual/reference/command/aggregate.md#mongodb-dbcommand-dbcmd.aggregate); [`count`](https://www.mongodb.com/docs/manual/reference/command/count.md#mongodb-dbcommand-dbcmd.count); [`distinct`](https://www.mongodb.com/docs/manual/reference/command/distinct.md#mongodb-dbcommand-dbcmd.distinct) The original query shape of the `mongos` operation may differ after the `mongos` sends the operation to the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-program-mongod) . MongoDB 8.3 also introduces slow in-progress query log entries. Queries trigger a slow-in progress log during execution. These logs contain less information than standard slow query logs. MongoDB logs queries at most once if the query's duration surpasses the [`operationProfiling.slowOpInProgressThresholdMs`.](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-operationProfiling.slowOpInProgressThresholdMs) When an operation specifies a [time limit for a query](https://www.mongodb.com/docs/manual/tutorial/query-documents/specify-query-timeout.md#std-label-manual-query-timeout), slow query logs contain a `deadline` field. `deadline` indicates the time the operation must complete by, which is equal to the time at the start of the operation plus the value of the query timeout. | For a [pretty-printed](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-pretty-printing) example of a slow operation log entry, see [Log Message Examples.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-json-examples) ### Time Waiting for Shards Logged in `remoteOpWaitMillis` Field **New in version 5.0** Starting in MongoDB 5.0, you can use the `remoteOpWaitMillis` log field to obtain the wait time (in milliseconds) for results from [shards.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-shard) `remoteOpWaitMillis` is only logged: - If you configure [slow operations logging.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-slow-ops) - On the [shard](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-shard) or [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) that merges the results. To determine if a merge operation or a shard issue is causing a slow query, compare the `workingMillis` and `remoteOpWaitMillis` time fields in the log. `workingMillis` is the total time the query took to complete. Specifically: - If `workingMillis` is slightly longer than `remoteOpWaitMillis`, then waiting for a shard response took the most time. For example, `workingMillis` of 17 and `remoteOpWaitMillis` of 15. - If `workingMillis` is significantly longer than `remoteOpWaitMillis`, then performing the merge took the most time. For example, `workingMillis` of 100 and `remoteOpWaitMillis` of 15. ## Log Redaction ### Queryable Encryption Log Redaction When using [Queryable Encryption](https://www.mongodb.com/docs/manual/core/queryable-encryption.md#std-label-qe-manual-feature-qe), CRUD operations against encrypted collections are omitted from the slow query log. For details, see [Queryable Encryption redaction.](https://www.mongodb.com/docs/manual/core/queryable-encryption/reference/limitations.md#std-label-qe-redaction) ### Enterprise Log Redaction *Available in MongoDB Atlas and MongoDB Enterprise only* A [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) or [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) running with [`redactClientLogData`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.redactClientLogData) redacts any message accompanying a given log event before logging, leaving only metadata, source files, or line numbers related to the event. [`redactClientLogData`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.redactClientLogData) prevents potentially sensitive information from entering the system log at the cost of diagnostic detail. For example, the following operation inserts a document into a [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) running without log redaction. The [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) has the [log verbosity level](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-configure-verbosity) set to `1`: ```javascript db.clients.insertOne( { "name" : "Joe", "PII" : "Sensitive Information" } ) ``` This operation produces the following log event: ```javascript { "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, ... } ... } } ``` When [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) runs with [`redactClientLogData`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.redactClientLogData) and performs the same insert operation, it produces the following log event: ```javascript { "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": "###", ... } ... } } ``` Use [`redactClientLogData`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.redactClientLogData) in conjunction with [Encryption at Rest](https://www.mongodb.com/docs/manual/core/security-encryption-at-rest.md#std-label-security-encryption-at-rest) and [TLS/SSL (Transport Encryption)](https://www.mongodb.com/docs/manual/core/security-transport-encryption.md#std-label-transport-encryption) to assist compliance with regulatory requirements. ## Parsing Structured Log Messages Log parsing is the act of programmatically searching through and analyzing log files, often in an automated manner. With the introduction of structured logging, log parsing is made simpler and more powerful. For example: - Log message fields are presented as key-value pairs. Log parsers can query by specific keys of interest to efficiently filter results. - Log messages always contain the same message structure. Log parsers can reliably extract information from any log message, without needing to code for cases where information is missing or formatted differently. The following examples demonstrate common log parsing workflows when working with MongoDB JSON log output. ### Log Parsing Examples When working with MongoDB structured logging, you can use the third-party [jq command-line utility](https://stedolan.github.io/jq/) for easy pretty-printing of log entries, and powerful key-based matching and filtering. `jq` is an open-source JSON parser, and is available for Linux, Windows, and macOS. These examples use `jq` to simplify log parsing. #### Counting Unique Messages The following example shows the top 10 unique message values in a given log file, sorted by frequency: ```bash jq -r ".msg" /var/log/mongodb/mongod.log | sort | uniq -c | sort -rn | head -10 ``` #### Monitoring Connections Remote client connections are shown in the log under the "remote" key in the attribute object. The following counts all unique connections over the course of the log file and presents them in descending order by number of occurrences: ```bash jq -r '.attr.remote' /var/log/mongodb/mongod.log | grep -v 'null' | sort | uniq -c | sort -r ``` Note that connections from the same IP address, but connecting over different ports, are treated as different connections by this command. You could limit output to consider IP addresses only, with the following change: ```bash jq -r '.attr.remote' /var/log/mongodb/mongod.log | grep -v 'null' | awk -F':' '{print $1}' | sort | uniq -c | sort -r ``` #### Analyzing Driver Connections The following example counts all remote [MongoDB driver](https://www.mongodb.com/docs/drivers/) connections, and presents each driver type and version in descending order by number of occurrences: ```bash jq -cr '.attr.doc.driver' /var/log/mongodb/mongod.log | grep -v null | sort | uniq -c | sort -rn ``` #### Analyzing Client Types The following example analyzes the reported [client data](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-client-data) of remote [MongoDB driver](https://www.mongodb.com/docs/drivers/) connections and client applications, including [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh), and prints a total for each unique operating system type that connected, sorted by frequency: ```bash jq -r '.attr.doc.os.type' /var/log/mongodb/mongod.log | grep -v null | sort | uniq -c | sort -rn ``` The string "Darwin", as reported in this log field, represents a macOS client. #### Analyzing Slow Queries With [slow operation logging](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-slow-ops) enabled, the following returns only the slow operations that took above 2000 milliseconds:, for further analysis: ```bash jq 'select(.attr.workingMillis>=2000)' /var/log/mongodb/mongod.log ``` Consult the [jq documentation](https://stedolan.github.io/jq/manual/) for more information on the `jq` filters shown in this example. #### Filtering by Component Log components (the third field in the [JSON log output format](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-json-output-format)) indicate the [general category](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-components) a given log message falls under. Filtering by component is often a great starting place when parsing log messages for relevant events. The following example prints only the log messages of [component](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-components) type **REPL**: ```bash jq 'select(.c=="REPL")' /var/log/mongodb/mongod.log ``` The following example prints all log messages *except* those of [component](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-components) type **REPL**: ```bash jq 'select(.c!="REPL")' /var/log/mongodb/mongod.log ``` The following example print log messages of [component](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-components) type **REPL** *or* **STORAGE**: ```bash jq 'select( .c as $c | ["REPL", "STORAGE"] | index($c) )' /var/log/mongodb/mongod.log ``` Consult the [jq documentation](https://stedolan.github.io/jq/manual/) for more information on the `jq` filters shown in this example. #### Filtering by Known Log ID Log IDs (the fifth field in the [JSON log output format](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-json-output-format)) map to specific log events, and can be relied upon to remain stable over successive MongoDB releases. As an example, you might be interested in the following two log events, showing a client connection followed by a disconnection: ```javascript {"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"}} ``` The log IDs for these two entries are `22943` and `22944`. You could then filter your log output to show only these log IDs, effectively showing only client connection activity, using the following `jq` syntax: ```bash jq 'select( .id as $id | [22943, 22944] | index($id) )' /var/log/mongodb/mongod.log ``` Consult the [jq documentation](https://stedolan.github.io/jq/manual/) for more information on the `jq` filters shown in this example. #### Filtering by Date Range Log output can be further refined by filtering on the timestamp field, limiting log entries returned to a specific date range. For example, the following returns all log entries that occurred on April 15th, 2020: ```bash jq 'select(.t["$date"] >= "2020-04-15T00:00:00.000" and .t["$date"] <= "2020-04-15T23:59:59.999")' /var/log/mongodb/mongod.log ``` Note that this syntax includes the full timestamp, including milliseconds but excluding the timezone offset. Filtering by date range can be combined with any of the examples above, creating weekly reports or yearly summaries for example. The following syntax expands the "Monitoring Connections" example from earlier to limit results to the month of May, 2020: ```bash 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 ``` Consult the [jq documentation](https://stedolan.github.io/jq/manual/) for more information on the `jq` filters shown in this example. ### Log Ingestion Services Log ingestion services are third-party products that intake and aggregate log files, usually from a distributed cluster of systems, and provide ongoing analysis of that data in a central location. The [JSON log format](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-json-output-format) allows for more flexibility when working with log ingestion and analysis services. Whereas plaintext logs generally require some manner of transformation before being eligible for use with these products, JSON files can often be consumed out of the box, depending on the service. Further, JSON-formatted logs offer more control when performing filtering for these services, as the key-value structure offers the ability to specifically import only the fields of interest, while omitting the rest. Consult the documentation for your chosen third-party log ingestion service for more information. ## Log Message Examples The following examples show log messages in JSON output format. These log messages are presented in [pretty-printed format](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-pretty-printing) for convenience. ### Startup Warning This example shows a startup warning: ```javascript { "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" ] } ``` ### Client Connection This example shows a client connection that includes [client data:](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-client-data) ```javascript { "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" } } } } ``` ### Slow Operation Starting in MongoDB 8.0, slow operations are logged based on the time that MongoDB spends working on that operation, rather than the total latency for the operation. You can use the metrics in the slow operation log to identify where an operation spends time in its lifecycle, which helps identify possible performance improvements. In the following example log message: - The amount of time spent waiting for resources while executing the query is shown in these metrics: - `queues.execution.totalTimeQueuedMicros` - `timeAcquiringMicros` - `workingMillis` The amount of time that MongoDB spends working on the operation. - `durationMillis` The operation's total latency. - `inUseTrackedMemBytes` **New in version 8.3** Number of bytes of tracked memory in use by the current query operation. - `peakTrackedMemBytes` **New in version 8.3** Maximum number of bytes of tracked memory in use by the current query operation. ```javascript { "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, "inUseTrackedMemBytes":368, "peakTrackedMemBytes":795, "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 } } ``` Starting in MongoDB 8.0, the existing `queryHash` field is duplicated in a new field named `planCacheShapeHash`. If you're using an earlier MongoDB version, you'll only see the `queryHash` field. Future MongoDB versions will remove the deprecated `queryHash` field, and you'll need to use the `planCacheShapeHash` field instead. ### Escaping This example demonstrates [character escaping](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-json-escaping), as shown in the `setName` field of the attribute object: ```javascript { "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 } }" } } ``` ### View Starting in MongoDB 5.0, [log messages for slow queries](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-slow-ops) on [views](https://www.mongodb.com/docs/manual/core/views.md#std-label-views-landing-page) include a `resolvedViews` field that contains the view details: ```javascript "resolvedViews": [ { "viewNamespace": , // namespace and view name "dependencyChain": , // view name and collection "resolvedPipeline": // aggregation pipeline for view } ] ``` The following example uses the `test` database and creates a view named `myView` that sorts the documents in `myCollection` by the `firstName` field: ```javascript use test db.createView( "myView", "myCollection", [ { $sort: { "firstName" : 1 } } ] ) ``` Assume a [slow query](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-slow-ops) is run on `myView`. The following example log message contains a `resolvedViews` field for `myView`: ```javascript { "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 } } } ``` Starting in MongoDB 8.0, the existing `queryHash` field is duplicated in a new field named `planCacheShapeHash`. If you're using an earlier MongoDB version, you'll only see the `queryHash` field. Future MongoDB versions will remove the deprecated `queryHash` field, and you'll need to use the `planCacheShapeHash` field instead. ### Authorization Starting in MongoDB 5.0, [log messages for slow queries](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-slow-ops) include a [`system.profile.authorization`](https://www.mongodb.com/docs/manual/reference/database-profiler.md#mongodb-data-system.profile.authorization) section. These metrics help determine if a request is delayed because of contention for the user authorization cache. ```javascript "authorization": { "startedUserCacheAcquisitionAttempts": 1, "completedUserCacheAcquisitionAttempts": 1, "userCacheWaitTimeMicros": 508 }, ``` ### Session Workflow Log Message Starting in MongoDB 6.3, a message is added to the log if the time to send an operation response exceeds the [slowms threshold option.](https://www.mongodb.com/docs/manual/reference/command/profile.md#std-label-slowms-threshold-option) The message is known as a session workflow log message and contains various times to perform an operation in a database session. Example session workflow log message: ```javascript { "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 } } } ``` The times are in milliseconds. A session workflow message is added to the log if `sendResponseMillis` exceeds the [slowms threshold option.](https://www.mongodb.com/docs/manual/reference/command/profile.md#std-label-slowms-threshold-option) | Field | Description | | --- | --- | | `totalMillis` | Total time to perform the operation in the session, which includes the time spent waiting for a message to be received. | | `activeMillis` | Time between receiving a message and completing the operation associated with that message. Time includes sending a response and performing any clean up. | | `receivedWorkMillis` | Time to receive the operation information over the network. | | `processWorkMillis` | Time to process the operation and create the response. | | `sendResponseMillis` | Time to send the response. | | `yieldMillis` | Time between releasing the worker thread and the thread being used again. | | `finalize` | Time to end and close the session workflow. | ### Connection Acquisition To Wire Log Message Starting in MongoDB 6.3, a message is added to the log if the time that an operation waited between acquisition of a server connection and writing the bytes to send to the server over the network exceeds 1 millisecond. By default, the message is logged at the `"I"` information level, and at most once every second to avoid too many log messages. If you must obtain every log message, change your log level to debug. If the operation wait time exceeds 1 millisecond and the message is logged at the information level within the last second, then the next message is logged at the debug level. Otherwise, the next message is logged at the information level. Example log message: ```javascript { "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 } } ``` The following table describes the `durationMicros` field in `attr`. | Field | Description | | --- | --- | | `durationMicros` | Time in microseconds that the operation waited between acquisition of a server connection and writing the bytes to send to the server over the network. | ### Cache Refresh Times **Note:** Cache refresh log fields are specific to sharded clusters and only appear in logs generated by the [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) router. They are not available in unsharded replica sets or standalone deployments. Starting in MongoDB 6.1, [log messages for slow queries](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-slow-ops) include the following cache refresh time fields: | Field | Description | | --- | --- | | `catalogCacheDatabaseLookupDurationMillis` | Time in milliseconds to retrieve metadata from the catalog cache for database metadata. | | `catalogCacheCollectionLookupDurationMillis` | Time in milliseconds to retrieve metadata from the catalog cache for collection metadata. | | `databaseVersionRefreshDurationMillis` | Time in milliseconds to refresh database metadata for operations like [`movePrimary`](https://www.mongodb.com/docs/manual/reference/command/movePrimary.md#mongodb-dbcommand-dbcmd.movePrimary), `createDatabase`, and [`dropDatabase`.](https://www.mongodb.com/docs/manual/reference/command/dropDatabase.md#mongodb-dbcommand-dbcmd.dropDatabase) | | `shardVersionRefreshMillis` | Time in milliseconds that specifies how often to refresh the cache for shard version operations. | Starting in MongoDB 7.0, [log messages for slow queries](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-message-slow-ops) also include the `catalogCacheIndexLookupDurationMillis` field that indicates the time that the operation spent fetching information from the index cache. This release also renames the `shardVersionRefreshMillis` field to `placementVersionRefreshDurationMillis`. `placementVersionRefreshDurationMillis` is the time for refreshing the cache for operations like: - `createCollection` - [`shardCollection`](https://www.mongodb.com/docs/manual/reference/command/shardCollection.md#mongodb-dbcommand-dbcmd.shardCollection) - `dropCollection` - [`moveChunk`](https://www.mongodb.com/docs/manual/reference/command/moveChunk.md#mongodb-dbcommand-dbcmd.moveChunk) - [`renameCollection`](https://www.mongodb.com/docs/manual/reference/command/renameCollection.md#mongodb-dbcommand-dbcmd.renameCollection) - [`reshardCollection`](https://www.mongodb.com/docs/manual/reference/command/reshardCollection.md#mongodb-dbcommand-dbcmd.reshardCollection) - [`refineCollectionShardKey`](https://www.mongodb.com/docs/manual/reference/command/refineCollectionShardKey.md#mongodb-dbcommand-dbcmd.refineCollectionShardKey) - [`mergeChunks`](https://www.mongodb.com/docs/manual/reference/command/mergeChunks.md#mongodb-dbcommand-dbcmd.mergeChunks) - [`split`](https://www.mongodb.com/docs/manual/reference/command/split.md#mongodb-dbcommand-dbcmd.split) The following example includes: - `catalogCacheDatabaseLookupDurationMillis` - `catalogCacheCollectionLookupDurationMillis` - `catalogCacheIndexLookupDurationMillis` ```javascript { "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 Limitations In a Linux system, messages are subject to the rules defined in the Linux configuration file `/etc/systemd/journald.conf`. By default, log message bursts are limited to 1000 messages within a 30 second period. To see more messages, increase the `RateLimitBurst` parameter in `/etc/systemd/journald.conf`. ## Download Your Logs You can use MongoDB Atlas to download a zipped file containing the logs for a selected hostname or process in your database deployment. To learn more, see [View and Download MongoDB Logs.](https://www.mongodb.com/docs/atlas/mongodb-logs/)