Docs Menu
Docs Home
/
MongoDB Cloud Manager
/

Health Check Solutions

On this page

  • Host has decreasing available disk space
  • Host has excessive disk utilization
  • Host has startup warnings
  • Host is unreachable
  • MongoDB version outdated
  • Replica set has an even number of votes
  • Replica set has less than three data-bearing nodes
  • Replica set has mixed version nodes
  • Replica set has more than one arbiter
  • Shared cluster has mixed version nodes
  • Too many queued operations
  • Too much replication lag

This page lists issues that can be raised by a Cloud Manager health check and provides their solutions.

Cloud Manager considers any disk on any host as needing more disk capacity if it estimates that the disk will be full in two weeks or less.

To remedy this problem, move your database to disk(s) with greater capacity.

Cloud Manager considers any disk on any host as having excessive disk utilization if it is actively storing or retrieving data for a prolonged period of time.

To remedy this problem, move your database to disk(s) with greater throughput.

Process and user limits with low default values can cause a number of issues in the course of normal MongoDB operation. For further information and recommendations, see UNIX ulimit Settings in the MongoDB Manual.

Running MongoDB on a system with NUMA can cause a number of operational problems, including slow performance for periods of time and high system process usage. For further information and recommendations, see MongoDB and NUMA Hardware in the MongoDB Manual.

Please see the readahead information in this section of the MongoDB Manual for information and recommendations about the Readahead startup warning.

For information and recommendations about the Transparent Huge Pages and Defrag startup warning, see Disable Transparent Huge Pages (THP).

The MongoDB Agent connects to each MongoDB process in your deployment to collect diagnostic data.

If your MongoDB Agent cannot connect to a process, consider the following possible resolutions:

Reason
Resolution
Host no longer exists.
Remove host from Cloud Manager.
Monitoring cannot reach host.
See Remedies for a Host Down Alert for possible resolutions.

For MongoDB deployments managed by Cloud Manager, Cloud Manager supports safe automatic upgrade and downgrade operations between releases of MongoDB while maximizing the availability of your deployment. Cloud Manager supports upgrade and downgrade operations for sharded clusters, replica sets, and standalone MongoDB instances.

Configure Available MongoDB Versions describes how to choose which versions of MongoDB are available to Cloud Manager.

If Cloud Manager doesn't manage your deployment, manually change the version of MongoDB. The MongoDB Manual provides upgrade tutorials with each release. For example, see Upgrade MongoDB to 4.2 for upgrading to MongoDB 4.2 from an earlier version.

For managed deployments:

1
  1. If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

  2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

  3. If the Deployment page is not already displayed, click Deployment in the sidebar.

    The Deployment page displays.

2

Click the Processes tab for your deployment.

The Processes page displays.

3
  1. Click the Topology view.

  2. On the line listing the cluster, replica set, or process, click Modify.

  3. In the Version field, select the version. Then click Apply.

  4. Click Review & Deploy.

  5. Click Confirm & Deploy.

For more information and precautions, see Change the Version of MongoDB.

An even number of voting members in a replica set can lead to election issues in the event of a primary node failure. You should consider adding an additional voting node to your replica sets to ensure an odd number of votes.

You can add an arbiter to your replica set to allow an uneven number of members without the overhead of a member that replicates data.

If your deployment is not managed by Cloud Manager, follow the MongoDB Manual's instructions to manually add an arbiter to your replica set.

For managed deployments:

1
  1. If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

  2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

  3. If the Deployment page is not already displayed, click Deployment in the sidebar.

    The Deployment page displays.

2

Click the Processes tab for your deployment.

The Processes page displays.

3
  1. Click the Topology view.

  2. On the line listing the replica set, click Modify.

4
  1. Under Member Options, click Add and select Arbiter.

  2. Click Apply.

  3. Click Review & Deploy. Cloud Manager displays your proposed changes.

  4. Click Confirm & Deploy.

We recommend that your replica set includes at least three data-bearing nodes to ensure high availability. For factors that affect high availability, see the MongoDB Manual's pages on

