Navigation
This version of the documentation is archived and no longer supported.

Log Messages

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:

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

For example:

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:

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:

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:

{
   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:

{
   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:

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.

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):

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.

Log Redaction

Available in MongoDB Enterprise only

A mongod or mongos running with redactClientLogData redacts any message accompanying a given log event before logging, leaving only metadata, source files, or line numbers related to the event. 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 running without log redaction. The mongod has the log verbosity level set to 1:

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

This operation produces the following log event:

2017-06-09T13:35:23.446-04:00 I COMMAND  [conn1] command internal.clients
   appName: "MongoDB Shell"
   command: insert {
      insert: "clients",
      documents: [ {
            _id: ObjectId('593adc5b99001b7d119d0c97'),
            name: "Joe",
            PII: " Sensitive Information"
         } ],
      ordered: true
   }
   ...

When mongod runs with redactClientLogData and performs the same insert operation, it produces the following log event:

2017-06-09T13:45:18.599-04:00 I COMMAND  [conn1] command internal.clients
   appName: "MongoDB Shell"
   command: insert {
      insert: "###", documents: [ {
         _id: "###", name: "###", PII: "###"
      } ],
      ordered: "###"
   }

Use redactClientLogData in conjunction with Encryption at Rest and TLS/SSL (Transport Encryption) to assist compliance with regulatory requirements.