Anomaly detection

更新时间:
复制 MD 格式

Timely detection of database anomalies is critical to daily database O&M. Database Autonomy Service (DAS) provides an anomaly detection feature that uses machine learning and fine-grained monitoring data to automatically detect anomalies 24/7 without manual activation. Compared with rule-based or threshold-based alerting, this feature detects abnormal changes in databases more promptly.

Prerequisites

  • The target database instance is one of the following types:

    Database

    Region

    • ApsaraDB RDS for MySQL

    • MyBase for MySQL

    • Public cloud

      China (Hangzhou), China (Shanghai), China (Shenzhen), China (Heyuan), China (Guangzhou), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Nanjing - Local Region - Decommissioning), China (Fuzhou - Local Region - Decommissioning), China (Chengdu), China (Zhengzhou), China (Hong Kong), Japan (Tokyo), South Korea (Seoul), Singapore, Malaysia (Kuala Lumpur), Malaysia (Johor), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok), UAE (Dubai), Saudi Arabia (Riyadh), Germany (Frankfurt), US (Silicon Valley), US (Virginia), UK (London), and Mexico

    • Finance Cloud

      China East 1 Finance, China East 2 Finance, China South 1 Finance, and China North 2 Finance (invitation-only preview)

    • Alibaba Gov Cloud

      China North 2 Ali Gov 1

    • General Industry Cloud

      China (Ulanqab)

    ApsaraDB RDS for PostgreSQL

    • Public cloud

      China (Hangzhou), China (Shanghai), China (Shenzhen), China (Heyuan), China (Guangzhou), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Chengdu), China (Hong Kong), Japan (Tokyo), South Korea (Seoul), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), UAE (Dubai), Germany (Frankfurt), US (Silicon Valley), US (Virginia), and UK (London)

    • Finance Cloud

      China East 1 Finance, China East 2 Finance, and China South 1 Finance

    • Alibaba Gov Cloud

      China North 2 Ali Gov 1

    ApsaraDB RDS for SQL Server

    • Public cloud

      China (Hangzhou), China (Shanghai), China (Shenzhen), China (Heyuan), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Chengdu), China (Hong Kong), Japan (Tokyo), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), UAE (Dubai), Germany (Frankfurt), US (Silicon Valley), US (Virginia), and UK (London)

    • Finance Cloud

      China East 1 Finance, China East 2 Finance, and China South 1 Finance

    • Alibaba Gov Cloud

      China North 2 Ali Gov 1

    PolarDB for MySQL Standard Edition and Enterprise Cluster Edition

    • Public cloud

      China (Hangzhou), China (Shanghai), China (Shenzhen), China (Heyuan), China (Guangzhou), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Chengdu), China (Hong Kong), Japan (Tokyo), South Korea (Seoul), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), Germany (Frankfurt), US (Silicon Valley), US (Virginia), and UK (London)

    • Finance Cloud

      China East 1 Finance, China East 2 Finance, China South 1 Finance, and China North 2 Finance (invitation-only preview)

    • Alibaba Gov Cloud

      China North 2 Ali Gov 1

    • Tair (Redis-compatible)

    • MyBase Redis

    • Community Edition

    • Tair (Enterprise Edition) Memory-optimized

    • Public cloud

      China (Hangzhou), China (Shanghai), China (Shenzhen), China (Heyuan), China (Guangzhou), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Chengdu), China (Hong Kong), Japan (Tokyo), South Korea (Seoul), Singapore, Malaysia (Kuala Lumpur), Malaysia (Johor), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok), UAE (Dubai), Saudi Arabia (Riyadh), Germany (Frankfurt), US (Silicon Valley), US (Virginia), and UK (London)

    • Finance Cloud

      China East 1 Finance, China East 2 Finance, China South 1 Finance, and China North 2 Finance (invitation-only preview)

    • Alibaba Gov Cloud

      China North 2 Ali Gov 1

    Tair (Enterprise Edition) Persistent memory-optimized and disk-based

    • Public cloud

      China (Hangzhou), China (Shanghai), China (Shenzhen), China (Beijing), China (Zhangjiakou), China (Hong Kong), Singapore, Germany (Frankfurt), and US (Virginia)

    • Alibaba Gov Cloud

      China North 2 Ali Gov 1

    MongoDB

    • Public cloud

      China (Hangzhou), China (Shanghai), China (Shenzhen), China (Heyuan), China (Guangzhou), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Chengdu), China (Hong Kong), Japan (Tokyo), South Korea (Seoul), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok), Malaysia (Johor), Germany (Frankfurt), UK (London), Saudi Arabia (Riyadh), UAE (Dubai), Mexico, US (Virginia), US (Atlanta), and US (Silicon Valley)

  • The target database instance is registered with DAS and the connection status is Normal Access.

    Note

    For more information about how to register a database instance, see Connect an Alibaba Cloud database to DAS.

