แก้ไข

แชร์ผ่าน

OpenTelemetry Support and Feedback for Application Insights

  • บทความ

This document outlines available resources for assistance, support channels, and feedback mechanisms related to OpenTelemetry (OTel) integration with Azure Monitor Application Insights for .NET, Java, Node.js, and Python applications.

Frequently asked questions

What is OpenTelemetry?

It's a new open-source standard for observability. Learn more at OpenTelemetry.

Why is Microsoft Azure Monitor investing in OpenTelemetry?

Microsoft is investing in OpenTelemetry for the following reasons:

  • It's vendor-neutral and provides consistent APIs/SDKs across languages.
  • Over time, we believe OpenTelemetry will enable Azure Monitor customers to observe applications written in languages beyond our supported languages.
  • It expands the types of data you can collect through a rich set of instrumentation libraries.
  • OpenTelemetry Software Development Kits (SDKs) tend to be more performant at scale than their predecessors, the Application Insights SDKs.
  • OpenTelemetry aligns with Microsoft's strategy to embrace open source.

What's the status of OpenTelemetry?

See OpenTelemetry Status.

What is the Azure Monitor OpenTelemetry Distro?

You can think of it as a thin wrapper that bundles together all the OpenTelemetry components for a first-class experience on Azure. This wrapper is also called a distribution in OpenTelemetry.

Why should I use the Azure Monitor OpenTelemetry Distro?

There are several advantages to using the Azure Monitor OpenTelemetry Distro over native OpenTelemetry from the community:

In the spirit of OpenTelemetry, we designed the distro to be open and extensible. For example, you can add:

  • An OpenTelemetry Protocol (OTLP) exporter and send to a second destination simultaneously
  • Other instrumentation libraries not included in the distro

Because the Distro provides an OpenTelemetry distribution, the Distro supports anything supported by OpenTelemetry. For example, you can add more telemetry processors, exporters, or instrumentation libraries, if OpenTelemetry supports them.

Note

The Distro sets the sampler to a custom, fixed-rate sampler for Application Insights. You can change this to a different sampler, but doing so might disable some of the Distro's included capabilities. For more information about the supported sampler, see the Enable Sampling section of Configure Azure Monitor OpenTelemetry.

For languages without a supported standalone OpenTelemetry exporter, the Azure Monitor OpenTelemetry Distro is the only currently supported way to use OpenTelemetry with Azure Monitor. For languages with a supported standalone OpenTelemetry exporter, you have the option of using either the Azure Monitor OpenTelemetry Distro or the appropriate standalone OpenTelemetry exporter depending on your telemetry scenario. For more information, see When should I use the Azure Monitor OpenTelemetry exporter?.

How can I test out the Azure Monitor OpenTelemetry Distro?

Check out our enablement docs for .NET, Java, JavaScript (Node.js), and Python.

Should I use OpenTelemetry or the Application Insights SDK?

We recommend using the Azure Monitor OpenTelemetry Distro for new projects when its capabilities align with your monitoring needs. OpenTelemetry is an industry-standard framework that enhances cross-platform observability and provides a standardized approach to telemetry collection.

However, the Application Insights SDKs still provide certain capabilities that aren't yet fully automated in OpenTelemetry, including:

  • Automatic dependency tracking – OpenTelemetry supports dependency tracking, but some dependencies require additional configuration compared to the automatic tracking available in Application Insights SDKs.
  • Custom telemetry types, such as AvailabilityTelemetry and PageViewTelemetry – OpenTelemetry doesn't have direct equivalents. Similar functionality can be implemented via manual instrumentation.
  • Telemetry processors and initializers – OpenTelemetry has processors and span processors, but they don't fully replace Application Insights Telemetry Processors and Initializers in all scenarios.
  • Extended metrics collection – While OpenTelemetry has a strong metrics system, some built-in metrics from Application Insights SDKs require manual setup in OpenTelemetry.

OpenTelemetry also provides advantages over the Application Insights SDKs, including:

  • Better standardization across platforms
  • A wider ecosystem of instrumentation libraries
  • Greater flexibility in data collection and processing
  • Improved vendor neutrality, though Azure Monitor OpenTelemetry Distro is still optimized for Azure.

Azure Monitor's OpenTelemetry integration is continuously evolving, and Microsoft continues to enhance its capabilities. If you're considering a transition, carefully evaluate whether OpenTelemetry currently meets your observability requirements or if the Application Insights SDK remains the better fit for your needs.

When should I use the Azure Monitor OpenTelemetry exporter?

For ASP.NET Core, Java, Node.js, and Python, we recommend using the Azure Monitor OpenTelemetry Distro. It's one line of code to get started.

