Closed szattila98 closed 1 year ago
Well as always I immediately find a solution after posting an issue, but not before searching for hours :D
I turned off the tracing-log
feature on tracing-subscriber
and it turned off all crate emitted logs. I am still curious if there are better options to tune the logs emitted to my liking.
You set the global log level to something like warn
and then set your crate log level lower (trace/debug/..). That way everything else is emitting only warn/error stuff and your own code can emit lower level errors.
Example from my code. Sets the global logger to warn
(so by default only warning and higher is emitted), and then lowers it for specific crates. Can get overridden by specifying your own RUST_LOG environment variable. So something like warn,my_crate=trace,notify=error
would set everything to warning levels, your my_crate
to trace and notify specifically to only errors (though just for demonstration, warn should be totally fine for notify).
Or you set the global one low (trace) and some specific ones high (warn) for this crate - but that usually doesn't work out, as pulling in axum/tokio will already get you a ton of those different crates.
You could even define your default log level to be higher (warn) for release builds and more verbose (trace) for debug, by using conditional compilation #[cfg(debug_assertions)]
.
Hello, I would like to use this crate in my application in an async manner inside
tokio::spawn
. I got it working fine but my problem is that every time a file event happens. It seems logs get published by thelog
crate. I use thetracing
crate in my application and these logs do not conform to the rules it sets. At first I thought that the logs are in a different span and that is why they are unruly but I made them use the current span and still they come. Can you give me some pointers how to filter out the logs emitted by notify? I could not find a way online, as it is kinda hard to google, given thelog
crate name :D