MongoDB looks deceptively simple to run until the day a primary election takes down write traffic for forty seconds, or a shard fills up and nobody notices until queries start timing out. Monitoring MongoDB properly means watching replication health, shard balance, and query performance together, not treating them as separate concerns. Get that wrong and you find out about problems from angry users instead of from a dashboard.
This piece walks through what actually matters in a production MongoDB deployment – replica sets, sharded clusters, and the performance metrics that predict trouble before it hits.
Replica Set Health: What to Watch and Why
A replica set’s whole job is to survive a node failure without losing data or availability. That only works if replication is actually keeping up.
Replication lag is the single most important number here. If a secondary falls too far behind the primary’s oplog, two things go wrong: read-preference queries against that secondary return stale data, and if the primary dies before the secondary catches up, you can lose writes. Anything over a few seconds of lag under normal load deserves attention; sustained lag in the tens of seconds usually points at disk I/O contention or a secondary that’s undersized relative to the primary.
The oplog window is the second thing worth tracking, and it’s the one teams forget until it bites them. The oplog is a capped collection – once it fills, old entries roll off. If a secondary goes offline for maintenance longer than the oplog window covers, it can’t resume replication and needs a full resync, which on a large collection can take hours. Track oplog window size in minutes/hours, not just percentage full.
Also watch:
Election frequency – frequent primary elections usually mean network flakiness or resource starvation, not bad luck.
Replica set member state – a node stuck in RECOVERING or ROLLBACK needs immediate attention.
Heartbeat latency between members – rising latency between nodes in different availability zones often precedes an election storm.
Sharding Metrics That Actually Matter
Sharding solves a scale problem and introduces a balance problem. A common misconception is that MongoDB automatically keeps data evenly distributed across shards the moment sharding is enabled. It doesn’t – the balancer runs migrations gradually and can fall behind, especially with a poorly chosen shard key.
Watch chunk distribution per shard. If one shard is holding a disproportionate share of chunks or data size, queries against that range become a bottleneck regardless of how much capacity the cluster has overall. This is almost always a shard key problem – monotonically increasing keys (timestamps, auto-incrementing IDs) create hot shards because all new writes land on the same range.
Other sharding metrics worth tracking:
Balancer activity – is it running, and how long do migrations take? A balancer that’s been disabled for “just a little while” during a busy period and never re-enabled is a surprisingly common find during audits.
mongos query routing – scatter-gather queries that hit every shard instead of targeting one are expensive; a rising rate of these usually means queries aren’t including the shard key.
Config server health – often ignored because it “just works,” but if config servers fall behind, chunk metadata gets stale and routing breaks in subtle ways.
Core Performance Metrics Beyond Cluster Topology
Independent of replica set or sharding concerns, a handful of numbers tell you whether MongoDB itself is under stress:
WiredTiger cache usage – when the cache is consistently near 100% and eviction rates climb, working set no longer fits in memory and MongoDB starts reading from disk more often, which shows up as latency.
Queued reads and writes (ticket exhaustion) – WiredTiger uses a limited number of concurrency tickets; when they’re exhausted, operations queue instead of running, and this is often the real cause of “random” slowdowns.
Connection counts – MongoDB has a hard connection limit, and a leaking connection pool from an application server can quietly march toward it over days. This is the same failure pattern covered in database connection pool monitoring, and it applies just as much to MongoDB as to relational databases.
Slow query log volume – a sudden jump usually correlates with a missing index after a schema change, not a hardware issue.
These four alone catch the majority of real-world MongoDB incidents. For a broader view of which numbers matter across database engines generally, it’s worth comparing against the metrics outlined in database health metrics every DBA should monitor.
A Myth Worth Retiring
Replication is not backup. This gets said often but still trips teams up: a replica set protects against hardware failure and downtime, not against a bad application deploy that deletes or corrupts data. Corruption or accidental deletes replicate to every secondary within seconds. Point-in-time backups or oplog-based recovery are the only real protection against that scenario, and they need to be verified independently, not assumed to work because replication looks healthy.
Setting Up Practical Alerting
A workable alerting baseline looks like this:
1. Alert on replication lag exceeding a threshold tied to your oplog window, not a fixed number – ten seconds means something different on a cluster with a six-hour oplog than one with a six-day oplog.
2. Alert on primary elections happening more than once in a short window.
3. Alert on WiredTiger cache eviction rate trending upward over a sustained period, not single spikes.
4. Alert on connection count approaching the configured limit.
5. Alert on unbalanced chunk distribution across shards.
Baselines matter more than fixed thresholds here, since normal load varies a lot between a reporting cluster and an OLTP-heavy one. Building those baselines from historical data is exactly the approach described in capacity planning with historical monitoring data – knowing what “normal” oplog growth or cache pressure looks like for your workload makes anomalies obvious instead of guesswork.
FAQ
How much replication lag is acceptable in MongoDB?
There’s no universal number – it depends on your oplog window and how read preference is configured. As a rule of thumb, sustained lag beyond a few seconds under normal load warrants investigation, and lag approaching your oplog window size is urgent.
Does sharding automatically fix performance problems?
No. Sharding distributes load across more hardware, but a poor shard key can concentrate reads and writes on a single shard anyway, negating the benefit. Shard key choice matters more than the number of shards.
Is a healthy replica set enough for disaster recovery?
No. Replica sets protect against node failure, not data corruption or accidental deletion, since bad writes replicate everywhere. Separate, verified backups are still required.
MongoDB rewards teams that watch replication lag, oplog window, and shard balance as a single picture rather than isolated numbers. Start with those three, layer in cache and connection metrics, and most production incidents get caught while they’re still a warning instead of an outage.