This topic provides answers to some frequently asked questions about monitoring in AnalyticDB for MySQL.
If the product edition is not specified in an FAQ, the FAQ applies only to AnalyticDB for MySQL Data Warehouse Edition.
FAQ overview
How do I monitor the disk usage for a Data Warehouse Edition cluster in reserved mode?
To prevent disk usage from exceeding the threshold, configure an alert rule. The rule sends an alert when the usage reaches the threshold. This helps you manage disk space and keep your business running.
You do not need to configure disk monitoring alerts for Enterprise Edition, Basic Edition, or Data Lakehouse Edition clusters.
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.
In the left-side navigation pane, click Monitoring and Alerts.
On the Monitoring and Alerts page, view the disk usage.
Click Alerts tab.
On the Click Alerts tab. page, click Create Alert Rule.
In the Create Alert Rule panel, configure the parameters that are described in the following table.
Parameter
Description
Resource Range
The resources to which you want to apply the alert rule. Valid values:
All Resources: The alert rule applies to all clusters of the specified service. For example, you set the Resource Range parameter to All Resources for a rule that triggers an alert if the disk usage of an AnalyticDB for MySQL cluster is greater than or equal to 80%. This alert rule applies to all AnalyticDB for MySQL clusters within your Alibaba Cloud account. Each alert rule can be applied to up to 1,000 resources for a specified service. If your account contains more than 1,000 resources of the specified service, the system may not generate an alert regardless of whether the rule conditions are met. Before you configure the alert rule, we recommend that you classify resources into different application groups by service based on your business requirements.
Instances: The alert rule applies to the specified instances of the specified service. For example, you set the Resource Range parameter to Instances for a rule that triggers an alert if the disk usage of a cluster is greater than or equal to 80%. An alert is triggered only if the disk usage of the specified cluster is greater than or equal to 80%.
Rule Description
The content of the alert rule. This parameter specifies the conditions that trigger the alert. To specify the content of the alert rule, perform the following steps:
Click Add Rule.
In the Configure Rule Description panel, configure the following parameters: Alert Rule, Metric Type, Metric, Threshold and Alert Level, and Chart Preview.
Click OK.
Mute Period
The interval at which CloudMonitor resends alert notifications before an alert is cleared. Valid values: 5 Minutes, 15 Minutes, 30 Minutes, 60 Minutes, 3 Hours, 6 Hours, 12 Hours, and 24 Hours. If the conditions of an alert rule are met, an alert is triggered. If the alert is triggered within the mute period, CloudMonitor does not resend an alert notification. If the alert is not cleared after the mute period ends, CloudMonitor resends alert notifications.
Effective Period
The period during which the alert rule is effective. CloudMonitor monitors the specified resources based on the alert rule only within the specified period.
ImportantEach contact can receive up to four alert notifications for disk usage every day.
Alert Contact Group
The alert contact group to which alert notifications are sent.
The alert notifications of the application group are sent to the alert contacts that belong to the selected alert contact group. An alert contact group can contain one or more alert contacts. For information about how to create an alert contact and an alert contact group, see Create an alert contact or alert contact group.
Alert Callback
The callback URL that can be accessed over the Internet. CloudMonitor sends a POST request to push an alert to the callback URL that you specified. Only HTTP requests are supported. For information about how to configure an alert callback, see Use the alert callback feature to send notifications about threshold-triggered alerts.
NoteYou can click Advanced Settings to configure this parameter.
Auto Scaling
If you turn on Auto Scaling and an alert is triggered, the specified scaling rule is enabled. In this case, configure the following parameters: Region, ESS Group, and ESS Rule.
For information about how to create a scaling group, see Manage scaling groups.
For information about how to create a scaling rule, see Configure scaling rules.
NoteYou can click Advanced Settings to configure this parameter.
Log Service
If you turn on Log Service and an alert is triggered, the alert information is written to Simple Log Service. In this case, configure the following parameters: Region, Project Name, and Logstore.
For information about how to create a project and a Logstore, see Collect and analyze ECS text logs using LoongCollector.
NoteYou can click Advanced Settings to configure this parameter.
Simple Message Queue (formerly MNS) - Topic
If you turn on Simple Message Queue (formerly MNS) - Topic and an alert is triggered, the alert information is written to the specified topic in Message Service (MNS). In this case, select a region and a topic. For information about how to create a topic, see Create a topic.
Method to handle alerts when no monitoring data is found
The method that is used to handle alerts if no monitoring data exists. Valid values:
Do not do anything (default)
Send alert notifications
Treated as normal
NoteYou can click Advanced Settings to configure this parameter.
Tag
The tag that can be added to alert notifications. Each tag key is paired with a tag value. You can specify multiple pairs of tags.
Click Confirm.
How do I view how much storage is used for hot data and cold data?
Log on to the AnalyticDB for MySQL console. On the Monitoring and Alerts page, view the Hot Data Size and Cold Data Size metrics in Disk Space Used chart.
How do I check information such as the table size?
Log on to the AnalyticDB for MySQL console. On the page of the cluster, click the Table Storage Information tab to view information such as the table size.
Why is the hot data usage on the Monitoring Information page greater than the total data usage?
An AnalyticDB for MySQL cluster has multiple storage nodes. The Disk Data Usage metric shows the maximum usage of a single read/write node. The Hot Data Usage metric shows the total usage of all read/write nodes.
Why does the average CPU utilization increase on the monitoring interface after a cluster is changed from reserved mode to elastic mode?
When a C32 cluster is changed from reserved mode to elastic mode, the core count of a single node is reduced to 8. By default, BUILD jobs use 3 cores, which causes the average CPU utilization to increase. If your business is not affected, you can ignore this increase. If your business is affected, you can upgrade the cluster or Submit a ticket for technical support. For more information about BUILD jobs, see BUILD.
A long query response time is displayed on the Monitoring Information page, but no corresponding time-consuming SQL query is found on the Diagnostics and Optimization page. Why?
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 includes the time required to cache the result set, but the Total Duration does not. Therefore, if a query returns a large result set, the caching time can make the Query Response Time longer than the Total Duration. You can find time-consuming SQL queries on the SQL Audit page.
The following section describes the time components of an SQL query:
When you submit an SQL query to AnalyticDB for MySQL, it goes through several stages, each contributing to the total response time. First, the query enters a queue. High query concurrency can lead to long queuing times. After leaving the queue, the query enters the execution engine, which parses the statement and generates an execution plan. Then, subtasks are run on storage and compute nodes. Finally, if the query returns a large result set, the frontend nodes cache the result. This caching process also contributes to the overall response time. The following figure shows the time breakdown of an SQL query: