Skip to content
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

A way to force a particular a span! to be always enabled regardless of the rest of the configuration #978

Open
MOZGIII opened this issue Sep 15, 2020 · 2 comments

Comments

@MOZGIII
Copy link

MOZGIII commented Sep 15, 2020

Feature Request

There's no way to guarantee that a particular span is enabled. We'd like to have the ability to force-enable the Span, regardless of the current log level.

Crates

tracing = "0.1.15"
tracing-subscriber = "0.2.2"
tracing-log = "0.1.0"

Motivation

I want to:
a) use tracing::spans fields as labels at metrics crate, see metrics-rs/metrics#87;
b) be able to test this integration.

For both use cases, it'd be pretty good to have the ability to create a span even when the env filter is set to off.

In our test code, when log level is set to off (which is the default for tests), the Span is always disabled:

#[test]
fn test_labels_injection() {
    trace_init(); // inits the tracing in the test environment, defaults to `off`

    let span = span!(Level::ERROR, "my span", component_name = "foobar");
    if span.is_disabled() {
        panic!("span is disabled");
    }

    // ...
}

More info here: vectordotdev/vector#3888

Proposal

Alter the span! macro in such a way that it's possible to force the actual span being created, instead of it being Span::none().

Alternatives

There is a potential way to create such Span manually, by borrowing Callsites and doing other very implementation-specific tricks, but it's not a maintainable solution.

@jyn514
Copy link
Contributor

jyn514 commented Oct 6, 2020

How would this interact with STATIC_MAX_LEVEL? To avoid a performance hit, I think the static max level would have to take precedence.

@MOZGIII
Copy link
Author

MOZGIII commented Oct 6, 2020

I imagine this as something that goes entirely around the level configurations of any kind. Performance hit or not, this is some functionality that has to be on unconditionally. I think this is the whole point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants