You can configure alarm rules for monitoring metrics to prevent your system operations from being disrupted when these metrics reach a certain value. When monitoring data meets the configured conditions, the system can check it automatically and send alarm notifications to the admin. This allows you to stay on top of business exceptions and solve them quickly.
Alarming and Monitoring Metrics
TencentDB for MongoDB provides alarm configurations in three dimensions: instance, replica set, and node. You can set alarm rules for metrics of each dimension. The details are as follows:
Instance: The instance dimension is for the entire MongoDB cluster. It monitors the number of requests, disks, latency, and connections of the entire cluster.
Replica set: Each replica set of TencentDB for MongoDB adopts a one-primary-multiple-secondary architecture, and each shard of the sharded cluster is also a replica set structure, so the database documents are stored in the replica set. This dimension is for the architecture of the stored document. It monitors the cache dirty data, cache utilization, request hit rate, disk utilization, oplog storage time, and primary-secondary delay.
Node(Mongod, Mongos): This dimension is for all nodes in the database cluster. It monitors the usage of Mongod and Mongos nodes, including CPU, memory, disk, inbound and outbound traffic, number of read and write requests, waiting queues, and number of connections.
Alert Metrics
Before alarms are configured, familiarize yourself with the monitoring metrics defined for different policy dimensions and view the alarm configuration recommendations for key metrics. For metrics without specific recommendations, configure them based on your actual business needs.
Instance dimension
Monitoring Metric
Unit
Description
Alarm Configuration Recommendation
Write Requests
-
Number of write requests received by the instance.
-
Read Requests
-
Number of read requests received by the instance.
-
Update Requests
-
Number of update requests received by the instance.
-
Deletion Requests
-
Number of deletion requests received by the instance.
-
Count Requests
-
Number of total requests received by the instance.
-
Aggregate Requests
-
Number of aggregate requests received by the instance.
-
Successfully Executed Requests
-
Number of requests received by the instance that are executed successfully.
-
Disk Utilization
%
The percentage of the used space to the total space of the current disk.
Monitoring cycle: 1 minute. If the utilization is greater than or equal to 90% and the metric exception persists for 3 data points, an alarm will be triggered every 30 minutes.
Requests Consuming 10-50 ms
-
Number of requests with an execution time between 10 and 50 ms.
-
Requests Consuming 50-100 ms
-
Number of requests with an execution time between 50 and 100 ms.
-
Requests Consuming More Than 100 ms
-
Number of requests with an execution time of more than 100 ms.
Monitoring cycle: 1 minute. If the count is greater than or equal to 100 and the metric exception persists for 3 data points, an alarm will be triggered every 30 minutes.
Connection Utilization
%
The percentage of current connections to the maximum connections of the cluster.
Monitoring cycle: 1 minute. If the utilization is greater than or equal to 90% and the metric exception persists for 3 data points, an alarm will be triggered every 30 minutes.
Requests per Second
-
Number of requests received by the instance per second.
-
Command Requests
-
Number of command requests received by the cluster other than INSERT, UPDATE, DELETE, and QUERY requests.
-
Number of Connections
-
Number of TCP connections from cluster clients.
-
Replica set dimension
Monitoring Metric
Unit
Description
Alarm Configuration Recommendation
Dirty Data in Cache
%
The percentage of dirty data in the cache (in bytes) to the maximum cache size.
Monitoring cycle: 1 minute. If the percentage is greater than or equal to 20% and the metric exception persists for 3 data points, an alarm will be triggered every 30 minutes.
Cache Utilization
%
The ratio of the actual cache usage to the configured maximum cache size.
-
Disk Utilization
%
The percentage of the used space to the total space of the current disk.
Monitoring cycle: 1 minute. If the utilization is greater than or equal to 90% and the metric exception persists for 3 data points, an alarm will be triggered every 30 minutes.
Cache Hit Rate
%
The ratio of the number of requests that retrieve data from the cache to the total number of requests.
-
Oplog Retention Period
hours
Oplog is used to record the operation log of the database, and this metric counts its storage time.
-
Average primary-secondary delay in Unit Time
s
In the replica set architecture, the secondary node periodically polls the oplog (operation log) of the primary node to replicate the data from it. This metric counts the primary-secondary delay in data sync.
Monitoring cycle: 1 minute. If the latency is greater than or equal to 1800 seconds and the metric exception persists for 3 data points, an alarm will be triggered every 30 minutes.
Mongod node
Monitoring Metric
Unit
Description
Alarm Configuration Recommendation
CPU Utilization
%
The percentage of time the CPU is executing processes to the total CPU time.
Monitoring cycle: 1 minute. If the utilization is greater than or equal to 80% and the metric exception persists for 3 data points, an alarm will be triggered every 30 minutes.
Memory Utilization
%
The percentage of the used space in the current memory to the total memory space.
-
Inbound Network Traffic
KB/s
Number of bytes per second in the traffic inbound to the node.
-
Outbound Network Traffic
KB/s
Number of bytes per second in the traffic outbound from the node.
-
Read Requests in Queue
Pcs
Number of read requests waiting in the queue.
Monitoring cycle: 1 minute. If the count is greater than or equal to 40 and the metric exception persists for 3 data points, an alarm will be triggered every 30 minutes.
Write Requests in Queue
Pcs
Number of write requests waiting in the queue.
Monitoring cycle: 1 minute. If the count is greater than or equal to 40 and the metric exception persists for 3 data points, an alarm will be triggered every 30 minutes.
Number of Connections
Pcs
Number of client connections.
Used Disk Space
MB
Used node disk capacity.
WiredTiger Active Reads
Pcs
Number of active read requests in the memory.
Monitoring cycle: 1 minute. If the count is greater than or equal to 40 and the metric exception persists for 3 data points, an alarm will be triggered every 30 minutes.
WiredTiger Active Writes
Pcs
Number of active write requests in the memory.
Monitoring cycle: 1 minute. If the count is greater than or equal to 40 and the metric exception persists for 3 data points, an alarm will be triggered every 30 minutes.
Data Entries Deleted via TTL
Pcs
The number of data entries automatically deleted by the database after the TTL expires.
-
TTL Run Times
-
The number of times data is checked within the TTL time set in the database.
-
Mongos node
Monitoring Metric
Unit
Description
Alarm Configuration Recommendation
CPU utilization
%
Indicates the percentage of CPU time spent on executing processes compared to total CPU time.
Monitoring cycle: 1 minute. If the utilization is greater than or equal to 80% and the metric exception persists for 3 data points, an alarm will be triggered every 30 minutes.
Memory utilization
%
Indicates the percentage of memory currently in use on the Mongos node compared to total memory capacity.
-
Inbound network traffic
MB/s
Statistics of inbound traffic per second for the node.
-
Outbound network traffic
MB/s
Statistics of outbound traffic per second for the node.
-
Billing Overview
TCOP allows you to configure alarm policies to monitor the key metrics of instances and offers a free trial.
Currently, only alarm SMS messages are charged. For more information, see Purchase Guide.
2. In the MongoDB drop-down list on the left sidebar, select Replica Set Instance or Sharded Cluster Instance. The directions for replica set instances and sharded cluster instances are similar.
3. Above the Instance List on the right, select the region.
4. In the instance list, find the target instance.
5. In the row of the target instance, enter the Create Policy page of TCOP in any of the following ways:
Click
in the Monitoring/Status column and click Configure Alarms in the top-right corner of the instance monitoring dashboard.
Click the instance ID in blue to enter the Instance Details page. Then, select the System Monitoring tab and click Configure Alarms.
6. On the Create alarm policy page, configure a new alarm policy as shown below. For more information on the basic concepts of alarm policy, see Creating Alarm Policy.
Parameter
Description
Policy Name
Customize the alarm policy name for easier identification.
Remarks
Briefly describe the alarm policy for easier identification.
Monitoring Type
Select Cloud Product Monitoring.
Policy Type
Set Policy Type to TencentDB/MongoDB/instance, TencentDB/MongoDB/node, or TencentDB/MongoDB/replica set.
Project
Specify a project for the alarm policy. You can quickly locate all alarm policies of a project in the alarm policy list.
Alarm Object
If you select Instance ID, the alarm policy will be bound to the specified database instance.
If you select Instance Group, the alarm policy will be bound to the specified database instance group. For more information on how to create an instance group, see Instance Group.
If you select All Objects, the alarm policy will be bound to all instances the current account has permission on.
If you select Tag, the alarm policy will be bound to all instances associated with the current tag key and tag value.
Trigger Condition
Select template: You can select a template file in the drop-down list, and alarms will be reported based on the trigger conditions preset in the template. For specific configurations, see Configuring Trigger Condition Template.
Configure manually: You need to configure the threshold for triggering an alarm for each metric in the Metric Alarm section below. Alarm threshold type has the following values:
If you select Static, you can manually set a fixed threshold, and alarms will be triggered when the threshold is reached.
If you select Dynamic, exceptions will be determined based on the dynamic threshold boundaries calculated by machine learning algorithms.
You can select a preset or custom notification template. Each alarm policy can be bound to three notification templates at most. For more information, see Alarm Notification.
7. After confirming that the configuration is correct, click Complete. For more information on alarms, see Alarm Overview.
Yes
No
Was this page helpful?