I use Zap for basically every service I write, it's great! There's one issue I have though. Since I use pkg/errors, each error satisfies the fmt.Formatter interface and thus, every error log comes with a stack trace. This is great in production when that information is vital, but during development, (i.e. with NewDevelopmentConfig) they still show up; which, given the less vital scenario, is a bit annoying.
I notice there's DisableStacktrace which removes the stack trace that originates from the log call itself but no way to disable errorVerbose.
In development, stack traces clutter the logs and makes scanning the terminal pretty difficult. I usually don't need to know the full stack trace, only the top-most element (or, the top-most errors.New call). And if I do, in a perfect world, I could flip a env var to enable it!
I use Zap for basically every service I write, it's great! There's one issue I have though. Since I use pkg/errors, each error satisfies the fmt.Formatter interface and thus, every error log comes with a stack trace. This is great in production when that information is vital, but during development, (i.e. with
NewDevelopmentConfig) they still show up; which, given the less vital scenario, is a bit annoying.I notice there's
DisableStacktracewhich removes the stack trace that originates from the log call itself but no way to disableerrorVerbose.In development, stack traces clutter the logs and makes scanning the terminal pretty difficult. I usually don't need to know the full stack trace, only the top-most element (or, the top-most
errors.Newcall). And if I do, in a perfect world, I could flip a env var to enable it!