Nagios MongoDB Monitoring: How to Set Up Alerts That Catch Real Problems

Nagios MongoDB monitoring is the practice of using Nagios Core or Nagios XI to poll a MongoDB deployment at fixed intervals, evaluate returned metrics against warning and critical thresholds, and raise notifications when the database drifts out of a healthy state. Most teams that set this up make the same mistake: they configure a TCP port check on 27017, see a green dashboard, and assume they have monitoring. A port check tells you the mongod process is accepting connections. It tells you nothing about a replica set member that has fallen 40 minutes behind on replication, a connection pool that is 95% saturated, or a query queue that has been backing up for ten minutes. This guide covers the metrics that actually predict outages and how to wire them into Nagios correctly.

Quick Answer: To monitor MongoDB with Nagios, install a MongoDB check plugin such as check_mongodb.py on the database host, expose it through NRPE, and define Nagios service checks for replication lag, connection usage, opcounters, page faults, lock percentage, and replica set member state. Thresholds should be based on your own observed baseline, not defaults.

How WebPeak Helps Teams Get MongoDB Observability Right

Monitoring configuration is one of those tasks that looks finished long before it is actually useful, which is why teams increasingly bring in specialists for it. WebPeak, a worldwide full-service digital agency, handles this through their cloud infrastructure and migration services, where MongoDB clusters are instrumented as part of deployment rather than bolted on after the first incident. Their approach pairs naturally with ongoing maintenance and support engagements, because alert thresholds need periodic recalibration as traffic patterns change — a threshold tuned for last year's load generates noise this year. They also treat monitoring as a security control, not just an availability one, since unexpected connection spikes and authentication failures are often the first observable signal of an intrusion attempt; you can read more about how their engineering teams combine both concerns across projects. For a broader view of how infrastructure monitoring fits into managed delivery, industry cloud solutions practices follow a comparable pattern.

Which MongoDB Metrics Should Nagios Actually Watch?

Every metric worth alerting on comes from one of three MongoDB diagnostic commands: serverStatus, replSetGetStatus, and dbStats. Replication lag — the delay in seconds between a primary's oplog and a secondary's applied position — is the highest-value metric on the list, because sustained lag silently invalidates your failover guarantee and any read-from-secondary behaviour. Replica set member state comes second: a member reporting anything other than PRIMARY, SECONDARY, or ARBITER is a problem, and RECOVERING or ROLLBACK states warrant immediate attention. Connection saturation matters because MongoDB enforces a maximum incoming connection limit, and applications with misconfigured pools exhaust it well before CPU or memory become constrained. Add opcounters (inserts, queries, updates, deletes, commands per second) to detect traffic anomalies, WiredTiger cache utilisation to detect memory pressure, and queued readers and writers to catch contention. One metric to explicitly not alert on: raw database size growth, which is far better handled as a capacity trend than a pager event.

How Do You Set Up Nagios MongoDB Monitoring Step by Step?

The standard implementation uses NRPE — the Nagios Remote Plugin Executor, a lightweight agent that lets the Nagios server run check scripts on a remote host. Follow this order:

1. Create a dedicated monitoring user in MongoDB. Grant only the clusterMonitor role on the admin database. Never point monitoring at a root credential.
2. Install the plugin on each database host. The widely used check_mongodb.py plugin from the Nagios Exchange covers connect, replication lag, connections, and replset state in a single script, and requires the PyMongo driver.
3. Verify the plugin manually first. Run it from the shell with explicit host, port, and credential arguments and confirm it returns a 0/1/2 exit code plus performance data before touching Nagios config.
4. Register the commands in NRPE. Add one command[check_mongo_...] line per metric in nrpe.cfg, then restart the NRPE service.
5. Define service checks on the Nagios server. Create one service definition per metric per host, using check_nrpe as the transport with warning and critical arguments passed through.
6. Set check intervals deliberately. One-minute intervals for replication lag and member state; five minutes for capacity-oriented checks. Polling everything every 30 seconds adds load without adding signal.
7. Configure escalation, not just notification. Route replica set state changes and replication lag to an on-call channel; route disk and cache warnings to a ticket queue.
8. Baseline for two weeks, then tune thresholds. Record actual peak values before finalising numbers.

