MongoDB performance monitoring in production: a 2026 guide

MongoDB monitoring is split across four surfaces — serverStatus(), db.stats(), currentOp(), and the profiler. Each tells a different story; none alone is enough. This is what we scrape from each in production, and how to reason about replica lag, oplog window, and aggregation pipeline cost.

The four surfaces

serverStatus — host metrics

Run from admin. The whole document is huge; the fields worth scraping every 15s are bounded.

db.adminCommand({ serverStatus: 1 })

// extract:
opcounters.{insert,query,update,delete,getmore,command}
opcountersRepl.*                                // for replicas
connections.{current,available,totalCreated}
network.{bytesIn,bytesOut,numRequests}
wiredTiger.cache.{
  "bytes currently in the cache",
  "tracked dirty bytes in the cache",
  "pages evicted by application threads",
  "unmodified pages evicted",
  "modified pages evicted"
}
locks.Global.acquireCount.{r,w,R,W}
asserts.{regular,warning,msg,user,rollovers}
metrics.queryExecutor.scanned                   // collection scans
metrics.queryExecutor.scannedObjects

db.stats — per-database storage

db.stats()

// fields worth tracking:
collections, indexes, dataSize, storageSize, indexSize, totalSize

Track these per-database, daily. Sudden growth in indexSize usually means someone added an index that doesn’t fit in cache; sudden growth in storageSize without document growth means fragmentation.

currentOp — live activity

The 1 Hz poll for live ops. Filter aggressively or you’ll DoS your own monitoring.

db.currentOp({
  active: true,
  $or: [
    { secs_running: { $gt: 1 } },               // > 1s
    { "lockStats.acquireWaitCount.r": { $gt: 0 } },
    { "lockStats.acquireWaitCount.w": { $gt: 0 } }
  ]
})

For each op, scrape:

• opid, op, ns (namespace = db.collection)
• secs_running — wall-clock duration so far
• command — the BSON of the actual operation
• planSummary — index hint + plan stage names
• waitingForLock, lockStats — lock waits per scope (Global / Database / Collection)

Profiler — slow query log

Set per-database. The profiler writes to system.profile in that database. Level 1 means “log slow ops only.”

db.setProfilingLevel(1, { slowms: 100, sampleRate: 1.0 })

// then read:
db.system.profile
  .find({ millis: { $gt: 200 } })
  .sort({ ts: -1 }).limit(50)

For each profile entry, the meaningful fields are ts, op, ns, command, planSummary, keysExamined, docsExamined, nreturned, millis, and writeConflicts.

High docsExamined with low nreturned = missing index. High writeConflicts = MongoDB’s deadlock-equivalent on an unsharded write-heavy collection.

Replica set metrics

rs.status()

// derive:
members[i].health, members[i].state, members[i].uptime
members[i].optimeDate                           // for replication lag
SECONDARY_optime - PRIMARY_optime               // = lag, in seconds

• Track lag as maxLag across all secondaries — alert on it.
• Oplog window: db.getReplicationInfo().tFirst to tLast. If a secondary is > window behind, it falls off and needs a resync.
• Election count from serverStatus.electionMetrics — repeated elections mean instability.

Sharded cluster metrics

From mongos:

sh.status()

// extract per shard:
chunks count
moveChunk activity (from changelog)
balancer state
config.collections (sharded collections, shard keys)

The most common sharded-cluster pathology is a hot shard — one shard handling most of the writes. Look at per-shard opcounters and chunk counts.

Aggregation pipeline performance

$group, $lookup, and $unwind stages are where aggregations become expensive. Use $indexStats and explain():

db.orders.explain("executionStats").aggregate([
  { $match: { customerId: ObjectId(...) } },
  { $group: { _id: "$status", n: { $sum: 1 } } }
])

// look for:
executionStats.totalDocsExamined / nReturned     // ratio < 10 ideal
stages[i].executionTimeMillisEstimate            // hot stages

FAQ