Reference >
Log Messages

Log Messages¶

On this page

Log Message Format (Console/Log File)
Timestamp (Console/Log File)
Severity Levels
Client Data
Components
Verbosity Levels

Log Message Format (Console/Log File)¶

Starting in MongoDB 3.0, MongoDB includes the severity level and the component for each log message when output to the console or a logfile (i.e. not to syslog [1]).

The log messages have the form:

copy

<timestamp> <severity> <component> [<context>] <message>

For example:

copy

2014-11-03T18:28:32.450-0500 I NETWORK [initandlisten] waiting for connections on port 27017

[1]	Syslog messages follow the standard syslog message format. Starting in version 4.2, MongoDB includes the component in its log messages to `syslog`.

Logging Slow Operations¶

Client operations appear in the log if their duration exceeds the slow operation threshold or when the log verbosity level is 1 or higher. [3] These log entries include the full command object associated with the operation.

Starting in MongoDB 4.2, the profiler entries and the diagnostic log messages (i.e. mongod/mongos log messages) for read/write operations include:

queryHash to help identify slow queries with the same query shape.
planCacheKey to provide more insight into the query plan cache for slow queries.

The following example output includes information about a slow aggregation operation:

copy

2019-01-14T12:00:59.166-0500 I COMMAND  [conn4] command test.items appName: "MongoDB Shell" command: aggregate { aggregate: "items", pipeline: [ { $match: { a: { $lte: 500.0 } } }, { $sort: { a: -1.0 } } ], allowDiskUse: true, cursor: {}, lsid: { id: UUID("a73100a6-2f4d-48b7-a119-4632491c20eb") }, $db: "test" } planSummary: IXSCAN { a: 1, _id: -1 } cursorid:4808731480531288834 keysExamined:12524506 docsExamined:25003 hasSortStage:1 usedDisk:1 fromMultiPlanner:1 numYields:98113 nreturned:101 queryHash:811451DD planCacheKey:759981BA reslen:1305014 locks:{ Global: { acquireCount: { r: 98211, w: 98211 } }, Database: { acquireCount: { r: 98211 } }, Collection: { acquireCount: { r: 98211 } } } storage:{ data: { bytesRead: 112803842, timeReadingMicros: 62720 } } protocol:op_msg 39658ms

Time Waiting for Shards Logged in `remoteOpWaitMillis` Field¶

New in version 4.2.10.

Starting in MongoDB 4.2.10, you can use the remoteOpWaitMillis log field to obtain the wait time (in milliseconds) for results from shards.

remoteOpWaitMillis is only logged:

If you configure slow operations logging.
On the shard or mongos that merges the results.

To determine if a merge operation or a shard issue is causing a slow query, compare the durationMillis and remoteOpWaitMillis time fields in the log. durationMillis is the total time the query took to complete. Specifically:

If durationMillis is slightly longer than remoteOpWaitMillis, then most of the time was spent waiting for a shard response. For example, durationMillis of 17 and remoteOpWaitMillis of 15.
If durationMillis is significantly longer than remoteOpWaitMillis, then most of the time was spent performing the merge. For example, durationMillis of 100 and remoteOpWaitMillis of 15.

Timestamp (Console/Log File)¶

When logging to the console or a logfile [2], the default format for the <timestamp> is iso8601-local. To modify the timestamp format, use the --timeStampFormat runtime option or the systemLog.timeStampFormat setting.

[2]	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 Levels¶

The following table lists the severity levels associated with each log message:

Level	Description
`F`	Fatal
`E`	Error
`W`	Warning
`I`	Informational, for Verbosity Level of `0`
`D`[1-5]	Debug, for All Verbosity Levels > `0` Starting in version 4.2, MongoDB logs the debug verbosity level. For example, if verbosity level is 2, MongoDB logs `D2`. In previous versions, MongoDB log messages only specified `D` for Debug level.

