slog: Handle arbitrary log level #603
Labels
proposal
Proposal to add a new feature to pterm
proposal-accepted
Proposals which are accepted for implementation in the future
Problem
slog.Level
is an alias on anint
. While slog has defined some constants likeslog.Level{Debug, Info, Warn, Error}
, the docs state that these are not the only supported levels and there are levels between the default constants.However, pterm does a 1:1 mapping of the constants and not allow any others:
pterm/slog_handler.go
Lines 15 to 27 in 33f6aa1
The code above effectively means that something like
is not going to be printed, even though it might conceptually match pterm's
LogLevelTrace
.Proposal
Support arbitrary slog levels
...Especially for increased verbosity like debugging/traces. The good news is, that both pterm and slog use a numeric type for level with increasing severity for higher values. slog starts at 0 for
info
, pterm starts with an offset at3
. In the easy case we can just add 3 to the slog level. E.g.The "bad" news is that
pterm.LogLevelDisabled
equals 0 and a slog level higher thanInfo
doesn't match pterm's log level as pterm doesn't have gaps between Info and Warn like slog has, so we can't just add 3 there.For the former problem, passing
slog.Level(-3)
matchespterm.LogLevelDisabled
(=0) and that would cause nothing to be printed, so we'll need to address that.For the latter problem either the
Enabled
func needs to handle this case, or pterm's levels also introduces gaps (which may be a breaking change).Example (haven't tested this)
Also, for debugging or lower levels, we might prefer to print the level with the value, e.g.
TRACE-2
or justLEVEL-2
. See for example how slog does it:https://github.com/golang/go/blob/6018ad99a4a951581b2d846a8ccd6f1d4e74fd11/src/log/slog/level.go#L59-L77
Also, styling would be adjusted for their base level, e.g. use debug style for slog levels -3, -2 and -1, while using Trace style for slog levels below -4.
My list of changes isn't complete, there may be other changes required to achieve this.
Disabled log level
Set the value of
LogLevelDisabled
to a arbitrary high value (something afterLogLevelPrint
I guess), or evenmath.MaxInt
. By logic higher values produce less and less of logs, to the point where nothing is printed. Or some other form of disabling logging, e.g. remove this "level" and create a dedicatedSetDisabled
func or encourage users to use a no-op handler. Depending on implementation, this may be a breaking change.Background
My app is using the go-logr framework with pterm as the implementation backend. I love pterm's colored output and thus created plogr to marry go-logr with pterm. This was back before
slog
was a thing. Now both go-logr and pterm supportslog
in-between so basically my stack looks like this:logr -> slog -> pterm
(which makes plogr obsolete).My app uses for example logs like this:
A good argument for arbitrary log levels are cases like this: Business layer uses info/debug level (0 or 1 resp.). While it uses a REST client, the client's using level 2 for logging responses, and increased verbosity with level 3 or 4 would even print request headers for example.
debug
andtrace
would not be enough levels for this kind of verbosity increase.(Just to be clear, I'm not saying
debug
andtrace
levels are bad and should be gone or anything, as this is too much of a debate of opinions. I'm just proposing an improved implementation for the slog handler as envisioned by the slog designers.)The text was updated successfully, but these errors were encountered: