Is there any way to pretty print our JSON logging?

[ghost]

Hi. I would like to use zap to achieve structured logging of my CLI app. I like what I'm seeing with sugar.Errorw() , but it would be great if I could pretty print the json so as to look more like jq.

I found this, but I'm not clear how I could use it for this purpose without changes upstream:

https://github.com/hokaccha/go-prettyjson

Thoughts?

[austindoeswork]

you might be able to just tail log files then pipe it into jq

tail -f log.json | jq

[akshayjshah]

We haven't shipped this in zap, since most Unix tools expect logs to be newline-delimited. Pretty-printing JSON on multiple lines breaks all these tools pretty badly and isn't particularly useful in production either.

If you'd like something like this, I suggest either redirecting your application's logs through jq or wrapping zapcore.JSONEncoder to include your pretty-printing logic.

[maoueh]

I created https://github.com/maoueh/zap-pretty as a stream CLI tool to pretty print Zap JSON log output. You pipe the stream to it and it will format zap JSON log line into a pretty format.

Usage:

./binary 2>&1 | zap-pretty # By default `zap.NewProduction` outputs in `stderr`, so `2>&1` is required on the default case
[2018-12-10 17:06:24.101 UTC] INFO (main.go:45) doing some stuff {"count":2}
[2018-12-10 17:06:25.241 UTC] INFO (main.go:45) doing some stuff2 {
  "more":2,
  "fields":2,
  "shown":2,
}
Random non JSON line

[akshayjshah]

Cool! This is exactly what I had in mind.

Feel free to open a PR and add this to the FAQ if you'd like to publicize this a bit more :)

[maoueh]

@akshayjshah PR sent :) (#676)

[owenchak]

I suppose this still isn't a feature in zap? I saw the NewDevelopment() which returns a logger which is meant to provide a more human-friendly format but IMO it doesn't. Although pretty printing json logs doesn't work well with unix tools, it would be nice to have an option for local development.

[maoueh]

Outside of zap-pretty, we also coded a more developper friendly encoder that you can see here: https://github.com/streamingfast/logging/blob/develop/encoder.go#L85.

We prefer our encoder over the development one. It can be easily instantiated with:

// Development logger (terminal is from "golang.org/x/crypto/ssh/terminal")
isTTY := terminal.IsTerminal(int(os.Stderr.Fd()))
logStdoutWriter := zapcore.Lock(os.Stderr)
	
logger := zap.New(zapcore.NewCore(logging.NewEncoder(verbosity, isTTY), logStdoutWriter, zapcore.DebugLevel))

Use the develop branch of the link library though, we did not do a proper release with this encoder so you will need to rely on develop branch.

[thessem]

Piling in to this issue to state that I've also been working on something to solve this: https://github.com/thessem/zap-prettyconsole

I have strayed fairly far from the concept of "pretty JSON" though.

[piotrostr]

I created https://github.com/maoueh/zap-pretty as a stream CLI tool to pretty print Zap JSON log output. You pipe the stream to it and it will format zap JSON log line into a pretty format.

Usage:

./binary 2>&1 | zap-pretty # By default `zap.NewProduction` outputs in `stderr`, so `2>&1` is required on the default case
[2018-12-10 17:06:24.101 UTC] INFO (main.go:45) doing some stuff {"count":2}
[2018-12-10 17:06:25.241 UTC] INFO (main.go:45) doing some stuff2 {
  "more":2,
  "fields":2,
  "shown":2,
}
Random non JSON line

One can achieve same result using the open-source tool jq:

go run . 2>&1 | jq

Since it is frequently used apt-managed tool it might facilitate setup and maintenance.

[lordzsolt]

Can we please stop suggesting jq or other CLI tools?

IntelliJ and their IDEs for example do not support this.
Sometimes you're working in an environment where you cannot install CLI tools or do post-formatting.

[anatoly-cnvrg]

I see that @lordzsolt comment mostly downvoted, maybe there's an option to use jq with Intellij and we don't know? Can someone explain if has managed to do it.

[dwin]

@anatoly-cnvrg I assume the post received mostly downvotes because many Go developers do not use IntelliJ. Just because a tool isn't useful for those who don’t use it doesn't mean it lacks utility for others who find it meets their needs.

It might have been more effective to ask, "How can this be accomplished in IntelliJ or in an environment where you cannot install command-line tools or perform post-formatting?" instead.