Better support for using tracing-log with the log feature
#204
Labels
Comments
This was referenced Jul 22, 2019
|
Of the potential solutions, the simplest might just be to have a global boolean flag indicating whether Alternatively, we could re-introduce more complex filtering to |
hawkw
added a commit
that referenced
this issue
Jul 23, 2019
## Motivation People writing libraries using tracing may wish to expose regular `log` support via the `tracing/log` feature. At the same time, to get tracing support for crates using `log`, users may turn to `tracing_log::LogTracer`. Enabling both means logging events twice. ## Solution This branch adds a `Builder` to the `tracing_log::LogTracer` type, which allows configuring the `LogTracer` to ignore log records with targets beginning with a certain string. This can be used to ignore any crates which are emitting log records via the `tracing/log` feature. Ideally, we would provide a way to do this automatically, without requiring configuration, but that'll take some thinking. The ability to ignore certain sets of log records may be valuable even if we have an automatic method for crates to signal that they are using the `tracing/log` feature in the future. I've also moved the `LogTracer` and `TraceLogger` types in `tracing-log` out of `lib.rs` into their own modules, since the main lib file was getting a bit lengthy. Refs: #204 Signed-off-by: Eliza Weisman <eliza@buoyant.io>
|
10,000,000 thanks for getting something working in #215! This already makes a huge difference |
hawkw
added a commit
that referenced
this issue
Sep 13, 2019
## Motivation Currently, when `tracing`'s `log` feature is enabled, all spans and events will emit `log` records as well as `tracing` events. When `tracing-log` is being used to convert `log` records into `tracing` events, this results in duplicate events being observed: those emitted by the event macros directly, and those generated from the log records they emit by `tracing-log`. ## Solution In `tracing-core` 0.1.6, we added an internal API for checking if a `tracing` subscriber has ever been set. In addition to the performance optimizations which this was initially intended to enable, this also gives us a way for `tracing` macros in libraries to check if a downstream application that depends on those libraries is actually using `tracing`. If `tracing` is in use and a subscriber has been set, the macros can be disabled. In a handful of cases, users _may_ wish to collect `log` records and `tracing` events totally separately. For example, `log` records might be output to the console while `tracing` is used to generate metrics or for performance profiling. In this case, there is an additional `log-always` feature flag which applications can set to enable all of `tracing`'s log records regardless of whether a subscriber is in use. In most cases where the `log` feature is currently used (libraries that want to emit both `tracing` and `log` diagnostics for their users), this will not be necessary. Fixes #204 Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature Request
Crates
tracing,tracing-logMotivation
People writing libraries using tracing may wish to expose regular
logsupport via thetracing/logfeature. At the same time, to get tracing support for crates usinglog, users may turn totracing_log::LogTracer. Enabling both means logging events twice.Proposal
Some way to pass knowledge of the
tracing/logfeature toLogTracerso it can skip those events?Alternatives
Hope that everybody exposes
tracing/logvia a feature flag from their crates, so that it can be disabled withdefault-features = false.The text was updated successfully, but these errors were encountered: