Configure Azure Monitor OpenTelemetry

This guide explains how to configure OpenTelemetry (OTel) in Azure Monitor Application Insights using the Azure Monitor OpenTelemetry distro. Proper configuration ensures consistent telemetry data collection across .NET, Java, Node.js, and Python applications, allowing for more reliable monitoring and diagnostics.

Note

For Azure Function Apps, see Use OpenTelemetry with Azure Functions.

Connection string

A connection string in Application Insights defines the target location for sending telemetry data.

To set the connection string, see Connection string.

Set the Cloud Role Name and the Cloud Role Instance

For supported languages, the Azure Monitor OpenTelemetry Distro automatically detects the resource context and provides default values for the Cloud Role Name and the Cloud Role Instance properties of your component. However, you might want to override the default values to something that makes sense to your team. The cloud role name value appears on the Application Map as the name underneath a node.

To set the cloud role name, see cloud role name.

To set the cloud role instance, see cloud role instance.

Enable Sampling

You might want to enable sampling to reduce your data ingestion volume, which reduces your cost. Azure Monitor provides a custom fixed-rate sampler that populates events with a sampling ratio, which Application Insights converts to ItemCount. The fixed-rate sampler ensures accurate experiences and event counts. The sampler is designed to preserve your traces across services, and it's interoperable with older Application Insights Software Development Kits (SDKs). For more information, see Learn More about sampling.

Note

Metrics and Logs are unaffected by sampling. If you're seeing unexpected charges or high costs in Application Insights, this guide can help. It covers common causes like high telemetry volume, data ingestion spikes, and misconfigured sampling. It's especially useful if you're troubleshooting issues related to cost spikes, telemetry volume, sampling not working, data caps, high ingestion, or unexpected billing. To get started, see Troubleshoot high data ingestion in Application Insights.

Starting from 3.4.0, rate-limited sampling is available and is now the default. For more information about sampling, see Java sampling.

Tip

When using fixed-rate/percentage sampling and you aren't sure what to set the sampling rate as, start at 5%. (0.05 sampling ratio) Adjust the rate based on the accuracy of the operations shown in the failures and performance panes. A higher rate generally results in higher accuracy. However, ANY sampling affects accuracy so we recommend alerting on OpenTelemetry metrics, which are unaffected by sampling.

Live metrics

Live metrics provides a real-time analytics dashboard for insight into application activity and performance.

The Live Metrics experience is enabled by default.

For more information on Java configuration, see Configuration options: Azure Monitor Application Insights for Java.

Offline Storage and Automatic Retries

Azure Monitor OpenTelemetry-based offerings cache telemetry when an application disconnects from Application Insights and retries sending for up to 48 hours. For data handling recommendations, see Export and delete private data. High-load applications occasionally drop telemetry for two reasons: exceeding the allowable time or exceeding the maximum file size. When necessary, the product prioritizes recent events over old ones.

When the agent can't send telemetry to Azure Monitor, it stores telemetry files on disk. The files are saved in a telemetry folder under the directory specified by the java.io.tmpdir system property. Each file name starts with a timestamp and ends with the .trn extension. This offline storage mechanism helps ensure telemetry is retained during temporary network outages or ingestion failures.

The agent stores up to 50 MB of telemetry data by default and allows configuration of the storage limit. Attempts to send stored telemetry are made periodically. Telemetry files older than 48 hours are deleted and the oldest events are discarded when the storage limit is reached.

For a full list of available configurations, see Configuration options.

Enable the OTLP Exporter

You might want to enable the OpenTelemetry Protocol (OTLP) Exporter alongside the Azure Monitor Exporter to send your telemetry to two locations.

Note

The OTLP Exporter is shown for convenience only. We don't officially support the OTLP Exporter or any components or third-party experiences downstream of it.

The Application Insights Java Agent doesn't support OTLP. For more information about supported configurations, see the Java supplemental documentation.

OpenTelemetry configurations

The following OpenTelemetry configurations can be accessed through environment variables while using the Azure Monitor OpenTelemetry Distros.

For more information about Java, see the Java supplemental documentation.

Redact URL Query Strings

To redact URL query strings, turn off query string collection. We recommend this setting if you call Azure storage using a SAS token.

Add the following to the applicationinsights.json configuration file:

{
  "preview": {
    "processors": [
      {
        "type": "attribute",
        "actions": [
          {
            "key": "url.query",
            "pattern": "^.*$",
            "replace": "REDACTED",
            "action": "mask"
          }
        ]
      },
      {
        "type": "attribute",
        "actions": [
          {
            "key": "url.full",
            "pattern": "[?].*$",
            "replace": "?REDACTED",
            "action": "mask"
          }
        ]
      }
    ]
  }
}

Metric export interval

You can configure the metric export interval using the OTEL_METRIC_EXPORT_INTERVAL environment variable.

OTEL_METRIC_EXPORT_INTERVAL=60000

The default value is 60000 milliseconds (60 seconds). This setting controls how often the OpenTelemetry SDK exports metrics.

Tip

Azure Monitor Metrics and Azure Monitor Workspace ingest custom metrics at a fixed 60-second interval. Metrics sent more frequently are buffered and processed once every 60 seconds. Log Analytics records metrics at the interval they’re sent, which can increase cost at shorter intervals and delay visibility at longer ones.

For reference, see the following OpenTelemetry specifications: