Monitoring the state of MongoDB clusters and hosts
Data on cluster and host states are available in the management console. You can view them on the Monitoring tab of the cluster management page or in Yandex Monitoring.
Diagnostic information about cluster states is presented as graphs.
Chart update rate:
- Standard hosts and hosts with an increased RAM to vCPU ratio (
memory-optimized
): 15 seconds. - Hosts with a guaranteed vCPU share under 100% (
burstable
): 150 seconds.
Note
The most appropriate multiple units (MB, GB, and more) are automatically used in charts.
You can configure alerts in Yandex Monitoring to receive notifications about cluster failures. In Yandex Monitoring, there are two alert thresholds: Warning
and Alarm
. If the specified threshold is exceeded, you will receive alerts via the configured notification channels.
Monitoring cluster state
To view detailed information about the Managed Service for MongoDB cluster state:
-
Go to the folder page
and select Managed Service for MongoDB. -
Click the cluster name and open the Monitoring tab.
-
To get started with Yandex Monitoring metrics, dashboards, or alerts, click Open in Monitoring in the top panel.
The following charts will open on the page:
- Asserts total: Number of asserts
triggered in the cluster. - Average operation time per host: Average time of operation execution by each host (in microseconds).
- Average operations time on primary: Average operation execution time on primary replicas (in microseconds).
- Average operations time on secondaries: Average operation execution time on secondary replicas (in microseconds).
- CPU usage per host: vCPU usage per host (as a ratio of the number of vCPU cores).
- CPU usage per host, top 5 hosts: 5 hosts with the highest vCPU utilization (%).
- Configured oplog size per host: Size of the oplog on each cluster host (in GB).
- Connections per host: Average number of connections to each host.
- Data size on primary, top 5 databases: Size of the five largest DBs on the primary replica (in bytes). The chart counts data without compression.
- Disk read per host, top 5 hosts: 5 hosts with the highest load on reading from the disk subsystem (bytes per second).
- Disk space usage per host, top 5 hosts: 5 hosts that take up the most disk space (two charts are displayed: in bytes and %). The chart counts data after compression.
- Disk usage per host, top 5 hosts: 5 hosts with the highest load on the storage I/O subsystem (bytes per second).
- Disk write per host, top 5 hosts: 5 hosts with the highest load on writing to the disk subsystem (kilobytes per second).
- Documents affected on primary: Average number of documents affected by queries on the primary replica.
- Documents affected on secondaries: Average number of documents affected by queries on all secondary replicas.
- Documents affected per host: Average number of documents affected by queries on each host.
- Hosts available for read: Number of hosts that accept read data queries.
- Hosts available for write: Number of hosts that accept write data queries.
- Index size on primary, top 5 indexes: Size of the five largest indexes on the primary replica (in bytes).
- Memory usage per host: Amount of RAM used by each host (in bytes).
- Memory usage per host, top 5 hosts: 5 hosts that use the most RAM (%).
- Network data received per host, top 5 hosts: 5 hosts with the highest network load on reading (kilobytes per second).
- Network data sent per host, top 5 hosts: 5 hosts with the highest network load on writing (kilobytes per second).
- Network usage per host, top 5 hosts: 5 hosts with the highest total network load (kilobytes per second).
- Open cursors total: Number of open cursors in the cluster.
- Oplog window: Time interval, for which replication data is stored in each host's oplog collection.
- Page faults per host: Number of page faults
on each host. - Queries on secondaries: Average number of queries of each type on secondary replicas.
- Queries on primary: Average number of each type of query on primary replicas.
- Read operations count, top 5 collections: 5 collections with the longest time spent in reads.
- Readers/writers active queue per host, top 5: Total size of the 5 largest queues for each host:
- With read requests
- With write requests
- Replicated queries: Average number of replicated queries in the cluster.
- Replication lag per host and write_concern wait: Replication lag on each host and waiting time for write concern
(in seconds). - Scan and order per host: Number of data sorts without index usage on each host.
- Scanned / returned: Shows the following ratios:
scanned_docs / returned_docs
: Documents scanned to documents returned.scanned_keys / returned_docs
: Index keys scanned to documents returned.
- TTL indexes activity: Total number of TTL indexes
. - Total operations count on cluster: Total number of operations performed in the cluster.
- Total operations time on cluster: Total operation execution time in the cluster (in milliseconds).
- WiredTiger cache pages evicted on primary: Average number of memory pages evicted on the primary replica.
- WiredTiger cache state on primary: WiredTiger cache usage on the primary replica (in bytes).
- WiredTiger checkpoint time on primary: Time it takes to create WiredTiger checkpoints on the primary replica (in milliseconds).
- WiredTiger concurrent transactions on primary: Average number of parallel transactions on the primary replica.
- WiredTiger transactions state on primary: Average number of transactions on each level on the primary replica.
- Write conflicts per host: Number of write conflicts on each host.
- Write operations count, top 5 collections: 5 collections with the longest time spent in writes.
Monitoring the state of hosts
To view detailed information about the state of individual Managed Service for MongoDB hosts:
- Go to the folder page
and select Managed Service for MongoDB. - Click the cluster name and select the Hosts → Monitoring tab.
- Select the host from the drop-down list. You will see the host role (
PRIMARY
orSECONDARY
) and type (MONGOCFG
,MONGOD
,MONGOINFRA
, orMONGOS
) next to the host name.
This page displays charts showing the load on an individual host in the cluster:
- CPU: Load on processor cores. As the load goes up, the Idle value goes down.
- Memory: Use of RAM, in bytes. At high loads, the value of the Free parameter goes down while those of other parameters go up.
- Disk bytes: Speed of disk operations (bytes per second).
- Disk IOPS: Number of disk operations per second.
- Network bytes: Speed of data exchange over the network, in bytes per second.
- Network packets: Number of packets exchanged over the network, per second.
Alert settings in Yandex Monitoring
-
In the management console
, select the folder with the cluster you want to configure alerts for. -
In the list of services, select
Monitoring. -
Under Service dashboards, select:
- Managed Service for MongoDB to configure cluster alerts.
- Managed Service for MongoDB — Host Overview to configure host alerts.
-
In the chart you need, click
and select Create alert. -
If the chart shows multiple metrics, select a data query to generate a metric and click Continue. You can learn more about the query language in the Yandex Monitoring documentation.
-
Set the
Alarm
andWarning
thresholds to trigger an alert. -
Click Create alert.
To have other cluster health indicators monitored automatically:
- Create an alert.
- Add a status metric.
- In the alert parameters, set up your alert thresholds.
The recommended thresholds are as follows:
Metric | Parameter | Alarm |
Warning |
---|---|---|---|
DB write availability | can_write |
Equals 0 |
— |
Replication delay | replset_status-replicationLag |
180 |
30 |
Storage space used | disk.used_bytes |
90% of the storage size | 70% of the storage size |
For the disk.used_bytes
metric, the Alarm
and Warning
thresholds are only set in bytes. For example, the recommended values for a 100 GB disk are as follows:
Alarm
:96,636,764,160
bytes (90%)Warning
:75,161,927,680
bytes (70%)
You can view the current storage size in the detailed information about the cluster. For a complete list of supported metrics, see the Monitoring documentation.
Monitoring the switch to read-only mode
To monitor storage usage on cluster hosts and get notifications when free space is about to run out:
-
Add the
disk.free_bytes
status metric.To do this, create a query in the query builder:
service=managed-mongodb
→name=disk.free_bytes
→host=*
→resource_id=*
→resource_type=cluster
. -
Set the alert threshold values in the alert settings:
-
Condition: Set the
Less than or equals
condition for the size of free disk space to trigger an alert.The recommended threshold values depending on the storage size are as follows:
Storage size, GB Alarm
Warning
⩽ 600 1G
(1 GB)1500M
(1.5 GB)> 600 6G
(6 GB)10G
(10 GB) -
Advanced settings → Aggregation function: Select
Minimum
(a minimum metric value for the period).
-
Cluster state and status
The State of a cluster shows the health of its hosts, while the Status shows whether the cluster is started, stopped, or is at an intermediate stage.
To view a cluster's state and status:
- Go to the folder page
and select Managed Service for MongoDB. - Hover over the indicator in the Availability column in the required cluster row.
Cluster states
State | Description | Suggested actions |
---|---|---|
ALIVE | Cluster is operating normally. | No action is required. |
DEGRADED | Cluster is not running at its full capacity: the state of at least one of the hosts is other than ALIVE . |
Run the diagnostics:
|
DEAD | Cluster is out of order: all of its hosts are down. | Prepare an application to support
|
UNKNOWN | Cluster state is unknown. | Prepare an application to support
|
Cluster statuses
Status | Description | Suggested actions |
---|---|---|
CREATING | Preparing for the first launch | Wait a while and get started. The time it takes to create a cluster depends on the host class. |
RUNNING | Cluster is operating normally | No action is required. |
STOPPING | Stopping | After a while, the cluster's status will change to STOPPED and it will be disabled. No action is required. |
STOPPED | Stopped | For instructions on how to restart it, see Stopping and restarting a cluster. |
STARTING | Starting the cluster that was stopped earlier | After a while, the cluster's status will change to RUNNING . Wait a while and get started. |
UPDATING | Updating the cluster status | After the update is completed, the cluster's status will change to RUNNING . Wait a while and get started. |
ERROR | An error occurred that does not allow the cluster to continue working | Run the initial diagnostics:
|
STATUS_UNKNOWN | Cluster is unable to determine its own status | Run the initial diagnostics:
|