MongoDB monitoring: operations, cache and replica sets
Track operation latency, WiredTiger cache, connections, replication lag and oplog window for every MongoDB deployment, and see which service sends the slow queries.
Why monitor MongoDB with Obseria
Latency per operation type
Reads, writes and commands are measured separately, so you see whether a slowdown comes from queries, inserts or updates.
Replica set safety
Replication lag and oplog window per member warn you before a secondary falls too far behind to catch up.
Queries linked to code
Database spans from OpenTelemetry instrumentation show the collection, operation and endpoint behind each slow request.
MongoDB components Obseria monitors
- mongod instances. Operations, latency, connections, cursors, memory and network I/O per instance.
- WiredTiger storage engine. Cache hits and misses, cache reads and concurrent transaction tickets in use.
- Replica sets. Member count and status, replication lag, oplog size, oplog window and replication headroom.
- Databases and collections. Collections, objects, data and storage size, index count and index size per database.
- Indexes and query execution. Index access counts, collection scans and scanned documents versus returned results.
- MongoDB Atlas. Atlas clusters through the OpenTelemetry mongodbatlas receiver, which reads metrics from the Atlas API.
The MongoDB signals that matter
Obseria collects these values automatically and shows them in ready-made dashboards and alerts.Workload and speed
Shows how many requests the database handles and how quickly it answers them, the basis for fast applications.
Replication safety
Tells you whether backup copies are up to date and how much time you have to recover after an outage.
Query efficiency
Reveals inefficient searches, waiting requests and abandoned lookups that slow down your applications without obvious errors.
Memory and cache
Shows how much memory the database uses and how well it keeps frequently used data close at hand.
Show all 10 metrics in detail
| Metric | Unit | What it tells you |
|---|---|---|
mongodb.operation.count | {operations} | Operations by type (insert, query, update, delete, getmore, command). |
mongodb.operation.latency.time | us | Latency per operation type for reads, writes and commands. |
mongodb.connection.count | {connections} | Active, available and current connections; available near zero blocks clients. |
mongodb.cache.operations | {operations} | WiredTiger cache hits and misses; a rising miss share means the working set does not fit. |
mongodb.replica_set.lag | s | How far a secondary is behind the primary. |
mongodb.oplog.window | s | Time span covered by the oplog; lag must stay well below it. |
mongodb.global_lock.time | ms | Time the global lock has been held. |
mongodb.query_executor.collection_scan.count | {query} | Queries that scanned whole collections, a sign of missing indexes. |
mongodb.cursor.timeout.count | {cursors} | Cursors that timed out, often from clients that never close them. |
mongodb.memory.usage | By | Resident and virtual memory of the mongod process. |
Set up MongoDB monitoring in minutes
- Step 1
Create a monitoring user
Create a MongoDB user with the built-in clusterMonitor role and keep its password in an environment variable.
- Step 2
Configure the mongodb receiver
Add the mongodb receiver to the OpenTelemetry Collector or Obseria Agent and enable replication lag, oplog window and latency metrics.
- Step 3
Instrument the clients
Add OpenTelemetry instrumentation to the services that use the MongoDB drivers, so database spans connect queries to requests.
receivers:
mongodb:
hosts:
- endpoint: mongo-0.mongo:27017
username: otel_monitor
password: ${env:MONGODB_PASSWORD}
collection_interval: 30s
tls:
insecure: false
ca_file: /etc/otel/mongo-ca.pem
metrics:
mongodb.replica_set.lag:
enabled: true
mongodb.oplog.window:
enabled: true
mongodb.operation.latency.time:
enabled: true
exporters:
otlphttp:
endpoint: ${env:OBSERIA_OTLP_ENDPOINT}
headers:
Authorization: "Bearer ${env:OBSERIA_TOKEN}"
service:
pipelines:
metrics:
receivers: [mongodb]
exporters: [otlphttp]
Out of the box
Dashboards, alerts and SLOs that are ready the moment data arrives.
- MongoDB overview: operations, latency, connections
- WiredTiger cache efficiency
- Replica set health, replication lag and oplog window
- Alert: replication lag above half the oplog window
- Alert: collection scans or latency above baseline
MongoDB monitoring: what matters
Why MongoDB monitoring matters
MongoDB is popular because it adapts to changing data models without migrations. That flexibility moves responsibility into the application: which fields are indexed, how documents grow, how queries are shaped. Performance problems in MongoDB are therefore often caused by code changes rather than by the database itself. MongoDB monitoring needs to connect database metrics with the services and queries that produce the load.
Obseria collects metrics with the mongodb receiver of the OpenTelemetry Collector, which reads serverStatus, dbStats and replica set status. For MongoDB Atlas, the mongodbatlas receiver reads metrics from the Atlas API. Database spans from your services add the query context.
The MongoDB metrics that matter
Throughput and latency
mongodb.operation.count shows operations by type and mongodb.operation.latency.time shows latency for reads, writes and commands. A latency increase only for writes points to journaling, replication write concern or disk; an increase only for reads points to indexes or cache.
WiredTiger cache
WiredTiger keeps the working set in its cache. mongodb.cache.operations reports hits and misses. When the miss share rises, reads go to disk and latency follows. Typical causes are growing collections, new query patterns that touch cold data, or a cache that is too small for the instance.
Connections and cursors
mongodb.connection.count distinguishes current and available connections. If available connections approach zero, new clients wait or fail. mongodb.cursor.timeout.count grows when clients open cursors and never exhaust or close them.
Replication
In a replica set, mongodb.replica_set.lag shows how far each secondary is behind. mongodb.oplog.window is how much history the oplog holds. If lag ever exceeds the window, the secondary can no longer catch up and needs a full resync.
Common problems and how to detect them
- Missing indexes:
mongodb.query_executor.collection_scan.countrises and scanned documents far exceed returned documents. The database span in the trace shows which collection and endpoint are involved. - Cache pressure: cache misses grow together with disk reads on the host. Review the working set and index sizes.
- Connection storms: many application pods each open large pools after a deployment. Watch current connections against available connections.
- Replication lag: heavy write bursts or an overloaded secondary. Alert when lag exceeds a fraction of the oplog window, for example half.
- Lock contention: long global or collection lock times during index builds or large updates.
Best practices for MongoDB monitoring
- Use a dedicated user with the
clusterMonitorrole instead of an administrative account. - Monitor every replica set member, not only the primary, and tag metrics with the member state.
- Track oplog window during peak traffic, because that is when it is shortest.
- Enable the database profiler only for short investigations with a slow threshold; rely on database spans for continuous visibility.
- Keep query shapes visible but values masked; Obseria Pipeline can strip sensitive fields from database spans at ingest.
How Obseria helps with MongoDB monitoring
Obseria stores MongoDB metrics, logs and database spans in one place in Obseria Lake. TopoGraph shows which services use which MongoDB cluster and collection, so a latency alert immediately names the affected applications. Obseria Intelligence correlates slowdowns with deployments, new query patterns, cache misses and host metrics, and shows the likely root cause with a chain of evidence. Dashboards for operations, cache and replica set health, alerts and SLOs are included.
A good rollout starts with the receiver on every replica set, followed by OpenTelemetry instrumentation in the services with the highest database traffic. With OQL you can then filter database spans by collection and operation and compare their p95 latency with cache misses over the same window, all without leaving the platform.
For sharded clusters, look at metrics per shard and per mongos router separately. Uneven operation counts across shards point to a poorly chosen shard key, which database spans per collection make easy to confirm. An alert on the oplog window per shard keeps a single secondary from silently falling out of reach.
Related integrations
Related capabilities
Database Monitoring
Find the slow query behind a slow endpoint. Obseria links database metrics, query performance and logs to the traces and services that call them.
Learn moreDistributed Tracing
Follow each request across services, queues and databases with OpenTelemetry-native distributed tracing, and find the slow span or failing dependency in seconds.
Learn moreAnomaly Detection
Obseria Intelligence learns the normal rhythm of every service, flags real deviations instead of threshold noise and groups related anomalies into one problem with a probable root cause.
Learn moreLearn more
The four golden signals: latency, traffic, errors and saturation
The four golden signals explained: latency, traffic, errors and saturation, how they relate to the RED and USE methods, and how to measure them with OTel.
What is root cause analysis (RCA)?
What is root cause analysis? The RCA process for software incidents, 5 Whys, fishbone and fault tree methods, a worked example and how AI speeds up RCA.
MongoDB monitoring FAQ
Yes. The OpenTelemetry mongodbatlas receiver reads cluster metrics from the Atlas API with an API key, and self-managed deployments use the mongodb receiver.
The built-in clusterMonitor role is enough to read server status, replica set status and database statistics.
Enable mongodb.replica_set.lag and mongodb.oplog.window in the receiver and alert when lag reaches a significant share of the oplog window.
Use database spans from OpenTelemetry instrumentation of your MongoDB driver to see slow operations per collection and endpoint, and watch collection scan counts for missing indexes.
The receiver runs lightweight status commands at the collection interval you set, typically every 10 to 60 seconds, which is negligible for most deployments.
Start monitoring MongoDB today
Connect MongoDB in minutes with OpenTelemetry or the Obseria Agent. Free for 14 days.