Edit

What is Microsoft OpenTelemetry Distro?

Microsoft OpenTelemetry Distro is a unified observability distribution that provides a single onboarding experience for collecting traces, metrics, and logs from agentic and nonagentic applications. It supports observability for Microsoft Agent 365, Microsoft Foundry, Azure Monitor, and any OpenTelemetry Protocol (OTLP)-compatible backend. The distro supports .NET, Node.js, and Python, and replaces fragmented setup across multiple observability stacks with one import and one configuration call.

Supported scenarios

Microsoft OpenTelemetry Distro supports observability scenarios that share OpenTelemetry concepts and instrumentation patterns across Microsoft product surfaces.

Scenario Common Distro role
Application observability Collect traces, metrics, and logs from applications and common infrastructure libraries.
Agent observability Capture agent invocation, tool execution, inference, and output telemetry where supported.
Generative AI observability Collect telemetry from supported generative AI frameworks and clients.
Multi-destination export Send telemetry to one or more destination categories, such as Azure Monitor, Microsoft Agent 365, OTLP, or console output.
OpenTelemetry interoperability Use OpenTelemetry conventions, resources, exporters, processors, and instrumentation patterns.

Feature coverage varies by language and product surface. Product documentation can layer product-specific workflow requirements on top of these shared Distro scenarios.

Key benefits

The Microsoft OpenTelemetry Distro provides these benefits:

  • One package, one API: Replace multiple exporter and instrumentation packages with a single dependency.
  • Multi-backend support: Send telemetry to Azure Monitor, any OpenTelemetry Protocol (OTLP)-compatible endpoint such as Datadog, Grafana, or New Relic, and Microsoft Agent 365 at the same time.
  • Built-in instrumentations: Use automatic instrumentation for HTTP, databases, Azure SDK, Azure Functions, and more with no extra configuration.
  • Standards-based: Build on OpenTelemetry, the industry-standard observability framework.
  • Minimal boilerplate: Add one import and one function call to your application entry point.

Supported languages and packages

The Microsoft OpenTelemetry Distro package identifiers and install commands are:

Language Package Install command
Python microsoft-opentelemetry pip install microsoft-opentelemetry
Node.js @microsoft/opentelemetry npm install @microsoft/opentelemetry
.NET Microsoft.OpenTelemetry dotnet add package Microsoft.OpenTelemetry

How it works

The Microsoft OpenTelemetry Distro wraps the OpenTelemetry SDK with preconfigured exporters and instrumentations. When you call the setup function, the distro:

  1. Creates standalone OpenTelemetry providers.
  2. Attaches Microsoft Agent 365 export when you enable Microsoft Agent 365.
  3. Configures Azure Monitor export when you enable Azure Monitor.
  4. Attaches OpenTelemetry Protocol (OTLP) exporters when it detects an OTLP endpoint.
  5. Enables standard instrumentations for HTTP, databases, and frameworks.
  6. Enables generative AI instrumentations, such as OpenAI Agents and LangChain, when you configure them.

Destination categories

The Microsoft OpenTelemetry Distro can export telemetry to several destination categories. Product documentation can add the destination-specific workflow, access, and validation details.

Azure Monitor

Azure Monitor is a Microsoft observability destination for application telemetry. Depending on language and configuration, Azure Monitor scenarios can include traces, metrics, logs, Live Metrics, and Azure resource context.

Microsoft Agent 365

Microsoft Agent 365 is a Microsoft observability destination for agent scenarios. Depending on language and configuration, Microsoft Agent 365 scenarios can include agent and generative AI spans, baggage propagation, hosting integration, and scope-based telemetry.

OpenTelemetry Protocol (OTLP)

OTLP is the standards-based OpenTelemetry export protocol. Use OTLP when telemetry flows through an OpenTelemetry Collector or another OTLP-compatible backend.

Console

Console output is a local development and validation destination. It can help confirm that telemetry is produced before validating a production destination.

Instrumentation overview

The Microsoft OpenTelemetry Distro combines standard OpenTelemetry pipelines with Microsoft-curated instrumentation. The Distro can collect application telemetry, infrastructure telemetry, and agent or generative AI telemetry depending on language and configuration.

Category What it covers
Signal pipelines Traces, metrics, and logs.
Resource detection Service, host, cloud, and Azure runtime context where supported.
Infrastructure instrumentation HTTP, ASP.NET Core, Azure SDK, database clients, and logging frameworks where supported.
Generative AI instrumentation OpenAI, Azure OpenAI, Semantic Kernel, LangChain, OpenAI Agents SDK, and Agent Framework where supported.
Manual agent scopes Agent invocation, tool execution, inference, and output telemetry where supported.
Exporters and processors Azure Monitor, Microsoft Agent 365, OTLP, console output, span processors, log processors, and metric readers.

Instrumentation coverage

Language Common application instrumentation Common agent and generative AI instrumentation
Python OpenTelemetry resources, processors, readers, logging, metrics, and traces. Semantic Kernel, OpenAI Agents SDK, Agent Framework, LangChain, Microsoft Agent 365 baggage, and Microsoft Agent 365 scopes.
Node.js HTTP, Azure SDK, Azure Functions, MongoDB, MySQL, PostgreSQL, Redis, Bunyan, and Winston. OpenAI Agents SDK, LangChain, Microsoft Agent 365 baggage, and Microsoft Agent 365 scopes.
.NET ASP.NET Core, HttpClient, SQL Client, Azure SDK, resource detection, metrics, and logs. Semantic Kernel, OpenAI and Azure OpenAI, Agent Framework, Microsoft Agent 365 baggage, and Microsoft Agent 365 scopes.

Automatic instrumentation listens to telemetry signals emitted by supported libraries and frameworks. Manual instrumentation is used when an application needs to describe agent-specific operations, such as invocation, tool execution, inference, or asynchronous output.

Add custom OpenTelemetry sources, meters, processors, or readers when your application emits telemetry that isn't covered by the built-in instrumentations.

Next steps

  • Last updated on