add flag to log to syslog

[yoshuawuyts]

We should add a {flag, method, option} to enable logging to the syslog provider.

An interesting thing here is that systemd sets $JOURNAL_STREAM when it manages a process, so we could catch that and automatically switch it over to the syslog provider. This opens a few questions:

1. Do we need to add a flag for this? Is detecting an env var enough?
2. Should we remove the --pretty option, and always use a pretty-printer. Right now there's not too much difference between the two anyway.
3. Can we still apply filtering using the env logger provider?

Refs

• https://unix.stackexchange.com/a/313727/118157

[killercup]

Good idea. Would probably be easiest if we switched to a crate like slog that has drains for syslog and journald readily available.

…

Am 12.10.2018 um 09:06 schrieb Yoshua Wuyts ***@***.***>: We should add a {flag, method, option} to enable logging to the syslog provider. An interesting thing here is that systemd sets $JOURNAL_STREAM when it manages a process, so we could catch that and automatically switch it over to the syslog provider. This opens a few questions: • Do we need to add a flag for this? Is detecting an env var enough? • Should we remove the --pretty option, and always use a pretty-printer. Right now there's not too much difference between the two anyway. • Can we still apply filtering using the env logger provider? • https://unix.stackexchange.com/a/313727/118157 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[epage]

Is the intention of this crate to be focused on CLIs or to be a general logging configuration crate?

If CLIs, I'd suggest sysalog support would be outside of the scope. I can't imagine rg, fd, tokei, cobalt, or many other CLIs would ever want syslog support, that seems more intended for daemons and the like.

But who knows, maybe there is something I'm missing here.

[yoshuawuyts]

If CLIs, I'd suggest sysalog support would be outside of the scope. I can't imagine rg, fd, tokei, cobalt, or many other CLIs would ever want syslog support, that seems more intended for daemons and the like.

Good point! -- right now I'm building out a service, and I think you're right it doesn't make sense there. Perhaps we ought to create one clap-log-flag and a clap-slog-flag crate? Or perhaps feature flag it to disable?

Good idea. Would probably be easiest if we switched to a crate like slog that has drains for syslog and journald readily available.

Ideally we could still support inline calls to log::info!() and the like. For example tokio uses those, and they can be super useful to help with debugging.

[epage]

Ideally we could still support inline calls to log::info!() and the like. For example tokio uses those, and they can be super useful to help with debugging.

Slog has adapters for these situations