Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

logformat enhancement #54

Open
notzippy opened this issue Mar 13, 2015 · 2 comments
Open

logformat enhancement #54

notzippy opened this issue Mar 13, 2015 · 2 comments

Comments

@notzippy
Copy link
Contributor

It would be nice if I could specify a series of keys into TerminalFormat so that I could layout the key values in a specific named order like

func TerminalFormat(contextKeys []string, "[%s] [%s] %s %s %-40s %s") log.Format { 

Missing context keys would be passed empty strings, unused context items would be added to the end

BTW noticed the following in format

    // try to justify the log output for short messages
    if len(r.Ctx) > 0 && len(r.Msg) < termMsgJust {
        b.Write(bytes.Repeat([]byte{' '}, termMsgJust-len(r.Msg)))
    }

That could be removed by changing the above format statements to

    if color > 0 {
        fmt.Fprintf(b, "\x1b[%dm%s\x1b[0m[%s] %-40s ", color, lvl, r.Time.Format(termTimeFormat), r.Msg)
    } else {
        fmt.Fprintf(b, "[%s] [%s] %-40s ", lvl, r.Time.Format(termTimeFormat), r.Msg)
    }

The "%-40s" provides the right pad

This is a great package, the value of the MatchFilterHandler is underated and makes this the perfect tool for module logs. thanks !

@ChrisHines
Copy link
Collaborator

Interesting idea. Have you seen the discussion on issue #14?

I'm on the fence here. On the one hand TerminalFormat is documented as not recommended for production uses because it isn't as machine parsable as other formats, so giving the developer some control seems reasonable. On the other hand it goes against log15's opinion that we should prefer machine parsable log formats.

If we did include a format like this in log15 we would prefer to create a new format rather than breaking the v2 API by changing the existing TerminalFormat.

@notzippy
Copy link
Contributor Author

I looked at #14 and I agree that machine parsable code is far better to store historical data, that said watching an os.StdOut dump visually is far easier if we can specify the order. For example in my web application the logger will always have the ip, module and controller in the log context so I would like to be able to specify for the terminal output those items first, then the message then any other context.

And I am ok with a new Formatter implementing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants