Automatic OpenTelemetry data collection and resource detectors

Note

For .NET, Node.js, and Python applications:

New app or adopting OpenTelemetry for the first time: Use the Microsoft OpenTelemetry Distro.
Already using the Azure Monitor OpenTelemetry Distro: No action needed.
Using Application Insights .NET SDK 2.x: Upgrade to 3.x to minimize reinstrumentation, or start fresh with the Microsoft OpenTelemetry Distro.

For Java applications, use the Azure Monitor OpenTelemetry Distro.

This article explains automatic telemetry collection and resource detection in Application Insights. Use the Microsoft OpenTelemetry Distro for .NET, Node.js, and Python. Java continues to use the Azure Monitor OpenTelemetry Distro and its agent or native-image integrations. Select the tab for your language to review bundled instrumentation and resource metadata.

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

Note

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

Included instrumentation libraries

The Microsoft OpenTelemetry Distro for .NET, Node.js, and Python and the Azure Monitor OpenTelemetry Distro for Java bundle instrumentation libraries to collect data automatically. First, enable OpenTelemetry and select Azure Monitor as the export destination. Don't initialize a second distro or a duplicate provider for the same signal.

Requests

ASP.NET Core ¹²

Dependencies

Logging

ILogger

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

The Microsoft OpenTelemetry Distro for .NET includes HttpClient, SqlClient, and Azure SDK instrumentation, along with resource detection, metrics, and logging support. You don't need to add a separate Azure SDK subscription or HttpClient deduplication filter for the bundled instrumentation.

For console and other non-hosted applications, initialize the distro as follows. Set APPLICATIONINSIGHTS_CONNECTION_STRING before starting the application, and keep the SDK alive until shutdown:

// Import the Microsoft OpenTelemetry Distro and supporting APIs.
using Microsoft.OpenTelemetry;
using OpenTelemetry;

// Create the SDK and keep its providers alive until application shutdown.
using var sdk = OpenTelemetrySdk.Create(telemetry =>
{
    // Configure the Microsoft OpenTelemetry Distro.
    telemetry.UseMicrosoftOpenTelemetry(options =>
    {
        options.Exporters = ExportTarget.AzureMonitor;
    });
});

Requests

Java Message Service (JMS) consumers
Kafka consumers
Netty
Quartz
RabbitMQ
Servlets
Spring scheduling

Note

Servlet and Netty autoinstrumentation covers most Java HTTP services, including Java EE, Jakarta EE, Spring Boot, Quarkus, and Micronaut.

Dependencies (plus downstream distributed trace propagation)

Apache HttpClient
Apache HttpAsyncClient
AsyncHttpClient
Google HttpClient
gRPC
java.net.HttpURLConnection
Java 11 HttpClient
JAX-RS client
Jetty HttpClient
JMS
Kafka
Netty client
OkHttp
RabbitMQ

Dependencies (without downstream distributed trace propagation)

Supports Cassandra
Supports Java Database Connectivity (JDBC)
Supports MongoDB (async and sync)
Supports Redis (Lettuce and Jedis)

Metrics

Micrometer Metrics, including Spring Boot Actuator metrics
Java Management Extensions (JMX) Metrics

Logs

Logback (including MDC properties) ¹
Log4j (including MDC/Thread Context properties) ¹
JBoss Logging (including MDC properties) ¹
java.util.logging ¹

Default collection

Telemetry emitted by the following Azure SDKs is automatically collected by default:

Azure App Configuration 1.1.10+
Azure AI Search 11.3.0+
Azure Communication Chat 1.0.0+
Azure Communication Common 1.0.0+
Azure Communication Identity 1.0.0+
Azure Communication Phone Numbers 1.0.0+
Azure Communication SMS (Short Message Service) 1.0.0+
Azure Cosmos DB 4.22.0+
Azure Digital Twins - Core 1.1.0+
Azure Event Grid 4.0.0+
Azure Event Hubs 5.6.0+
Azure Event Hubs - Azure Blob Storage Checkpoint Store 1.5.1+
Azure AI Document Intelligence 3.0.6+
Azure Identity 1.2.4+
Azure Key Vault - Certificates 4.1.6+
Azure Key Vault - Keys 4.2.6+
Azure Key Vault - Secrets 4.2.6+
Azure Service Bus 7.1.0+
Azure Storage - Blobs 12.11.0+
Azure Storage - Blobs Batch 12.9.0+
Azure Storage - Blobs Cryptography 12.11.0+
Azure Storage - Common 12.11.0+
Azure Storage - Files Data Lake 12.5.0+
Azure Storage - Files Shares 12.9.0+
Azure Storage - Queues 12.9.0+
Azure Text Analytics 5.0.4+

Tip

For Microsoft OpenTelemetry Distro examples, see the Node.js samples.

The Microsoft OpenTelemetry Distro for Node.js includes the following instrumentation libraries. Initialize it before loading the application libraries you want to instrument. For ESM applications, preload the Microsoft OpenTelemetry Distro loader.

