I've got the impression that
tokio-console and its
console_subscriber are based on the
tracing crate, but I don't see tracing's spans anywhere in the tokio console. At all.
I'd expect to be able to see all active tracing spans in real time, or at very least spawned tasks showing which spans were active/entered when they were spawned.
But my view in the tokio console has empty
Name column for every task, task details are mostly all the same — empty, and task locations are just vague code locations like
/usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.32.0/src/task/local.rs:587:35, rather than locations of spans in my code.
#[tracing::instrument] on everything async. I've tried
let _x = span.enter(), but the console shows no spans at all.
Have I failed to set it up properly, or tokio-console is not supposed to show tracing's spans?
Tokio console doesn't show tracing events or spans.
I would say "doesn't show yet", as it's something that I'd certainly like to see in there, but I think that is missing the point.
Tokio console's primary job is showing you the state of your tokio runtime (or runtimes) at a task and resource level. To do this, tokio is instrumented with tracing spans and events, which is why there is a tracing subscriber (
console-subscriber) involved. This subscriber only collects the instrumented traces, it doesn't collect generic traces at all.
I hope that this helps clarify what you're seeing.
Have you read the docs.rs page for tokio-console? That might help give some more insight. If you think it's still confusing, please let me know.
Now to the 2 points you raised about the console API.
- tokio console has empty
Name column. To get a task name, you need to use Tokio's task builder API: Builder in tokio::task - Rust
- locations are things like
.../tokio-1.32.0/src/task/local.rs:587:35. This is a bug in the instrumentation (there is a missing
#[track_caller] attribute. Thanks for finding this, I'll fix it now and that should be in the next tokio release.
Thank you for explanations.
I think root of my confusion comes from the fact that the
console_subscriber is explicitly a tracing subscriber instance. I got impression that this is its public API, and not merely an implementation detail. I assumed that this implied it was meant to be used like
tracing-log or any other tracing subscriber, for everything including user-provided spans.
The integration instructions only say to run
console_subscriber::init(), and don't explicitly say that the
Builder::name() is needed to name the tasks. I eventually found the task builder API, but it was documented as unstable, so I assumed it exists for the already-unstable console_susbcriber to use, not for me.
Almost all of my tasks are spawned through a couple of helper functions in
main.rs, so everything my server spawns has the same file and line number in tokio console.
I'm using actix-web, and it also spawns everything from a couple of central functions in actix-rt. So I don't have any tasks with useful locations. I would never guess that
tracing-based console would rely on
#[track_caller], which I can't add to actix's internals.
Yeah, this is also sort of an implementation detail. It's a way to pass along the "real" calling location (in user code, not in library code) of something. Obviously this is used when panicking, but it can also be used in cases like this for improved usability.
The tokio task builder API basically only exists for the tracing instrumentation in tokio, that name isn't used or available anywhere else. It's just that the main use case for the tracing instrumentation is to feed into tokio-console.
I'll have a think about how to make this clearer in the documentation. Thanks for your feedback.
Oh, and maybe Actix could be convinced to add
#[track_caller] where appropriate to improve the usability of Actix with tokio-console.