-
Notifications
You must be signed in to change notification settings - Fork 710
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate out Timings
extension from FmtSubscriber
#2946
Comments
This was referenced Jul 23, 2024
joshka
added a commit
to joshka/tracing
that referenced
this issue
Aug 17, 2024
This allows for the timing subscriber logic to be composed and used by any subscriber rather than just users of the fmt subscriber. TODO: work out how to properly configure the fmt subscriber to use the timing subscriber as a layer. Fixes: tokio-rs#2946 Replaces: tokio-rs#3038
In #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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.The text was updated successfully, but these errors were encountered: