OpenTelemetry reached general availability for.NET in 2022. The promise: vendor-neutral instrumentation that lets you change your observability backend without re-instrumenting your application.
The three signals
OpenTelemetry standardises three observability signals: traces (the complete path of a request through distributed services), metrics (numeric measurements over time), and logs (discrete events with timestamps and attributes). The standardisation means a single instrumentation library produces data that any compatible backend can ingest. You instrument once; you can export to Jaeger, Zipkin, Datadog, Azure Monitor, or any OTLP-compatible backend.
Auto-instrumentation in.NET
OpenTelemetry.NET supports automatic instrumentation for the common frameworks: ASP.NET Core, HttpClient, Entity Framework Core, and several third-party libraries. Adding OpenTelemetry to an ASP.NET Core application with three NuGet packages and a few lines of configuration produces distributed traces with service name, operation name, HTTP status, and duration, without touching application code. The auto-instrumentation covers 80% of the observability value.
Activity API for custom spans
For custom instrumentation beyond the auto-instrumented frameworks,.NET's System.Diagnostics.Activity API provides a clean model. Creating an Activity creates an OpenTelemetry span. Adding tags to the Activity adds span attributes. The Activity API is built into the BCL from.NET 5, so there is no dependency on the OpenTelemetry package for custom instrumentation, only for the export configuration.
Baggage propagation
OpenTelemetry Baggage is a mechanism for passing key-value context across service boundaries in a distributed request. Common uses: tenant ID, user ID, feature flag state. The baggage propagates via HTTP headers and is accessible in every service that handles the request without explicit parameter passing. This is useful for correlation that cuts across service boundaries in a multi-tenant system.