Observability Instrumentation

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 tools have signal to work with — and so a 3am incident is debuggable.

When this fires

Adding logging / tracing / metrics to new code, reviewing instrumentation, or fixing "we can't tell what happened in prod." Not for installing an SDK (use the Sentry/Langfuse plugins) or post-hoc triage (use the monitor/audit skills).

The one rule that matters most: correlation

A prod incident is only debuggable if you can pivot error ↔ trace ↔ log ↔ user from any one of them. Make every layer share an id.

• Generate/propagate a request id (or OTel trace_id) at the entry point (HTTP middleware, edge function, job start). Put it in async context (AsyncLocalStorage / context var), not a parameter threaded everywhere.
• Stamp it on everything: every log line, Sentry setTag("request_id", id) / setContext, and the Langfuse trace (trace.id or metadata). On an LLM error, attach the Langfuse trace URL to the Sentry event so you jump straight from the exception to the prompt/response.
• Set user/session/tenant scope (Sentry.setUser, Langfuse userId/sessionId) — scrubbed (see redaction).

Structured logging discipline

• Structured, not string-soup. Emit JSON with stable fields (level, msg, request_id, event, domain ids). One event per line. Use the platform logger (pino / structlog / slog), not bare console.log.
• Levels mean things: error = needs a human; warn = degraded but handled; info = state transitions / business events; debug = dev-only, off in prod. Don't log error for handled flow.
• No console.log shipped to prod — it's unsearchable, unleveled, and a PII leak risk. Remove or convert to a leveled structured log.
• Log decisions, not noise: log the branch taken + key inputs/outputs at boundaries, not every line. A log you'd never grep is cost, not signal.