backend-observabilitylisted

# backend-observability You cannot debug what you cannot see. This skill instruments a service so that when it misbehaves at 3am, an on-call engineer can answer *what broke, for whom, and where* from telemetry alone — without redeploying to add a log line. The three pillars (logs, metrics, traces) are wired to a single correlation id so you can pivot between them. ## Use when - A service emits `console.log`/`print` and nothing else. - Incidents take too long to diagnose because there's no signal. - As the `observability/` step when scaffolding a new service. ## The one thread: correlation id Every request gets a correlation id at the edge (accept an inbound `traceparent`/`X-Request-Id` if present, else generate one). It flows through logs (as a field), traces (as the trace id), and to downstream calls (as a propagated header). This is what lets you take a log line, jump to its trace, and see the metric it contributed to. Wire this first — the pillars are far less useful uncorrelated. ## Structured logs - **JSON, one object per line.** Never interpolate values into a message string you'll later have to regex. `log.info("order placed", { orderId, userId, amountCents })`, not `log.info("order " + id + " placed")`. - **Levels mean things.** `error` = a human should look; `warn` = degraded but handled; `info` = business milestones; `debug` = off in prod. If everything is `error`, nothing is. - **Every log line carries** the correlation id, service name, and version. Add reques