DAS continuously monitors your database instances using machine learning and fine-grained monitoring data to detect performance anomalies — no configuration required.
Compared with rule-based or threshold-based alerting, anomaly detection catches abnormal database changes faster, covering a wider range of signals: monitoring metrics, SQL statements, logs, locks, and O&M events.
How it works
DAS builds a prediction model from each instance's historical performance data. The model uses hourly data from previous periods to establish a baseline that represents expected behavior for that instance. During continuous monitoring, DAS compares real-time metrics against this baseline and flags deviations as anomalous events.
The prediction model uses hourly data from previous periods to predict current metric values. The change multiple (actual value / predicted value) quantifies how far a metric has deviated from its expected baseline — you can view this in the Analysis of Abnormal Metrics section of an Anomaly Snapshot.
| Traditional alerting | DAS anomaly detection | |
|---|---|---|
| Method | Rule-based or threshold-based | AI-based |
| Monitored objects | Monitoring metrics | Monitoring metrics, SQL statements, logs, locks, and O&M events |
| Timeliness | 5 minutes to 1+ days | Near real-time |
| Detection method | Fault-driven | Exception-driven |
| Periodic detection | None | Automatic |
| Adaptability | Cannot adapt to business features | Adapts to business features |
| Prediction | None | Yes |
Supported databases and regions
Anomaly detection is available for the following database types and regions. Your instance must also be connected to DAS with connection status Normal Access. For connection instructions, see Connect an Alibaba Cloud database instance to DAS.
| 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), Zhengzhou, China (Hong Kong), Japan (Tokyo), South Korea (Seoul), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok), UAE (Dubai), SAU (Riyadh - Partner Region), Germany (Frankfurt), US (Silicon Valley), US (Virginia), UK (London) <br>Alibaba Finance Cloud: China East 1 Finance, China East 2 Finance, China South 1 Finance, China North 2 Finance (invitational preview) <br>Alibaba Gov Cloud: China North 2 Ali Gov 1 |
| 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), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), UAE (Dubai), Germany (Frankfurt), US (Silicon Valley), US (Virginia), UK (London) <br>Alibaba Finance Cloud: China East 1 Finance, China East 2 Finance, China South 1 Finance <br>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), UK (London) <br>Alibaba Finance Cloud: China East 1 Finance, China East 2 Finance, China South 1 Finance <br>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), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), Germany (Frankfurt), US (Silicon Valley), US (Virginia), UK (London) <br>Alibaba Finance Cloud: China East 1 Finance, China East 2 Finance, China South 1 Finance, China North 2 Finance (invitational preview) <br>Alibaba Gov Cloud: China North 2 Ali Gov 1 |
| Tair (Redis OSS-compatible) Community Edition and 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), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok), UAE (Dubai), SAU (Riyadh - Partner Region), Germany (Frankfurt), US (Silicon Valley), US (Virginia), UK (London) <br>Alibaba Finance Cloud: China East 1 Finance, China East 2 Finance, China South 1 Finance, China North 2 Finance (invitational preview) <br>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), US (Virginia) <br>Alibaba Gov Cloud: China North 2 Ali Gov 1 |
View anomaly detection results
Log on to the DAS console.
In the left navigation pane, click Intelligent O&M Center > Instance Monitoring.
Find the target instance, and click the instance ID to go to the instance details page.
In the left navigation pane, click Autonomy Center.
Select a time range to view the anomalous events detected during that period.
Set up event notifications
Enable event subscription to receive notifications — such as text messages — when DAS detects an anomalous event. This lets you respond to issues without manually checking the console.subscriptionsubscription
Anomalous events are sent at the Warning alert level. Adjust the alert level threshold for notifications based on your requirements.
For setup instructions, see Enable the event subscription feature.
FAQ
How is the change multiple calculated?
In the Analysis of Abnormal Metrics section of an Anomaly Snapshot for an Anomaly Detection of Metrics (Time Series Anomaly Detection) event:
Change multiple = Actual value / Predicted value
DAS uses hourly data from a previous period to predict the current metric value. That predicted value becomes the baseline. The change multiple shows how far the actual value deviates from what was expected.
Why does a newly created instance or node trigger a large number of Time-series Anomaly Detection for Monitoring Metrics events?
DAS builds its prediction model from historical data. For a new instance or node, there isn't much history yet, so the baseline starts low. Once real traffic arrives, metrics can deviate significantly from the predicted values — triggering frequent anomaly events even when the traffic is stable.
After enough data accumulates, DAS automatically rebuilds a more accurate model, and the Metric Time Series Anomaly Detection events caused by false spikes will no longer occur.
Why wasn't an event triggered even though I saw a clear spike in my metrics?
DAS analyzes data averaged over one-minute intervals. Short-lived spikes — lasting only a few seconds — are smoothed out by this averaging process and may not cross the detection threshold. As a result, brief anomalies may not trigger a Monitoring Metric Anomaly Detection (Time Series Anomaly Detection) event.
What's next
Use DAS autonomy features to automatically resolve anomalies when they occur: