zerolog-observability

# Zerolog Structured Logging ## Overview Logs are for machines first: structured fields you can filter and correlate, not prose. The recurring defects are `fmt.Println` debugging left in, data interpolated into the message instead of fields, the same error logged at every layer, and secrets leaking into logs. **Core principle:** Log the failure at its site, with fields, once. ## Rules - `github.com/rs/zerolog` exclusively — never `fmt.Println` / `log.Printf` in production code. - **Fields, not interpolation:** ids and operation names are structured fields, not baked into the message string. - **Correlate:** attach `request_id` (and relevant entity ids) so one request is traceable across layers. - **Don't double-log:** log-and-return the same error at each layer reports it N times. Log at the site that has the most context (usually where it's handled), propagate elsewhere with `%w`. - **Never log secrets, tokens, or full request bodies** that may carry user data. ## Levels | Level | Use for | |-------|---------| | Debug | development detail, verbose tracing | | Info | state changes worth auditing (task moved, migration applied) | | Warn | handled anomaly (retry, fallback taken) | | Error | a failure needing attention | ## Worked Example ```go // ❌ prose message, interpolated id, will be logged again by the caller too log.Error().Msg(fmt.Sprintf("dispatch failed for task %s: %v", id, err)) // ✅ structured fields, error attached, logged once at the handling site log.Er...