Disable message coloring for dependent crates

[HaronK]

Hi all!

I've created my tracing_subscriber with .with_ansi(false) and while it doesn't show any colors for timestamp and level fields it still do coloring of some messages coming from dependent crates (rocket, sqlx, etc.) that are using log crate.
Is it possible somehow to disable coloring completely?

Actually my configuration has 2 output layers: one outputs into the file (using tracing_appender) and here I don't need any coloring, and second outputs to the console with full coloring.

I suppose it should be done in .with_ansi(...) method or there should be a separate one, i.e. .with_log_ansi(...).

Or is there probably a simpler way to do this?

[hawkw]

How are the messages from the log crate being recorded? Are you using tracing_subscriber's integration for log, or are you setting a log::Logger as well as a tracing subscriber?

[hawkw]

In the case of rocket, rocket emits the colors as part of its log messages. Since rocket uses the log crate rather than tracing, there's no way that tracing-subscriber can tell rocket whether or not to use colors. Instead, though, rocket does provide a configuration option to disable colors: https://api.rocket.rs/v0.5-rc/rocket/struct.Config.html#structfield.cli_colors

I'm not familiar with sqlx, so I'm not sure if it's doing something similar, but my guess is that it probably is?

[HaronK]

My log initialization code looks like this:

fn init_log(log_folder: impl AsRef<Path>) -> Result<WorkerGuard, BoxDynError> {
    let file_appender = tracing_appender::rolling::daily(log_folder, "my-app");
    let (non_blocking, guard) = tracing_appender::non_blocking(file_appender);

    let filter_layer = EnvFilter::try_from_default_env().or_else(|_| EnvFilter::try_new("warn"))?;
    let file_output_layer = fmt::layer()
        .with_ansi(false)
        .with_writer(non_blocking)
        .with_target(false);
    let console_output_layer = fmt::layer().with_ansi(true).with_target(false);

    let registry = tracing_subscriber::registry()
        .with(filter_layer)
        .with(file_output_layer)
	.with(console_output_layer).try_init()?;

    Ok(guard)
}

so there is no any specific code for log crates messages treatment. I think it's done automatically by tracing crate.
As you can see here I'm using .with_ansi(false) for file output but it works only for timestamp and level fields. So the output I get is something like this:

2021-11-29T14:00:22.225140Z  WARN Configured for debug.    
2021-11-29T14:00:22.225461Z  WARN address: �[1;49;39m127.0.0.1�[0m    
2021-11-29T14:00:22.225929Z  WARN port: �[1;49;39m8000�[0m    
2021-11-29T14:00:22.226354Z  WARN workers: �[1;49;39m8�[0m    

From your comment about Rocket framework I understand there is no direct way to switch on/off coloring for messages.
Would it be possible to add some kind of filtering to subscriber where I can modify message before it goes to file or console?
Something like layer filtering for the registry above but for subscriber.

[hawkw]

From your comment about Rocket framework I understand there is no direct way to switch on/off coloring for messages.

I don't think that's the case, actually. You can use Rocket's configuration system to switch off coloring of log messages. I believe this can be done by adding a line in Rocket.toml, like this:

[default]
# ...
cli_colors = false

Alternatively, I believe you can use rocket::custom() to override the cli_colors setting programmatically rather than in your config file.

Would it be possible to add some kind of filtering to subscriber where I can modify message before it goes to file or console?
Something like layer filtering for the registry above but for subscriber.

It would be possible to add some code to the subscriber to strip out ANSI escape codes from the formatted message, yes. This would come at some performance cost, however. I would probably do this by writing a wrapper around a type implementing std::io::Write, that uses a regular expression or something to split the written bytes on ANSI escape codes, and then forwards the bytes without the ANSI escapes to the inner writer.

I would probably not suggest this approach, though, given that it introduces a performance cost at runtime. Since you can configure Rocket to not emit ANSI color escapes, as I mentioned above, that's probably the best approach, as it doesn't introduce a runtime performance cost.

Hope that helps!

[HaronK]

Hi hawkw, thank you for suggestions. I would probably go with the second approach since performance is not critical in my case and I also have to disable coloring not only from the Rocket library. Additionally I need to keep coloring when I output to the console so using Rocket config file won't help in this case.
Anyway thanks for the help!