MongoDB Monitoring and Alerts: A Practical Guide with Real Examples

Intro

MongoDB monitoring and alerts with practical examples should help operators move from an observed problem to a verified result. Start by identifying the installed version, deployment topology, prerequisites, and the exact component being inspected.

This article focuses on MongoDB monitoring for developers, DevOps consultants, and technical startup teams. It connects MongoDB alerts, MongoDB metrics, MongoDB dashboards, and MongoDB incident response to commands, expected output, failure signals, and recovery decisions that match the selected technology.

The goal is operational safety: observe before changing, limit the blast radius, use placeholders instead of secrets, verify the result, and document how to recover if the expected state is not reached.

Version and Environment Inventory

Before monitoring anything, know exactly what you are running. Start by capturing the MongoDB server version, build info, and deployment topology. This is a read-only inventory step that sets the stage for all subsequent monitoring and alerting decisions.

Prerequisites: You need mongosh installed locally or access to the server where mongosh is available. Network access to the MongoDB instance on port 27017 (or your custom port) is required. No authentication is assumed in this example; if your deployment requires authentication, adjust the connection string accordingly.

Read-only observation command:

mongosh --quiet --eval "db.version()"

Expected output:

6.0.5

This tells you the major.minor.patch version, which determines feature availability and metric names. For example, serverStatus metrics may differ between 4.4 and 6.0.

Next, confirm the deployment topology. Is this a standalone instance, a replica set, or a sharded cluster? Run:

mongosh --quiet --eval "db.adminCommand({replSetGetStatus: 1}).myState"

If the output is 1, the node is a primary; 2 is a secondary; an error indicates a standalone. For a sharded cluster, check sh.status().

Failure signal: If db.version() fails or returns an unexpected version, stop and resolve the connectivity or environment issue before proceeding. Do not attempt to configure monitoring on a misidentified deployment.

Blast radius: These commands are read-only and safe. They do not affect performance or data.

Recovery: If the command fails, verify the MongoDB service is running (sudo systemctl status mongod), check the log file (/var/log/mongodb/mongod.log), and ensure network connectivity.

Safe Configuration Path

Configuring monitoring and alerting safely means making small, reversible changes with clear rollback steps. The most common first step is enabling the database profiler to capture slow queries, but do so with caution.

Observation before change: Check current profiler status:

mongosh --quiet --eval "db.getProfilingStatus()"

Expected output:

{ "was": 0, "slowms": 100, "sampleRate": 1 }

was: 0 means profiling is off. slowms: 100 means queries slower than 100ms are considered slow if profiling is enabled.

Smallest justified change: Enable profiling at level 1 (only slow queries) with a threshold of 200ms, and set a sample rate of 0.5 to reduce overhead. This change is in-memory only; it does not persist across restarts.

mongosh --quiet --eval "db.setProfilingLevel(1, { slowms: 200, sampleRate: 0.5 })"

Verification:

mongosh --quiet --eval "db.getProfilingStatus()"

Expected output:

{ "was": 1, "slowms": 200, "sampleRate": 0.5 }

Blast radius: Profiling adds a small amount of I/O and CPU overhead per profiled query. With a 0.5 sample rate, only half of slow queries are logged. This is generally safe, but monitor the profiler collection size.

Recovery: To disable profiling, set level back to 0:

mongosh --quiet --eval "db.setProfilingLevel(0)"

Persistence warning: This change is not persistent. If you want it to survive restarts, you must set the profile and slowms parameters in the configuration file (/etc/mongod.conf). Always test configuration changes in a staging environment first.

Verification and Diagnostics

Once monitoring is set up, you need to verify that metrics are being collected and can diagnose issues. The key command is serverStatus, which provides a wealth of operational metrics.

Read-only observation:

mongosh --quiet --eval "JSON.stringify(db.serverStatus().opcounters)"

Expected output:

{"insert":100,"query":250,"update":50,"delete":20,"getmore":10,"command":80}

This shows the cumulative operations since the server started. To see rates, you need to sample twice and compute the difference.

Diagnosing high CPU: Check the globalLock.currentQueue metric:

mongosh --quiet --eval "JSON.stringify(db.serverStatus().globalLock.currentQueue)"

If total is consistently high (e.g., > 10), there may be lock contention. Correlate with serverStatus().locks for deeper analysis.

Checking for replication lag (replica sets only):

mongosh --quiet --eval "db.printSecondaryReplicationInfo()"

This reports the oplog window and replication lag for each secondary. For example:

source: mongo1:27017
    syncedTo: Thu Jan 01 2026 12:00:00 GMT+0000 (UTC)
    0 secs (0 hrs) behind the primary

Failure signal: If metrics are missing (e.g., opcounters is empty), check whether the mongod process is running and whether the user has permission to run serverStatus (requires clusterMonitor role).

Recovery: For permission issues, grant the role: db.grantRolesToUser("monitorUser", ["clusterMonitor"]).

