The Current State of OpenTelemetry in .NET
OpenTelemetry vs. OpenTracing and the Future of Observability in .NET
In the past we’ve discussed why distributed tracing is becoming commonplace and the OpenTracing standard for instrumenting libraries and applications. In this post I want to touch on the emerging OpenTelemetry standard, which will become a common component used to instrument ASP.NET Core applications in the not too distant future.
What is OpenTelemetry?
OpenTelemetry is the convergence of two competing tracing standards:
- OpenTracing - developed by a community of APM vendors and library authors and
- OpenCensus - developed by Google.
The goal is to provide a unified set of APIs library authors can include inside their applications in order to:
- Propagate distributed tracing context, including the new W3C HTTP tracing standard;
- Aggregate metrics (counters, meters, etc); and
- Export metrics and trace data to a variety of different Application Performance Monitoring (APM) backends, which can be configured entirely by the application developer.
OpenTelemetry vs. OpenTracing
So what are the material differences between OpenTelemetry and OpenTracing? Why do we need another new standard?
The major technical differences are:
- OpenTelemetry’s core library is the
Tracer
implementation - the traces are created and correlated using OpenTelemetry calls and then only during the export process do the traces hit any vendor-specific code. This makes the performance of OpenTelemetry very consistent regardless of what vendors end-users choose. In contrast, with OpenTracing all of the real calls are done by a vendor-specific implementation of the OpenTracing APIs - so as a library author you could have a great set of benchmarks using a Zipkin OpenTracing library but not-so-great ones using a Jaeger OpenTracing library. I prefer OpenTelemetry’s approach here. - OpenTelemetry supports metrics instrumentation in addition to tracing - a library author...