Edit

Share via

Metrics in Application Insights

Application Insights supports three different types of metrics: standard (preaggregated), log-based, and custom metrics. Each one brings a unique value in monitoring application health, diagnostics, and analytics. Developers who are instrumenting applications can decide which type of metric is best suited to a particular scenario. Decisions are based on the size of the application, expected volume of telemetry, and business requirements for metrics precision and alerting. This article explains the difference between all supported metrics types.

Standard metrics

Application Insights collects and monitors standard metrics automatically. These predefined metrics cover a wide range of performance and usage indicators, such as CPU usage, memory consumption, request rates, and response times. You don't need to configure anything to start using them. During collection, the service preaggregates standard metrics and stores them as a time series in a specialized repository with only key dimensions. This design improves query performance. Because of their speed and structure, standard metrics work best for near real-time alerting and responsive dashboards.

Log-based metrics

Log-based metrics in Application Insights are a query-time concept. The system represents them as time series built from your application's log data. It doesn't preaggregate the underlying logs during collection or storage. Instead, it retains all properties of each log entry.

This retention allows you to use log properties as dimensions when querying log-based metrics. You can apply metric chart filtering and metric splitting, which gives these metrics strong analytical and diagnostic value.

However, telemetry volume reduction techniques affect log-based metrics. Techniques like sampling and telemetry filtering, often used to reduce data from high-volume applications, reduce the number of collected log entries. This reduction lowers the accuracy of log-based metrics.

Custom metrics (preview)

Custom metrics in Application Insights allow you to define and track specific measurements that are unique to your application. These metrics can be created by instrumenting your code to send custom telemetry data to Application Insights. Custom metrics provide the flexibility to monitor any aspect of your application that isn't covered by standard metrics, enabling you to gain deeper insights into your application's behavior and performance.

For more information, see Custom metrics in Azure Monitor (preview).

Note

Application Insights also provides a feature called Live Metrics stream, which allows for near real-time monitoring of your web applications and doesn't store any telemetry data.

Metrics comparison

Feature Standard metrics Log-based metrics Custom metrics
Data source Preaggregated time series data collected during runtime. Derived from log data using Kusto queries. User-defined metrics collected via the Application Insights SDK or API.
Granularity Fixed intervals (1 minute). Depends on the granularity of the log data itself. Flexible granularity based on user-defined metrics.
Accuracy High, not affected by log sampling. Can be affected by sampling and filtering. High accuracy, especially when using preaggregated methods like GetMetric.
Cost Included in Application Insights pricing. Based on log data ingestion and query costs. See Pricing model and retention.
Configuration Automatically available with minimal configuration. Require configuration of log queries to extract the desired metrics from log data. Requires custom implementation and configuration in code.
Query performance Fast, due to preaggregation. Slower, as it involves querying log data. Depends on data volume and query complexity.
Storage Stored as time series data in the Azure Monitor metrics store. Stored as logs in Log Analytics workspace. Stored in both Log Analytics and the Azure Monitor metrics store.
Alerting Supports real-time alerting. Allows for complex alerting scenarios based on detailed log data. Flexible alerting based on user-defined metrics.
Service limit Subject to Application Insights limits. Subject to Log Analytics workspace limits. Limited by the quota for free metrics and the cost for extra dimensions.
Use cases Real-time monitoring, performance dashboards, and quick insights. Detailed diagnostics, troubleshooting, and in-depth analysis. Tailored performance indicators and business-specific metrics.
Examples CPU usage, memory usage, request duration. Request counts, exception traces, dependency calls. Custom application-specific metrics like user engagement, feature usages.

Metrics preaggregation

OpenTelemetry SDKs and some Application Insights SDKs (Classic API) preaggregate metrics during collection to reduce the volume of data sent from the SDK to the telemetry channel endpoint. This process applies to standard metrics sent by default, so the accuracy isn't affected by sampling or filtering. It also applies to custom metrics sent using the OpenTelemetry API or GetMetric and TrackValue, which results in less data ingestion and lower cost. If your version of the Application Insights SDK supports GetMetric and TrackValue, it's the preferred method of sending custom metrics.

Some SDKs don't implement preaggregation. Examples include older versions of the Application Insights SDK and browser-based instrumentation. In these cases, the back end creates the new metrics by aggregating the events received through the telemetry channel.

To send custom metrics, use the trackMetric method.

These SDKs don't reduce the volume of data sent. However, you can still use the preaggregated metrics they produce. This setup gives you better performance and supports near real-time dimensional alerting, even without preaggregation during collection.

