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-common-schema-definitions.md
+27-11Lines changed: 27 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
title: Alert schema definitions in Azure Monitor
3
-
description: Understanding the common alert schema definitions for Azure Monitor
3
+
description: This article explains the common alert schema definitions for Azure Monitor.
4
4
author: ofirmanor
5
5
ms.topic: conceptual
6
6
ms.date: 07/20/2021
@@ -9,13 +9,15 @@ ms.reviewer: ofmanor
9
9
10
10
# Common alert schema definitions
11
11
12
-
This article describes the [common alert schema definitions](./alerts-common-schema.md) for Azure Monitor, including those for webhooks, Azure Logic Apps, Azure Functions, and Azure Automation runbooks.
12
+
This article describes the [common alert schema definitions](./alerts-common-schema.md) for Azure Monitor. It includes the definitions for webhooks, Azure Logic Apps, Azure Functions, and Azure Automation runbooks.
13
13
14
14
Any alert instance describes the resource that was affected and the cause of the alert. These instances are described in the common schema in the following sections:
15
-
***Essentials**: A set of standardized fields, common across all alert types, which describe what resource the alert is on, along with additional common alert metadata (for example, severity or description).
16
-
***Alert context**: A set of fields that describes the cause of the alert, with fields that vary based on the alert type. For example, a metric alert includes fields like the metric name and metric value in the alert context, whereas an activity log alert has information about the event that generated the alert.
15
+
16
+
***Essentials**: A set of standardized fields that are common across all alert types. Fields describe what resource the alert is on, along with other common alert metadata. Examples are severity or description.
17
+
***Alert context**: A set of fields that describe the cause of the alert. Fields vary based on the alert type. For example, a metric alert includes fields like the metric name and metric value in the alert context. An activity log alert has information about the event that generated the alert.
17
18
18
19
**Sample alert payload**
20
+
19
21
```json
20
22
{
21
23
"schemaId": "azureMonitorCommonAlertSchema",
@@ -71,14 +73,14 @@ Any alert instance describes the resource that was affected and the cause of the
71
73
72
74
| Field | Description|
73
75
|:---|:---|
74
-
| alertId | The unique resource ID identifying the alert instance. |
76
+
| alertId | The unique resource ID that identifies the alert instance. |
75
77
| alertRule | The name of the alert rule that generated the alert instance. |
76
-
| Severity | The severity of the alert. Possible values: Sev0, Sev1, Sev2, Sev3, or Sev4. |
77
-
| signalType | Identifies the signal on which the alert rule was defined. Possible values: Metric, Log, or Activity Log. |
78
+
| Severity | The severity of the alert. Possible values are Sev0, Sev1, Sev2, Sev3, or Sev4. |
79
+
| signalType | Identifies the signal on which the alert rule was defined. Possible values are Metric, Log, or Activity Log. |
78
80
| monitorCondition | When an alert fires, the alert's monitor condition is set to **Fired**. When the underlying condition that caused the alert to fire clears, the monitor condition is set to **Resolved**. |
79
81
| monitoringService | The monitoring service or solution that generated the alert. The fields for the alert context are dictated by the monitoring service. |
80
82
| alertTargetIds | The list of the Azure Resource Manager IDs that are affected targets of an alert. For a log alert defined on a Log Analytics workspace or Application Insights instance, it's the respective workspace or application. |
81
-
| configurationItems |The list of affected resources of an alert.<br>In some cases, the configuration items can be different from the alert targets. For example, in metric-for-log or log alerts defined on a Log Analytics workspace, the configuration items are the actual resources sending the telemetry, and not the workspace.<br><ul><li>In the log alerts API (Scheduled Query Rules) v2021-08-01, the configurationItem values are taken from explicitly defined dimensions in this priority: 'Computer', '_ResourceId', 'ResourceId', 'Resource'.</li><li>In earlier versions of the log alerts API, the configurationItem values are taken implicitly from the results in this priority: 'Computer', '_ResourceId', 'ResourceId', 'Resource'.</li></ul>In ITSM systems, the configurationItems field is used to correlate alerts to resources in a CMDB. |
83
+
| configurationItems |The list of affected resources of an alert.<br>In some cases, the configuration items can be different from the alert targets. For example, in metric-for-log or log alerts defined on a Log Analytics workspace, the configuration items are the actual resources sending the telemetry and not the workspace.<br><ul><li>In the log alerts API (Scheduled Query Rules) v2021-08-01, the `configurationItem` values are taken from explicitly defined dimensions in this priority: `Computer`, `_ResourceId`, `ResourceId`, `Resource`.</li><li>In earlier versions of the log alerts API, the `configurationItem` values are taken implicitly from the results in this priority: `Computer`, `_ResourceId`, `ResourceId`, `Resource`.</li></ul>In ITSM systems, the `configurationItems` field is used to correlate alerts to resources in a configuration management database. |
82
84
| originAlertId | The ID of the alert instance, as generated by the monitoring service generating it. |
83
85
| firedDateTime | The date and time when the alert instance was fired in Coordinated Universal Time (UTC). |
84
86
| resolvedDateTime | The date and time when the monitor condition for the alert instance is set to **Resolved** in UTC. Currently only applicable for metric alerts.|
@@ -87,6 +89,7 @@ Any alert instance describes the resource that was affected and the cause of the
87
89
|alertContextVersion | The version number for the `alertContext` section. |
88
90
89
91
**Sample values**
92
+
90
93
```json
91
94
{
92
95
"essentials": {
@@ -110,11 +113,14 @@ Any alert instance describes the resource that was affected and the cause of the
110
113
111
114
## Alert context
112
115
116
+
The following fields describe the cause of an alert.
117
+
113
118
### Metric alerts - Static threshold
114
119
115
120
#### `monitoringService` = `Platform`
116
121
117
122
**Sample values**
123
+
118
124
```json
119
125
{
120
126
"alertContext": {
@@ -150,6 +156,7 @@ Any alert instance describes the resource that was affected and the cause of the
150
156
#### `monitoringService` = `Platform`
151
157
152
158
**Sample values**
159
+
153
160
```json
154
161
{
155
162
"alertContext": {
@@ -186,6 +193,7 @@ Any alert instance describes the resource that was affected and the cause of the
186
193
#### `monitoringService` = `Platform`
187
194
188
195
**Sample values**
196
+
189
197
```json
190
198
{
191
199
"alertContext": {
@@ -215,11 +223,12 @@ Any alert instance describes the resource that was affected and the cause of the
215
223
### Log alerts
216
224
217
225
> [!NOTE]
218
-
> For log alerts that have a custom email subject and/or JSON payload defined, enabling the common schema reverts email subject and/or payload schema to the one described as follows. This means that if you want to have a custom JSON payload defined, the webhook cannot use the common alert schema. Alerts with the common schema enabled have an upper size limit of 256 KB per alert. Search results aren't embedded in the log alerts payload if they cause the alert size to cross this threshold. You can determine this by checking the flag `IncludedSearchResults`. When the search results aren't included, you should use the`LinkToFilteredSearchResultsAPI` or `LinkToSearchResultsAPI` to access query results with the [Log Analytics API](/rest/api/loganalytics/dataaccess/query/get).
226
+
> For log alerts that have a custom email subject and/or JSON payload defined, enabling the common schema reverts email subject and/or payload schema to the one described as follows. This means that if you want to have a custom JSON payload defined, the webhook can't use the common alert schema. Alerts with the common schema enabled have an upper size limit of 256 KB per alert. Search results aren't embedded in the log alerts payload if they cause the alert size to cross this threshold. You can determine this by checking the flag `IncludedSearchResults`. When the search results aren't included, use `LinkToFilteredSearchResultsAPI` or `LinkToSearchResultsAPI` to access query results with the [Log Analytics API](/rest/api/loganalytics/dataaccess/query/get).
219
227
220
228
#### `monitoringService` = `Log Analytics`
221
229
222
230
**Sample values**
231
+
223
232
```json
224
233
{
225
234
"alertContext": {
@@ -296,6 +305,7 @@ Any alert instance describes the resource that was affected and the cause of the
296
305
#### `monitoringService` = `Application Insights`
297
306
298
307
**Sample values**
308
+
299
309
```json
300
310
{
301
311
"alertContext": {
@@ -368,9 +378,10 @@ Any alert instance describes the resource that was affected and the cause of the
368
378
#### `monitoringService` = `Log Alerts V2`
369
379
370
380
> [!NOTE]
371
-
> Log alerts rules from API version 2020-05-01 use this payload type, which only supports common schema. Search results aren't embedded in the log alerts payload when using this version. You should use [dimensions](./alerts-unified-log.md#split-by-alert-dimensions) to provide context to fired alerts. You can also use the `LinkToFilteredSearchResultsAPI` or `LinkToSearchResultsAPI` to access query results with the [Log Analytics API](/rest/api/loganalytics/dataaccess/query/get). If you must embed the results, use a logic app with the provided links the generate a custom payload.
381
+
> Log alerts rules from API version 2020-05-01 use this payload type, which only supports common schema. Search results aren't embedded in the log alerts payload when you use this version. Use [dimensions](./alerts-unified-log.md#split-by-alert-dimensions) to provide context to fired alerts. You can also use `LinkToFilteredSearchResultsAPI` or `LinkToSearchResultsAPI` to access query results with the [Log Analytics API](/rest/api/loganalytics/dataaccess/query/get). If you must embed the results, use a logic app with the provided links to generate a custom payload.
372
382
373
383
**Sample values**
384
+
374
385
```json
375
386
{
376
387
"alertContext": {
@@ -418,6 +429,7 @@ Any alert instance describes the resource that was affected and the cause of the
0 commit comments