For all other .NET scenarios, including classic ASP.NET, console apps, Windows Forms (WinForms), etc., we recommend using the .NET Azure Monitor OpenTelemetry exporter: Azure.Monitor.OpenTelemetry.Exporter.

For more complex Python telemetry scenarios that require advanced configuration, we recommend using the Python Azure Monitor OpenTelemetry Exporter.

What's the current release state of features within the Azure Monitor OpenTelemetry Distro?

The following chart breaks out OpenTelemetry feature support for each language.

Feature .NET Node.js Python Java
Distributed tracing ✅ ✅ ✅ ✅
Custom metrics ✅ ✅ ✅ ✅
Standard metrics ✅ ✅ ✅ ✅
Fixed-rate sampling ✅ ✅ ✅ ✅
Offline storage and automatic retries ✅ ✅ ✅ ✅
Exception reporting ✅ ✅ ✅ ✅
Logs collection ✅ ⚠️ ✅ ✅
Custom Events ⚠️ ⚠️ ⚠️ ✅
Microsoft Entra authentication ✅ ✅ ✅ ✅
Live metrics ✅ ✅ ✅ ✅
Live Metrics Filtering ✅ ❌ ❌ ❌
Detect Resource Context for VM/VMSS and App Service ✅ ❌ ✅ ✅
Detect Resource Context for Azure Kubernetes Service (AKS) and Functions ❌ ❌ ❌ ✅
Availability Testing Events generated using the Track Availability API ❌ ❌ ❌ ✅
Filter requests, dependencies, logs, and exceptions by anonymous user ID and synthetic source ❌ ❌ ❌ ✅
Filter dependencies, logs, and exceptions by operation name ❌ ❌ ❌ ✅
Adaptive sampling ❌ ❌ ❌ ✅
.NET Profiler ❌ ❌ ❌ ⚠️
Snapshot Debugger ❌ ❌ ❌ ❌

Key

Can OpenTelemetry be used for web browsers?

Yes, but we don't recommend it and Azure doesn't support it. OpenTelemetry JavaScript is heavily optimized for Node.js. Instead, we recommend using the Application Insights JavaScript SDK.

When can we expect the OpenTelemetry SDK to be available for use in web browsers?

The OpenTelemetry web SDK doesn't have a determined availability timeline. We're likely several years away from a browser SDK that is a viable alternative to the Application Insights JavaScript SDK.

Can I test OpenTelemetry in a web browser today?

The OpenTelemetry web sandbox is a fork designed to make OpenTelemetry work in a browser. It's not yet possible to send telemetry to Application Insights. The SDK doesn't define general client events.

Is running Application Insights alongside competitor agents like AppDynamics, DataDog, and NewRelic supported?

This practice isn't something we plan to test or support, although our Distros allow you to export to an OTLP endpoint alongside Azure Monitor simultaneously.

Can I use preview features in production environments?

We don't recommend it. See Supplemental terms of use for Microsoft Azure previews.

What's the difference between manual and automatic instrumentation?

See the OpenTelemetry Overview.

Can I use the OpenTelemetry Collector?

Some customers use the OpenTelemetry Collector as an agent alternative, even though Microsoft doesn't officially support an agent-based approach for application monitoring yet. In the meantime, the open-source community contributed an OpenTelemetry Collector Azure Monitor Exporter that some customers are using to send data to Azure Monitor Application Insights. This is not supported by Microsoft.

What's the difference between OpenCensus and OpenTelemetry?

OpenCensus is the precursor to OpenTelemetry. Microsoft helped bring together OpenTracing and OpenCensus to create OpenTelemetry, a single observability standard for the world. The current production-recommended Python SDK for Azure Monitor is based on OpenCensus. Microsoft is committed to making Azure Monitor based on OpenTelemetry.

In Grafana, why do I see Status: 500. Can't visualize trace events using the trace visualizer?

You could be trying to visualize raw text logs rather than OpenTelemetry traces.

In Application Insights, the 'Traces' table stores raw text logs for diagnostic purposes. They aid in identifying and correlating traces associated with user requests, other events, and exception reports. However, the 'Traces' table doesn't directly contribute to the end-to-end transaction view (waterfall chart) in visualization tools like Grafana.

With the growing adoption of cloud-native practices, there's an evolution in telemetry collection and terminology. OpenTelemetry became a standard for collecting and instrumenting telemetry data. In this context, the term 'Traces' took on a new meaning. Rather than raw logs, 'Traces' in OpenTelemetry refer to a richer, structured form of telemetry that includes spans, which represent individual units of work. These spans are crucial for constructing detailed transaction views, enabling better monitoring and diagnostics of cloud-native applications.

Troubleshooting

Support

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

OpenTelemetry Feedback

To provide feedback: