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-resource-manager/management/control-plane-metrics.md
+78-18Lines changed: 78 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,9 @@ ms.date: 12/01/2021
8
8
# Azure Resource Manager metrics in Azure Monitor
9
9
When you create and manage resources in Azure, your requests are orchestrated through Azure's [control plane](./control-plane-and-data-plane.md), Azure Resource Manager. This article describes how to monitor the volume and latency of control plane requests made to Azure.
10
10
11
-
With these metrics, you can observe traffic and latency for control plane requests throughout your subscriptions. The metrics are available for up to three months (93 days) and only track synchronous requests. For a scenario like a VM creation, the metrics do not represent the performance or reliability of the long running asynchronous operation.
11
+
With these metrics, you can observe traffic and latency for control plane requests throughout your subscriptions. For example, you can now figure out when your requests have been throttled or failed by filtering for specific status codes. We've dug into this below in [examining throttled requests](#examining-throttled-requests) and [examining server errors](#examining-server-errors).
12
+
13
+
The metrics are available for up to three months (93 days) and only track synchronous requests. For a scenario like a VM creation, the metrics do not represent the performance or reliability of the long running asynchronous operation.
12
14
13
15
## Accessing Azure Resource Manager metrics
14
16
@@ -22,8 +24,8 @@ For guidance on how to retrieve a bearer token and make requests to Azure, see [
22
24
23
25
The definition for Azure Resource Manager metrics in Azure Monitor is only accessible through the 2017-12-01-preview API version. To retrieve the definition, you can run the following snippet, with your subscription ID replacing "00000000-0000-0000-0000-000000000000":
24
26
25
-
```c
26
-
> curl --location --request GET 'https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/providers/microsoft.insights/metricDefinitions?api-version=2017-12-01-preview&metricnamespace=microsoft.resources/subscriptions' \
27
+
```bash
28
+
curl --location --request GET 'https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/providers/microsoft.insights/metricDefinitions?api-version=2017-12-01-preview&metricnamespace=microsoft.resources/subscriptions' \
27
29
--header 'Authorization: bearer {{bearerToken}}'
28
30
```
29
31
@@ -32,14 +34,18 @@ This will return the definition for the metrics schema. Notably, this schema inc
32
34
| Dimension Name | Description |
33
35
| ------------------- | ----------------- |
34
36
|**ResourceUri**| The full Resource ID for a particular resource. |
35
-
|**RequestRegion**| The region where control plane requests originate, like "EastUS2" |
37
+
|**RequestRegion**| The Azure Resource Manager region where your control plane requests land, like "EastUS2". This is not the same as your resource's location.|
36
38
|**StatusCode**| Response type from Azure Resource Manager for your control plane request. Possible values are (but not limited to): <br/>- 0<br/>- 200<br/>- 201<br/>- 400<br/>- 404<br/>- 429<br/>- 500<br/>- 502|
37
39
|**StatusCodeClass**| The class for the status code returned from Azure Resource Manager. Possible values are: <br/>- 2xx<br/>- 4xx<br/>- 5xx|
38
40
|**Namespace**| The namespace for the Resource Provider, in all caps, like "MICROSOFT.COMPUTE"|
39
41
|**ResourceType**| Any resource type in Azure that you have created or sent a request to, in all caps, like "VIRTUALMACHINES" |
40
42
|**Method**| The HTTP method used in the request made to Azure Resource Manager. Possible values are: <br/>- GET<br/>- HEAD<br/>- PUT<br/>- POST<br/>- PATCH<br/>- DELETE|
41
43
42
-
### Example: Query traffic and latency control plane metrics via Azure portal
44
+
## Examples
45
+
46
+
Now, let's look at some scenarios that can help you exploring Azure Resource Manager metrics.
47
+
48
+
### Query traffic and latency control plane metrics via Azure portal
43
49
44
50
First, navigate to the Azure Monitor blade within the [portal](https://portal.azure.com):
45
51
@@ -53,21 +59,23 @@ Then, after selecting **Apply**, you can visualize your Traffic or Latency contr
53
59
54
60
:::image type="content" source="./media/view-arm-monitor-metrics/arm-metrics-view.png" alt-text="From the metrics visualization, you can filter and split by the dimensions you choose.":::
55
61
56
-
### Example: Query traffic and latency control plane metrics via REST API
62
+
### Query traffic and latency control plane metrics via REST API
57
63
58
-
After you are authenticated with Azure, you can make a request to retrieve control plane metrics for your subscription. In the script shared below, please replace"00000000-0000-0000-0000-000000000000" with your subscription ID:
64
+
After you are authenticated with Azure, you can make a request to retrieve control plane metrics for your subscription. In the script shared below, please replace"00000000-0000-0000-0000-000000000000" with your subscription ID.
59
65
60
-
```c
61
-
> curl --location --request GET "https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/providers/microsoft.insights/metrics?api-version=2021-05-01&interval=P1D&metricnames=Latency,Traffic&metricnamespace=microsoft.resources/subscriptions®ion=global&aggregation=average,count×pan=2021-11-01T00:00:00Z/2021-11-01T02:00:00Z" \
66
+
The request below will retrieve the average request latency (in seconds) and the total request count for the 2 day timespan, broken down by 1 day intervals:
67
+
68
+
```bash
69
+
curl --location --request GET "https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/providers/microsoft.insights/metrics?api-version=2021-05-01&interval=P1D&metricnames=Latency&metricnamespace=microsoft.resources/subscriptions®ion=global&aggregation=average,count×pan=2021-11-01T00:00:00Z/2021-11-03T00:00:00Z" \
62
70
--header "Authorization: bearer {{bearerToken}}"
63
71
```
64
72
65
-
The response for the request above would be populated with your metrics in a JSON response:
73
+
In the case of Azure Resource Manager metrics, you can actually retrieve the traffic count by simply using the Latency metric and including the 'count' aggregation. You'll see the JSON response for the request below:
@@ -86,13 +94,39 @@ The response for the request above would be populated with your metrics in a JSO
86
94
{
87
95
"timeStamp": "2021-11-01T00:00:00Z",
88
96
"count": 1406.0,
89
-
"average": 0.19345163584637265
97
+
"average": 0.19345163584637273
98
+
},
99
+
{
100
+
"timeStamp": "2021-11-02T00:00:00Z",
101
+
"count": 1517.0,
102
+
"average": 0.28294792353328935
90
103
}
91
104
]
92
105
}
93
106
],
94
107
"errorCode": "Success"
95
-
},
108
+
}
109
+
],
110
+
"namespace": "microsoft.resources/subscriptions",
111
+
"resourceregion": "global"
112
+
}
113
+
```
114
+
115
+
As seen above, you actually get the traffic count included in the Latency metric by including 'count' as part of the aggregation. If you want to retrieve only the traffic count, then you can utilize the Traffic metric with the 'count' aggregation:
116
+
117
+
```bash
118
+
curl --location --request GET 'https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/providers/microsoft.insights/metrics?api-version=2021-05-01&interval=P1D&metricnames=Traffic&metricnamespace=microsoft.resources/subscriptions®ion=global&aggregation=count×pan=2021-11-01T00:00:00Z/2021-11-03T00:00:00Z' \
119
+
--header 'Authorization: bearer {{bearerToken}}'
120
+
```
121
+
122
+
The response for this will look similar but notice the **only** difference is in the *unit* property:
@@ -108,8 +142,11 @@ The response for the request above would be populated with your metrics in a JSO
108
142
"data": [
109
143
{
110
144
"timeStamp": "2021-11-01T00:00:00Z",
111
-
"count": 1406.0,
112
-
"average": 0.19345163584637276
145
+
"count": 1406.0
146
+
},
147
+
{
148
+
"timeStamp": "2021-11-02T00:00:00Z",
149
+
"count": 1517.0
113
150
}
114
151
]
115
152
}
@@ -122,10 +159,33 @@ The response for the request above would be populated with your metrics in a JSO
122
159
}
123
160
```
124
161
125
-
For the metrics supporting dimensions, you need to specify the dimension value to see the corresponding metrics values. For example, if you want to use **Latency** value for successful requests to ARM, you need to filter the **StatusCodeClass** dimension with **2XX**.
162
+
For the metrics supporting dimensions, you need to specify the dimension value to see the corresponding metrics values. For example, if you want to focus on the **Latency** for successful requests to ARM, you need to filter the **StatusCodeClass** dimension with **2XX**.
126
163
127
-
Similarly with **Traffic**, you would need to filter the **Namespace** dimension for **MICROSOFT.NETWORK** if you want to look at the number of requests made in your subscription for Networking resources, like Virtual Networks and Load Balancers.
164
+
If you want to look at the number of requests made in your subscription for Networking resources, like Virtual Networks and Load Balancers, you would need to filter the **Namespace** dimension for **MICROSOFT.NETWORK**.
165
+
166
+
### Examining Throttled Requests
167
+
168
+
To view only your throttled requests, you need to filter for 429 status code responses only. For REST API calls, this is accomplished via the [$filter property](/rest/api/monitor/Metrics/List#uri-parameters) and the StatusCode dimension by appending: $filter=StatusCode eq '429' as seen at the end of the request in the following snippet:
169
+
170
+
```bash
171
+
curl --location --request GET 'https://management.azure.com/subscriptions/dff2e75b-8fe7-4dc7-8360-9247be413c9b/providers/microsoft.insights/metrics?api-version=2021-05-01&interval=P1D&metricnames=Latency&metricnamespace=microsoft.resources/subscriptions®ion=global&aggregation=count,average×pan=2021-11-01T00:00:00Z/2021-11-03T00:00:00Z&$filter=StatusCode%20eq%20%27429%27' \
172
+
--header 'Authorization: bearer {{bearerToken}}'
173
+
```
174
+
175
+
You can also do this directly in portal:
176
+
:::image type="content" source="./media/view-arm-monitor-metrics/throttling-filter-portal.png" alt-text="Filter HTTP Status Code to 429 responses only":::
177
+
178
+
179
+
### Examining Server Errors
180
+
181
+
Similar to looking at throttled requests, you view *all* requests that returned a server error response code by filtering 5xx responses only. For REST API calls, this is accomplished via the [$filter property](/rest/api/monitor/Metrics/List#uri-parameters) and the StatusCodeClass dimension by appending: $filter=StatusCodeClass eq '5xx' as seen at the end of the request in the following snippet:
182
+
183
+
```bash
184
+
curl --location --request GET 'https://management.azure.com/subscriptions/dff2e75b-8fe7-4dc7-8360-9247be413c9b/providers/microsoft.insights/metrics?api-version=2021-05-01&interval=P1D&metricnames=Latency&metricnamespace=microsoft.resources/subscriptions®ion=global&aggregation=count,average×pan=2021-11-01T00:00:00Z/2021-11-03T00:00:00Z&$filter=StatusCodeClass%20eq%20%275xx%27' \
185
+
--header 'Authorization: bearer {{bearerToken}}'
186
+
```
128
187
188
+
You can also accomplish generic server errors filtering within portal by setting the filter property to 'StatusCodeClass' and the value to '5xx', similar to what was in the throttling example above.
0 commit comments