You can specify the verbosity level of various components to determine the amount of Informational and Debug messages MongoDB outputs. [3]

To set verbosity levels, see Configure Log Verbosity Levels.

Client Data¶

New in version 3.4.

Client application debugging and performance monitoring is easier when you can clearly match server events with particular client requests. With this in mind, recent MongoDB drivers and client applications (including the mongo shell) have the ability to 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.

The exact fields included vary by client. Below is a sample client data document:

copy

{
   application: {
     name: "MongoDB Shell"
   },
   driver: {
      name: "MongoDB Internal Client",
      version: "3.4.0"
   },
   os: {
      type: "Darwin",
      name: "Mac OS X",
      architecture: "x86_64",
      version: "15.3.0"
   }
}

When secondary members of a replica set initiate a connection to a primary, they send similar data. A typical connection document is as follows:

copy

{
   driver: {
      name: "NetworkInterfaceASIO-Replication",
      version: "3.4.0"
   },
   os: {
      type: "Darwin",
      name: "Mac OS X",
      architecture: "x86_64",
      version: "15.3.0"
   }
}

For a complete description of client information and required fields, see the MongoDB Handshake specification.

Components¶

Log messages now include components, providing functional categorization of the messages:

ACCESS¶: Messages related to access control, such as authentication. To specify the log level for ACCESS components, use the systemLog.component.accessControl.verbosity setting.

COMMAND¶: Messages related to database commands, such as count. To specify the log level for COMMAND components, use the systemLog.component.command.verbosity setting.

CONTROL¶: Messages related to control activities, such as initialization. To specify the log level for CONTROL components, use the systemLog.component.control.verbosity setting.

ELECTION¶

Messages related specifically to replica set elections. To specify the log level for ELECTION components, set the systemLog.component.replication.election.verbosity parameter.

REPL is the parent component of ELECTION. If systemLog.component.replication.election.verbosity is unset, MongoDB uses the REPL verbosity level for ELECTION components.

FTDC¶: New in version 3.2.

Messages related to the diagnostic data collection mechanism, such as server statistics and status messages. To specify the log level for FTDC components, use the systemLog.component.ftdc.verbosity setting.

GEO¶: Messages related to the parsing of geospatial shapes, such as verifying the GeoJSON shapes. To specify the log level for GEO components, set the systemLog.component.geo.verbosity parameter.

INDEX¶: Messages related to indexing operations, such as creating indexes. To specify the log level for INDEX components, set the systemLog.component.index.verbosity parameter.

INITSYNC¶

Messages related to initial sync operation. To specify the log level for INITSYNC components, set the systemLog.component.replication.initialSync.verbosity parameter.

REPL is the parent component of INITSYNC. If systemLog.component.replication.initialSync.verbosity is unset, MongoDB uses the REPL verbosity level for INITSYNC components.

NETWORK¶: Messages related to network activities, such as accepting connections. To specify the log level for NETWORK components, set the systemLog.component.network.verbosity parameter.

QUERY¶: Messages related to queries, including query planner activities. To specify the log level for QUERY components, set the systemLog.component.query.verbosity parameter.

REPL¶: Messages related to replica sets, such as initial sync, heartbeats, steady state replication, and rollback. [3] To specify the log level for REPL components, set the systemLog.component.replication.verbosity parameter.

REPL_HB¶

Messages related specifically to replica set heartbeats. To specify the log level for REPL_HB components, set the systemLog.component.replication.heartbeats.verbosity parameter.

REPL is the parent component of REPL_HB. If systemLog.component.replication.heartbeats.verbosity is unset, MongoDB uses the REPL verbosity level for REPL_HB components.

ROLLBACK¶

Messages related to rollback operations. To specify the log level for ROLLBACK components, set the systemLog.component.replication.rollback.verbosity parameter.

REPL is the parent component of ROLLBACK. If systemLog.component.replication.rollback.verbosity is unset, MongoDB uses the REPL verbosity level for ROLLBACK components.

