Add compoment min level logging - #1788
Conversation
To Support per project component logging level
|
boks1971
left a comment
There was a problem hiding this comment.
component log levels already work
@boks1971 Does it already have project-level component logging? I have not found the relevant config. |
| // Note this reports the logger's component min leveler but not its min | ||
| // level: see ZapLogger.WithMinLevel. levelEnablers is shared by every | ||
| // logger built from this config, so a min leveler's opinion, which is | ||
| // particular to one logger, must not be cached in it. | ||
| if override := l.zl.componentMinLevel(component); override != nil { | ||
| return zaputil.OrLevelEnabler{l.zl.sc.ComponentLevel(component), l.zl.tap, override} | ||
| } |
There was a problem hiding this comment.
cache both min level and component min level enablers in fdfcb40
There was a problem hiding this comment.
we cannot serialize every WithValues call on a global mutex..
There was a problem hiding this comment.
There is a short circuit to return the OrLevelEnabler directly when ComponentMinLeveler is empty, so the mutex is hit only when the project component level is set in the config. I think in most cases the project component level is empty and behavior keeps unchange, except we turn it on for pion shortly.
Also asked claude about using xsync.Map and it said a mutex is better here..
Technically yes — it's a drop-in, same LoadOrCompute shape as zapConfig. But I'd keep the mutex+map, because the allocation profile is what separates the two cases:
two xsync.Map: 6048 B/op, 10 allocs/op
enablerCache{} (lazy): 24 B/op, 1 alloc/op
enablerCache + 1 entry: 360 B/op, 3 allocs/opzapConfig's two maps are allocated once per process and read by every logger for the lifetime of the binary — 6 KB amortizes to nothing, and lock-free reads are worth it under fleet-wide contention. This cache is allocated per project logger, and in cloud that means per participant, per relay downtrack, and per HTTP request: pkg/node/middleware.go:236 builds one inside the per-request auth middleware, as does settings.go:96. For a debug-enabled project that's a cache per request, and almost none of those requests ever resolve a pion component — with the lazy maps they pay 24 bytes and never allocate a map at all.
| }) | ||
| } else { | ||
| enab := zaputil.OrLevelEnabler{l.minLevel, l.sc.ComponentLevel(l.component)} | ||
| enab := zaputil.NewOrLevelEnabler(l.minLevel, l.sc.ComponentLevel(l.component), componentMinLevel) |
There was a problem hiding this comment.
this allocates for every derived logger
There was a problem hiding this comment.
It is an equivalent of zaputil.OrLevelEnabler{} that doesn't allocate more.
To Support per project component logging level