This adds a test that when a field value is recorded after a span is
created, and the new value changes the filter level for the span, the
filter updates accordingly.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch moves the field filter tests to their own test file,
separate from the tests for target filters which include directives that
match all callsites. This should fix the occasional flakiness in the
field-filtering tests when the tests are executed concurrently in a
particular order.
I've run the tests in a loop for about 4 minutes on my machine, and I
haven't seen any flakiness so far.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Currently, `tracing-fmt` provides an implementation of `env_logger`-like
filtering directives. However, there are two issues:
1. The implementation is specific to `tracing-fmt` and does not work
with other subscribers.
2. Filtering dynamically based on field values is not supported.
Now that the `Layer` type has been added to `tracing-subscriber` (see
#136), we can implement filtering generically, as a `Layer` that can
wrap other `Subscriber`s to provide a particular filtering strategy.
## Solution
This branch re-implements the `env_logger` style filtering in
`tracing-fmt` as a `tracing-subscriber::Layer`. The new `Layer` type
implements dynamic filtering on span fields, in addition to the
functionality of the `tracing-fmt` implementation. I've also added a
wrapper type to support runtime reloading of a `Layer`, similarly to
the `Reload` type in `tracing-fmt::filter`, but more general.
Finally, I've added some tests and an interactive demo for the new
filtering. The example runs a simple web service with a load generator,
and allows users to explore the `tracing-fmt` output from the example
service by dynamically reloading the filter settings.
## Notes
This is admittedly a pretty large branch, but I think it makes the
most sense to merge everything together, since the example requires
both the filter implementation *and* the reload layer. I've tried to
make sure the most complex bits of the filtering code has comments
describing the implementation, but please let me know if anything
is unclear.
Also, there is a lot of room for potential performance improvements
in the current filter implementation. I've left comments on some code
that I think could probably be made more efficient. Ideally, though,
any future optimization work ought to be guided by benchmarks as well.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
