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

Log Messages

Log Message Format

Changed in version 3.0.

Starting in MongoDB 3.0, MongoDB includes the severity level and the component associated with each log message. 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

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

The following example output includes information about an aggregation operation:

2017-10-13T10:55:42.935-0700 I COMMAND  [conn1] command test.items appName: "MongoDB Shell" command: aggregate { aggregate: "items", pipeline: [ { $match: { a: { $gte: 4.0 } } } ], cursor: {} } planSummary: COLLSCAN keysExamined:0 docsExamined:5 cursorExhausted:1 numYields:0 nreturned:2 reslen:155 locks:{ Global: { acquireCount: { r: 8 } }, Database: { acquireCount: { r: 4 } }, Collection: { acquireCount: { r: 3 } } } protocol:op_command 0ms


The default format for the <timestamp> is iso8601-local. To modify the timestamp format, use the --timeStampFormat runtime option or the systemLog.timeStampFormat setting.

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 Debug, for All Verbosity Levels > 0

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

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.


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


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


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


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


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.


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.


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


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


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


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


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.


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.


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.


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


Messages related specifically to journaling activities. To specify the log level for JOURNAL components, use the setting.

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


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. [1]

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 to 2, and the to 1:

   verbosity: 1
         verbosity: 2
         verbosity: 2
            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
} )


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")
[1](1, 2, 3) For MongoDB 3.6 deployments, starting in version 3.6.11, 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 under the REPL component with the text applied op: <oplog entry> took <num>ms. These slow oplog entries depend only on the slow operation threshold. They do not depend on the log levels (either at the system or component level), or the profiling level, or the slow operation sample rate. The profiler does not capture slow oplog entries.