The telemetry channel endpoint preaggregates events before ingestion sampling. For this reason, ingestion sampling never affects the accuracy of preaggregated metrics, regardless of the SDK version you use with your application.

The following tables list where preaggregation are preaggregated.

Metrics preaggregation with Azure Monitor OpenTelemetry Distro

Current production SDK Standard metrics preaggregation Custom metrics preaggregation
ASP.NET Core SDK SDK via OpenTelemetry API
.NET (via Exporter) SDK SDK via OpenTelemetry API
Java (3.x) SDK SDK via OpenTelemetry API
Java native SDK SDK via OpenTelemetry API
Node.js SDK SDK via OpenTelemetry API
Python SDK SDK via OpenTelemetry API

Metrics preaggregation with Application Insights SDK (Classic API)

Current production SDK Standard metrics preaggregation Custom metrics preaggregation
.NET Core and .NET Framework SDK (V2.13.1+) SDK (V2.7.2+) via GetMetric
Telemetry channel endpoint via TrackMetric
Java (2.x) Telemetry channel endpoint Telemetry channel endpoint via TrackMetric
JavaScript (Browser) Telemetry channel endpoint Telemetry channel endpoint via TrackMetric
Node.js Telemetry channel endpoint Telemetry channel endpoint via TrackMetric
Python Telemetry channel endpoint SDK via OpenCensus.stats (retired)
Telemetry channel endpoint via TrackMetric

Caution

Metrics preaggregation with autoinstrumentation

With autoinstrumentation, the SDK is automatically added to your application code and can't be customized. For custom metrics, manual instrumentation is required.

Current production SDK Standard metrics preaggregation Custom metrics preaggregation
ASP.NET Core SDK 1 Not supported
ASP.NET SDK 2 Not supported
Java SDK Supported 3
Node.js SDK Not supported
Python SDK Not supported

Footnotes

Custom metrics dimensions and preaggregation

All metrics that you send using OpenTelemetry, trackMetric, or GetMetric and TrackValue API calls are automatically stored in both the metrics store and logs. These metrics can be found in the customMetrics table in Application Insights and in Metrics Explorer under the Custom Metric Namespace called azure.applicationinsights. Although the log-based version of your custom metric always retains all dimensions, the preaggregated version of the metric is stored by default with no dimensions. Retaining dimensions of custom metrics is a Preview feature that can be turned on from the Usage and estimated cost tab by selecting With dimensions under Send custom metrics to Azure Metric Store.

Screenshot that shows usage and estimated costs.

Quotas

Preaggregated metrics are stored as time series in Azure Monitor. Azure Monitor quotas on custom metrics apply.

Note

Going over the quota might have unintended consequences. Azure Monitor might become unreliable in your subscription or region. To learn how to avoid exceeding the quota, see Design limitations and considerations.

Why is collection of custom metrics dimensions turned off by default?

Application Insights turns off the collection of custom metric dimensions by default. Storing custom metrics with dimensions incurs separate billing from Application Insights. Storing nondimensional custom metrics remains free, up to a quota. For details, see the Azure Monitor pricing page.

Create charts and explore metrics

Use Azure Monitor metrics explorer to plot charts from preaggregated, log-based, and custom metrics, and to author dashboards with charts. After you select the Application Insights resource you want, use the namespace picker to switch between metrics.

Screenshot that shows Metric namespace.

Pricing models for Application Insights metrics

Ingesting metrics into Application Insights, whether log-based or preaggregated, generates costs based on the size of the ingested data. For more information, see Azure Monitor Logs pricing details. Your custom metrics, including all its dimensions, are always stored in the Application Insights log store. Also, a preaggregated version of your custom metrics with no dimensions is forwarded to the metrics store by default.

Selecting the Enable alerting on custom metric dimensions option to store all dimensions of the preaggregated metrics in the metric store can result in increased charges based on custom metrics pricing.

Available metrics

The following sections list metrics with supported aggregations and dimensions. The details about log-based metrics include the underlying Kusto query statements.

Important

  • Time Series Limit: Each metric can only have up to 5,000 time series within 24 hours. Once this limit is reached, all dimension values of that metric point are replaced with the constant Maximum values reached.

  • Cardinality limit: Each dimension supports a limited number of unique values within a seven-day period. When the limit is reached, Azure Monitor replaces all new values with the constant Other values. The following tables list the cardinality limit for each dimension.

Availability metrics

Metrics in the Availability category enable you to see the health of your web application as observed from points around the world. Configure the availability tests to start using any metrics from this category.

Availability (availabilityResults/availabilityPercentage)

