search

clap-rs / clap-log-flag

Add a logger to CLIs using structopt
Apache License 2.0
10 stars 1 forks source link

add flag to log to syslog #5

Open yoshuawuyts opened 5 years ago

yoshuawuyts commented 5 years ago

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

killercup commented 5 years ago

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 notifications@github.com:

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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