-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Add support for adding custom log layers #7682
Conversation
After this comment #8101 (comment) for my PR
I think that the best approach would be to use |
Closing; similar work was completed in #10822. |
# Objective This PR is heavily inspired by #7682 It aims to solve the same problem: allowing the user to extend the tracing subscriber with extra layers. (in my case, I'd like to use `use metrics_tracing_context::{MetricsLayer, TracingContextLayer};`) ## Solution I'm proposing a different api where the user has the opportunity to take the existing `subscriber` and apply any transformations on it. --- ## Changelog - Added a `update_subscriber` option on the `LogPlugin` that lets the user modify the `subscriber` (for example to extend it with more tracing `Layers` ## Migration Guide > This section is optional. If there are no breaking changes, you can delete this section. - Added a new field `update_subscriber` in the `LogPlugin` --------- Co-authored-by: Charles Bournhonesque <cbournhonesque@snapchat.com>
Objective
LogPlugin
Solution
Subscribers
toLogPlugin
's settingsAdditional notes
Draft PR because how
extra_layers
is passed in (Arc<Mutex<Option<Vec>>>
) is pretty ugly. I'm not sure what the current idiom of lettingPlugin::build
take ownership of something is? Should it be in a resource instead?