Standardize on span naming #41
Comments
|
I think we should probably care about just a standardized span name, rather than a standardized span name and For example, @nikomatsakis mentioned wanting to instrument The other thing is whether Perhaps one option would be to require overridden targets beginning with |
|
To help avoid name collision, we can probably include a prefix. e.g. "runtime.spawn". |
|
+1 for @carllerche's suggestion of |
|
Ref: tokio-rs/tokio#3954 with regards to figuring out how to name resource spans. My guess is we need a "kind" annotation to identify resource spans vs. operation spans as well. |
The instrumentation conforms to the standardized naming requirements for `tokio-console` (see tokio-rs/console#41), so they will show up in the console. The `tracing` dependency is an opt-in feature flag. Signed-off-by: Eliza Weisman <[email protected]>
|
I believe #68 completed the console side work for this. We still need to update tokio to use the new naming scheme, though. |
Currently, the per-task spans generated by Tokio's `tracing` feature have the span name "task" and the target "tokio::task". This is because the console subscriber identified tasks by looking specifically for the "tokio::task" target. In tokio-rs/console#41, it was proposed that the console change to a more generic system for identifying the spans that correspond to tasks, to allow recording tasks belonging to multiple runtime crates (e.g. an application that uses Tokio for async tasks and Rayon for CPU-bound tasks). PR tokio-rs/console#68 changed the console to track any spans "runtime.spawn", regardless of target (so that the target can be used to identify the runtime a task came from), with "tokio::task/task" tracked for backwards-compatibility with the current release version of tokio. This branch changes Tokio's span naming to the new convention. I also rearranged a couple fields so that the task's kind field always comes before the name and spawn location, since it's likely to be the shortest, and renamed the `function` field on blocking tasks to `fn`, for brevity's sake. Signed-off-by: Eliza Weisman <[email protected]>
Currently, the per-task spans generated by Tokio's `tracing` feature have the span name "task" and the target "tokio::task". This is because the console subscriber identified tasks by looking specifically for the "tokio::task" target. In tokio-rs/console#41, it was proposed that the console change to a more generic system for identifying the spans that correspond to tasks, to allow recording tasks belonging to multiple runtime crates (e.g. an application that uses Tokio for async tasks and Rayon for CPU-bound tasks). PR tokio-rs/console#68 changed the console to track any spans "runtime.spawn", regardless of target (so that the target can be used to identify the runtime a task came from), with "tokio::task/task" tracked for backwards-compatibility with the current release version of tokio. This branch changes Tokio's span naming to the new convention. I also rearranged a couple fields so that the task's kind field always comes before the name and spawn location, since it's likely to be the shortest, and renamed the `function` field on blocking tasks to `fn`, for brevity's sake. Signed-off-by: Eliza Weisman <[email protected]>
The instrumentation conforms to the standardized naming requirements for `tokio-console` (see tokio-rs/console#41), so they will show up in the console. The `tracing` dependency is an opt-in feature flag. Signed-off-by: Eliza Weisman <[email protected]>
The prototype currently just looks for a span named
tokio::task::spawn, but if want to work for any "runtime"-like thingy, we probably should have a more generic name. It still needs to be unique enough that a user would be very unlikely to create a span with the same name.Besides task spawning, we also need to do this for wakers and resources too.
The text was updated successfully, but these errors were encountered: