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");

[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.

[nmabhinandan]

Either set your desired tracing level (to exclude INFO for example) or use tracing (i.e. not log) directly. You can learn more about how to use tracing by reading the tracing docs.

Would it be possible for me to change the log level of tower-sessions from TRACE to DEBUG?

UPDATE:
It is possible. When creating your subscriber you can override things in addition to env variables.

        .with_env_filter(
            tracing_subscriber::filter::EnvFilter::from_default_env()
                .add_directive("tower_sessions=debug".parse().expect("Failed to parse directive")),
        )

[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.