Open mladedav opened 5 months ago
In https://github.com/tokio-rs/tracing/pull/3063 I made a draft stub of how this might look for feedback purposes, as I want this for some tracing stuff I'm exploring in Ratatui. I didn't look at solving the configuration part of this yet.
Feature Request
Crates
tracing-subscriber
Motivation
The timings shouldn't be tracked by the formatting subscribe. It's implementation was probably also copied when
tracing-opentelemetry
was created and now there are two slightly different implementations doing the same thing.This seems like something a single layer in the subscriber should be doing and then the other layers (such as fmt and otel) can simply load the extension and use the value if needed.
Proposal
Extract the timings implementation as its own
Subscribe
, publicly expose theTimings
struct and haveFmtSubscriber
(and eventually OpenTelemetry) use that.The drawback is that now everything works out of the box while with this change, timings can only work if the
Subscribe
for timings is added to theCollector
before the consumingSubscribe
. Otherwise the extension may be missing or it may contain outdated information.This could be fixed by having a way to register other
Subscribe
-like functionality in methods such ason_register_collector
but that's currently impossible as far as I see. I do think that's something that could be useful in other areas as well - differentSubscribe
implementations reusing and registering required functionality. I'd like to know opinions on this, but I guess that if there is no opposition, this should maybe have its own issue.Alternatives
Have all the implementations call the timings
Subscribe
methods directly in their respectiveSubscribe
methods. That would at least deduplicate the code but the timings would still be measured twice unless they would somehow synchronize about who should do it.