Change tracing levels for instrumentation

[etrombly]

• I have looked for existing issues (including closed) about this

Bug Report

I'm currently logging my application to syslog, and have a ton of 'call;' and 'get_record;' events that aren't very useful. If you could change the span in call() to the tracing level, and the same for get_record:

#[tracing::instrument(skip(self), err, level=Level::TRACE)]

It would be really helpful. Or possibly setting tracing as a feature, but that would be a lot more work.

Version

Platform

Crates

Description

[Snapstromegon]

I came across the same thing today and at least this line seems to spam:

tower-sessions/src/service.rs

Line 181 in a07bb7a

let span = tracing::info_span!("call");

[etrombly]

I'm not using tracing though, I'm using the syslog crate. I don't want trace spans to show up in my application logs at the info level, but I do want events from other application components at the info level.

It looks like the actual issue is you have the log feature enabled, https://docs.rs/tracing/0.1.40/tracing/#emitting-log-records. It says that those messages should be at the trace level, but I have my logs set to Info, and they still show up.

you could turn that off if you don't want to change the LevelFilter to Trace.

[maxcountryman]

Please read the docs re the log feature: it's meant to be enabled as it is.

I would certainly recommend using tracing and not other logging crates.

However, if you need to use syslog then you may be able to use something like syslog-tracing; using a proper subscriber ensures that empty spans aren't logged.

[Snapstromegon]

I actually resolved this for myself, by just disabling all "tracing::span" logs like this:

env_logger::builder()
        .filter_level(log::LevelFilter::Info)
        .filter_module("tracing::span", log::LevelFilter::Error)
        .init();

Nevertheless I think that this span should be Level::TRACE and not Level::INFO.

[maxcountryman]

As I mentioned, reading the tracing docs will help you configure this to your specific needs.

We don't make library-level changes for specific use cases so there's no need to make any further changes.

[Snapstromegon]

After switching to a purely tracing based logging setup, the spammy log output is indeed gone without any additional setup.

From taking a look at it (and with my limited understanding of the tracing crate as I have only used the fundamentals from it), I right now still think that the referenced span should be at debug level (or even trace), but I want to learn more about tracing actually works / is meant to be used before further commenting on this.

[etrombly]

I switched over to syslog-tracing, with some additional configuration I was able to get the output I wanted. I appreciate the work you've put in to this crate, it works really well. It would be nice if you'd be open to setting the "log" feature on tracing as a feature on your crate as well though, it would have saved me a lot of effort, and I'm sure it'll come up again for other users.

[maxcountryman]

I'm not interested in making changes to this. The log feature is being used as intended and it's up to downstream consumers to decide how they want to consume tracing output. This is out of scope for the crate so I certainly would encourage folks to consume the documentation material around tracing itself to ensure their use cases are being met.