OpenTelemetry .NET SDK progress
Thanks Ankit Srivastava for preparing this article and Sourabh Shirhatti and Tarek Mahmoud Sayed for review.
Recently we announced that OpenTelemetry is officially in beta. As many SDKs are being tried out and specifications are wrapping up, we are making some more changes to the OpenTelemetry .NET SDK and are even planning to move parts of our SDK to the .NET framework itself. Read on to find out more and see how you can participate in this discussion and provide us feedback.
We are delighted to announce some of our .NET plans for the OpenTelemetry project. We believe in the project’s vision of making telemetry a built-in feature of all software, and we are constantly working towards this vision by defining a multi-language, multi-vendor standard for distributed tracing, metrics, and other important signals. As one of our major goals we want to ensure a smooth integration between OpenTelemetry and .NET, for both developers and library authors.
Today distributed tracing instrumentation is only added to a few critical libraries such as ASP.NET Core or the HttpClient implementation in .NET. This is done via the Activity API, which is built-in into .NET. While working on the OpenTelemetry .NET SDK, we recognized how confusing it could be to have both APIs. The Activity API has a smaller feature set and can be difficult to use, while OpenTelemetry’s separation from .NET makes it challenging for library authors and the framework itself to take a dependency on it.
As part of our efforts, we are adding to the existing Activity object model and creating a new way to listen to the Activity events (e.g. Start and Stop).
This should provide developers with the following:
1) Stronger contracts between in-proc producers and consumers of distributed tracing data, and a richer set of information that Activity can represent and streamlined calling patterns for typical scenarios.
2) Additionally, app developers can now simply add a reference to the OpenTelemetry SDK NuGet package and all the activity-based instrumentation of their codebase, 3rd party libraries as well as runtime will get logged and collected.
Library authors can simply write to a platform standard API that doesn’t force any specific dependency on the library users, but lights up in a predictable way when OpenTelemetry (or any other agent) is present.
As next steps, it is also our mutual goal with the Open Telemetry community to eliminate the current TelemetrySpan type and use Activity as the .NET representation of OT’s Span concept. We’ll be working towards this goal.
Participate and give feedback
You can find more information on how Activity may replace Span and how .NET API may look like here: github.com/dotnet/designs:proposed/activity-improvements.md
Associated Github Issue: https://github.com/dotnet/runtime/issues/31373
Please comment and send your feedback. We believe that this work will put OpenTelemetry closer to its North Star and make all applications observable out of the box.
