capnslog: Set some defaults, propose a CoreOS formatter #28
Conversation
|
@barakmich Maybe move the time to the first col? |
|
Oh my. whatever the default formatter is it is going to make its way into journal logs which already has timestamps and so on, making them heck to read (etcd has long had this problem). I'm fine with providing a verbose format for when running a tool outside of systemd/journal but otherwise it is a load of noise. :( |
|
Yes, please no timestamps, "levels", etc if we detect we are running under systemd. Ideally capnlog will detect these cases and write to the journal instead with the Send method: https://github.com/coreos/go-systemd/blob/master/journal/send.go#L61 |
|
Just to illustrate here is what this would look like once it lands in the journal: |
|
That's fine -- I'm happy to write a syslog style formatter (in fact, I have already) -- if you actually switch it to running on syslog, then it will "Do The Right Thing" This is for replacing the text output, which exists today in terms of What's really terrible is that what's useful in systemd is not at all useful on the command line or through normal output -- which |
|
I might make another package/folder in this repo with coreos defaults -- but I want to create a great logging package here, and then we can deal with systemd :P |
|
Why wouldn't we build this with systemd in mind? We use systemd! The whole point of this package is to make logging easier for us. |
|
Maybe we could have a format that is especially designed for running softwares through systemd in CoreOS, which helps reach the best UX. @crawford IMO, this logging package is to uniform the logging of company-wide softwares, which do not always run in systemd. |
|
It's fine that we don't always run under CoreOS/systemd, but that is the default case. Why wouldn't our logging library reflect that fact? |
|
shameless +1 On Thu, Jun 11, 2015 at 3:04 PM, Alex Crawford [email protected]
|
|
Alright, let's make everyone happy: If we're running under PID 1, we're pretty much running as a daemon or systemd unit. Let's speak natively to systemd, if we can (sysvinit will not see it as enabled and default to dev-mode): (You can't see the bold and the red, but yay, native log level translation) But if you're running as a dev, you get the usual style above. (Or, incidentally, under docker, I would imagine which does its own process tree and log collection) Win/win. What do you think? (I'm not included in Semaphore though I have an account -- i added go-systemd as a dependency, and it needs to be fetched, to make the build green) |
|
Sounds good. |
|
@barakmich Sounds good to me |
|
Build fails? |
|
@yifan-gu Needs dependencies which @barakmich can't add via go-get due to no permissions in semaphore. |
|
@barakmich Any progress on this one? |
|
Made changes. Still treats systemd correctly. Semaphore green. PTAL. |
|
My only concern is we call one of these the Otherwise LGTM |
|
Maybe PrettyFormatter? |
Sounds good. |
|
+1 on renaming CoreOSFormatter to PrettyFormatter |
|
Done |
|
LGTM |
capnslog: Set some defaults, propose a CoreOS formatter
Chasing #26.
This is a little bold, but somebody's got to take a position and go for consensus. Here's some thoughts on sane defaults and a real CoreOS formatter.
The notion is as follows: we have a common log format, for which I'm proposing this:
But wait, there's more! A built-in debug flag to the CoreOS formatter yields the following:
The notion being that a new standard
--debugflag for CoreOS apps can (a) drop the log level to debug or trace and (b) start tracing code lines (which is expensive in normal operation).I designed the format for greppability and visual cues, without using ANSI color.