Motivation

We should provide a good experience when users are trying to inspect why vector may have failed. Vector should provide methods in which developres/users can extract extensive debug information on specific components.

Proposal

Write extensive documentation on how users can use the LOG environment variable to dig deeper into the logs of vector to diagnose certains issues. These issues can range from high level topology issues to low level tokio task issues.

Using the LOG environment variable should follow the way directives are setup within tracing-subscriber. These filters follow roughly what https://docs.rs/env_logger/0.7.0/env_logger/ provides but with additional features to support spans. This additional support is important to allow us to dig deeper into specific components. Possible questions that can be answered are: why are all my sinks failing? why did my http sink fail to gzip my body? why didn't my source task wake up the inner task? All of these questions can be answered by providing the correct filter.

Example

This will only provide trace logs for events created within the vector crate and at the trace level.

$ LOG=vector[sinks]=trace vector -c my_config.toml

This will provide debug logs for just the "http" typed sinks.

$ LOG=vector[sinks{type="http"}]=debug vector -c my_config.toml

This will provide debug logs for our HTTP client from the hyper crate for just the "http" typed sinks.

$ LOG=hyper[sinks{type="http"}]=debug vector -c my_config.toml

Blockers

Only one issue is blocking supporting all of these features: https://github.com/tokio-rs/tracing/issues/367.