observability

# Observability <!-- routing-eval reads this line; it lives in the BODY so the always-on skill LISTING stays inside Claude Code's budget (1% of the context window) — an overflowing listing gets descriptions truncated or dropped, which strips the very keywords a match depends on. --> Trigger phrases: "observability", "structured logging", "structured log", "add a trace", "add a metric", "correlation id", "add logging" Goal: to be able to answer "what happened, where, why" during a production incident **by looking at the logs**. It is stack-agnostic; when you need a framework-specific library/format, do a web search. ## Three signals - **Log** — event record (structured/JSON, leveled). - **Metric** — numeric time series (request count, latency, error rate, resource usage). - **Trace** — a request's journey across services (spans + correlation id). ## Checklist - [ ] Logs are **structured** (JSON/key-value), not string interpolation - [ ] Every log line carries a **correlation id** (request/trace id) - [ ] Levels are correct: the DEBUG/INFO/WARN/ERROR distinction is meaningful - [ ] **No PII/secret is logged** (password, token, card, national/ID number, email body) - [ ] Error logs carry context (input summary, user/resource id — not PII); the stack trace does not leak to the user - [ ] Critical business metric + infrastructure metric are emitted (where applicable) - [ ] The correlation id is **propagated** across service-to-service calls (header/propagation) ## H...