feat: control log verbosity with LOG_LEVEL - #359
Open
eliasmeireles wants to merge 3 commits into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Problem
wuzapi's own logs have no level control.
SetGlobalLevelis never called, so zerolog stays at itsTraceLeveldefault and everyDebugandInfoline is emitted unconditionally. There is no flag and no environment variable to turn it down —-wadebuggoverns the whatsmeow logger (waLog), not zerolog.On a busy instance this is most of the log. Measured on a deployment with active sessions, over a 10-minute window: 728 lines — 38% Info, 35% Debug, 19% Warn, the rest being multi-line payload dumps. Operators either keep all of it or grep around it.
Change
LOG_LEVELsets the minimum severity for wuzapi's own logs, accepting the nameszerolog.ParseLevelunderstands (trace,debug,info,warn,error,fatal,panic).It is set as the first statement in
main()on purpose: the global level is consulted per record rather than baked into the logger, so setting it there also covers the configuration lines emitted before theConsoleWriter/JSON logger is installed. Placed after the logger, those lines escape the filter.Compatibility
Unset or unrecognized values keep today's behaviour exactly —
zerolog.ParseLevelreturns an error, the level is left untouched, and nothing is silenced by a typo.zerolog.NoLevel(which an empty string parses to) is excluded for the same reason. An operator who does not set the variable sees no change at all.Testing
go build ./...,go vet ./...andgo test ./...pass.Verified on a live deployment with active WhatsApp sessions, same 10-minute window and comparable traffic:
LOG_LEVELwarnerrorAt
warnthe Debug and Info volume disappears while warnings and errors still come through; aterrorthe instance stays silent unless something actually fails. Boot-time configuration lines are filtered too, confirming the placement inmain().The branch has two follow-up commits reverting log-level reclassifications I had included initially; the net diff is the 14 lines in
main.go. Happy to squash into a single commit if you prefer.