To make it easier for you to view and stay up to date with how instances work, TencentDB for MySQL provides a wide variety of performance monitoring metrics and convenient monitoring features (custom view, time comparison, merged monitoring metrics, etc). You can log in to the TencentDB for MySQL console, and view them in Instance Monitoring on the instance management page.

Note：

• You can get instance monitoring metrics by calling the GetMonitorData API or using the TencentDB for MySQL monitoring metrics in Cloud Monitor.
• You can create dashboards for monitoring metrics to analyze monitored data dynamically.
• If the number of tables in a single instance exceeds one million, database monitoring may be affected. Make sure that the number of tables in a single instance is below one million.

Types of Instances for Monitoring

TencentDB for MySQL source, read-only, and disaster recovery instances as well as database proxy nodes can be monitored, and each instance is provided with a separate monitoring view for easy query.

Types of Monitoring

Four types of monitoring are available for TencentDB for MySQL: resource monitoring, engine monitoring (general), engine monitoring (extended), and deployment monitoring. You can view the metrics of different monitoring types to gain a quick and accurate understanding of how instances perform and operate.

• Resource monitoring provides monitoring data of CPU, memory, disk, and network.

• Engine monitoring (general) provides monitoring data of the number of connections, locks, hotspot tables, and slow queries, helping you troubleshoot issues and optimize the performance.

• Engine monitoring (extended) provides a wider variety of engine-related monitoring metrics so as to assist you in identifying existing or potential database problems as much as possible.

• Deployment monitoring provides monitoring metrics with regard to source-replica delay. It divides into source monitoring and replica monitoring:

  • Deploy monitoring on the source: when the monitored instance is a source instance which is not a replica of any instance, replication-related monitoring data is invalid for the source, and the IO and SQL threads are disabled. Replication-related monitoring data is valid and the IO and SQL threads can be enabled only when the monitored instance is a disaster recovery or a read-only instance.

  • Deploy monitoring on the replica: the two-node or three-node source instance and disaster recovery instance come in a source/replica architecture by default. As a result, replication-related monitoring data is valid for the replica only when the monitored instance is a source or disaster recovery instance. Such monitoring data can reflect the replication delay distance and time between the source or disaster recovery instance and its hidden replica nodes. We recommend you keep an eye out for such monitoring data of the replica. If the source or disaster recovery instance fails, its monitored hidden replica nodes can be promoted to the source instance quickly.

Monitoring Granularity

TencentDB for MySQL has adopted an adaptive policy for monitoring granularity since August 11, 2018, which means that you cannot select a monitoring granularity as desired for the time being. The adaptive policy is as follows:

Note：

Currently, you can view monitoring data of TencentDB for MySQL in the past 30 days.

Monitoring Metrics

Cloud Monitor provides the following monitoring metrics for TencentDB for MySQL instances in the instance dimension:

Note：

For more information on how to use TencentDB monitoring metrics, see TencentDB for MySQL Monitoring Metrics.