- Reference >
- Log Messages
Log Messages¶
On this page
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:
For example:
[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:
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 thanremoteOpWaitMillis
, then most of the time was spent waiting for a shard response. For example,durationMillis
of 17 andremoteOpWaitMillis
of 15. - If
durationMillis
is significantly longer thanremoteOpWaitMillis
, then most of the time was spent performing the merge. For example,durationMillis
of 100 andremoteOpWaitMillis
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 > Starting in version 4.2, MongoDB logs the debug verbosity
level. For example, if
verbosity level is 2, MongoDB logs In previous versions, MongoDB log messages only specified |
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:
When secondary members of a replica set initiate a connection to a primary, they send similar data. A typical connection document is as follows:
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 thesystemLog.component.accessControl.verbosity
setting.
-
COMMAND
¶ Messages related to database commands, such as
count
. To specify the log level forCOMMAND
components, use thesystemLog.component.command.verbosity
setting.
-
CONTROL
¶ Messages related to control activities, such as initialization. To specify the log level for
CONTROL
components, use thesystemLog.component.control.verbosity
setting.
-
ELECTION
¶ Messages related specifically to replica set elections. To specify the log level for
ELECTION
components, set thesystemLog.component.replication.election.verbosity
parameter.REPL
is the parent component ofELECTION
. IfsystemLog.component.replication.election.verbosity
is unset, MongoDB uses theREPL
verbosity level forELECTION
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 thesystemLog.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 thesystemLog.component.geo.verbosity
parameter.
-
INDEX
¶ Messages related to indexing operations, such as creating indexes. To specify the log level for
INDEX
components, set thesystemLog.component.index.verbosity
parameter.
-
INITSYNC
¶ Messages related to initial sync operation. To specify the log level for
INITSYNC
components, set thesystemLog.component.replication.initialSync.verbosity
parameter.REPL
is the parent component ofINITSYNC
. IfsystemLog.component.replication.initialSync.verbosity
is unset, MongoDB uses theREPL
verbosity level forINITSYNC
components.
-
NETWORK
¶ Messages related to network activities, such as accepting connections. To specify the log level for
NETWORK
components, set thesystemLog.component.network.verbosity
parameter.
-
QUERY
¶ Messages related to queries, including query planner activities. To specify the log level for
QUERY
components, set thesystemLog.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 thesystemLog.component.replication.verbosity
parameter.
-
REPL_HB
¶ Messages related specifically to replica set heartbeats. To specify the log level for
REPL_HB
components, set thesystemLog.component.replication.heartbeats.verbosity
parameter.REPL
is the parent component ofREPL_HB
. IfsystemLog.component.replication.heartbeats.verbosity
is unset, MongoDB uses theREPL
verbosity level forREPL_HB
components.
-
ROLLBACK
¶ Messages related to rollback operations. To specify the log level for
ROLLBACK
components, set thesystemLog.component.replication.rollback.verbosity
parameter.REPL
is the parent component ofROLLBACK
. IfsystemLog.component.replication.rollback.verbosity
is unset, MongoDB uses theREPL
verbosity level forROLLBACK
components.
-
SHARDING
¶ Messages related to sharding activities, such as the startup of the
mongos
. To specify the log level forSHARDING
components, use thesystemLog.component.sharding.verbosity
setting.
-
STORAGE
¶ Messages related to storage activities, such as processes involved in the
fsync
command. To specify the log level forSTORAGE
components, use thesystemLog.component.storage.verbosity
setting.
-
RECOVERY
¶ Messages related to recovery activities. To specify the log level for
RECOVERY
components, use thesystemLog.component.storage.recovery.verbosity
setting.
-
JOURNAL
¶ Messages related specifically to journaling activities. To specify the log level for
JOURNAL
components, use thesystemLog.component.storage.journal.verbosity
setting.STORAGE
is the parent component ofJOURNAL
. IfsystemLog.component.storage.journal.verbosity
is unset, MongoDB uses theSTORAGE
verbosity level forJOURNAL
components.
-
TXN
¶ Messages related to multi-document transactions. To specify the log level for
TXN
components, use thesystemLog.component.transaction.verbosity
setting.
-
WRITE
¶ Messages related to write operations, such as
update
commands. To specify the log level forWRITE
components, use thesystemLog.component.write.verbosity
setting.
-
-
¶ Messages not associated with a named component. Unnamed components have the default log level specified in the
systemLog.verbosity
setting. ThesystemLog.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
:
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.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):
[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:
The profiler does not capture slow oplog entries. |