fix(logs): respect log level explicitly declared by structured loggers - #4624
Conversation
Siumauricio
left a comment
There was a problem hiding this comment.
Reviewed and tested locally: applied the diff on current canary, all 12 tests pass, and verified it composes cleanly with #4824 (16/16 tests passing with both changes merged — declared levels short-circuit before the keyword fallback, which #4824 fixes). Nice work covering pino/bunyan numeric scales, syslog/GELF, logfmt and GCP severity, with the LOG_LEVEL= env-var guard.
| const jsonStringMatch = message.match( | ||
| /"(?:level|severity|log\.level|loglevel)"\s*:\s*"([a-z]+)"/i, | ||
| ); | ||
| if (jsonStringMatch?.[1]) { | ||
| return LEVEL_NAME_TO_TYPE[jsonStringMatch[1].toLowerCase()] ?? null; | ||
| } | ||
|
|
||
| // JSON numeric levels: {"level":50} | ||
| const jsonNumericMatch = message.match(/"level"\s*:\s*(\d{1,2})\b/); | ||
| if (jsonNumericMatch?.[1]) { | ||
| return numericLevelToType(Number(jsonNumericMatch[1])); | ||
| } | ||
|
|
||
| // logfmt: level=error | ||
| const logfmtMatch = message.match(/(?:^|\s)(?:level|severity)=([a-z]+)\b/i); |
There was a problem hiding this comment.
Nested fields override declared levels
When a structured log contains a nested level field before its top-level declaration, or a level-like token inside a quoted logfmt value, these regexes select that earlier payload value, causing the dashboard to assign the wrong badge and filtering category.
Knowledge Base Used: Monitoring and Live Terminal/Log Streaming
What
The Docker log viewer classifies log lines purely by keyword matching and ignores the log level the application actually declared. Structured log lines (pino, bunyan, winston, zap, slog, logfmt) end up with wrong badges:
{"level":"error",...}never matches the error patterns (they expect whitespace-delimited words likeerror:), so a pino error line falls through to the debug branch via\b(?:version|...|get|post)\b— pino lines always carry"version"/"method":"GET".{"level":"warn","msg":"Webhook status event..."}is classified as info because\bstatus\bmatches first.{"level":"info","msg":"Request completed"}is classified as success because of\bcompleted\b.Fix
Check for an explicitly declared level before any inference, and only fall back to the existing keyword heuristics when none is present:
"level":"error","severity":"ERROR"(GCP),"log.level"(ECS)"level":50(pino/bunyan 10–60 scale, syslog/GELF 0–7 scale)level=errorA declared level also wins over the inferred
statusCodeclassification. Unknown level names fall back to the keyword detection, which is unchanged.Kept intentionally minimal (no scoring system) per the maintainer feedback on #3070.
Issues related
Closes #4589. Related: #4538, #1996.
Before / After
Same container (pino JSON + logfmt lines), tested on a local dev instance (
pnpm dokploy:dev):Before —
"level":"error"shows asdebug,"level":"warn"asinfo,"level":"info"assuccess:After — badges match the declared level; numeric pino levels and logfmt are also respected:
Tests
Added
__test__/utils/log-type.test.ts— 12 tests covering pino/winston/zap string levels, pino/bunyan numeric levels, syslog/GELF numeric levels, GCP severity, ECS log.level, logfmt, precedence over statusCode and keywords, fallback for unknown level names, and the regression cases from #4589/#4538. Full vitest suite,tsc --noEmitand Biome pass.Checklist
canarybranch.Greptile Summary
This PR makes explicitly declared structured-log levels take precedence over status-code and keyword inference.
Confidence Score: 4/5
The PR should not merge until explicit-level extraction is constrained to actual structured logger fields rather than nested or quoted payload data.
Raw application log text is searched with unstructured regular expressions, so an earlier nested or quoted level token can override the real logger declaration and produce incorrect badges and filtering.
Files Needing Attention: apps/dokploy/components/dashboard/docker/logs/utils.ts
Reviews (1): Last reviewed commit: "Merge branch 'canary' into fix/structure..." | Re-trigger Greptile
Context used: