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/best-practices-cost.md
+8-36Lines changed: 8 additions & 36 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,82 +4,54 @@ description: Recommendations for reducing costs in Azure Monitor.
4
4
ms.topic: conceptual
5
5
author: bwren
6
6
ms.author: bwren
7
-
ms.date: 08/03/2023
7
+
ms.date: 03/12/2024
8
8
ms.reviewer: bwren
9
9
---
10
10
11
11
# Cost optimization in Azure Monitor
12
+
12
13
Cost optimization refers to ways to reduce unnecessary expenses and improve operational efficiencies. You can significantly reduce your cost for Azure Monitor by understanding your different configuration options and opportunities to reduce the amount of data that it collects. Before you use this article, you should see [Azure Monitor cost and usage](cost-usage.md) to understand the different ways that Azure Monitor charges and how to view your monthly bill.
13
14
14
-
This article describes [Cost optimization](/azure/architecture/framework/cost/) for Azure Monitor as part of the [Azure Well-Architected Framework](/azure/architecture/framework/). This is a set of guiding tenets that can be used to improve the quality of a workload. The framework consists of five pillars of architectural excellence:
15
+
This article describes [Cost optimization](/azure/architecture/framework/cost/) for Azure Monitor as part of the [Azure Well-Architected Framework](/azure/architecture/framework/). The Azure Well-Architected Framework is a set of guiding tenets that can be used to improve the quality of a workload. The framework consists of five pillars of architectural excellence:
> - Collect only critical resource log data from Azure resources.
35
33
36
-
37
34
### Configuration recommendations
38
35
39
36
| Recommendation | Benefit |
40
37
|:---|:---|
41
-
| Collect only critical resource log data from Azure resources. | When you create [diagnostic settings](essentials/diagnostic-settings.md) to send [resource logs](essentials/resource-logs.md) for your Azure resources to a Log Analytics database, only specify those categories that you require. Since diagnostic settings don't allow granular filtering of resource logs, you can use a [workspace transformation](essentials/data-collection-transformations.md?#workspace-transformation-dcr) to further filter unneeded data for those resources that use a [supported table](logs/tables-feature-support.md). See [Diagnostic settings in Azure Monitor](essentials/diagnostic-settings.md#controlling-costs) for details on how to configure diagnostic settings and using transformations to filter their data. |
38
+
| Collect only critical resource log data from Azure resources. | When you create [diagnostic settings](essentials/diagnostic-settings.md) to send [resource logs](essentials/resource-logs.md) for your Azure resources to a Log Analytics database, only specify those categories that you require. Since diagnostic settings don't allow granular filtering of resource logs, you can use a [workspace transformation](essentials/data-collection-transformations.md?#workspace-transformation-dcr) to filter unneeded data for those resources that use a [supported table](logs/tables-feature-support.md). See [Diagnostic settings in Azure Monitor](essentials/diagnostic-settings.md#controlling-costs) for details on how to configure diagnostic settings and using transformations to filter their data. |
> - Change to Workspace-based Application Insights.
65
-
> - Use sampling to tune the amount of data collected.
66
-
> - Limit the number of Ajax calls.
67
-
> - Disable unneeded modules.
68
-
> - Pre-aggregate metrics from any calls to TrackMetric.
69
-
> - Limit the use of custom metrics.
70
-
> - Ensure use of updated SDKs.
71
-
72
-
### Configuration recommendations
73
-
74
-
| Recommendation | Benefit |
75
-
|:---|:---|
76
-
| Change to Workspace-based Application Insights | Ensure that your Application Insights resources are [Workspace-based](app/create-workspace-resource.md) so that they can leverage new cost savings tools such as [Basic Logs](logs/basic-logs-configure.md), [Commitment Tiers](logs/cost-logs.md#commitment-tiers), [Retention by data type and Data Archive](logs/data-retention-archive.md#configure-retention-and-archive-at-the-table-level). |
77
-
| Use sampling to tune the amount of data collected. |[Sampling](app/sampling.md) is the primary tool you can use to tune the amount of data collected by Application Insights. Use sampling to reduce the amount of telemetry that's sent from your applications with minimal distortion of metrics. |
78
-
| Limit the number of Ajax calls. |[Limit the number of Ajax calls](app/javascript.md#configuration) that can be reported in every page view or disable Ajax reporting. If you disable Ajax calls, you'll be disabling [JavaScript correlation](app/javascript.md#enable-distributed-tracing) too. |
79
-
| Disable unneeded modules. |[Edit ApplicationInsights.config](app/configuration-with-applicationinsights-config.md) to turn off collection modules that you don't need. For example, you might decide that performance counters or dependency data aren't required. |
80
-
| Pre-aggregate metrics from any calls to TrackMetric. | If you put calls to TrackMetric in your application, you can reduce traffic by using the overload that accepts your calculation of the average and standard deviation of a batch of measurements. Alternatively, you can use a [pre-aggregating package](https://www.myget.org/gallery/applicationinsights-sdk-labs). |
81
-
| Limit the use of custom metrics. | The Application Insights option to [Enable alerting on custom metric dimensions](app/pre-aggregated-metrics-log-metrics.md#custom-metrics-dimensions-and-pre-aggregation) can increase costs. Using this option can result in the creation of more pre-aggregation metrics. |
82
-
| Ensure use of updated SDKs. | Earlier versions of the ASP.NET Core SDK and Worker Service SDK [collect many counters by default](app/eventcounters.md#default-counters-collected), which were collected as custom metrics. Use later versions to specify [only required counters](app/eventcounters.md#customizing-counters-to-be-collected). |
@@ -89,7 +61,7 @@ This section provides answers to common questions.
89
61
90
62
Yes, for experimental use. In the basic pricing plan, your application can send a certain allowance of data each month free of charge. The free allowance is large enough to cover development and publishing an app for a few users. You can set a cap to prevent more than a specified amount of data from being processed.
91
63
92
-
Larger volumes of telemetry are charged by the gigabyte. We provide some tips on how to [limit your charges](#application-insights).
64
+
Larger volumes of telemetry are charged per gigabyte. We provide some tips on how to [limit your charges](#application-insights).
93
65
94
66
The Enterprise plan incurs a charge for each day that each web server node sends telemetry. It's suitable if you want to use Continuous Export on a large scale.
95
67
@@ -111,9 +83,9 @@ Read the [pricing plan](https://azure.microsoft.com/pricing/details/application-
111
83
112
84
This answer depends on the distribution of our endpoints, *not* on where your Application Insights resource is hosted.
113
85
114
-
### Will I incur network costs if my Application Insights resource is monitoring an Azure resource (i.e., telemetry producer) in a different region?
86
+
### Do I incur network costs if my Application Insights resource is monitoring an Azure resource (that is, telemetry producer) in a different region?
115
87
116
-
Yes, you may incur additional network costs which will vary depending on the region the telemetry is coming from and where it is going. Refer to [Azure bandwidth pricing](https://azure.microsoft.com/pricing/details/bandwidth/) for details.
88
+
Yes, you may incur more network costs, which vary depending on the region the telemetry is coming from and where it's going. Refer to [Azure bandwidth pricing](https://azure.microsoft.com/pricing/details/bandwidth/) for details.
> - Change to workspace-based Application Insights.
13
+
> - Use sampling to tune the amount of data collected.
14
+
> - Limit the number of Ajax calls.
15
+
> - Disable unneeded modules.
16
+
> - Preaggregate metrics from any calls to TrackMetric.
17
+
> - Limit the use of custom metrics where possible.
18
+
> - Ensure use of updated software development kits (SDKs).
19
+
> - Limit unwanted host trace and general trace logging using log levels.
20
+
21
+
### Configuration recommendations
22
+
23
+
| Recommendation | Benefit |
24
+
|:---------------|:--------|
25
+
| Change to workspace-based Application Insights. | Ensure that your Application Insights resources are [workspace-based](../app/create-workspace-resource.md). Workspace-based Application Insights resources can apply new cost savings tools such as [Basic Logs](../logs/basic-logs-configure.md), [commitment tiers](../logs/cost-logs.md#commitment-tiers), and [retention by data type and data archive](../logs/data-retention-archive.md#configure-retention-and-archive-at-the-table-level). |
26
+
| Use sampling to tune the amount of data collected. |[Sampling](../app/sampling.md) is the primary tool you can use to tune the amount of data collected by Application Insights. Use sampling to reduce the amount of telemetry sent from your applications with minimal distortion of metrics. |
27
+
| Limit the number of Ajax calls. |[Limit the number of Ajax calls](../app/javascript.md#configuration) that can be reported in every page view or disable Ajax reporting. If you disable Ajax calls, you also disable [JavaScript correlation](../app/javascript.md#enable-distributed-tracing). |
28
+
| Disable unneeded modules. |[Edit ApplicationInsights.config](../app/configuration-with-applicationinsights-config.md) to turn off collection modules that you don't need. For example, you might decide that performance counters or dependency data aren't required. |
29
+
| Preaggregate metrics from any calls to TrackMetric. | If you put calls to TrackMetric in your application, you can reduce traffic by using the overload that accepts your calculation of the average and standard deviation of a batch of measurements. Alternatively, you can use a [preaggregating package](https://www.myget.org/gallery/applicationinsights-sdk-labs). |
30
+
| Limit the use of custom metrics. | The Application Insights option to [Enable alerting on custom metric dimensions](../app/pre-aggregated-metrics-log-metrics.md#custom-metrics-dimensions-and-pre-aggregation) can increase costs. Using this option can result in the creation of more preaggregation metrics. |
31
+
| Ensure use of updated software development kits (SDKs). | Earlier versions of the ASP.NET Core SDK and Worker Service SDK [collect many counters by default](../app/eventcounters.md#default-counters-collected), which were collected as custom metrics. Use later versions to specify [only required counters](../app/eventcounters.md#customizing-counters-to-be-collected). |
32
+
| Limit unwanted trace logging. | Application Insights has several possible [log sources](../app/app-insights-overview.md#logging-frameworks). Log levels can be used to tune and reduce trace log telemetry. Logging can also apply to the host. For example, customers using Azure Kubernetes Service (AKS) should adjust [control plane and data plane logs](../../aks/monitor-aks.md#logs). Similarly, customers using Azure functions should [adapt log levels and scope](../../azure-functions/configure-monitoring.md) to optimize log volume and costs. |
0 commit comments