Diagnostics with Tracing, a Unified Instrumentation System for Rust

For me, the main advantage of tracing is dynamically instrumenting systems, including production, without significant overhead when instrumentation is not attached.

One of the implementations of this pattern is dtrace (http://dtrace.org/blogs/about/)

Are there any plans to have something similar to this? I.e. dynamically attach to a running process with tracing capabilities, and inspect/aggregate/filter/analyze live events?

I have to admit that when I heard the title I assumed it was a project to introduce proper online debugging to Rust.

It’s a good project nevertheless. Rust needs that.

Hi Mycoliza! One of the authors of OpenTelemetry here. It would be great to see an OpenTelemetry implementation in Rust. If you're interested in bootstrapping a group to work on that, please let me know!

This is a great question, and the answer is "it's complicated". The core `tracing` libraries don't use either; instead, they provide an interface for `Subscriber`s (the pluggable component that collects & records trace data, kind of like a logger but fancier) to implement a way of tracking whatever contexts they care about. The typical approach is for the subscriber to track a current span per thread, but they could implement something else.

`tracing` instruments futures by wrapping them with a future combinator that enters a span each time the future is polled; the `#[tracing::instrument]` attribute will do the same thing under the hood when used on an `async fn`. This is kind of analogous to the Go-style context parameter, in that the contexts are stored in structures or on the stack, except that users don't have to manually pass the context around.

The core library provides an option to set the `Subscriber` that collects trace data in a scope; this does use thread-local storage. However, the default dispatcher can also be set globally (like the `log` crate), and the use of thread-locals is feature-flagged so it can be turned off by `no-std` users.

Finally, I have some thoughts on an abstraction for "context-local" storage that allows the user to customize the context that's used to shard the data. This could be used like a user-space version of OS thread-locals when threads are present, but it could also be used by bare metal code for (say) having a context for each CPU core. This would allow subscriber implementations to track a span per thread by default, but let embedded or kernel-mode users override this without having to reimplement the rest of the subscriber logic. This is still in the early stages though.

Hope that all makes sense; I'm happy to answer any further questions!