observability-logging-metrics-tracinglisted

# Observability: logging, metrics, tracing You cannot debug what you cannot see. Instrument while building — bolting on observability after an incident means the incident that would have proven it useful already happened without it. ## 1. Structured logging - Emit **JSON** (or another machine-parseable structure), not free-text interpolated strings — `logger.info("order failed", { orderId, reason })`, not `logger.info("order " + orderId + " failed: " + reason)`. Structured fields are queryable/filterable; interpolated strings force regex archaeology later. - Use **levels** deliberately: `debug` (dev-only detail), `info` (normal operational events worth keeping), `warn` (recoverable but noteworthy), `error` (something failed and needs attention). Don't log everything at `info` — that just trains everyone to ignore the log stream. - **Never log secrets or PII**: passwords, API keys, tokens, full card numbers, SSNs, raw auth headers. Redact or omit before the log call, not after — a leaked secret in a log aggregator is a breach regardless of intent. When in doubt, log an id you can look up, not the sensitive value itself. ## 2. Correlation / request IDs Generate a correlation (request) id at the system's edge — the first service that receives an external request — and propagate it through every downstream call: HTTP headers to other services, message metadata onto queue publishes, into every log line for that request's lifetime. Without it, reconstruct