All Products
Search
Document Center

AnalyticDB:Monitoring

Last Updated:Mar 28, 2026

This page answers common questions about monitoring in AnalyticDB for MySQL.

Unless a product edition is specified, the answers on this page apply to Data Warehouse Edition only.

FAQ overview

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

This applies to Data Warehouse Edition clusters in reserved mode only. Enterprise Edition, Basic Edition, and Data Lakehouse Edition clusters do not require disk monitoring alerts.

Set up a CloudMonitor alert rule to receive notifications before disk usage reaches a critical level.

  1. Log on to the AnalyticDB for MySQL console. In the upper-left corner, select a region. In the left-side navigation pane, click Clusters, then click the cluster ID.

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

  3. On the Monitoring and Alerts page, check the current 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

      The maximum disk usage is the highest disk usage among all nodes in the cluster. If the value is 90% or higher, the disk is locked. Pay close attention to this metric.

    • Elastic modeimage.png

      Note

      The disk usage is the maximum disk usage of a single read/write node. If the value is 8 TB or higher, data cannot be written to the cluster. Pay close attention to this metric.

  4. Click the Alerts tab, then click Create Alert Rule.

  5. In the Create Alert Rule panel, configure the parameters described in the following table.

    ParameterDescription
    Resource RangeThe resources the alert rule applies to. All Resources applies the rule to all clusters in your account (up to 1,000 resources per 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. Instances applies the rule to specific clusters only.
    Rule DescriptionThe conditions that trigger the alert. Click Add Rule, configure Alert Rule, Metric Type, Metric, Threshold and Alert Level, and Chart Preview in the Configure Rule Description panel, then click OK.
    Mute PeriodHow long CloudMonitor waits before resending an alert notification while the alert remains active. 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. Valid values: 5 Minutes, 15 Minutes, 30 Minutes, 60 Minutes, 3 Hours, 6 Hours, 12 Hours, and 24 Hours.
    Effective PeriodThe time window during which CloudMonitor evaluates the alert rule. Each contact receives up to four disk usage alert notifications per day.
    Alert Contact GroupThe contact group that receives alert notifications. For how to create contacts and groups, see Create an alert contact or alert contact group.
    Alert Callback(Optional — click Advanced Settings) A publicly accessible HTTP URL. CloudMonitor sends a POST request to this URL when an alert is triggered. For configuration details, see Use the alert callback feature to send notifications about threshold-triggered alerts.
    Auto Scaling(Optional — click Advanced Settings) When enabled, triggers a scaling rule when an alert fires. Requires Region, ESS Group, and ESS Rule. For setup, see Manage scaling groups and Configure scaling rules.
    Log Service(Optional — click Advanced Settings) When enabled, writes alert information to Simple Log Service. Requires Region, Project Name, and Logstore. For setup, see Collect and analyze ECS text logs using LoongCollector.
    Simple Message Queue (formerly MNS) - TopicWhen enabled, writes alert information to a Message Service topic. Select a region and topic. For how to create a topic, see Create a topic.
    Method to handle alerts when no monitoring data is found(Optional — click Advanced Settings) Specifies behavior when no monitoring data exists. Valid values: Do not do anything (default), Send alert notifications, and Treated as normal.
    TagKey-value pairs added to alert notifications. Multiple pairs are supported.
  6. Click Confirm.

How do I view storage used for hot data and cold data?

Log on to the AnalyticDB for MySQL console. On the Monitoring and Alerts page, check the Disk Space Used chart — it shows Hot Data Size and Cold Data Size as separate metrics.

How do I check table size information?

Log on to the AnalyticDB for MySQL console. Navigate to Storage Analysis > Storage Overview for the cluster, then click the Table Storage Information tab.

Why is the hot data usage greater than the total data usage on the Monitoring Information page?

The two metrics measure different things:

  • Disk Data Usage shows the maximum usage of a single read/write node.

  • Hot Data Usage shows the combined usage across all read/write nodes.

If your cluster has multiple read/write nodes, Hot Data Usage will naturally exceed Disk Data Usage because it sums all nodes.

Why does average CPU utilization increase after a cluster switches from reserved mode to elastic mode?

When a C32 cluster switches from reserved mode to elastic mode, each node's core count drops to 8. Because BUILD jobs use 3 cores by default, they consume a higher proportion of available cores — raising the average CPU utilization reading.

If the increase does not affect your workload, no action is needed. If queries are slowing down, upgrade the cluster or submit a ticket for technical support. For more information about BUILD jobs, see BUILD.

Why does the Monitoring Information page show a long query response time, but no slow SQL query appears on the Diagnostics and Optimization page?

The two pages measure query time differently:

  • Query Response Time (Monitoring Information page): includes the time to cache the result set after query execution.

  • Total Duration (Diagnostics and Optimization page): does not include result-caching time.

For queries that return large result sets, caching can add significant time to Query Response Time without appearing in Total Duration. To find slow SQL queries, check the SQL Audit page.

To understand where time is spent in a query, AnalyticDB for MySQL processes SQL queries through these stages:

StageDescription
QueueThe query waits in a queue. High concurrency can cause long wait times.
Parse and planThe execution engine parses the statement and generates an execution plan.
ExecuteSubtasks run on storage and compute nodes.
Cache resultsFor large result sets, frontend nodes cache the data before returning it. This step contributes to Query Response Time but not to Total Duration.

The following figure shows the time breakdown of an SQL query:

image