How to Monitor MongoDB Health Using Atlas Metrics?

Just as getting a health check can prevent a health scare, your database needs regular checks to prevent performance and downtime scares. The health of your MongoDB Atlas deployment significantly influences performance, uptime, and cost when building applications. As such, we need to closely monitor cluster metrics to ensure they remain within the safe zone.

What is MongoDB Atlas?

MongoDB Atlas is a fully managed database as a service (DBaaS) that handles deployment, scaling, and maintenance of MongoDB databases across major cloud providers (AWS, Azure, GCP). It simplifies global application development by automating infrastructure management.

With MongoDB Atlas, you have various cluster options (ranging from M0-600) to accommodate your workload.

• M0 Atlas Cluster: An M0 cluster is a free, shared cluster tier that provides a sandbox environment with limited resources, specifically 512MB of storage.
• Flex Clusters (formerly M2 and M5): Flex clusters provide an economical way to get started with MongoDB and for low-throughput applications, providing backups for your cluster data, increased storage, and API access, compared to the M0.
• Dedicated Clusters (M10 and Higher): Dedicated clusters (M10 and M20) support development environments, low-traffic applications, and replica set deployments.

With your M0 Atlas cluster, you can keep a close eye on metrics through the Metrics tab and by setting alerts to track certain conditions, making sure that your MongoDB Atlas cluster is in a healthy state.

The Real-Time Performance Panel gives you deeper insight into the health of your database, applications, and service, and is only available on M10+ clusters. It’s unavailable on M0 (free tier) MongoDB Atlas clusters due to resource limitations.

M0 clusters have strict resource constraints, and the Real-Time Performance Panel requires significant computational resources to operate, making it incompatible with the free tier's limitations on memory, CPU, and storage.

In this article, you will be deploying an M0 MongoDB Atlas (free tier) cluster to monitor the health of the cluster through metrics and setting up alerts. Keep in mind that you can deploy one such cluster per project.

Prerequisites:

• A MongoDB Atlas account (free tier is okay) with at least one deployed cluster. Read Getting Started With Atlas to set it up.
• Basic familiarity with MongoDB (via Compass, shell).
• No prior database monitoring experience needed.

We will look at:

• Accessing MongoDB Atlas Metrics.
• An Overview of MongoDB Metrics.
• The Key Metrics to Monitor for Health Include:
  • Connections
  • Network
  • Operation throttling
  • Opcounters
  • Sort
  • Logical size
• How to create an alert to monitor your MongoDB Atlas cluster.
• Additional resources.

1. Accessing MongoDB Atlas Metrics

Let’s view our metrics via the MongoDB Atlas dashboard. To access your MongoDB Atlas cluster, log in to your Atlas account to view your dashboard.

On the dashboard, click on `View Monitoring` to view the metrics of your cluster.

Alternatively, you can click 'Cluster' on the left-hand menu to see a snapshot of your cluster with metrics and details. Click 'View Monitoring' for a more detailed view.

After clicking 'View Monitoring', you will be directed to the Metrics tab which displays a detailed view of your cluster split into replica sets (P stands for primary and S stands for secondary). The primary replica set’s metrics are being shown. You can toggle between the other replica sets by clicking on the P and S signs at the top of the metrics chart.

2. Overview of MongoDB Metrics

These metrics can be found at the bottom of the chart page. On the metrics charts, you may see annotations in the form of colored vertical lines to indicate server events.

• A red vertical bar indicates a server restart.
• An orange vertical bar indicates the server is now a primary.
• A brown vertical bar indicates the server is now a secondary.

3. Key Metrics to Monitor For Health

Monitoring metrics gives us insight into how our cluster is doing, how to improve performance, and it spotlights where resources are wasted or where opportunities lie. Key metrics to keep a close eye on are:

• Connections
• Network
• Operation throttling
• Opcounters
• Sort
• Logical size

3.1. Connections

Connections represent the number of currently active connections to this server. A stack (dedicated memory) is allocated per connection so a lot of connections will inflate RAM usage, thereby reducing memory available for caching data or indexing and affecting performance.

An example of an unhealthy connection metric would be spikes showing that active connection client connections have exceeded peak limit.

3.2. Network

The Network metric is used to assess a network's performance, health, and efficiency. In the Network chart, the activity of the 'bytesIn', 'bytesOut', and 'numRequests' metrics show how much traffic your MongoDB server is processing which enables you to catch issues early.

An example of an unhealthy network metric would be high network throughput (Bytes In/Out) and a high rate of requests per second (network.numRequests) significantly above baseline.

3.3. Operation Throttling

Operation throttling is a system protection mechanism when dealing with concurrency to prevent the storage engine from being overwhelmed—essentially, ensuring stability under load. The 'rejected' and 'killed' operations protect cluster health against overload and exceeding CPU limits.

An example of an unhealthy operation throttling metric would be growing queues (read/write/total) in 'globalLock.currentQueue', resulting in latency and issues with concurrency. The 'globalLock.currentQueue' provides information concerning the number of operations queued because of a lock.

3.4. Opcounters

Opcounters (operation counters) are a vital set of metrics reported by the serverStatus() command. They represent the total number of each type of operation executed since the database server was last started. As such, high query/update counts may indicate inefficient queries. Metrics under the Opcounter are 'command', 'query', 'update', 'delete', 'getmore', and 'ttldeleted'.

An example of an unhealthy opcounter metric would be unexpected spikes or drops in operation rates (inserts, queries, updates, deletes).

3.5. Sort

The Sort metric tracks how many $sort operations spill to disk instead of completing in memory. If you perform a $sort operation that exceeds the 32 MB memory limit (for M0/free clusters), it spills to disk, degrading query performance. A great way to resolve this is to optimize queries or increase cluster tier, if this happens frequently.

The 'spill to disk during sort' highlights resource-intensive queries which use a $sort stage.

An example of an unhealthy sort metric would be an increase in `scanAndOrder` rate which occurs when sorts are performed in memory rather than via index.

3.6. Logical Size

Logical size refers to the sum total size in bytes of the document and index data across all databases.

An example of an unhealthy logical size metric would be exceeding defined thresholds (especially on M0/free/shared clusters, which have a 5GB limit).

4. Create an Alert to Monitor Your MongoDB Atlas Cluster

Setting up alerts helps in detecting and resolving issues proactively, and this reduces downtime and damage before users are impacted. To create an alert for your MongoDB Atlas cluster:

Go to Project Settings > Select Alerts (on the left pane).

Click 'Add New Alert' > Add a condition and save.

For example, 'Cluster is missing an active mongos' or Connections % of configured limit is above 80.

Add a Notification Method/Notifier > Click 'Save'.

Now, you have configured alerts for your cluster and will be notified once the conditions set are met. Alternatively, you will see the logs under the 'Alert Settings' Tab.