RFC: tokio-tracing compatible layer

[andylokandy]

By adding a tokio-tracing compatible layer to minitrace, we can provide a low-overhead tracing solution for tokio applications, combining the performance benefits of minitrace with the convenience and familiarity of tokio-tracing.

Initial thoughts:

• Collect spans generated by tokio-tracing, convert and attach to minitrace spans.
• Reports span generated either by minitrace or tokio-tracing by minitrace.

cc @zhongzc

[andylokandy]

@dotansimha I noticed mix usage of minitrace and tokio-tracing in Conductor, would the compatible layer help?

[dotansimha]

@dotansimha I noticed mix usage of minitrace and tokio-tracing in Conductor, would the compatible layer help?

At the moment we are using tracing only for logging and some performance information. We are not using it to generate trace spans. These logs and performance info are internal to the service at the moment.
We are using minitrace to create spans for things that the user want to ship externally (see https://the-guild.dev/graphql/gateway/docs/plugins/telemetry).

Regarding your question, I don't see a real need at the moment to have a unified setup, as we are using each library for different purposes.
I'm actually considering another alternative: drop tracing and replace it with the log crate.

[zhongzc]

By reversing your initial thought, we might be able to realize performance gains:

minitrace is in charge of span generation, and tokio-tracing collects the spans produced by minitrace.

[andylokandy]

Both direction have their use case, but I think it's a fact that only application could include a compat layer, and most libraries are using tokio-tracing, therefore only the direction of tokio-tracing to minitrace is needed in practise.

[zhongzc]

So low-overhead cannot be achieved. Are there any scenarios for this requirement?

[andylokandy]

it's temporary for transition. The ultimate goal will be completly removing the compat layer in the build graph.