How to Monitor MongoDB with OpenTelemetry

What to observe in MongoDB

For MongoDB the signals that matter are operation throughput and latency by type, connection usage, cache and working-set behaviour, replication lag across the replica set, and index efficiency. Missing indexes and collection scans are the most common cause of slow operations, and a replica falling behind quietly serves stale reads.

The most useful reading is operation latency alongside whether queries are using indexes, because a MongoDB slowdown is very often a query that has started doing a collection scan as data grew.

How OpenTelemetry collects it

The Collector's mongodb receiver connects to the server and reads its status, emitting operation, connection, cache, lock and index metrics over OTLP. The filelog receiver collects the MongoDB logs, which record slow operations. Application spans carrying the operation and collection let you trace a slow query to its source.

The access detail is the monitoring role: the receiver's user needs the cluster-monitor role to read server status, or the metrics come back incomplete.

Key metrics to watch

The signals that explain most MongoDB incidents:

What to put on a dashboard

A MongoDB dashboard should surface scans, cache pressure and replication first. Row one: operation latency by type and operation throughput. Row two: cache hit ratio and connection usage against the limit. Row three: replication lag per secondary and an indicator of operations not using an index.

# read latency by operation type (rising = likely missing index)
mongodb.operation.latency.time{operation="query"}

# cache miss pressure (working set exceeding cache)
rate(mongodb.cache.operations{type="miss"}[5m])

# connection saturation
mongodb.connection.count{type="active"} / mongodb_connection_limit

Reading the signals: common failure modes

Collection scans from missing indexes

A query that was fast gets slow as the collection grows, because it is scanning every document instead of using an index. Read latency climbs and index-access counts stay flat relative to operations. Add the index the query needs; the logs identify the slow operation.

Cache pressure

Read latency rises and disk activity climbs because the WiredTiger cache can no longer hold the working set, so operations read from disk. Cache misses climbing is the tell. Size the cache to the working set or reduce the data each query touches.

Replication lag

A secondary falls behind the primary, so reads routed to secondaries return stale data and failover would lose recent writes. Lag in seconds is the signal. Causes include a slow secondary, heavy write load, or network issues between members.

Example alert conditions

Starting thresholds to tune:

From monitoring to autonomous resolution

Ops Singularity's TelemetryOps ingests MongoDB telemetry over OpenTelemetry, and Sentinel AI resolves database incidents through governed Action Tickets. Explore TelemetryOps.