SHARDING¶: Messages related to sharding activities, such as the startup of the mongos. To specify the log level for SHARDING components, use the systemLog.component.sharding.verbosity setting.

STORAGE¶: Messages related to storage activities, such as processes involved in the fsync command. To specify the log level for STORAGE components, use the systemLog.component.storage.verbosity setting.

RECOVERY¶: Messages related to recovery activities. To specify the log level for RECOVERY components, use the systemLog.component.storage.recovery.verbosity setting.

JOURNAL¶

Messages related specifically to journaling activities. To specify the log level for JOURNAL components, use the systemLog.component.storage.journal.verbosity setting.

STORAGE is the parent component of JOURNAL. If systemLog.component.storage.journal.verbosity is unset, MongoDB uses the STORAGE verbosity level for JOURNAL components.

TXN¶: Messages related to multi-document transactions. To specify the log level for TXN components, use the systemLog.component.transaction.verbosity setting.

WRITE¶: Messages related to write operations, such as update commands. To specify the log level for WRITE components, use the systemLog.component.write.verbosity setting.

-¶: Messages not associated with a named component. Unnamed components have the default log level specified in the systemLog.verbosity setting. The systemLog.verbosity setting is the default setting for both named and unnamed components.

Verbosity Levels¶

View Current Log Verbosity Level¶

To view the current verbosity levels, use the db.getLogComponents() method.

Configure Log Verbosity Levels¶

You can configure the verbosity level using: the systemLog.verbosity and systemLog.component.<name>.verbosity settings, the logComponentVerbosity parameter; the db.setLogLevel() method. [3]

`systemLog` Verbosity Settings¶

To configure the default log level for all components, use the systemLog.verbosity setting. To configure the level of specific components, use the systemLog.component.<name>.verbosity settings.

For example, the following configuration sets the systemLog.verbosity to 1, the systemLog.component.query.verbosity to 2, the systemLog.component.storage.verbosity to 2, and the systemLog.component.storage.journal.verbosity to 1:

copy

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

All components not specified in the configuration have the systemLog.verbosity of 1.

`logComponentVerbosity` Parameter¶

To set the logComponentVerbosity parameter, pass a document with the verbosity settings to change.

For example, the following sets the default verbosity level to 1, the query to 2, the storage to 2, and the storage.journal to 1.

copy

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

`db.setLogLevel()`¶

Use the 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 to its parent verbosity (i.e. default verbosity):

copy

db.setLogLevel(-1, "query")

[3]

(1, 2, 3, 4)

Starting in version 4.2, secondary members of a replica set now log oplog entries that take longer than the slow operation threshold to apply. These slow oplog messages:

Are logged for the secondaries in the diagnostic log.
Are logged under the REPL component with the text applied op: <oplog entry> took <num>ms.
Do not depend on the log levels (either at the system or component level)
Do not depend on the profiling level.
May be affected by slowOpSampleRate, depending on your MongoDB version:

In MongoDB 4.2, these slow oplog entries are not affected by the slowOpSampleRate. MongoDB logs all slow oplog entries regardless of the sample rate.

The profiler does not capture slow oplog entries.

← MongoDB Wire Protocol Exit Codes and Statuses →

Log Messages¶

Log Message Format (Console/Log File)¶

Logging Slow Operations¶

Time Waiting for Shards Logged in remoteOpWaitMillis Field¶

Timestamp (Console/Log File)¶

Severity Levels¶

Client Data¶

Components¶

Verbosity Levels¶

View Current Log Verbosity Level¶

Configure Log Verbosity Levels¶

systemLog Verbosity Settings¶

logComponentVerbosity Parameter¶

db.setLogLevel()¶

Time Waiting for Shards Logged in `remoteOpWaitMillis` Field¶

`systemLog` Verbosity Settings¶

`logComponentVerbosity` Parameter¶

`db.setLogLevel()`¶