The Availability metric shows the percentage of the web test runs that didn't detect any issues. The lowest possible value is 0, which indicates that all of the web test runs failed. The value of 100 means that all of the web test runs passed the validation criteria.

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Percentage Avg Run ___location availabilityResult/___location 50
Test name availabilityResult/name 100

Availability test duration (availabilityResults/duration)

The Availability test duration metric shows how much time it took for the web test to run. For the multi-step web tests, the metric reflects the total execution time of all steps.

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Milliseconds Avg, Max, Min Run ___location availabilityResult/___location 50
Test name availabilityResult/name 100
Test result availabilityResult/success 2

Availability tests (availabilityResults/count)

The Availability tests metric reflects the count of the web tests runs by Azure Monitor.

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Count Count Run ___location availabilityResult/___location 50
Test name availabilityResult/name 100
Test result availabilityResult/success 2

Browser metrics

The Application Insights JavaScript SDK collects browser metrics from real end-user browsers. These metrics give you valuable insights into your users' experience with your web app. The SDK typically doesn't sample browser metrics, so they offer higher precision in usage numbers. In contrast, server-side metrics often use sampling, which can skew results.

Note

To collect browser metrics, your application must be instrumented with the Application Insights JavaScript SDK.

Browser page load time (browserTimings/totalDuration)

Unit of measure Supported aggregations Supported dimensions
Milliseconds Avg, Max, Min None

Client processing time (browserTiming/processingDuration)

Unit of measure Supported aggregations Supported dimensions
Milliseconds Avg, Max, Min None

Page load network connect time (browserTimings/networkDuration)

Unit of measure Supported aggregations Supported dimensions
Milliseconds Avg, Max, Min None

Receiving response time (browserTimings/receiveDuration)

Unit of measure Supported aggregations Supported dimensions
Milliseconds Avg, Max, Min None

Send request time (browserTimings/sendDuration)

Unit of measure Supported aggregations Supported dimensions
Milliseconds Avg, Max, Min None

Failure metrics

The metrics in Failures show problems with processing requests, dependency calls, and thrown exceptions.

Browser exceptions (exceptions/browser)

This metric reflects the number of thrown exceptions from your application code running in browser. Only exceptions that are tracked with a trackException() Application Insights API call are included in the metric.

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Count Count Cloud role name cloud/roleName 100

Dependency call failures (dependencies/failed)

The number of failed dependency calls.

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Count Count Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Dependency performance dependency/performanceBucket 20
Dependency type dependency/type 100
Is traffic synthetic operation/synthetic 10
Result code dependency/resultCode 100
Target of dependency call dependency/target 100

Exceptions (exceptions/count)

Each time when you log an exception to Application Insights, there's a call to the trackException() method of the SDK. The Exceptions metric shows the number of logged exceptions.

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Count Count Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Device type client/type 2

Failed requests (requests/failed)

The count of tracked server requests that were marked as failed. By default, the Application Insights SDK automatically marks each server request that returned HTTP response code 5xx or 4xx (except for 401) as a failed request. You can customize this logic by modifying success property of request telemetry item in a custom telemetry initializer. For more information about various response codes, see Application Insights telemetry data model.

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Count Count Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Is synthetic traffic operation/synthetic 10
Request performance request/performanceBucket 20
Result code request/resultCode 100

Server exceptions (exceptions/server)

This metric shows the number of server exceptions.

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Count Count Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100

Performance counters

Use metrics in the Performance counters category to access system performance counters collected by Application Insights.

Available memory (performanceCounters/availableMemory)

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Megabytes / Gigabytes (data dependent) Avg, Max, Min Cloud role instance cloud/roleInstance 100

Exception rate (performanceCounters/exceptionRate)

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Count Avg, Max, Min Cloud role instance cloud/roleInstance 100

HTTP request execution time (performanceCounters/requestExecutionTime)

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Milliseconds Avg, Max, Min Cloud role instance cloud/roleInstance 100

HTTP request rate (performanceCounters/requestsPerSecond)

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Requests per second Avg, Max, Min Cloud role instance cloud/roleInstance 100

HTTP requests in application queue (performanceCounters/requestsInQueue)

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Count Avg, Max, Min Cloud role instance cloud/roleInstance 100

Process CPU (performanceCounters/processCpuPercentage)

The monitored app's hosting process consumes a portion of the total processor capacity, and the metric shows how much it uses.

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Percentage Avg, Max, Min Cloud role instance cloud/roleInstance 100

Note

The range of the metric is between 0 and 100 * n, where n is the number of available CPU cores. For example, the metric value of 200% could represent full utilization of two CPU core or half utilization of four CPU cores and so on. The Process CPU Normalized is an alternative metric collected by many SDKs, which represents the same value but divides it by the number of available CPU cores. Thus, the range of Process CPU Normalized metric is 0 through 100.

