MongoDB logging: JSON fields, rotation, and slow-operation profiling

MongoDB's diagnostic logs have used structured JSON since version 4.4. Each record includes event time, severity, component, context, a message identifier, and event-specific attributes. This makes individual server events easier to search, but collecting the diagnostic file does not automatically collect the database profiler's separate records.

Use systemLog to choose the destination and verbosity, then decide whether slow-operation messages in the diagnostic log are sufficient or a short profiling session is needed. This guide covers self-managed MongoDB; managed services can expose different controls and access paths.

Set the destination and verbosity

A file-based mongod.conf can contain:

systemLog:
  destination: file
  path: /var/log/mongodb/mongod.log
  logAppend: true
  logRotate: reopen
  verbosity: 0
  component:
    command:
      verbosity: 1

destination: file requires a path writable by the MongoDB service. logAppend: true appends on startup rather than starting with a renamed old log. Omitting the destination sends diagnostic output to standard output; syslog is another supported destination on appropriate systems, with its own format and timestamp considerations.

Global verbosity: 0 retains normal informational and more severe events. Values 1 through 5 enable progressively more detailed debug messages. A component setting overrides its inherited level; -1 means inherit. The example increases command detail, which should be a deliberate troubleshooting choice rather than an automatic production default. Lowering a component to 0 removes its debug detail, not all of its messages.

Higher verbosity can expose query details and increase output volume. Change the relevant component for a bounded investigation, record the previous value, then restore it. MongoDB's configuration reference describes the supported destinations and component settings.

Rotate without confusing rename and reopen

MongoDB's rename rotation mode renames the existing log and opens a new one when rotation is requested. The example above selects reopen, which works with an external tool that first renames the file. It requires logAppend: true; MongoDB then closes and reopens the configured path when signaled or commanded.

From an authorized mongosh connection, request rotation with:

db.adminCommand({ logRotate: 1 })

On Unix, the documented SIGUSR1 mechanism is another option for the intended process. In reopen mode, triggering rotation before the external rename simply reopens the same path; it does not create an archive by itself. Coordinate the rename, new-file permissions, reopen action, collector tracking, compression, and retention. Use the official rotation procedure for the selected mode and service environment.

Read the JSON fields

This illustrative record shows the structure of a connection event:

{
  "t": {"$date": "2026-08-25T14:55:22.123+08:00"},
  "s": "I",
  "c": "NETWORK",
  "id": 22943,
  "ctx": "listener",
  "msg": "Connection accepted",
  "attr": {"remote": "192.0.2.8:51234", "connectionCount": 42}
}

Other components include access control, query processing, sharding, and WiredTiger-related subsystems; names and subcomponents vary by version. A slow-operation record may include durationMillis, planSummary, and nreturned under attr, but those attributes do not exist on every record. Treat missing fields as missing, not zero. The log-message reference describes the schema and debug levels.

Collect the diagnostic log in Guance

Configure DataKit file log collection for the actual mongod or mongos path, then test a real record through JSON extraction. Map s to Guance log severity, parse t.$date as event time, and retain c, ctx, id, and the attr fields needed for investigation.

Use distinct instance and role fields for routers, config servers, and shard members. Verify timestamp offsets, numeric duration, and namespaces before comparing hosts. A single JSON parser is not enough if it leaves every nested attribute inside an opaque string.

Profiler records live in system.profile and need a separate, explicitly configured reading path. They are not automatically present in mongod.log merely because the file collector is running.

Enable the profiler with a bounded scope

The database profiler runs on mongod, recording selected operations in a capped system.profile collection. It does not run on mongos. On a self-managed test database with permission to change profiling, inspect the current state before enabling it:

const previous = db.getProfilingStatus();
db.setProfilingLevel(1, { slowms: 100, sampleRate: 1.0, filter: "unset" });
db.system.profile.find().sort({ ts: -1 }).limit(5).pretty();

This example uses the current filter: "unset" option so an existing filter does not silently override the intended threshold. Review an existing policy before replacing it. The profiling level applies to the current database, while slowms and sampleRate affect the process's slow-operation settings more broadly. Coordinate those shared settings with other users of the instance.

At level 1, the threshold and sampling settings select operations unless a profiling filter is configured. A filter changes that selection and makes slowms and sampleRate inapplicable to the filtered diagnostic/profiling behavior. Level 2 profiles all operations; level 0 disables profiling, but does not necessarily disable slow-operation messages in the diagnostic log. Consult the profiling method reference for the version-specific behavior.

In MongoDB 8.0 and later, slow-operation selection uses workingMillis, the time spent actively working on an operation. It excludes waits such as lock acquisition and flow control, so do not assume the threshold is applied to the same elapsed duration displayed in every log record. Check the fields and behavior for your installed version.

Inspect execution-plan information, examined documents or keys, returned documents, and elapsed time where present. COLLSCAN is a useful lead, but a collection scan can be appropriate for a tiny collection or broad query. Compare the query shape, data size, indexes, and workload before deciding what to change.

When the investigation ends, restore the saved settings in the same shell session:

db.setProfilingLevel(previous.was, {
  slowms: previous.slowms,
  sampleRate: previous.sampleRate,
  filter: previous.filter ?? "unset",
});

Runtime profiling changes do not automatically persist across restart. Profiling has CPU, I/O, storage, and data-exposure costs at both levels 1 and 2; a low threshold under heavy load can be expensive even at level 1. Measure impact and bound duration rather than assuming it is safe to leave enabled. The capped collection can overwrite older evidence, so export what must be retained through an approved path.

Follow diagnostic patterns to their cause

These are investigation signals, not single-line diagnoses. Cache pressure does not by itself prove that the host is out of memory, and an election can be expected during maintenance. Correlate the messages with metrics and changes over the same time window.

Frequently asked questions

How do I parse pre-4.4 text logs?

Use a parser matching the older timestamp, severity, component, context, and message layout, such as an appropriate Pipeline grok rule. Validate with the actual version's records. Old releases also need a supported upgrade plan, but changing format alone is not a substitute for compatibility and upgrade testing.

Can I leave level 1 profiling on in production?

Only after evaluating its overhead, threshold, sample rate, filters, retained data, and access controls for that workload. The level number does not guarantee low cost. Diagnostic slow-operation logging may answer the question without collecting profiler records.

Should mongos and mongod logs be collected separately?

Use separate inputs or clear role attributes. Routers, config servers, and shard members have distinct responsibilities and files. A mongos slow-operation setting does not create a local system.profile collection.

How do I investigate repeated elections?

Filter the parsed replication component and examine role transitions across all members, with synchronized event times. Include connectivity and member-health evidence. Before alerting, define which event marks an election, how retries or related messages are deduplicated, and how expected maintenance is handled.

Further reading

• MongoDB database profiler
• Redis logging
• Docker logging
• PostgreSQL logging (Chinese)
• Log aggregation (Chinese)

Technical references checked October 14, 2026. MongoDB configuration and profiler examples are documentation-based; they were not executed against a MongoDB server for this guide.