Edit

Share via

Configure automatic data collection and resource detectors for Azure Monitor OpenTelemetry

This guide explains how Azure Monitor OpenTelemetry collects telemetry automatically, how community instrumentation libraries can be added, and how to configure resource detectors to enrich that telemetry with consistent metadata. You learn what signals are collected by default and how resource detectors populate attributes like service identity and environment details so your Application Insights data is easier to filter, correlate, and troubleshoot across .NET, Java, Node.js, and Python applications.

This guide provides instructions on integrating and customizing OpenTelemetry (OTel) instrumentation within Azure Monitor Application Insights.

To learn more about OpenTelemetry concepts, see the OpenTelemetry overview or OpenTelemetry FAQ.

Note

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

Automatic data collection

The distros automatically collect data by bundling OpenTelemetry instrumentation libraries.

Included instrumentation libraries

Requests

Dependencies

Logging

  • ILogger

To reduce or increase the number of logs sent to Azure Monitor, configure logging to set the appropriate log level or apply filters. For example, you can choose to send only Warning and Error logs to OpenTelemetry/Azure Monitor. OpenTelemetry doesn't control log routing or filtering - your ILogger configuration makes these decisions. For more information on configuring ILogger, see Configure logging.

For more information about ILogger, see Logging in C# and .NET and code examples.

Footnotes

  • ¹: Supports automatic reporting of unhandled/uncaught exceptions
  • ²: Supports OpenTelemetry Metrics

Note

The Azure Monitor OpenTelemetry Distros include custom mapping and logic to automatically emit Application Insights standard metrics.

Tip

All OpenTelemetry metrics whether automatically collected from instrumentation libraries or manually collected from custom coding are currently considered Application Insights "custom metrics" for billing purposes. Learn more.

Add a community instrumentation library

You can collect more data automatically when you include instrumentation libraries from the OpenTelemetry community.

Caution

We don't support or guarantee the quality of community instrumentation libraries. To suggest one for our distro, post or up-vote in our feedback community. Be aware, some are based on experimental OpenTelemetry specs and might introduce future breaking changes.

To add a community library, use the ConfigureOpenTelemetryMeterProvider or ConfigureOpenTelemetryTracerProvider methods, after adding the NuGet package for the library.

The following example demonstrates how the Runtime Instrumentation can be added to collect extra metrics:

dotnet add package OpenTelemetry.Instrumentation.Runtime 

// Create a new ASP.NET Core web application builder.
var builder = WebApplication.CreateBuilder(args);

// Configure the OpenTelemetry meter provider to add runtime instrumentation.
builder.Services.ConfigureOpenTelemetryMeterProvider((sp, builder) => builder.AddRuntimeInstrumentation());

// Add the Azure Monitor telemetry service to the application.
// This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor();

// Build the ASP.NET Core web application.
var app = builder.Build();

// Start the ASP.NET Core web application.
app.Run();

Resource detectors

Resource detectors discover environment metadata at startup and populate OpenTelemetry resource attributes such as service.name, cloud.provider, and cloud.resource_id. This metadata powers experiences in Application Insights like Application Map and compute linking, and it improves correlation across traces, metrics, and logs.

Tip

Resource attributes describe the process and its environment. Span attributes describe a single operation. Use resource attributes for app-level properties like service.name.

Supported environments

Environment How detection works Notes
Azure App Service The language SDK or Azure Monitor distro reads well-known App Service environment variables and host metadata Works with .NET, Java, Node.js, and Python when you use the guidance in this article.
Azure Functions See the Azure Functions OpenTelemetry how‑to All Azure Functions guidance lives there.
Azure Virtual Machines The language SDK or distro queries the Azure Instance Metadata Service Ensure the VM has access to the Instance Metadata Service endpoint.
Azure Kubernetes Service (AKS) Use the OpenTelemetry Collector k8sattributes processor to add Kubernetes metadata Recommended for all languages running in AKS.
Azure Container Apps Detectors map environment variables and resource identifiers when available You can also set OTEL_RESOURCE_ATTRIBUTES to fill gaps.

Manual and automatic instrumentation

  • Automatic instrumentation and the Azure Monitor distros enable resource detection when running in Azure environments where supported.

  • For manual setups, you can set resource attributes directly with standard OpenTelemetry options:

    # Applies to .NET (ASP.NET/ASP.NET Core), Java, Node.js, and Python
export OTEL_SERVICE_NAME="my-service"
export OTEL_RESOURCE_ATTRIBUTES="cloud.provider=azure,cloud.region=westus,cloud.resource_id=/subscriptions/<SUB>/resourceGroups/<RG>/providers/Microsoft.Web/sites/<APP>"

    On Windows PowerShell:

    $Env:OTEL_SERVICE_NAME="my-service"
$Env:OTEL_RESOURCE_ATTRIBUTES="cloud.provider=azure,cloud.region=westus,cloud.resource_id=/subscriptions/<SUB>/resourceGroups/<RG>/providers/Microsoft.Web/sites/<APP>"

OTLP ingestion considerations

  • Application Insights uses service.name to derive Cloud Role Name. Choose a stable name per service to avoid fragmented nodes in Application Map.

  • cloud.resource_id improves compute linking to Azure resources. If this attribute is missing, some experiences may not show the Azure resource that produced the data.

Next steps

  • Last updated on