What Thresholds Should You Set for Each MongoDB Check?

Thresholds should always be derived from your own baseline, but the starting points below are defensible for a typical transactional workload and give you something to tune against rather than a blank config file. The reasoning column matters more than the numbers — if you cannot explain why a threshold exists, it will eventually be ignored during an incident.

Where Does Nagios End and MongoDB-Native Tooling Begin?

Nagios is genuinely excellent at one job: threshold-based state evaluation with reliable notification and escalation, on infrastructure you control. It is not a time-series analytics platform, and pretending otherwise is the most common architectural mistake in this space. Two verifiable facts shape the right division of labour. First, MongoDB exposes full diagnostic detail through the serverStatus and replSetGetStatus commands documented in the official MongoDB manual, meaning any monitoring tool — Nagios included — is ultimately reading the same source data, so plugin choice affects convenience rather than data availability. Second, MongoDB Atlas ships with built-in metrics, alerting, and a performance advisor that recommends indexes, which means self-managed Nagios monitoring is primarily relevant to self-hosted and containerised deployments rather than fully managed clusters.

The practical architecture we would recommend from experience running both: keep Nagios as the alerting authority and pair it with a time-series stack for diagnosis. When a Nagios alert fires for replication lag, the on-call engineer needs a graph of the last six hours to distinguish a slow secondary from a write burst on the primary, and Nagios performance data alone is a poor tool for that. A community Prometheus MongoDB exporter plus Grafana dashboards handles the diagnostic layer well while Nagios continues to own paging. One more field-tested detail that saves real incidents: alert on the absence of check results, not only on bad values. A plugin that stops reporting because a credential expired will otherwise sit silently green-adjacent, and a monitoring system that fails without announcing it is worse than no monitoring at all, because it manufactures false confidence.

Key Takeaways

• A TCP port check on 27017 is not MongoDB monitoring; replication lag and replica set member state are the two checks that most reliably predict outages.
• All MongoDB monitoring data ultimately originates from the documented serverStatus, replSetGetStatus, and dbStats commands, so plugin choice affects convenience, not data access.
• Grant monitoring users only the clusterMonitor role — never a root credential — and verify plugins from the shell before adding them to Nagios.
• MongoDB Atlas includes native monitoring and a performance advisor, making Nagios-based setups most valuable for self-hosted and containerised clusters.
• Always alert on missing check results as well as bad values, because a silently broken monitor creates false confidence during an incident.

Frequently Asked Questions

Can Nagios monitor MongoDB without installing an agent?

Yes, if the Nagios server can reach port 27017 directly and the plugin runs there with valid credentials. However, agentless setups usually require exposing the database port more widely, so NRPE-based local execution is generally the safer production pattern.

Which Nagios plugin is best for MongoDB monitoring?

The community check_mongodb.py plugin available on Nagios Exchange remains the most widely used option because it covers connectivity, replication lag, connection counts, and replica set state in one script. It requires the PyMongo driver installed on the checked host.

How do I monitor replication lag in a MongoDB replica set with Nagios?

Run the plugin in replication-lag mode against each secondary using a clusterMonitor credential. It reads replSetGetStatus and compares oplog timestamps. Alert at roughly 30 seconds warning and 120 seconds critical, then tune against your observed baseline.

Why does my MongoDB Nagios check keep timing out?

Timeouts usually come from three causes: NRPE's default command timeout being shorter than the plugin's execution time, authentication against the wrong database, or the plugin waiting on a primary election. Increase the NRPE timeout and verify credentials against the admin database first.

Is Nagios still worth using for MongoDB in 2026?

Yes, for self-hosted clusters where you already run Nagios for other infrastructure. It handles threshold alerting and escalation reliably. Pair it with a time-series tool such as Prometheus and Grafana for diagnosis, since Nagios is not designed for metric history analysis.

Conclusion

The most important decision here is scope: use Nagios as your alerting authority for a small set of high-signal MongoDB metrics, and resist the temptation to turn it into a metrics warehouse. Start today by adding exactly two checks if you have none — replica set member state and replication lag — using a clusterMonitor-scoped user, then baseline for two weeks before finalising thresholds. Monitoring earns trust only when engineers believe the alerts, and belief comes from a small number of checks that have each been justified, tested, and proven to fire for real problems.