Monitoring

FAQ overview

• How do I monitor disk usage for a Data Warehouse Edition cluster in reserved mode?

• How can I view the storage space consumed by hot and cold data?

• How do I check information such as table size?

• Why is hot data usage higher than total disk usage on the Monitoring Information page?

• Why does the average CPU utilization increase after I change a cluster from reserved mode to elastic mode?

• Why does the Monitoring Information page show a high query response time, but no corresponding long-running SQL statements appear on the Diagnostics and Optimization page?

Monitor disk usage in reserved mode

Configure monitoring and alerts to prevent disk usage from exceeding the safety threshold. This ensures you receive timely notifications to manage disk space and maintain service stability.

1. Log on to the AnalyticDB for MySQL console. In the upper-left corner of the console, select a region. In the left-side navigation pane, click Clusters. Find the cluster that you want to manage and click the cluster ID.

2. In the left-side navigation pane, click Monitoring and Alerting.

3. On the Monitoring Information page, click the Query and Write tab to view the disk usage.

   In reserved mode, disk usage is displayed as a percentage. In elastic mode, the absolute disk usage of the read/write nodes is displayed.

   • Reserved mode

     Note

     Maximum disk usage is the highest disk usage among all nodes in the cluster. If this value reaches 90% or higher, write operations are locked. Pay close attention to this metric.

   • Elastic mode

     Note

     Disk usage refers to the maximum disk usage of a single read/write node. If this value reaches 8 TB or higher, you can no longer write data to the cluster. Pay close attention to this metric.

4. On the Monitoring Information page, click Alert Rule Settings.

5. On the Alert Rules page, click Create Alert Rules.

6. On the Create Alert Rule page, configure the parameters as prompted.

   Parameter	Description
   Resource Range	The scope of resources to which the alert rule applies. Valid values: All Resources: The rule applies to all instances of the product under your account. For example, if you set an alert rule for AnalyticDB for MySQL that is triggered when disk usage is greater than or equal to 80%, all AnalyticDB for MySQL instances under your account are monitored. When Resource Range is set to All Resources, an alert rule can apply to a maximum of 1,000 resources. If the number of resources exceeds this limit, alerts may not be triggered even if the threshold is met. We recommend that you use application groups to classify resources by business before you configure alert rules. Application Group: The alert rule applies to all resources within a specified application group of a specific cloud service. Instance: The rule applies only to specific instances of the cloud service. For example, if you configure an instance-level alert for disk usage that is triggered when the value is greater than or equal to 80%, an alert notification is sent only when the disk usage of that specific instance meets the condition.
   Rule description	The trigger conditions for the alert rule. An alert is triggered when the monitoring data meets the specified conditions. To configure the rule description, perform the following steps: Click Add Rule. In the Add Rule Description panel, configure parameters such as Rule Name, Metric Type, Monitoring Metric, Threshold and Alert Level, and Chart Preview. Click OK.
   Mute Period	The resend interval for alert notifications if an issue persists. Valid values: 5 minutes, 15 minutes, 30 minutes, 60 minutes, 3 hours, 6 hours, 12 hours, and 24 hours. When a monitored metric reaches the alert threshold, an alert notification is sent. If the metric continues to exceed the threshold, no more notifications are sent during the mute period. If the metric is still abnormal after the mute period, CloudMonitor sends another notification.
   Effective Time	The time frame during which the alert rule is active. The system checks monitoring data and triggers alerts only within this period. Important For disk usage alerts, each alert contact is notified a maximum of four times per day. Subsequent alerts are muted.
   Alert Contact Group	The contact group that receives alert notifications. Alert notifications for an application group are sent to the contacts in this group. An alert contact group can contain one or more contacts. To create alert contacts and alert contact groups, see Create an alert contact or an alert contact group.
   Alert Callback	Specify a publicly accessible URL. CloudMonitor pushes alert information to this URL through POST requests. Only HTTP is supported. To configure an alert callback, see Use threshold-triggered alert callbacks. Note Click Advanced Settings to configure this parameter.
   Auto Scaling	If you enable Auto Scaling, an alert triggers the corresponding scaling rule. You must specify the Region, ESS Group, and ESS Rule. To create a scaling group, see Manage scaling groups. To create a scaling rule, see Configure scaling rules. Note Click Advanced Settings to configure this parameter.
   Simple Log Service	If you enable Simple Log Service, the system writes alert information to Log Service when an alert is triggered. You must specify the Region, Project, and Logstore for Log Service. To create a project and a logstore, see Use LoongCollector to collect and analyze text logs from ECS instances. Note Click Advanced Settings to configure this parameter.
   Simple Message Queue (formerly MNS) - Topic	If you enable Simple Message Queue (formerly MNS) - Topic, the system sends alert information to a topic in Message Service when an alert is triggered. You must specify the region and topic for Message Service. To create a topic, see Create a topic.
   Method for handling alerts when no monitoring data is available	Specifies how to handle alerts when monitoring data is unavailable. Valid values: Do not do anything (default) Send alert notifications Treated as normal Note Click Advanced Settings to configure this parameter.
   Tag	The alert tags are added to the alert content. Each tag consists of a key and a value. You can add multiple tags.

7. After you configure the parameters, click OK.

View hot and cold data storage

Log on to the AnalyticDB for MySQL console. On the Monitoring Information page, you can view the Hot Data Space Used and Cold Data Space Used.

Check table size

Log on to the AnalyticDB for MySQL console. On the Monitoring Information page for your cluster, click the Table Information Statistics tab to view information such as table size.

Hot data usage vs. total disk usage

An AnalyticDB for MySQL cluster contains multiple storage nodes. Disk usage represents the maximum disk usage of a single read/write node, whereas hot data usage is the sum of disk usage across all read/write nodes.

Increased CPU utilization in elastic mode

When you change a C32 cluster from reserved mode to elastic mode, the core count of a single node is reduced to 8. By default, a BUILD task occupies 3 cores, which leads to an increase in average CPU utilization. If this increase does not affect your services, no action is required. If your services are affected, scale up the cluster or Submit a ticket to contact technical support. For more information about BUILD tasks, see BUILD.

Discrepancy in query response time

The query response time on the Monitoring Information page and the total duration on the Diagnostics and Optimization page are calculated differently. The query response time on the Monitoring Information page also includes the result set cache time. Therefore, if a query returns a large result set that requires caching, the query response time on the Monitoring Information page is longer than the total duration shown on the Diagnostics and Optimization page. You can use the SQL Audit page to find SQL statements with long response times.

The following information describes how the time consumed by an SQL statement is calculated:

After an SQL statement is submitted to AnalyticDB for MySQL, it is first placed in a queue. If query concurrency is high, this can result in a long queuing time. After leaving the queue, the statement enters the execution engine, which parses the query and generates an execution plan, a process that constitutes the execution plan time. After the execution plan is generated, subtasks run on storage and compute nodes, which constitutes the execution time. After the query is complete, if the result set is large, the frontend node caches the results, which constitutes the result set cache time. The following figure shows the time breakdown of an SQL statement: