Skip to content
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

Open
mladedav opened this issue Apr 21, 2024 · 0 comments
Open

Separate out Timings extension from FmtSubscriber #2946

mladedav opened this issue Apr 21, 2024 · 0 comments

Comments

@mladedav
Copy link
Contributor

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 the Timings struct and have FmtSubscriber (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 the Collector before the consuming Subscribe. 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 as on_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 - different Subscribe 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 respective Subscribe 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant