Add New Trace Logging Level

[LeviMatus]

A few people have expressed interest in having a TraceLevel added to Zap (Some mention of this in #680 and again in #747). This PR addresses that interest by introducing this logging level.

[codecov]

Codecov Report

Merging #749 into master will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #749      +/-   ##
==========================================
+ Coverage   97.44%   97.46%   +0.01%     
==========================================
  Files          40       40              
  Lines        2117     2126       +9     
==========================================
+ Hits         2063     2072       +9     
  Misses         46       46              
  Partials        8        8              

Impacted Files	Coverage Δ
level.go	100.00% <ø> (ø)
zapcore/level_strings.go	100.00% <ø> (ø)
logger.go	94.64% <100.00%> (+0.14%)	⬆️
zapcore/level.go	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0065243...4e1209c. Read the comment docs.

[CLAassistant]

All committers have signed the CLA.

[prashantv]

I'm not sure that we can add a level to zap 1.0 and retain backwards compatibility. Existing cores, hooks, etc do not know about the trace level and may not handle it properly. For example, here's an adapter library that checks for known levels:

https://github.com/uber-common/bark/blob/master/zbark/zapify.go#L64

That library at least handles it will by returning an error, but there may be other cases where it panics.

I don't think we can add any new levels unless we do a zap 2.0.

[LeviMatus]

Thanks for the code reference there to check against. Having external wrappers is something I had not thought of and is a great point. I see now how this could make introducing new levels more difficult.

Moreover, I just realized that I neglected to add Trace methods to sugar.go, so the PR can't even be considered complete at this time.

[novabyte]

@LeviMatus You've done great work on this pull request! It's sorely needed within Zap even if we cannot specify our own set of severity levels for output.

@prashantv Is there any kind of timeline for when a set of changes like this would be acceptible to the release constraints of Zap?

[prashantv]

@prashantv Is there any kind of timeline for when a set of changes like this would be acceptible to the release constraints of Zap?

We don't currently have a concrete timeline for zap 2.0, but the improvements we'd like to make in a 2.0 are tracked here: #388.

[se3000]

Any update on this? We would like to use it.

[Antonboom]

What's the bottom line? Wait for zap v2?

[prashantv]

We definitely can't add it in 1.0. It's possible for 2.0, but that's not in the roadmap. At that point, we'd want to consider the cost/benefit (it's added cognitive overhead to add another level, so we should ensure there's a significant benefit).

Closing for 1.0.

[Andrea-Campanella]

@prashantv I would say that there is significant benefit to introduce Trace level due to otherwise overwhelming debug logs. we have found ourselves in a position where DEBUG has way too many messages because we can't demote some to a lower (non existing) level but we can't also promote anything to INFO level due to the nature of the log. thoughts ?