feat: better logging settings, log client in certain logs #63
Conversation
cmd/gateway/main.go
Outdated
| } else { | ||
| logger, err = zap.NewDevelopment() | ||
| zapConfig := zap.NewDevelopmentConfig() | ||
| zapConfig.Encoding = "json" |
There was a problem hiding this comment.
I find JSON in development really hard to read, which makes developing slower.
Taking a step back, what's the use case for sending dev logs to datadog?
There was a problem hiding this comment.
Logging is only controlled by the development/production flags atm. So to get debug logs we have to turn on development. We might want to do this for debugging issues.
Zap's baked in development config has more than just debug logs. For example it includes stack traces for anything above warn.
The better solution perhaps is to expose a parameter called log level, and pipe that into the zap logger's config.
There was a problem hiding this comment.
Gotcha.
Yeah, exposing log level as an env variable makes a lot of sense. No need to always couple the log level to the logging environment.
brianluong
force-pushed
the
logging_improvements
branch
from
b666e5c
to
b03e0b8
Compare
!
cmd/gateway/main.go
Outdated
| func setupGlobalLogger(env, logLevel string) (logger *zap.Logger, err error) { | ||
| if env == "" || env == "production" { | ||
| if logLevel == "" { | ||
| logLevel = "info" |
There was a problem hiding this comment.
Consider extracting into a defaultProductionLogLevel constant.
brianluong
force-pushed
the
logging_improvements
branch
from
b03e0b8
to
8b238c6
Compare
Description
Type of change
How Has This Been Tested?
-e ENV=production -e LOG_LEVEL=debugworks