logging: Better console
encoder defaults
#5109
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is something that has bothered me for a while, so I figured I'd do something about it now since I'm playing in the logging code lately.
The
console
encoder doesn't actually match the defaults that zap's default logger uses. This makes it match better with the rest of the logs when using theconsole
encoder alongside somekind of filter, which requires you to configure an encoder to wrap.Before:
After:
As you can see, this colorizes + uppercases the level, and makes the timestamp not useless.
Worth saying, that technically zap's default logger sniffs the TTY to figure out whether it's interactive or not, and uses JSON if non-interactive, and a "modified" console encoder if interactive. I think it might turn off color if the terminal doesn't support it. But I don't think that's worth trying to do here for these defaults, because it only affects the log level and most people get the gist even if their terminal doesn't render the color shell escapes.