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
@@ -167,6 +184,22 @@ A 201 response is returned on successful creation. 200 is returned on successful
167
184
Log search alert rules have this dedicated PowerShell cmdlet:
168
185
-[New-AzScheduledQueryRule](/powershell/module/az.monitor/new-azscheduledqueryrule): Creates a new log search alert rule or updates an existing log search alert rule.
169
186
187
+
## Check the number of log alert rules in use
188
+
189
+
### In the Azure portal
190
+
1. On the Alerts screen in Azure Monitor, select **Alert rules**.
191
+
1. In the **Subscription** dropdown control, filter to the subscription you want. (Make sure you don't filter to a specific resource group, resource type, or resource.)
192
+
1. In the **Signal type** dropdown control, select **Log Search**.
193
+
1. Verify that the **Status** dropdown control is set to **Enabled**.
194
+
195
+
The total number of log search alert rules is displayed above the rules list.
Copy file name to clipboardExpand all lines: articles/azure-monitor/alerts/alerts-troubleshoot-log.md
+2-17Lines changed: 2 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -182,9 +182,10 @@ This error message is returned when trying to update or delete rules created wit
182
182
1. Edit or delete the rule programmatically using the Log Analytics [REST API](./api-alerts.md).
183
183
2. Recommended: [Upgrade your alert rules to use Scheduled Query Rules API](./alerts-log-api-switch.md) (legacy API is on a deprecation path).
184
184
185
-
## Alert rule quota was reached
185
+
## Alert rule service limit was reached
186
186
187
187
For details about the number of log search alert rules per subscription and maximum limits of resources, see [Azure Monitor service limits](../service-limits.md).
188
+
See [Check the total number of log alert rules in use](alerts-manage-alert-rules.md#check-the-number-of-log-alert-rules-in-use) to see how many metric alert rules are currently in use.
188
189
If you've reached the quota limit, the following steps might help resolve the issue.
189
190
190
191
1. Delete or disable log search alert rules that aren’t used anymore.
@@ -196,22 +197,6 @@ If you've reached the quota limit, the following steps might help resolve the is
196
197
- The resource type for the quota increase, such as **Log Analytics** or **Application Insights**
197
198
- The requested quota limit
198
199
199
-
### Check the current usage of log alert rules
200
-
201
-
#### Check the number of log alert rules in use in the Azure portal
202
-
203
-
1. On the Alerts screen in Azure Monitor, select **Alert rules**.
204
-
1. In the **Subscription** dropdown control, filter to the subscription you want. (Make sure you don't filter to a specific resource group, resource type, or resource.)
205
-
1. In the **Signal type** dropdown control, select **Log Search**.
206
-
1. Verify that the **Status** dropdown control is set to **Enabled**.
207
-
208
-
The total number of log search alert rules is displayed above the rules list.
209
-
210
-
### Use the API to check the number of log alert rules in use
Copy file name to clipboardExpand all lines: articles/azure-monitor/alerts/alerts-troubleshoot-metric.md
+27-45Lines changed: 27 additions & 45 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,9 +15,9 @@ Azure Monitor alerts proactively notify you when important conditions are found
15
15
16
16
## Metric alert didn't fire when it should have
17
17
18
-
If you believe a metric alert should have fired but it didn't, it isn't listed in the Azure portal, try the following steps:
18
+
If you believe a metric alert should have fired but it didn't, and it isn't listed in the Azure portal, try the following steps:
19
19
20
-
1.**Review the metric alert rule configuration**
20
+
1.**Review the metric alert rule configuration.**
21
21
22
22
- Check that **Aggregation type** and **Aggregation granularity (Period)** are configured as expected. **Aggregation type** determines how metric values are aggregated. To learn more, see [Azure Monitor Metrics aggregation and display explained](../essentials/metrics-aggregation-explained.md#aggregation-types). **Aggregation granularity (Period)** controls how far back the evaluation aggregates the metric values each time the alert rule runs.
23
23
- Check that **Threshold value** or **Sensitivity** are configured as expected.
@@ -26,33 +26,40 @@ If you believe a metric alert should have fired but it didn't, it isn't listed i
26
26
> [!NOTE]
27
27
> Dynamic thresholds require at least 3 days and 30 metric samples before they become active.
28
28
29
-
1.**Check if the alert fired but didn't send the notification**
29
+
1.**Check if the alert fired but didn't send the notification.**
30
30
31
31
Review the [fired alerts list](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/alertsV2) to see if you can locate the fired alert. If you can see the alert in the list but have an issue with some of its actions or notifications, see [Troubleshooting problems in Azure Monitor alerts](./alerts-troubleshoot.md).
32
32
33
-
1.**Check if the alert is already active**
33
+
1.**Check if the alert is already active.**
34
34
35
35
Check if there's already a fired alert on the metric time series for which you expected to get an alert. Metric alerts are stateful, which means that once an alert is fired on a specific metric time series, more alerts on that time series won't be fired until the issue is no longer observed. This design choice reduces noise. The alert is resolved automatically when the alert condition isn't met for three consecutive evaluations.
36
36
37
-
1.**Check the dimensions used**
37
+
1.**Check the dimensions used.**
38
38
39
39
If you've selected some [dimension values for a metric](./alerts-metric-overview.md#using-dimensions), the alert rule monitors each individual metric time series (as defined by the combination of dimension values) for a threshold breach. To also monitor the aggregate metric time series, without any dimensions selected, configure another alert rule on the metric without selecting dimensions.
40
40
41
-
1.**Check the aggregation and time granularity**
41
+
1.**Check the aggregation and time granularity.**
42
42
43
-
If you're visualizing the metric by using [metrics charts](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/metrics), ensure that:
43
+
If you're using [metrics charts](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/metrics), ensure that:
44
44
45
45
* The selected **Aggregation** in the metric chart is the same as **Aggregation type** in your alert rule.
46
46
* The selected **Time granularity** is the same as **Aggregation granularity (Period)** in your alert rule, and isn't set to **Automatic**.
47
47
48
+
1.**Check if the alert rule is missing the first evaluation period in a time series.**
49
+
50
+
You can reduce the likelihood of missing the first evaluation of added time series by making sure that you choose an **Aggregation granularity (Period)** that's larger than the **Frequency of evaluation** in the following cases:
51
+
52
+
- When a new dimension value combination is added to a metric alert rule that monitors multiple dimensions.
53
+
- When a new resource is added to the scope to a metric alert rule that monitors multiple resources.
54
+
- When the metric is emitted after a period longer than 24 hours in which it wasn't emitted for metric alert rule that monitors a metric that isn't emitted continuously (sparse metric).
55
+
48
56
## The metric alert is not triggered every time my condition is met
49
57
50
-
Metric alerts are stateful by default, so other alerts aren't fired if there's already a fired alert on a specific time series. To make a specific metric alert rule stateless and get alerted on every evaluation<sup>1</sup> in which the alert condition is met, use one of these options:
58
+
Metric alerts are stateful by default, so other alerts aren't fired if there's already a fired alert on a specific time series. To make a specific metric alert rule stateless and get alerted on every evaluation in which the alert condition is met, use one of these options:
51
59
52
60
- If you create the alert rule programmatically, for example, via [Azure Resource Manager](./alerts-metric-create-templates.md), [PowerShell](/powershell/module/az.monitor/), [REST](/rest/api/monitor/metricalerts/createorupdate), or the [Azure CLI](/cli/azure/monitor/metrics/alert), set the `autoMitigate` property to `False`.
53
-
- If you create the alert rule via the Azure portal, clear the **Automatically resolve alerts** option under the **Alert rule details** section.
54
-
55
-
<sup>1</sup> The frequency of notifications for stateless metric alerts differs based on the alert rule's configured frequency:
61
+
- If you create the alert rule in the Azure portal, clear the **Automatically resolve alerts** option under the **Alert rule details** section.
62
+
The frequency of notifications for stateless metric alerts differs based on the alert rule's configured frequency:
56
63
57
64
-**Alert frequency of less than 5 minutes**: While the condition continues to be met, a notification is sent somewhere between one and six minutes.
58
65
-**Alert frequency of more than 5 minutes**: While the condition continues to be met, a notification is sent between the configured frequency and double the frequency. For example, for an alert rule with a frequency of 15 minutes, a notification is sent somewhere between 15 to 30 minutes.
@@ -75,7 +82,7 @@ If you believe your metric alert shouldn't have fired but it did, the following
75
82
1. Review the [fired alerts list](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/alertsV2) to locate the fired alert. Select the alert to view its details. Review the information provided under **Why did this alert fire?** to see the metric chart, **Metric value**, and **Threshold value** at the time when the alert was triggered.
76
83
77
84
> [!NOTE]
78
-
> If you're using a Dynamic Thresholds condition type and think that the thresholds used weren't correct, provide feedback by using the frown icon. This feedback affects the machine learning algorithmic research and will help improve future detections.
85
+
> If you're using dynamic thresholds, and think that the thresholds weren't correct, provide feedback by using the frown icon. This feedback affects the machine learning algorithmic research and will help improve future detections.
79
86
80
87
1. If you've selected multiple dimension values for a metric, the alert is triggered when *any* of the metric time series (as defined by the combination of dimension values) breaches the threshold. For more information about using dimensions in metric alerts, see [Narrow the target using dimensions](./alerts-types.md#narrow-the-target-using-dimensions).
81
88
@@ -86,14 +93,13 @@ If you believe your metric alert shouldn't have fired but it did, the following
86
93
> [!NOTE]
87
94
> Dynamic thresholds require at least 3 days and 30 metric samples before becoming active.
88
95
89
-
1. If you're visualizing the metric by using [Metrics chart](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/metrics), ensure that:
96
+
1. If you're using [metrics charts](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/metrics), ensure that:
90
97
91
98
- The selected **Aggregation** in the metric chart is the same as the **Aggregation type** in your alert rule.
92
99
- The selected **Time granularity** is the same as the **Aggregation granularity (Period)** in your alert rule, and that it isn't set to **Automatic**.
93
100
94
-
1. If the alert fired while there are already fired alerts that monitor the same criteria that aren't resolved, check if the alert rule has been configured not to automatically resolve alerts. Such configuration causes the alert rule to become stateless, which means the alert rule doesn't auto-resolve fired alerts and doesn't require a fired alert to be resolved before firing again on the same time series.
101
+
1. If the alert fired while there are already fired alerts that monitor the same criteria that aren't resolved, check if the alert rule has been configured not to automatically resolve alerts. This means the alert rule is stateless, and doesn't auto-resolve fired alerts and doesn't require a fired alert to be resolved before firing again on the same time series.
95
102
To check if the alert rule is configured not to auto-resolve:
96
-
97
103
- Edit the alert rule in the Azure portal. See if the **Automatically resolve alerts** checkbox under the **Alert rule details** section is cleared.
98
104
- Review the script used to deploy the alert rule or retrieve the alert rule definition. Check if the `autoMitigate` property is set to `false`.
99
105
@@ -172,7 +178,7 @@ To avoid a deployment failure when you try to validate the custom metric's defin
172
178
> [!NOTE]
173
179
> Using the `skipMetricValidation` parameter might also be required when you define an alert rule on an existing custom metric that hasn't been emitted in several days.
174
180
175
-
### Warnings and errors
181
+
### Warnings and errors when configuring metric alert rules
176
182
177
183
#### Dynamic thresholds is currently not available for this metric warning
178
184
@@ -189,44 +195,20 @@ For example, in SQL Database resources or Storage file services, there are speci
189
195
190
196
This error indicates an issue with the alert rule scope. This can happen when editing an alert rule scoped to a resource type that supports multi-resource configuration (like Virtual machine or SQL database), and trying to add another resource of the same type, but from a different region. Alerting on multiple resources of the same type from different regions is not supported in Metric alerts.
191
197
192
-
## Set the alert rule's period and frequency
193
-
194
-
Choose an **Aggregation granularity (Period)** that's larger than the **Frequency of evaluation** to reduce the likelihood of missing the first evaluation of added time series in the following cases:
198
+
## The service limits for metric alert rules is too small
195
199
196
-
-**Metric alert rule that monitors multiple dimensions:** When a new dimension value combination is added.
197
-
-**Metric alert rule that monitors multiple resources:** When a new resource is added to the scope.
198
-
-**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.
199
-
200
-
## Metric alert rules quota too small
201
-
202
-
The allowed number of metric alert rules per subscription is subject to [quota limits](../service-limits.md).
200
+
The allowed number of metric alert rules per subscription is subject to [service limits](../service-limits.md).
201
+
See [Check the number of metric alert rules in use](alerts-manage-alert-rules.md#check-the-number-of-metric-alert-rules) to see how many metric alert rules are currently in use.
203
202
204
203
If you've reached the quota limit, the following steps might help resolve the issue:
205
204
206
205
1. Try deleting or disabling metric alert rules that aren't used anymore.
207
-
1. Switch to using metric alert rules that monitor multiple resources. With this capability, a single alert rule can monitor multiple resources by using only one alert rule counted against the quota. For more information about this capability and the supported resource types, see [this website](./alerts-metric-overview.md#monitoring-at-scale-using-metric-alerts-in-azure-monitor).
206
+
1. Switch to using metric alert rules that monitor multiple resources. With this capability, a single alert rule can monitor multiple resources by using only one alert rule counted against the quota. For more information about this capability and the supported resource types, see [metric-alerts](./alerts-types.md#monitor-the-same-condition-on-multiple-resources-using-splitting-by-dimensions).
208
207
1. If you need the quota limit to be increased, open a support request and provide the:
209
208
- Subscription IDs for which the quota limit needs to be increased.
210
-
- Resource type for the quota increase. Select **Metric alerts** or **Metric alerts (Classic)**.
209
+
- Resource type for the quota increase. Select **Metric alerts**.
211
210
- Requested quota limit.
212
211
213
-
### Check the total number of metric alert rules
214
-
215
-
To check the current usage of metric alert rules, follow the next steps.
216
-
#### From the Azure portal
217
-
218
-
1. Open the **Alerts** screen and select **Manage alert rules**.
219
-
1. Filter to the relevant subscription by using the **Subscription** dropdown box.
220
-
1. Make sure *not* to filter to a specific resource group, resource type, or resource.
221
-
1. In the **Signal type** dropdown box, select **Metrics**.
222
-
1. Verify that the **Status** dropdown box is set to **Enabled**.
223
-
1. The total number of metric alert rules are displayed above the alert rules list.
0 commit comments