Monitoring
Download
Focus Mode
Font Size
To help users view and understand the operational information of instances, TencentDB for MySQL offers comprehensive performance monitoring metrics and convenient monitoring features (including custom views, time-based comparisons, and combined monitoring metrics). Users can log in to the TencentDB for MySQL console and go to the Instance Monitoring page under instance management to view these details.
Note:
You can also obtain the monitoring metrics of an instance through the Pull Metric Monitoring Data and TencentDB for MySQL Monitoring Metrics in the Cloud Monitor API.
You can also create a Dashboard for monitoring metrics to dynamically analyze metric monitoring data.
If one instance contains more than 300,000 tables, it can negatively impact database monitoring. Therefore, it is crucial to manage the number of tables effectively and ensure that the total number of tables in each instance stays below this threshold.
Instance Types That Support Monitoring
TencentDB for MySQL supports monitoring of primary instances, read-only instances, disaster recovery instances, and database proxy nodes, and provides an independent monitoring view for each instance for querying.
Monitoring Category
TencentDB for MySQL provides four monitoring types: resource monitoring, engine monitoring (general), engine monitoring (extended), and deployment monitoring. By viewing metrics across these monitoring types, you can quickly and accurately assess instance performance and operational status.
Note:
TencentDB for MySQL single-node (cloud disk) edition instances support resource monitoring and engine monitoring (general), but currently do not support engine monitoring (extended) or deployment monitoring.
Resource Monitoring: Provides monitoring data related to CPU, memory, disk, and network.
Engine Monitoring (General): Provides monitoring data related to connection counts, lock information, hot tables, and slow queries to help you troubleshoot issues and optimize performance.
Engine Monitoring (Extended): Provides more comprehensive engine-related monitoring metrics to help you identify existing or potential health issues in your database to the greatest extent possible.
Deployment Monitoring: Provides monitoring metrics related to primary-secondary latency. Deployment monitoring is divided into primary and secondary servers:
If the instance is a primary instance, the deployment monitoring focuses on the linkage between the primary instance and its hidden secondary server. The monitoring displays the I/O and SQL thread statuses of the hidden secondary server, where the primary-secondary delay distance and primary-secondary latency refer to the relationship between the primary instance and its hidden secondary server.
If the instance is a read-only instance, the deployment monitoring focuses on the linkage between the primary instance and the read-only instance. The monitoring is displayed as the I/O and SQL thread statuses of the read-only instance, where the primary-secondary delay distance and primary-secondary latency refer to the relationship between the read-only instance and the primary instance.
If the instance is a disaster recovery instance:
The monitoring of disaster recovery instance deployment is mainly focused on the linkage between a disaster recovery instance and the primary instance. This monitoring system offers valuable insights into the I/O and SQL thread statuses of the disaster recovery instance, while the primary-replica delay distance and primary-replica delay time reflect the relationship between these two instances.
The monitoring of disaster recovery instance deployment is mainly focused on the linkage between a disaster recovery instance and the hidden secondary server. This monitoring system offers valuable insights into the I/O and SQL thread statuses of the hidden secondary server, while the primary-replica delay distance and primary-replica delay time reflect the relationship between the disaster recovery instance and the hidden secondary server.
Monitoring Granularity
Starting from August 11, 2018, TencentDB for MySQL implements an adaptive policy for monitoring granularity, and custom selection of monitoring granularity is currently not supported. The adaptive policy for monitoring granularity is as follows:
Time Span | Monitoring Granularity | Adaptive Description | Retention Duration |
(0h, 4h] | 5s | Time range within 4 hours, monitoring granularity is 5 seconds. | 1 day |
(4h, 2d] | 1min | If the time range exceeds 4 hours but is within 2 days, the monitoring granularity is adjusted to 1 minute. | 15 days |
(2d, 10d] | 5min | If the time range exceeds 2 days but is within 10 days, the monitoring granularity is adjusted to 5 minutes. | 31 days |
(10d, 30d] | 1h | If the time range exceeds 10 days but is within 30 days, the monitoring granularity is adjusted to 1 hour. | 62 days |
(30d, 180d] | 1 day | If the time range exceeds 30 days but is within 180 days, the monitoring granularity is adjusted to 1 day. | 180 days |
Note:
TencentDB for MySQL currently supports viewing monitoring data for up to 180 days.
Monitoring Metrics
The monitoring metrics in the following table are those displayed on the instance monitoring page of the TencentDB for MySQL instance management page. TCOP provides more comprehensive monitoring metrics for TencentDB for MySQL instances from the instance dimension. For details, see TencentDB for MySQL Monitoring Metrics.
In addition to monitoring metrics for tracking instance status, TencentDB for MySQL also supports monitoring events and event alarms. By defining event rules, event targets, and subscribed users, when abnormal events are detected, event alarms will notify users through multiple optional channels, enabling comprehensive control over instance operations.
For details about event alarms, see EventBridge.
For more supported monitoring events, see List of Events for TencentDB for MySQL.
For the monitoring metrics of the read-only analysis engine, see Monitoring and Alarms.
Note:
When you obtain monitoring data through calling APIs, the monitoring metric names used in the call parameter items should follow the Callable Metric Name column in the table below.
Disk utilization (VolumeRate): This metric will be gradually deprecated in a phased manner, and the official deprecation time will be announced through notifications or the console. The current formula for this metric is (Data file / Purchased space size) * 100%, and the formula after the metric is added to the allowlist is ((Data file + binlog file) / Purchased space) * 100%.
Disk remaining (DiskRemaining): This metric will be gradually deprecated in a phased manner, and the official deprecation time will be announced through notifications/console. The current status of this metric is linked with disk utilization (which is being deprecated). Specifically, Disk remaining = Purchased storage space - Data file space. If you add disk utilization to the allowlist, Disk remaining = Purchased storage space - Data file space - binlog file space. Going forward, subscribe to the latest monitoring metric: Remaining storage space (RemainCapacity).
Disk space usage (Capacity): Only the metric name is changed to Storage space usage.
Data file usage space (RealCapacity): Only the metric name is changed to Data file usage.
Tencent will update the storage space overuse lock rules, storage space monitoring metrics, and event alarms for instances to optimize storage space (disk) monitoring metrics for TencentDB for MySQL, improve the transparency of storage space composition, standardize resource usage, and ensure database service quality. For details, see Announcement.
Monitoring Metric Name | Callable Metric Name | Unit | Description |
CPU Utilization | CpuUseRate | % | May exceed 100% because some idle CPU resources can be overused. |
Memory Utilization | MemoryUseRate | % | May exceed 100% because some idle CPU resources can be overused. |
Memory Usage | MemoryUse | MB | May exceed purchase specifications because some idle CPU resources can be overused. |
Disk utilization | VolumeRate | % | Not on the allowlist: Disk utilization = Data usage space/Purchased instance space. Added to the allowlist: Disk utilization = (Data usage space + Log usage space)/Purchased instance space. Note: The disk utilization is calculated by the following formula: Disk utilization = (Data usage space + Log usage space)/Purchased instance space. If you need to display disk utilization, contact after-sales to enable this feature. |
Data file usage (formerly known as data file storage space) | RealCapacity | MB | Total storage space for data files. |
Storage usage (formerly known as disk usage) | Capacity | MB | Size of storage space used by users. |
Storage utilization | CapacityRate | % | (Size of storage space used by users / purchased space) * 100%. Used as a metric for users to determine whether storage space is overused for billing purposes. |
Data file space utilization | RealCapacityRate | % | (Size of instance data file storage space / purchased space) * 100%. Used as a metric for users to determine whether storage space is overused and locked. |
Log file usage | LogFileCapacity | MB | Total storage space for log files. |
binlog file space | LogCapacityBinlog | MB | Storage space for binlog files. |
redolog file space | LogCapacityRedolog | MB | Storage space for redolog files. |
undolog file space | LogCapacityUndolog | MB | Storage space for undolog files. |
relaylog file space | LogCapacityRelaylog | MB | Storage space for relaylog files. |
slowlog file space | LogCapacitySlowlog | MB | Storage space for slowlog files. |
errorlog file space | LogCapacityErrorlog | MB | Storage space for errorlog files. |
Other log file space | LogFileCapacityElse | MB | Storage space for log files other than those listed above. |
Log file space utilization | LogFileCapacityRate | % | (Total log file storage space / purchased space) * 100%. |
Other files | CapacityElse | MB | Instance temporary files and other files. |
Temporary files | DiskTmpUsed | MB | Temporary files generated by operations such as temporary tables and sorting. |
Unclassified files | OtherFileCapacity | MB | Other unclassified files. |
Remaining storage space | RemainCapacity | MB | Purchased space - storage space usage. |
Remaining storage utilization | RemainCapacityRate | % | ((Purchased space - storage space usage) / purchased space) * 100%. |
IOPS | Iops | counts/sec | Number of I/O operations per second. |
IOPS utilization | IopsUseRate | % | IOPS utilization. |
Private network outbound traffic | BytesSent | Byte/second | Number of bytes sent per second. |
Private network inbound traffic | BytesReceived | Byte/second | Number of bytes received per second. |
Queries per second | Qps | counts/sec | Number of SQL statements executed per second by the database (including operations such as insertion, selection, update, deletion, and replacement) primarily reflects the actual processing capability of the TencentDB for MySQL instance. |
Transactions per second | Tps | counts/sec | Number of transactions processed per second by the database. |
Connection utilization | ConnectionUseRate | % | Current number of established connections/Maximum number of allowed connections. |
Maximum Number of Connections | MaxConnections | pcs | The maximum connections. |
Number of open connections | ThreadsConnected | pcs | Current number of established connections. |
Number of slow queries | SlowQueries | | Number of queries that exceed the long_query_time threshold, measured in seconds. |
Number of full-table scans | SelectScan | counts/sec | Number of full-table scans per second. |
Number of queries | SelectCount | counts/sec | Number of queries per second. |
Number of Updates | ComUpdate | counts/sec | Number of updates per second. |
Number of deletions | ComDelete | counts/sec | Number of deletions per second. |
Number of insertions | ComInsert | counts/sec | Number of insertions per second. |
The number of Replaces | ComReplace | counts/sec | Number of replacements per second. |
Total number of requests | Queries | counts/sec | All executed SQL statements, including set and show. |
Query utilization | QueryRate | % | Queries per second/Recommended queries per second. |
Number of temporary tables | CreatedTmpTables | Counts/second | Number of temporary memory tables. |
Number of table lock waits | TableLocksWaited | counts/sec | Number of table lock waits per second. |
Cache hit rate | InnodbCacheHitRate | % | InnoDB cache hit rate. |
Cache utilization | InnodbCacheUseRate | % | InnoDB cache utilization. |
Number of disk reads | InnodbOsFileReads | counts/sec | Number of InnoDB disk reads. |
Number of disk writes | InnodbOsFileWrites | counts/sec | Number of InnoDB disk writes. |
Number of Fsync operations | InnodbOsFsyncs | counts/sec | Number of InnoDB Fsync operations. |
Current number of open InnoDB tables | InnodbNumOpenFiles | pcs | Current number of open InnoDB tables. |
Cache hit rate | KeyCacheHitRate | % | MyISAM cache hit rate. |
Cache utilization | KeyCacheUseRate | % | MyISAM cache utilization. |
Number of submissions | ComCommit | counts/sec | Number of submissions per second. |
Number of rollbacks | ComRollback | counts/sec | Number of rollbacks per second. |
Number of threads created | ThreadsCreated | counts/sec | Number of threads created. |
Number of running threads | ThreadsRunning | pcs | Number of running threads. |
Number of temporary disk tables | CreatedTmpDiskTables | counts/sec | Number of temporary disk tables. |
Number of temporary files | CreatedTmpFiles | counts/sec | Number of temporary files. |
Number of requests for next row reads | HandlerReadRndNext | counts/sec | Number of requests for next row reads. |
Number of internal rollbacks | HandlerRollback | counts/sec | Number of transaction rollbacks per second. |
Number of internal submissions | HandlerCommit | counts/sec | Number of internal submissions. |
Number of InnoDB free pages | InnodbBufferPoolPagesFree | pcs | Number of InnoDB free pages. |
Total number of InnoDB pages | InnodbBufferPoolPagesTotal | pcs | Total number of InnoDB pages. |
InnoDB logical reads | InnodbBufferPoolReadRequests | counts/sec | Number of InnoDB buffer pool reads ahead. |
InnoDB physical reads | InnodbBufferPoolReads | counts/sec | Number of InnoDB disk page reads. |
Number of InnoDB data reads | InnodbDataRead | Byte/second | Number of bytes read per second by the InnoDB engine. |
Total number of InnoDB data reads | InnodbDataReads | counts/sec | Total number of InnoDB data reads. |
Total number of InnoDB data writes | InnodbDataWrites | counts/sec | Total number of InnoDB data writes. |
InnoDB data written | InnodbDataWritten | Byte/second | Number of bytes written per second by the InnoDB engine. |
InnoDB rows deleted | InnodbRowsDeleted | counts/sec | Number of rows deleted per second by the InnoDB engine. |
InnoDB rows inserted | InnodbRowsInserted | counts/sec | Number of rows inserted per second by the InnoDB engine. |
InnoDB rows updated | InnodbRowsUpdated | counts/sec | Number of rows updated per second by the InnoDB engine. |
Number of InnoDB Row Reads | InnodbRowsRead | counts/sec | Number of rows read per second by the InnoDB engine. |
Average time to acquire row locks in InnoDB | InnodbRowLockTimeAvg | Milliseconds | Average duration of row locks in the InnoDB engine. |
Number of InnoDB row lock waits | InnodbRowLockWaits | counts/sec | Number of row lock waits per second in the InnoDB engine. |
Number of unused key cache blocks | KeyBlocksUnused | pcs | Number of unused key cache blocks in the MyISAM engine. |
Number of used key cache blocks | KeyBlocksUsed | pcs | Number of used key cache blocks in the MyISAM engine. |
Number of key cache block reads | KeyReadRequests | counts/sec | Number of key cache block reads per second in the MyISAM engine. |
Number of disk block reads | KeyReads | counts/sec | Number of disk block reads per second in the MyISAM engine. |
Number of key cache block writes | KeyWriteRequests | counts/sec | Number of key cache block writes per second in the MyISAM engine. |
Number of disk block writes | KeyWrites | counts/sec | Number of disk block writes per second in the MyISAM engine. |
Number of tables opened | OpenedTables | pcs | Number of tables opened at the instance level. |
Number of table locks released immediately | TableLocksImmediate | counts/sec | Number of table locks released immediately. |
Total number of open files | OpenFiles | pcs | Total number of open files. |
Log usage | LogCapacity | MB | Log usage space. |
I/O thread status | SlaveIoRunning | Status values: 0 - Yes 1 - No 2 - Connecting | I/O thread status of the primary instance. Note: In the status values, 0 indicates "running," 1 indicates "disconnected," and 2 indicates "connecting." |
SQL thread status | SlaveSqlRunning | Status values: 0 - Yes 1 - No | SQL thread status of the primary instance. Note: In the status values, 0 indicates "running" and 1 indicates "disconnected." |
Primary-Replica delay distance | MasterSlaveSyncDistance | MB | Primary-Replica delay distance. |
Primary-Replica delay time | SecondsBehindMaster | Second | Primary-Replica delay time. |
FAQs
How Do You Configure Monitoring for Primary-Replica Delays?
You can configure monitoring for primary-replica delays as required in the following two scenarios:
Scenario 1: Configure monitoring for primary-replica delays for the primary instance.
1. Log in to the Tencent Cloud Observability Platform console, choose Alarm Management in the left sidebar, and choose Alarm Configuration > Create Policy.
2. On the Alarm Policy page, choose CDB > MySQL > SLAVE under Policy Type.
Note:
To configure monitoring for primary-replica delays for the primary instance, select secondary server monitoring as the policy type to monitor the delay information from the secondary server to the primary server.
3. Under Configure Alarm Rules, set the trigger conditions for monitoring the primary-replica delay distance and primary-replica delay time, complete the settings for other configuration items as needed, and click Complete.
4. After the settings are completed, an alarm will be triggered when the primary-replica delay distance and primary-replica delay time meet the trigger conditions.
Scenario 2: Configure monitoring for primary-replica delays for RO and disaster recovery instances.
1. Log in to the Tencent Cloud Observability Platform console, choose Alarm Management in the left sidebar, and choose Alarm Configuration > Create Policy.
2. On the Alarm Policy page, choose CDB > MySQL > MASTER for the policy type.
Note:
To configure monitoring for primary-replica delays for an RO instance, select host monitoring as the policy type to monitor the delay information from the RO instance to its primary instance.
When monitoring for primary-secondary replication delays is configured for a disaster recovery instance, selecting Monitoring CVM Instances as the policy type will monitor the delay between the disaster recovery instance and its primary instance. On the other hand, if you select Secondary Server Monitoring, it will track the delay information from the secondary instance back to the disaster recovery instance.
3. Under Configure Alarm Rules, set the trigger conditions for monitoring the primary-replica delay distance and primary-replica delay time, complete the settings for other configuration items as needed, and click Complete.
4. After the settings are completed, an alarm will be triggered when the primary-replica delay distance and primary-replica delay time meet the trigger conditions.
Help and Support
Was this page helpful?
You can also Contact sales or Submit a Ticket for help.
Help us improve! Rate your documentation experience in 5 mins.
Feedback