Process IO rate (performanceCounters/processIOBytesPerSecond)

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Bytes per second Average, Min, Max Cloud role instance cloud/roleInstance 100

Process private bytes (performanceCounters/processPrivateBytes)

Amount of nonshared memory that the monitored process allocated for its data.

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Bytes Average, Min, Max Cloud role instance cloud/roleInstance 100

Processor time (performanceCounters/processorCpuPercentage)

CPU consumption by all processes running on the monitored server instance.

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Percentage Average, Min, Max Cloud role instance cloud/roleInstance 100

Note

The processor time metric isn't available for the applications hosted in Azure App Services. Use the Process CPU metric to track CPU utilization of the web applications hosted in App Services.

Server metrics

Dependency calls (dependencies/count)

This metric is in relation to the number of dependency calls.

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Count Count Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Dependency performance dependency/performanceBucket 20
Dependency type dependency/type 100
Is traffic synthetic operation/synthetic 10
Result code request/resultCode 2
Successful call dependency/success 100
Target of a dependency call dependency/target 100

Dependency duration (dependencies/duration)

This metric refers to duration of dependency calls.

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Milliseconds Avg, Max, Min Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Dependency performance dependency/performanceBucket 20
Dependency type dependency/type 100
Is traffic synthetic operation/synthetic 10
Result code request/resultCode 100
Successful call dependency/success 2
Target of a dependency call dependency/target 100

Server request rate (requests/rate)

This metric shows the number of incoming server requests your web application receives.

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Count per second Avg Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Is traffic synthetic operation/synthetic 10
Request performance request/performanceBucket 20
Result code request/resultCode 100
Successful call dependency/success 2

Server requests (requests/count)

Unit of measure Aggregations Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Count Count Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Is traffic synthetic operation/synthetic 10
Request performance request/performanceBucket 20
Result code request/resultCode 100
Successful call dependency/success 2

Server response time (requests/duration)

This metric reflects the time it took for the servers to process incoming requests.

Milliseconds Avg, Max, Min Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Count Count Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Is traffic synthetic operation/synthetic 10
Request performance request/performanceBucket 20
Result code request/resultCode 100
Successful call dependency/success 2

Usage metrics

Page view load time (pageViews/duration)

This metric refers to the amount of time it took for PageView events to load.

Milliseconds Avg, Max, Min Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Milliseconds Avg, Max, Min Cloud role name cloud/roleName 100
Is traffic synthetic operation/synthetic 10

Page views (pageViews/count)

The count of PageView events logged with the TrackPageView() Application Insights API.

Count Count Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Milliseconds Avg, Max, Min Cloud role name cloud/roleName 100
Is traffic synthetic operation/synthetic 10

Traces (traces/count)

The count of trace statements logged with the TrackTrace() Application Insights API call.

Count Count Dimension name
(Metrics Explorer)		 Dimension name
(Log Analytics)		 Cardinality limit
Count Count Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Is traffic synthetic operation/synthetic 10
Severity level trace/severityLevel 100

Custom metrics

Not applicable to standard metrics.

Access log-based metrics directly with the Application Insights REST API

The Application Insights REST API enables programmatic retrieval of log-based metrics. It also features an optional parameter ai.include-query-payload that when added to a query string, prompts the API to return not only the time series data, but also the Kusto Query Language (KQL) statement used to fetch it. This parameter can be beneficial for users aiming to comprehend the connection between raw events in Log Analytics and the resulting log-based metric.

To access your data directly, pass the parameter ai.include-query-payload to the Application Insights API in a query using KQL.

Note

To retrieve the underlying logs query, DEMO_APP and DEMO_KEY don't have to be replaced. If you just want to retrieve the KQL statement and not the time series data of your own application, you can copy and paste it directly into your browser search bar.

api.applicationinsights.io/v1/apps/DEMO_APP/metrics/users/authenticated?api_key=DEMO_KEY&prefer=ai.include-query-payload

This example shows a return KQL statement for the metric Authenticated Users. In this example, "users/authenticated" is the metric ID.

output
{
    "value": {
        "start": "2024-06-21T09:14:25.450Z",
        "end": "2024-06-21T21:14:25.450Z",
        "users/authenticated": {
            "unique": 0
        }
    },
    "@ai.query": "union (traces | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (requests | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (pageViews | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (dependencies | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (customEvents | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (availabilityResults | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (exceptions | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (customMetrics | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (browserTimings | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)) | where notempty(user_AuthenticatedId) | summarize ['users/authenticated_unique'] = dcount(user_AuthenticatedId)"
}

Next steps