MongoDB metrics reference

This page expands on the MongoDB alert thresholds in Exporters with a per-metric description, a PromQL expression, alert thresholds, and troubleshooting guidance. Use it when you’re building alert rules from scratch or investigating an alert that already fired.

MongoDB is Platform’s primary datastore. Every job, task, workflow definition, adapter configuration, and audit record lives there, so a degraded MongoDB instance affects everything Platform does.

Normalized CPU usage on all replica sets

High CPU usage can indicate an inefficient query, a missing index causing a collection scan, a complex aggregation pipeline, or a background operation such as an index build consuming excessive resources. Sustained high CPU can cause query timeouts, connection pool exhaustion, and replication lag as secondaries struggle to keep up.

PromQL:

100 - (avg by (instance, rs_nm) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

Identify expensive queries with db.currentOp() and the profiler, review the slow query log, add indexes for frequently run queries, and check for a runaway background operation.

Normalized memory usage on all replicas

MongoDB uses memory-mapped files and aggressive WiredTiger caching by design, so high memory usage on its own is expected. The danger is memory pressure that forces swapping, since disk I/O is orders of magnitude slower than RAM access and can degrade performance catastrophically.

PromQL:

100 * (1 - ((node_memory_MemAvailable_bytes{job="node_exporter"} or
  (node_memory_MemFree_bytes{job="node_exporter"} + node_memory_Cached_bytes{job="node_exporter"} + node_memory_Buffers_bytes{job="node_exporter"}))
  / node_memory_MemTotal_bytes{job="node_exporter"}))

Check the WiredTiger cache size configuration (target roughly 50% of RAM), review working set size against available RAM, and treat any swap activity as a critical red flag regardless of the memory percentage.

Normalized disk space utilization

MongoDB needs disk space for data files, the WiredTiger journal, the oplog, temporary sort and aggregation files, and backup snapshots. Running out of space causes MongoDB to shut down immediately to prevent data corruption.

PromQL:

100 - ((node_filesystem_avail_bytes{mountpoint=~"/data.*|/var/lib/mongo.*"} /
  node_filesystem_size_bytes{mountpoint=~"/data.*|/var/lib/mongo.*"}) * 100)

This is the second most critical MongoDB alert after an instance being down, since disk exhaustion means immediate shutdown. Free space by removing old backups and logs, review data retention policies, and consider compacting collections (compact, which requires downtime) or enabling compression.

Member health or status

A replica set member can be in state PRIMARY, SECONDARY, RECOVERING, STARTUP, DOWN, ARBITER, or ROLLBACK. An unhealthy member compromises high availability and, if enough members are unhealthy to lose quorum, the primary steps down and writes are blocked cluster-wide.

PromQL:

mongodb_rs_members_health{rs_nm!=""}

Check MongoDB logs on the affected member, verify network connectivity between replica set members, confirm mongod is running (systemctl status mongod), and check for resource exhaustion (CPU, memory, disk).

MongoDB connections

Current connections are all open connections from application servers, monitoring tools, and administrative sessions. MongoDB has a hard connection limit (default 65536, though the effective limit is usually lower due to memory and file descriptor constraints), and rejected connections mean direct user-facing errors.

PromQL:

sum(mongodb_ss_connections{conn_type=~"(current|rejected)"}) by (conn_type)

Identify connection sources with db.currentOp(), check for a connection leak in application code, and tune connection pool sizes rather than increasing maxIncomingConnections as a first response.

Available connections

This is the runway before connection exhaustion: the number of unused connections MongoDB can still accept before hitting maxIncomingConnections. It’s a predictive metric that gives advance warning before rejected connections actually start.

PromQL:

mongodb_ss_connections{env="", conn_type="available"}

Active connections

Active connections are executing an operation right now, as opposed to sitting idle in a pool. This metric distinguishes legitimate traffic growth from operations getting stuck: a spike alongside increasing query latency points to stuck operations, while a spike alone may just be a traffic increase.

PromQL:

mongodb_ss_connections{env="", conn_type="current"}

Use db.currentOp() to identify long-running operations and the slow query log to find problematic queries before killing anything stuck.

Replication lag

Replication lag is the delay between the primary and a secondary applying operations from the oplog, in seconds. High lag means stale reads from that secondary, a longer recovery time if it needs to become primary, and risk of falling off the oplog entirely, which forces a full resync.

PromQL:

mongodb_rs_members_optimeDate{member_state="PRIMARY"} - on(rs_nm) group_right
  mongodb_rs_members_optimeDate{member_state="SECONDARY"}

Check network latency between members (mongodb_rs_members_pingMs), review the secondary’s CPU and disk I/O, and check for a long-running operation on the secondary with db.currentOp().

Database size

Total storage size per database, excluding admin, config, and local. Unexpected growth can point to a missing time-to-live (TTL) index, an application bug creating duplicate data, or a data model issue, ahead of it becoming a disk space emergency.

PromQL:

sum(mongodb_dbstats_storageSize{database!~"(admin|config|local)"}) by (database)

Use db.stats() and db.collection.stats() to identify which collections are growing, and check for orphaned or duplicate documents.

Average object size

Average document size per database (total data size divided by document count). A significant change can indicate document bloat, large binary data stored inline instead of in GridFS, or an unbounded array growing without limit.

PromQL:

sum(mongodb_dbstats_avgObjSize{database!~"(admin|config|local)"}) by (database)

Oplog size

The oplog is a rolling record of every operation that modifies data, used for replication, initial sync, and point-in-time recovery. The oplog window is how much time it spans. If a secondary is offline longer than the window, it falls off the oplog and needs a full resync, which can take hours or days.

PromQL:

mongodb_oplog_stats_timeDiff{rs_nm!=""}

Increase the oplog size online with replSetResizeOplog, and make sure the window comfortably covers your longest planned maintenance window.

Allocated storage to collections

Total disk space allocated to collections and their indexes, including space pre-allocated for growth. A high ratio of allocated space to actual data size indicates fragmentation from deletes and updates.

PromQL:

sum(mongodb_collstats_storageSize) by (database, collection)

The compact command reclaims fragmented space but requires blocking writes to that collection, so schedule it during a maintenance window.

Disk I/O performance

Read latency

Average time to complete a disk read (total read time divided by read count). Queries not served from cache, index scans reading from disk, and large aggregations are all sensitive to this.

PromQL:

rate(node_disk_read_time_seconds_total{device=~"sd.*|nvme.*"}[5m]) /
  rate(node_disk_reads_completed_total{device=~"sd.*|nvme.*"}[5m])

Write latency

Average time to complete a disk write. MongoDB’s durability guarantee depends on writes reaching the journal, so write latency also drives replication lag and write concern timeouts.

PromQL:

rate(node_disk_write_time_seconds_total{device=~"sd.*|nvme.*"}[5m]) /
  rate(node_disk_writes_completed_total{device=~"sd.*|nvme.*"}[5m])

Ensure the journal is on fast storage, ideally the same tier as the data files, and check for fsync or checkpoint stalls.

I/O wait percentage

The percentage of CPU time spent waiting on disk I/O. High I/O wait means the storage subsystem, not CPU or memory, is the bottleneck, and it correlates directly with slow queries and replication lag even when CPU and memory both look fine.

PromQL:

avg by (instance) (rate(node_cpu_seconds_total{mode="iowait"}[5m])) * 100

Add indexes to reduce data scanned, increase RAM so the working set fits in memory, and consider faster storage or sharding to distribute I/O load.