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/app/tutorial-asp-net-custom-metrics.md
+11-5Lines changed: 11 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ ms.reviewer: casocha
11
11
12
12
In this article, you'll learn how to capture custom metrics with Application Insights in .NET and .NET Core apps.
13
13
14
-
Insert a few lines of code in your application to find out what users are doing with it or to help diagnose issues. You can send telemetry from device apps, desktop apps, web clients, and web servers. Use the [Application Insights](./app-insights-overview.md) core telemetry API to send custom events and metrics and your own versions of standard telemetry. This API is the same API that the standard Application Insights data collectors use.
14
+
Insert a few lines of code in your application to find out what users are doing with it or to help diagnose issues. You can send telemetry from device and desktop apps, web clients, and web servers. Use the [Application Insights](./app-insights-overview.md) core telemetry API to send custom events and metrics and your own versions of standard telemetry. This API is the same API that the standard Application Insights data collectors use.
15
15
16
16
## ASP.NET Core applications
17
17
@@ -34,9 +34,9 @@ The Application Insights .NET and .NET Core SDKs have two different methods for
34
34
35
35
#### Pre-aggregating vs non pre-aggregating API
36
36
37
-
`TrackMetric()` sends raw telemetry that denotes a metric. `TrackMetric()` is inefficient because it sends a single telemetry item for each value. `TrackMetric()` is also inefficient in terms of performance since every `TrackMetric(item)` goes through the full SDK pipeline of telemetry initializers and processors.
37
+
`TrackMetric()` sends raw telemetry that denotes a metric. `TrackMetric()` is inefficient because it sends a single telemetry item for each value. `TrackMetric()` is also inefficient in terms of performance because every `TrackMetric(item)` goes through the full SDK pipeline of telemetry initializers and processors.
38
38
39
-
Unlike `TrackMetric()`, `GetMetric()` handles local pre-aggregation for you and then only submits an aggregated summary metric at a fixed interval of one minute. If you need to closely monitor some custom metric at the second or even millisecond level, you can use `GetMetric()` to do so while only incurring the storage and network traffic cost of only monitoring every minute. This behavior also greatly reduces the risk of throttling from occurring because the total number of telemetry items that need to be sent for an aggregated metric are greatly reduced.
39
+
Unlike `TrackMetric()`, `GetMetric()` handles local pre-aggregation for you and then only submits an aggregated summary metric at a fixed interval of one minute. If you need to closely monitor some custom metric at the second or even millisecond level, you can use `GetMetric()` to do so while only incurring the storage and network traffic cost of only monitoring every minute. This behavior also greatly reduces the risk of throttling occurring because the total number of telemetry items that need to be sent for an aggregated metric are greatly reduced.
40
40
41
41
In Application Insights, custom metrics collected via `TrackMetric()` and `GetMetric()` aren't subject to [sampling](./sampling.md). Sampling important metrics can lead to scenarios where the alerting you may have built around these metrics could become unreliable. By never sampling your custom metrics, you can generally be confident that when your alert thresholds are breached, an alert will fire. Because custom metrics aren't sampled, there are some potential concerns, which are described below.
42
42
@@ -249,7 +249,13 @@ By default, multi-dimensional metrics within the Metric explorer experience aren
249
249
250
250
### Enable multi-dimensional metrics
251
251
252
-
To enable multi-dimensional metrics for an Application Insights resource, Select **Usage and estimated costs** > **Custom Metrics** > **Send custom metrics to Azure Metric Store (With dimensions)** > **OK**.
252
+
This section walks through enabling multi-dimensional metrics for an Application Insights resource.
253
+
254
+
1. In the [Azure portal](https://portal.azure.com), select the **Application Insights** resource.
255
+
1. Select **Usage and estimated costs**.
256
+
1. Select **Custom Metrics**.
257
+
1. Select **Send custom metrics to Azure Metric Store (With dimensions)**.
258
+
1. Select **OK**.
253
259
254
260
After you enable multi-dimensional metrics for an Application Insights resource and send new multi-dimensional telemetry, you can split a metric by dimension.
255
261
@@ -344,7 +350,7 @@ After you enable multi-dimensional metrics for an Application Insights resource
0 commit comments