Requests

HTTP/HTTPS²

Dependencies

Logs

AI libraries

OpenAI Agents SDK, when the application installs @openai/agents.
LangChain, when the application installs @langchain/core.

For configuration and defaults, see Microsoft OpenTelemetry Distro instrumentation options.

Important

Bunyan and Winston aren't enabled by default. You can enable instrumentation libraries by setting enabled: true in the instrumentation options.

Configure Bunyan logging with the Microsoft OpenTelemetry Distro

This example assumes the application uses bunyan. For TypeScript, install @types/bunyan as a development dependency.

import {
    useMicrosoftOpenTelemetry,
    MicrosoftOpenTelemetryOptions,
} from "@microsoft/opentelemetry";

// Set the Azure Monitor exporter options.
const options: MicrosoftOpenTelemetryOptions = {
    azureMonitor: {
        azureMonitorExporterOptions: {
            connectionString:
                process.env.APPLICATIONINSIGHTS_CONNECTION_STRING || "<ConnectionString>",
        },
    },
    // Enable Bunyan instrumentation, which is disabled by default.
    instrumentationOptions: {
        bunyan: { enabled: true },
    },
};

// Initialize the distro before loading Bunyan.
useMicrosoftOpenTelemetry(options);

// Load Bunyan after instrumentation is configured.
const { default: bunyan } = await import("bunyan");

// Create an application logger; instrumentation captures its log records.
const logger = bunyan.createLogger({ name: "my-app" });
logger.info("Application started");
logger.warn({ requestId: "abc-123" }, "Slow response detected");
logger.error(new Error("Something failed"), "Unhandled error");

Requests

Django ¹
FastApi ¹
Flask ¹

Dependencies

Logs

Python logging library

For Python logging examples, see the Microsoft OpenTelemetry Distro samples.

The Microsoft OpenTelemetry Distro for Python also supports instrumentation for OpenAI, OpenAI Agents SDK, LangChain, Semantic Kernel, and Microsoft Agent Framework when the corresponding application libraries are installed. Azure SDK instrumentation is enabled when Azure Monitor export is active. See supported Python instrumentation and defaults.

Footnotes

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

Note

The Microsoft OpenTelemetry Distro versions' Azure Monitor integration and Azure Monitor OpenTelemetry for Java include mapping and logic to emit Application Insights standard metrics. For billing purposes, all OpenTelemetry metrics, whether automatically collected from instrumentation libraries or manually collected from custom coding, are currently considered Application Insights custom metrics. Learn more.

Tip

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 Azure Monitor.

Resource detectors

Resource detectors identify the service and host that produce telemetry. They read environment variables or host metadata and populate OpenTelemetry resource attributes such as service.name, service.instance.id, and cloud.resource_id.

What resource detectors power

Application Insights uses resource attributes to provide context for your telemetry:

Service and instance identification: Service attributes help set the Cloud Role Name and Cloud Role Instance shown in Application Map. Use a stable service name so instances of the same service aren't shown as separate components. For explicit configuration, see Set the Cloud Role Name and the Cloud Role Instance.
Compute linking: Attributes such as cloud.resource_id identify the Azure resource that hosts an application. Missing resource metadata can prevent Application Insights from linking application telemetry to its Azure compute resource.
Environment context: Host, operating-system, region, and service-version attributes describe where an application runs. The available attributes depend on the detector and hosting environment.

Resource attributes describe the service or process. Span attributes describe a single operation. Resource detection doesn't replace the trace-context propagation that connects requests and dependencies.

Supported environments

Detector availability and the attributes they collect vary by language, package version, and hosting integration. Use the registration code to see which detectors the distro enables, and the implementation to see which environment values they read. Select the repository tag that matches your installed package when checking a specific version.

Language or integration	Detector registration and implementation
ASP.NET Core and .NET	Microsoft OpenTelemetry detector registration and Azure detector implementations.
Node.js	Microsoft OpenTelemetry resource configuration and Azure detector implementations.
Python	Microsoft OpenTelemetry detector selection and Azure detector implementations.
Java agent	Application Insights Java resource-provider configuration.
Java native	Spring Boot integration and Quarkus Azure exporter. Detector configuration depends on the framework.

For Azure Functions, follow the Azure Functions OpenTelemetry guidance. For collector-based Kubernetes enrichment, see the Kubernetes attributes processor.

Resource metadata metric

The Azure Monitor exporters can send resource attributes in a special metric named _OTELRESOURCE_. The metric's properties carry the metadata; its numeric value isn't a measurement of application performance. This separate metadata record supplies resource context without adding every resource attribute to every telemetry item.

For the emitted name and properties, see the exporter implementations for .NET, Node.js, Python, and Java.

Note

