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.
I've slapped #[tracing::instrument] on everything async. I've tried info_span!(…) + 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.
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.