You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-monitor/alerts/alerts-dynamic-thresholds.md
+118-2Lines changed: 118 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -97,13 +97,129 @@ If you have a new resource or missing metric data, Dynamic Thresholds won't trig
97
97
98
98
The system automatically recognizes prolonged outages and removes them from the threshold learning algorithm. As a result, despite prolonged outages, dynamic thresholds understand the data. Service issues are detected with the same sensitivity as before an outage occurred.
99
99
100
+
## The Dynamic Thresholds borders don't seem to fit the data
101
+
102
+
If the behavior of a metric changed recently, the changes won't necessarily be reflected in the Dynamic Threshold borders (upper and lower bounds) immediately. The borders are calculated based on metric data from the last 10 days. When you view the Dynamic Threshold borders for a given metric, look at the metric trend in the last week and not only for recent hours or days.
103
+
104
+
## Why is weekly seasonality not detected by Dynamic Thresholds?
105
+
106
+
To identify weekly seasonality, the Dynamic Thresholds model requires at least three weeks of historical data. When enough historical data is available, any weekly seasonality that exists in the metric data is identified and the model is adjusted accordingly.
107
+
108
+
## Dynamic Thresholds shows a negative lower bound for a metric even though the metric always has positive values
109
+
110
+
When a metric exhibits large fluctuation, Dynamic Thresholds builds a wider model around the metric values. This action can result in the lower border being below zero. Specifically, this scenario can happen when:
111
+
112
+
- The sensitivity is set to low.
113
+
- The median values are close to zero.
114
+
- The metric exhibits an irregular behavior with high variance, which appears as spikes or dips in the data.
115
+
116
+
When the lower bound has a negative value, it's plausible for the metric to reach a zero value given the metric's irregular behavior. Consider choosing a higher sensitivity or a larger **Aggregation granularity (Period)** to make the model less sensitive. Or, use the **Ignore data before** option to exclude a recent irregularity from the historical data used to build the model.
117
+
118
+
## The Dynamic Thresholds alert rule is too noisy or fires too much
119
+
120
+
To reduce the sensitivity of your Dynamic Thresholds alert rule, use one of the following options:
121
+
122
+
-**Threshold sensitivity:** Set the sensitivity to **Low** to be more tolerant for deviations.
123
+
-**Number of violations (under Advanced settings):** Configure the alert rule to trigger only if several deviations occur within a certain period of time. This setting makes the rule less susceptible to transient deviations.
124
+
125
+
## The Dynamic Thresholds alert rule doesn't fire or is not sensitive enough
126
+
127
+
Sometimes an alert rule won't trigger, even when a high sensitivity is configured. This scenario usually happens when the metric's distribution is highly irregular.
128
+
Consider one of the following options:
129
+
130
+
* Move to monitoring a complementary metric that's suitable for your scenario, if applicable. For example, check for changes in success rate rather than failure rate.
131
+
* Try selecting a different value for **Aggregation granularity (Period)**.
132
+
* Check if there was a drastic change in the metric behavior in the last 10 days, for example, an outage. An abrupt change can affect the upper and lower thresholds calculated for the metric and make them broader. Wait for a few days until the outage is no longer taken into the thresholds calculation. Or use the **Ignore data before** option under **Advanced settings**.
133
+
* If your data has weekly seasonality, but not enough history is available for the metric, the calculated thresholds can result in having broad upper and lower bounds. For example, the calculation can treat weekdays and weekends in the same way and build wide borders that don't always fit the data. This issue should resolve itself after enough metric history is available. Then, the correct seasonality will be detected and the calculated thresholds will update accordingly.
134
+
135
+
## Metrics not supported by Dynamic Thresholds
136
+
137
+
Dynamic thresholds are supported for most metrics, but some metrics can't use dynamic thresholds.
138
+
139
+
The following table lists the metrics that aren't supported by Dynamic Thresholds.
Dynamic Thresholds can be applied to most platform and custom metrics in Azure Monitor, and it was also tuned for the common application and infrastructure metrics.
103
219
104
220
The following items are best practices on how to configure alerts on some of these metrics by using Dynamic Thresholds.
105
221
106
-
###Configure dynamic thresholds on virtual machine CPU percentage metrics
222
+
## Configure dynamic thresholds on virtual machine CPU percentage metrics
107
223
108
224
1. In the [Azure portal](https://portal.azure.com), select **Monitor**. The **Monitor** view consolidates all your monitoring settings and data in one view.
109
225
@@ -140,7 +256,7 @@ The following items are best practices on how to configure alerts on some of the
140
256
> [!NOTE]
141
257
> Metric alert rules created through the portal are created in the same resource group as the target resource.
142
258
143
-
###Configure dynamic thresholds on Application Insights HTTP request execution time
259
+
## Configure dynamic thresholds on Application Insights HTTP request execution time
144
260
145
261
1. In the [Azure portal](https://portal.azure.com), select **Monitor**. The **Monitor** view consolidates all your monitoring settings and data in one view.
Copy file name to clipboardExpand all lines: articles/azure-monitor/alerts/alerts-troubleshoot-metric.md
-115Lines changed: 0 additions & 115 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -299,121 +299,6 @@ Choose an **Aggregation granularity (Period)** that's larger than the **Frequenc
299
299
-**Metric alert rule that monitors multiple resources:** When a new resource is added to the scope.
300
300
-**Metric alert rule that monitors a metric that isn't emitted continuously (sparse metric):** When the metric is emitted after a period longer than 24 hours in which it wasn't emitted.
301
301
302
-
## The Dynamic Thresholds borders don't seem to fit the data
303
-
304
-
If the behavior of a metric changed recently, the changes won't necessarily be reflected in the Dynamic Threshold borders (upper and lower bounds) immediately. The borders are calculated based on metric data from the last 10 days. When you view the Dynamic Threshold borders for a given metric, look at the metric trend in the last week and not only for recent hours or days.
305
-
306
-
## Why is weekly seasonality not detected by Dynamic Thresholds?
307
-
308
-
To identify weekly seasonality, the Dynamic Thresholds model requires at least three weeks of historical data. When enough historical data is available, any weekly seasonality that exists in the metric data is identified and the model is adjusted accordingly.
309
-
310
-
## Dynamic Thresholds shows a negative lower bound for a metric even though the metric always has positive values
311
-
312
-
When a metric exhibits large fluctuation, Dynamic Thresholds builds a wider model around the metric values. This action can result in the lower border being below zero. Specifically, this scenario can happen when:
313
-
314
-
- The sensitivity is set to low.
315
-
- The median values are close to zero.
316
-
- The metric exhibits an irregular behavior with high variance, which appears as spikes or dips in the data.
317
-
318
-
When the lower bound has a negative value, it's plausible for the metric to reach a zero value given the metric's irregular behavior. Consider choosing a higher sensitivity or a larger **Aggregation granularity (Period)** to make the model less sensitive. Or, use the **Ignore data before** option to exclude a recent irregularity from the historical data used to build the model.
319
-
320
-
## The Dynamic Thresholds alert rule is too noisy (fires too much)
321
-
322
-
To reduce the sensitivity of your Dynamic Thresholds alert rule, use one of the following options:
323
-
324
-
-**Threshold sensitivity:** Set the sensitivity to **Low** to be more tolerant for deviations.
325
-
-**Number of violations (under Advanced settings):** Configure the alert rule to trigger only if several deviations occur within a certain period of time. This setting makes the rule less susceptible to transient deviations.
326
-
327
-
## The Dynamic Thresholds alert rule is too insensitive (doesn't fire)
328
-
329
-
Sometimes an alert rule won't trigger, even when a high sensitivity is configured. This scenario usually happens when the metric's distribution is highly irregular.
330
-
Consider one of the following options:
331
-
332
-
* Move to monitoring a complementary metric that's suitable for your scenario, if applicable. For example, check for changes in success rate rather than failure rate.
333
-
* Try selecting a different value for **Aggregation granularity (Period)**.
334
-
* Check if there was a drastic change in the metric behavior in the last 10 days, for example, an outage. An abrupt change can affect the upper and lower thresholds calculated for the metric and make them broader. Wait for a few days until the outage is no longer taken into the thresholds calculation. Or use the **Ignore data before** option under **Advanced settings**.
335
-
* If your data has weekly seasonality, but not enough history is available for the metric, the calculated thresholds can result in having broad upper and lower bounds. For example, the calculation can treat weekdays and weekends in the same way and build wide borders that don't always fit the data. This issue should resolve itself after enough metric history is available. Then, the correct seasonality will be detected and the calculated thresholds will update accordingly.
336
-
337
-
## When I configure an alert rule's condition, why is Dynamic Thresholds disabled?
338
-
339
-
Dynamic thresholds are supported for most metrics, but some metrics can't use dynamic thresholds.
340
-
341
-
The following table lists the metrics that aren't supported by Dynamic Thresholds.
0 commit comments