Interoperability Tracing and OpenTelemetry

[hdost]

I'm a contributor from the opentelemetry-rust project and after some recent interesting conversations in our SIG meeting. The topic was brought up about possible overlap of the API and maybe finding a way that provides a greater support for people in the rust community.

We have talked about looking at the overlapping APIs and possibly finding a path forward which would avoid multiple instrumentation APIs but possibly and providing the opentelemetry SDK which takes advantage of a singular implementation. This came from how things are done within the opentelemetry-dotnet SIG.

[davidbarsky]

That's certainly an interesting to hear—what do y'all have in mind? For what it's worth, I've found your meeting notes, and I—biased, obviously—would not be opposed if the primary tracing Span/Event API became the primary API, with opentelemetry-rust being a more a serialization layer, exporter, and set of extension traits to better support propagating distributed tracing IDs.

Looking over

tokio tracing is not a stable API

I suppose that is strictly true, in the tracing crate is at 0.1, but I think we have a track record of not breaking people for the last several years. Of course, if tracing-opentelemetry wants to reach 1.0 while depending on tracing 0.1, a release of tracing 0.2 would necessarily be a breaking change on tracing-opentelemetry, which might not be an ideal outcome for y'all.