You can't fix what you can't see. Good observability is the difference between a five-minute diagnosis and an all-night guess — but noisy logging is its own problem.

Log events, not narration. Record meaningful state transitions, decisions, and errors — not "entering function". Each log line should help answer "what happened and why" later.
Use levels deliberately. ERROR = needs attention; WARN = recoverable oddity; INFO = significant lifecycle events; DEBUG = detail for diagnosis. Don't log everything at INFO.
Make logs structured + correlatable. Prefer key/value (or JSON) over prose so they're searchable; carry an id (request/trace/session) through related lines so one flow can be reconstructed.
Include the context to act. On an error, log what was being attempted, the key inputs, and the cause — enough to reproduce. A bare "failed" is useless.
NEVER log secrets or PII. Tokens, passwords, keys, personal data must not hit logs. Redact at the boundary.
Metrics for the steady state, logs for the incident. Count/timing for rates and latency (the "is it healthy?"); detailed logs for the "why did THIS fail?".
Fail-safe: instrumentation must never crash or materially slow the path it measures.

Más de este repositorio

mismo repositorio

react-doctor

New1Direction/korgex

Catch bad React in your changes — run react-doctor's deterministic scan and fix what it flags

2026-06-055

security-scan

New1Direction/korgex

Run a verifiable security scan (vulns, secrets, misconfig) over code you wrote or deps you added, before calling the work done

2026-06-035

browser-automation

New1Direction/korgex

Drive a real browser verifiably — navigate, snapshot, act BY INDEX, extract; every step provable

2026-06-025

verifiable-orchestration

New1Direction/korgex

Run multi-agent work as ONE provable causal DAG — parallel subagents, an Orchestrate graph, an immutable spec-seed

2026-06-025

building-an-mcp-server

New1Direction/korgex

Author or connect a Model Context Protocol server so an agent gains new tools

2026-06-015

ci-cd-pipelines

New1Direction/korgex

Build automated pipelines that gate merges and ship reliably

2026-06-015

name	observability-and-logging
description	Instrument code so failures are diagnosable in production, without noise
version	1
trust	built-in

You can't fix what you can't see. Good observability is the difference between a five-minute diagnosis and an all-night guess — but noisy logging is its own problem.

Log events, not narration. Record meaningful state transitions, decisions, and errors — not "entering function". Each log line should help answer "what happened and why" later.
Use levels deliberately. ERROR = needs attention; WARN = recoverable oddity; INFO = significant lifecycle events; DEBUG = detail for diagnosis. Don't log everything at INFO.
Make logs structured + correlatable. Prefer key/value (or JSON) over prose so they're searchable; carry an id (request/trace/session) through related lines so one flow can be reconstructed.
Include the context to act. On an error, log what was being attempted, the key inputs, and the cause — enough to reproduce. A bare "failed" is useless.
NEVER log secrets or PII. Tokens, passwords, keys, personal data must not hit logs. Redact at the boundary.
Metrics for the steady state, logs for the incident. Count/timing for rates and latency (the "is it healthy?"); detailed logs for the "why did THIS fail?".
Fail-safe: instrumentation must never crash or materially slow the path it measures.