If your deployment is not managed by Cloud Manager, follow the MongoDB Manual's instructions to manually add a node to your replica set.

For managed deployments:

1
  1. If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

  2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

  3. If the Deployment page is not already displayed, click Deployment in the sidebar.

    The Deployment page displays.

2

Click the Processes tab for your deployment.

The Processes page displays.

3
  1. Click the Topology view.

  2. On the line listing the replica set, click Modify.

4
  1. Add the member by increasing the number of members in the MongoDs Per Replica Set field.

  2. Click Apply.

  3. Click Review & Deploy. Cloud Manager displays your proposed changes.

  4. Click Confirm & Deploy.

Because of potential incompatibilities, it is recommended you upgrade outdated versions of MongoDB instances to the most recent in your cluster.

If your deployment is not managed by Cloud Manager, you will need to manually change the version of MongoDB. The MongoDB Manual provides upgrade tutorials with each release. For example, see Upgrade MongoDB to 4.2 for upgrading to MongoDB 4.2 from an earlier version.

For managed deployments:

1
  1. If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

  2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

  3. If the Deployment page is not already displayed, click Deployment in the sidebar.

    The Deployment page displays.

2

Click the Processes tab for your deployment.

The Processes page displays.

3
  1. Click the Topology view.

  2. On the line listing the replica set, click Modify.

  3. In the Version field, select the version, and click Apply.

  4. Click Review & Deploy.

  5. Click Confirm & Deploy.

For more information and precautions, see Change the Version of MongoDB.

An arbiter is added to a replica set with an even number of members to add a vote in elections for primary. Arbiters always have exactly one vote, and thus allow replica sets to have an uneven number of members, without the overhead of a member that replicates data. Only one arbiter is required to break election ties.

If your deployment is not managed by Cloud Manager, follow the MongoDB Manual's instructions to manually remove a member from your replica set.

For managed deployments:

1
  1. If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

  2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

  3. If the Deployment page is not already displayed, click Deployment in the sidebar.

    The Deployment page displays.

2

Click the Processes tab for your deployment.

The Processes page displays.

3
  1. Click the Topology view.

  2. For the arbiter to be removed, click the ellipsis icon and select Remove from Replica Set.

  3. Click Remove to confirm.

  4. Click Review & Deploy. Cloud Manager displays your proposed changes.

  5. Click Confirm & Deploy.

For more information on deployment architectures, see Replica Set Deployment Architectures in the MongoDB Manual.

The components of the sharded cluster run different versions of MongoDB.

To avoid compatibility issues, use the same version of MongoDB for all the mongos and mongod processes that make up your sharded cluster. This includes all the mongod processes used for the cluster's config servers and shards.

To change the version of a mongod or mongos process, see Change the Version of MongoDB.

Queued operations are operations that are waiting to be processed. This may occur when you have reached your hardware capacity or if you have poorly performing queries.

If you have access to Cloud Manager Premium, you can track long running operations using the Cloud Manager Profiler. To enable the profiler tool in Cloud Manager:

1
  1. If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

  2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

  3. If the Deployment page is not already displayed, click Deployment in the sidebar.

    The Deployment page displays.

2

Click the Processes tab for your deployment.

The Processes page displays.

3
  1. Click the Topology view.

  2. On the line listing the process, click the Metrics button.

  3. Click the Profiler tab and follow the instructions to enable the profiler.

If you don’t have access to Cloud Manager Premium, you can still get access to profiling data for statistics about performance and database operations. To read more about profiling databases, see Profile Databases.

Replication lag is a delay between an operation on the primary and the application of that operation from the oplog to the secondary. Replication lag can be a significant issue and can seriously affect MongoDB replica set deployments. Excessive replication lag makes "lagged" members ineligible to quickly become primary and increases the possibility that distributed read operations will be inconsistent.

To learn how to troubleshoot replication lag, please see Check the Replication Lag in the MongoDB Manual.

Back

Alert Event Types