Failure Modes and Recovery

Monitoring and alerting itself can fail. Understanding common failure modes helps you design resilient monitoring.

1. Alert fatigue: Too many alerts, many of which are not actionable. This happens when alert thresholds are too tight or when alerts are sent for every transient spike. Recover by reviewing alert rules, consolidating similar alerts, and setting more realistic thresholds (e.g., CPU > 90% for 10 minutes instead of > 80% for 1 minute).

2. Monitoring system outage: If your monitoring system (e.g., Prometheus, Datadog) goes down, you lose visibility. Recover by having a secondary, lightweight monitor (e.g., a cron job that checks connectivity and writes a heartbeat file) and ensuring alerting for the monitoring system itself.

3. Metric collection lag: If metrics are delayed, incident response is impaired. This can be due to network latency or high load on the monitoring agent. Verify by checking the agent logs and the timestamp of the most recent metric. If lag exceeds 60 seconds, investigate the agent process and network.

4. False positives due to wrong baseline: When an alert is based on an outdated baseline, it may fire incorrectly. Recover by recalculating baselines periodically (e.g., weekly) using historical data.

5. Credential expiration: Monitoring agents often use database credentials that expire. When they do, metrics stop flowing. Recover by rotating credentials before expiry and using a secrets manager.

Operations Checklist

This checklist combines the key steps into a runbook for setting up and verifying MongoDB monitoring and alerts. Each item has an owner and a review frequency.

Common Pitfalls and How to Avoid Them

Pitfalls in MongoDB monitoring often stem from incorrect configuration, insufficient permissions, or misinterpreting metrics. Here are the most frequent ones.

Pitfall 1: Monitoring without proper user roles

Why it happens: New users often create a database user with only read role and try to run serverStatus, which requires the clusterMonitor role.

How to avoid: Create a dedicated monitoring user with clusterMonitor and readAnyDatabase roles. Example:

db.createUser({
  user: "monitorUser",
  pwd: "SecurePass123!",
  roles: [
    { role: "clusterMonitor", db: "admin" },
    { role: "readAnyDatabase", db: "admin" }
  ]
})

How to recover: If you encounter authorization errors, grant the missing role: db.grantRolesToUser("monitorUser", ["clusterMonitor"]).

Pitfall 2: Not monitoring replication lag

Why it happens: In a standalone mindset, developers forget that replica sets can fall behind, causing stale reads and failover issues.

How to avoid: Set up alerts for replication lag > 30 seconds. Use db.printSecondaryReplicationInfo() manually or integrate with a monitoring tool that tracks replSetGetStatus.members[i].optimeDate.

How to recover: If lag is high, check the secondary's network connectivity, oplog window size, and whether the secondary can keep up with primary write load. Consider increasing oplog size or adding a hidden secondary for analytics.

Pitfall 3: Enabling profiling globally with a low threshold

Why it happens: In the quest to find slow queries, teams enable profiling on all databases with slowms: 10, causing massive overhead and disk usage.

How to avoid: Use the database profiler selectively. Prefer slowms: 200 or higher and set sampleRate to a fraction (e.g., 0.25). Better yet, use the MongoDB logs with slowms set at the system level, which has lower overhead.

How to recover: Disable profiling (db.setProfilingLevel(0)) and clear the system.profile collection if it grew too large: db.system.profile.drop() (with caution).

Pitfall 4: Ignoring host-level metrics

Why it happens: Teams focus solely on MongoDB metrics and miss CPU, memory, disk I/O, and network saturation on the underlying host.

How to avoid: Combine MongoDB metrics with host metrics using Prometheus node exporter or cloud provider monitoring. Alert on host CPU > 85%, memory usage > 90%, disk latency > 20ms.

How to recover: If host metrics are missing, install and configure the appropriate exporter. Then correlate with MongoDB performance to identify resource bottlenecks.

Pitfall 5: Not testing alert delivery

Why it happens: Configuration seems correct, but alerts silently fail to reach the on-call team.

How to avoid: Schedule regular alert tests. Most monitoring tools have a "test alert" function. Also, have a secondary notification channel.

How to recover: If an alert fails to deliver, check the monitoring system's notification settings, API keys, and network egress. Verify the on-call rotation is up to date.

Conclusion

MongoDB monitoring and alerts with practical examples is useful only when each recommendation is version-scoped, observable, and reversible where the technology permits. Copying a command without checking prerequisites and expected output is not an operations procedure.

As a next step, choose one low-risk verification for MongoDB monitoring: capture the current serverStatus().opcounters and globalLock.currentQueue, record the values, then run the same check after five minutes and compute the rates. Compare the rates against your baseline and set a threshold alert.

A reliable technical workflow makes failure visible, protects sensitive values, limits changes to the intended resource, and defines recovery verification before an incident forces the decision. By following the structured approach in this article, you can build a monitoring and alerting system that helps you sleep at night.