backend-observability

# Observability Instrumentation **Degree of freedom: MIXED.** What to wrap and alert on `[HIGH freedom]`; correlation ids, PII redaction, and the DoD `[LOW freedom — run exactly]`. ## How to reason 1. **Observe** — which ids, logs, spans, and PII already exist 2. **Interpret** — can you pivot error ↔ trace ↔ log ↔ user from any one? 3. **Classify** — add-correlation / convert-console / redact / wrap-span / alert 4. **Severity** — uncorrelated prod 500 outranks a missing debug field ## Worked example > **Observe:** checkout 500 in Sentry has no request_id; pino logs the cart id; no LLM (Langfuse unused). > **Interpret:** cannot pivot error → logs; webhook still `console.log`s. > **Classify:** ALS request_id on logs + `Sentry.setTag`; convert console to pino; redact `Authorization`. > **Verify:** one id on the Sentry event and the log line; `beforeSend` strips the header. ## Self-critique before reporting - **Correlated** — same request/trace id on the log, Sentry, and Langfuse - **Redacted** — deny-list at the logger + `beforeSend`, not per-call hope - **Leveled** — no `console.log` in prod; handled paths are not `error` - **Right owner** — plan-only audit → `plan-error-handling`; investigate a Sentry issue → `debug-sentry-monitor` > The build-time counterpart to your monitoring stack. The Sentry plugin installs the SDK; `debug-sentry-monitor` triages after the fact; `audit-langfuse-llm` audits LLM traces. about instrumenting **correctly while you build** so those tool...