Currently, `tracing` spans are used to record HTTP access log entries.
These spans are recorded at the `INFO` level, in order to allow the use
of fast-path filtering for the more verbose `DEBUG` and `TRACE` levels
when running with the default tracing filter configuration
(`linkerd=info`) --- if no events will ever be enabled at a given level,
`tracing` can skip them more efficiently than when events with some
targets are enabled at that level. The access log spans are recorded
with a separate `_access_log` target, so that the default `linkerd=info`
filter does not enable them.
However, when running with a custom filter configuration that enables
`info` for all targets, the access log spans will be enabled even if
access logging is disabled. This means that these spans will be recorded
when they may not be needed to generate an access log. They also make
logs significantly more verbose when `DEBUG` events are enabled (only
debug and higher events will occur in these spans), which can make the
logs harder to parse.
This branch changes the per-layer filter used by the stdout logging
layer to explicitly disable the `_access_log` trace target, regardless
of the rest of the filter configuration. This way, a custom filter
configuration that globally enables the `INFO` level will not enable the
access log spans, and the spans will not be included in stdout logs even
if access logging is enabled. Since the layer that actually generates
the access log has its own, separate per-layer filter, the access log
spans will still be enabled _for that layer_, if and only if access
logging is actually enabled.
A potential longer-term solution is to rewrite the access logging code
to not use `tracing`, as was originally proposed. At the time, we opted
to use `tracing` to generate the access log because it seemed desirable
to have a single set of diagnostics that can generate different outputs.
However, in practice, it's probably better to keep general-purpose
debugging logs and access logging separate, as they are separate
concerns. A purpose-built implementation of access logging could avoid
issues like this one, and would also probably be more efficient --- it
wouldn't need to allocate strings to represent access log spans, and
could instead just store structured data that's formatted directly to
the output. But, the filtering change solves the immediate problem.
de97063b50