Detecting database issues promptly is a key part of daily database operations and maintenance (O&M). Database Autonomy Service (DAS) provides an anomaly detection feature that uses machine learning and fine-grained monitoring data to automatically detect issues 24/7. You do not need to manually enable this feature. Compared with rule-based or threshold-based alerting, this feature can detect abnormal database changes more quickly.
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), 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), and UK (London)
Alibaba Finance Cloud
China East 1 Finance, China East 2 Finance, China South 1 Finance, and China North 2 Finance (invitational preview)
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), and UK (London)
Alibaba 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)
Alibaba 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), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), Germany (Frankfurt), US (Silicon Valley), US (Virginia), and UK (London)
Alibaba Finance Cloud
China East 1 Finance, China East 2 Finance, China South 1 Finance, and China North 2 Finance (invitational preview)
Alibaba Gov Cloud
China North 2 Ali Gov 1
Tair (Redis OSS-compatible)
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), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok), UAE (Dubai), SAU (Riyadh - Partner Region), Germany (Frankfurt), US (Silicon Valley), US (Virginia), and UK (London)
Alibaba Finance Cloud
China East 1 Finance, China East 2 Finance, China South 1 Finance, and China North 2 Finance (invitational 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
The target database instance is connected to DAS, and its connection status is Normal Access.
NoteFor more information about how to connect a database instance, see Connect an Alibaba Cloud database instance to DAS.
Features
The anomaly detection feature uses machine learning and fine-grained monitoring data to automatically detect issues 24/7. You do not need to manually enable this feature. Compared with rule-based or threshold-based alerting, this feature detects abnormal database changes more quickly.
Item | Traditional solution | DAS anomaly detection |
Method | Rule-based or threshold-based. | AI-based. |
Monitored objects | Mainly based on monitoring metrics. | A wide range of objects, such as monitoring metrics, SQL statements, logs, locks, and O&M events. |
Timeliness | From 5 minutes to one or more days. | Near Real-Time. |
Detection method | Fault-driven. | Exception-driven. |
Periodic detection | None. | Automatic detection. |
Adaptability | Cannot adapt to business features. | Adapts to business features. |
Prediction | None. | Enables you to make predictions. |
View anomaly detection results
In the DAS autonomy center, you can view the anomalous events that were detected within a selected time range.
Log on to the DAS console.
In the navigation pane on the left, click Intelligent O&M Center > Instance Monitoring.
Find the target instance, click the instance ID, and then go to the instance details page.
In the navigation pane on the left, click Autonomy Center.
Select a time range to view the anomalous events that occurred during that period.
Enable event subscription
After you enable the event subscription feature, DAS sends you a notification, such as a text message, when an anomalous event is detected. This helps you promptly discover abnormal database changes. For more information, see Enable the event subscription feature.
The alert level for anomalous events is Warning. You can set the alert level for event notifications based on your requirements.
FAQ
How is the change multiple calculated for related metrics 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 for the instance. This predicted value serves as a baseline and is compared with the current actual value to calculate the change multiple.
Why do newly created instances or nodes trigger a high volume of Time-series Anomaly Detection For Monitoring Metrics events even though their traffic is stable?
The DAS anomaly detection feature first builds a prediction model based on an instance's historical data and then uses this model for detection. For a new instance or node, the amount of historical performance data is relatively low. Therefore, the prediction model built from this data also has a low baseline. After business operations start, metrics may differ significantly from the predicted values for a period, which causes a false surge. This can trigger frequent anomaly detection events.
NoteAfter a period of data accumulation, DAS automatically rebuilds a more accurate prediction model, and the Metric Time Series Anomaly Detection events caused by false spikes will no longer occur.
Why wasn't the Monitoring Metric Time-series Anomaly Detection event triggered even though the instance performance metrics showed a clear anomaly for a few seconds?
The anomaly detection feature in DAS analyzes data averaged over one-minute intervals. This process can smooth out short-lived anomalies, minimizing their impact on the data. As a result, these anomalies may go undetected and will not trigger a Monitoring Metric Anomaly Detection (Time Series Anomaly Detection) event.
Related documents
You can use the autonomy features of DAS to automatically resolve database anomalies when they occur.