Features

This feature uses machine learning and fine-grained monitoring data to provide automatic 24/7 anomaly detection without manual activation. Compared with rule-based or threshold-based alerting, it detects abnormal database changes more promptly.

Item

Traditional alerting

DAS anomaly detection

Method

Rule-based and threshold-based.

AI-based.

Detection scope

Primarily monitoring metrics.

Monitoring metrics, SQL statements, logs, locks, and O&M events.

Timeliness

At least 5 minutes, potentially up to a day.

Near real-time.

Detection principle

Fault-driven.

Anomaly-driven.

Periodic pattern recognition

Not supported.

Automatic.

Adaptability

Cannot adapt to business characteristics.

Adapts to business characteristics.

Predictive capability

Not available.

Available.

View anomaly detection results

In the DAS Autonomy Center, view the anomalous events detected within a specified time range.

  1. Log on to the DAS console.

  2. In the navigation pane on the left, click Intelligent O&M Center > Instance Monitoring .

  3. Find the target instance and click the instance ID to open the instance details page.

  4. In the navigation pane on the left, click Autonomy Center.

  5. Select a time range to view the anomalous events detected within that period.

Enable event alerts

After you enable event alerts, DAS sends notifications through your configured channels, such as SMS messages, when anomalous events are detected. This helps you promptly identify abnormal database changes. For more information, see Configure alerts.

Note

When you configure an alert rule, set Type to Autonomy Events and Event Type to Exceptions in Monitoring Metrics. This enables alerts for detected anomalous events.

FAQ

  • In the Anomaly Snapshots of a Monitoring Metric Anomaly Detection (Time Series Anomaly Detection) event, how is the change multiple for metrics in Analysis of Abnormal Metrics calculated?

    Change multiple = Actual metric value / Predicted metric value. DAS uses historical hourly data from the database instance to predict the current metric value. The predicted value serves as a baseline and is compared with the actual metric value to calculate the change multiple. In the Related Information table on the Anomaly Snapshot > Analysis of Abnormal Metrics page, the Related Metrics column displays each metric name along with its percentage change multiple, such as mysql.innodb_rows_read↑112890276.00%, mysql.innodb_rows_updated↑122309.00%, mysql.select_ps↑576.00%, mysql.cpu_usage↑8444.00%, and mysql.active_session↑1711.00%.

  • Why does a newly created instance or node with stable traffic trigger many Monitoring Metric Anomaly Detection (Time Series Anomaly Detection) events?

    The DAS anomaly detection feature first builds a prediction model based on the historical data of the instance and then uses this model for anomaly detection. For a newly created instance or node, the baseline performance data is relatively low. As a result, the prediction model built from this data also has a low baseline. When business operations begin, metrics may deviate significantly from the model predictions for a period, causing false spikes and triggering frequent anomaly detection events.

    Note

    After sufficient data is accumulated, DAS automatically rebuilds a more accurate prediction model, and the Monitoring Metric Anomaly Detection (Time Series Anomaly Detection) events caused by false spikes will stop occurring.

  • Why is a Monitoring Metric Anomaly Detection (Time Series Anomaly Detection) event not triggered even though instance performance metrics show obvious anomalies within a few seconds?

    The DAS anomaly detection feature uses minute-level average data for detection. Anomalies that last only a few seconds may be smoothed out due to their minimal impact on the averaged data, which prevents detection and does not trigger a Monitoring Metric Anomaly Detection (Time Series Anomaly Detection) event.

Related documentation

Use the autonomy features of DAS to automatically handle database anomalies.