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: 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.
Instance dimension
Monitoring Metric
Unit
Description
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.
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.
Connection Utilization
%
The percentage of current connections to the maximum connections of the cluster.
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
Dirty Data in Cache
%
The percentage of data in the current cache that has been modified but not yet written to disk to the total cache data.
Cache Utilization
%
The percentage of the used space to the total space of the current cache.
Disk Utilization
%
The percentage of the used space to the total space of the current disk.
Cache Hit Rate
%
The percentage of requested data that already exists in the cache when the system uses the cache.
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.
Node dimension
Monitoring Metric
Unit
Description
CPU Utilization
%
The percentage of time the CPU is executing processes to the total CPU time.
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.
Write Requests in Queue
Pcs
Number of write requests waiting in the queue.
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.
WiredTiger Active Writes
Pcs
Number of active write requests in the memory.
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.
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?