Earlier Java agent releases used _APPRESOURCEPREVIEW_; version 3.5.3 removed that metric. The exporter implementations linked here use _OTELRESOURCE_. Check your exporter version before relying on a resource-metric name in a query or filter.

Turn off resource metadata export

Keep resource metadata export enabled unless you have a specific requirement to suppress it. Disabling it can remove compute-resource context used during troubleshooting. To control telemetry volume, use sampling or telemetry filters instead.

To stop exporting the resource metadata metric, set the applicable environment variable before the application starts, and then restart the application:

Language	Environment variable	Value
ASP.NET Core and .NET	`OTEL_DOTNET_AZURE_MONITOR_ENABLE_RESOURCE_METRICS`	`false`
Node.js	`APPLICATIONINSIGHTS_OPENTELEMETRY_RESOURCE_METRIC_DISABLED`	`true`
Python	`APPLICATIONINSIGHTS_OPENTELEMETRY_RESOURCE_METRIC_DISABLED`	`true`

These settings control resource-metric export, not detector execution or the collection of all application metrics. Resource attributes can still be used to populate cloud role fields on other telemetry. Remove the environment variable and restart the application to restore the default export behavior.

The settings in this table don't apply to Java. The linked Java exporter doesn't expose an equivalent metadata-only opt-out; don't disable all telemetry or remove service attributes to suppress this metric.

OTLP ingestion considerations

When you use native OTLP ingestion, preserve resource attributes on the OTLP resource. The Azure Monitor exporter settings in the preceding section don't control an OTLP exporter. Attributes such as service.name and cloud.resource_id still identify the service and its Azure host.

Troubleshooting, feedback, and support

Tip

The following sections are available across all OpenTelemetry Distro articles.

Troubleshooting

For troubleshooting information, see Troubleshoot OpenTelemetry issues in .NET and Troubleshoot missing application telemetry in Azure Monitor Application Insights.

OpenTelemetry Feedback

To provide feedback:

Tell Microsoft about yourself by joining the OpenTelemetry Early Adopter Community.
Engage with other Azure Monitor users in the Microsoft Tech Community.
Make a feature request at the Azure Feedback Forum.

Support

Select a tab for the language of your choice to discover support options.

For Azure support issues, open an Azure support ticket.
For OpenTelemetry issues, contact the OpenTelemetry .NET community directly.
For a list of open issues related to Azure Monitor Exporter, see the GitHub Issues Page.

Next steps

To review the source code, see the Microsoft OpenTelemetry Distro repository for .NET.
To review a sample application, see Microsoft OpenTelemetry Distro for ASP.NET Core.
To install the NuGet package, check for updates, or view release notes, see the Microsoft.OpenTelemetry package.
For applications that still use Azure.Monitor.OpenTelemetry.AspNetCore, see the Azure Monitor distro documentation.
To learn more about OpenTelemetry and its community, see the OpenTelemetry .NET GitHub repository.
To enable usage experiences, enable web or browser user monitoring.

To review the source code, see the Microsoft OpenTelemetry Distro repository for .NET.
For non-hosted setup, see Configure the Microsoft OpenTelemetry Distro for console apps and background tools.
To install the NuGet package, check for updates, or view release notes, see the Microsoft.OpenTelemetry package.
For applications that use the standalone Azure.Monitor.OpenTelemetry.Exporter package, see the Azure Monitor exporter documentation.
To learn more about OpenTelemetry and its community, see the OpenTelemetry .NET GitHub repository.
To enable usage experiences, enable web or browser user monitoring.

To review the source code, see the Microsoft OpenTelemetry Distro repository for Node.js.
To review sample applications, see Microsoft OpenTelemetry Distro samples for Node.js.
To install the npm package and check for updates, see the @microsoft/opentelemetry package.
For applications that still use @azure/monitor-opentelemetry, see the Azure Monitor distro documentation.
To learn more about OpenTelemetry and its community, see the OpenTelemetry JavaScript GitHub repository.
To enable usage experiences, enable web or browser user monitoring.

To review the source code and configuration, see the Microsoft OpenTelemetry Distro repository for Python.
To review sample applications, see Microsoft OpenTelemetry Distro samples for Python.
To install the PyPI package and check for updates, see the microsoft-opentelemetry package.
Review the release notes on GitHub.
For applications that still use azure-monitor-opentelemetry, see the Azure Monitor distro documentation.
To review available OpenTelemetry instrumentations and components, see the OpenTelemetry Contributor Python GitHub repository.
To learn more about OpenTelemetry and its community, review the OpenTelemetry Python GitHub repository.
To enable usage experiences, enable web or browser user monitoring.

Last updated on 2026-10-23

Automatic OpenTelemetry data collection and resource detectors

Included instrumentation libraries

Resource detectors

What resource detectors power

Supported environments

Resource metadata metric

Turn off resource metadata export

OTLP ingestion considerations

Troubleshooting, feedback, and support

Troubleshooting

OpenTelemetry Feedback

Support

Next steps

Additional resources