Hacker News new | past | comments | ask | show | jobs | submit login
Diagnostics with Tracing, a Unified Instrumentation System for Rust (tokio.rs)
89 points by thramp 65 days ago | hide | past | web | favorite | 11 comments

Hi! I'm the author of the post & the primary maintainer of `tracing`— happy to answer any questions!

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!

We absolutely want to integrate with OpenTelemetry, and I'd love to work with the OpenTelemetry community on that. We have an issue (https://github.com/tokio-rs/tracing/issues/89) tracking integration with distributed tracing systems --- it would be great to get input from OpenTelemetry folks if any of y'all are interested!

Cool beans!

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?

dtrace works great with Rust programs - why would something new need to be implemented?

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.

having used lldb and gdb with Rust often, I'm not sure what you mean by "proper online debugging". Could you elaborate?

Does this use a thread local approach, or a Go-style ctx parameter? Since it's async I expected to see the ctx approach, unless the underlying async executor/framework also supports a thread local-ish capability?

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!

I wonder how much can be infered from runtime execution to create useful traces..

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact