Bevy Log Output to Files

[samcarey]

What problem does this solve or what need does it fill?

Bevy log can output to console, but I don't know of a way to easily output this to the filesystem as well.
It seems to me that this would be a common use case, where an app could log what happens to a file for later inspection (especially if it crashes for some reason).

What solution would you like?

I'm imagining an interface something like this:

// Either use a RollingFileAppender that you can configure yourself, or just simply output to some path...
// Maybe someone can think of better options...
enum FileLogger {
    Rolling(RollingFileAppender),
    Path(PathBuf),
}

app.insert_resource(LogSettings {
    ...
    file: vec![
        "log1".into(),
        tracing_appender::rolling::hourly("logs", "log_prefix").into(),
    ]
});

where log output would be duplicated in the console and all FileLogger configurations.

What alternative(s) have you considered?

I currently have a working workaround in an app where I disabled the LogPlugin, and substituted my own that's exactly the same except that I replaced the let subscriber... line with:

let file_appender = tracing_appender::rolling::hourly("logs", "log"); // This should be user configurable
let (non_blocking, worker_guard) = tracing_appender::non_blocking(file_appender);
let file_fmt_layer = tracing_subscriber::fmt::Layer::default()
    .with_ansi(false) // disable terminal color escape sequences 
    .with_writer(non_blocking);
app.insert_resource(worker_guard); // have to keep this from being dropped

let subscriber = subscriber.with(fmt_layer).with(file_fmt_layer);

So it'd be nice if this were built in so I don't have to duplicate the LogPlugin code.

[djeedai]

Since Bevy delegates logging to the tracing and tracing-subscriber crates (at least, on most platforms), shouldn't implementing tracing sinks/subscribers best left to user code, and instead Bevy to expose what's necessary for users to do so?

It seems that implementing file logging internally in Bevy is opening the door to more asks in the same vein (logging to networked file, logging to remote networked host, logging to syslogd, etc.), with all the variants/options each user may want for their app. Not to mention the extra per-platform work.

I'm not disagreeing file logging is needed (I agree that's important to have), but rather how we get there. Instead of the proposed approach, can we rather expose what's necessary for you @samcarey or someone else to simplify writing a file output customized to your use case? What is LogPlugin missing or what is it doing that forced you to avoid/replace it? Is it a matter of exposing the underlying tracing object(s)?

[samcarey]

Exposing what's necessary would work for me!

In order to factor out my file-logging-specific code, I could imagine having a field on the LogSettings struct like extra_layers: Vec<tracing_subscriber::fmt::fmt_layer::Layer>.
Then the LogPlugin could do something like

for layer in settings.extra_layers.iter() {
    subscriber = subscriber.with(layer);
}

Would that interface be general enough to cover most other cases like you mentioned?

[brandon-reinhart]

I would like to be able to add arbitrary layers to Bevy's tracing subscriber. While logging to files is nice, I would also like to direct trace messages to the console, for example.

[brandon-reinhart]

An alternative might be to raise an event on trace.

[DasEtwas]

I'm also interested!

[james7132]

This isn't wholly complete just yet, but the ability to customize the subscriber (added in #10822) seems to allow for this.