Structured Logging

A track of P37 · Observability — Logging, Metrics & Traces.

Logs a machine can read: build a structured logger with bound context and correlation IDs, use levels with intent, and never log secrets or PII - so one request can be followed across a whole pipeline.

The first pillar of observability is the one everyone thinks they already do: logging. The gap is that a print-a-sentence log is nearly useless at scale — you cannot filter it, aggregate it, or alert on it. This track rebuilds logging the way a production service does it: structured records (fields, not strings) that a log system can actually query.

Two mechanics carry the track. Context binding attaches fields once — a service name, a per-request correlation id — and returns a new logger whose every line carries them, so a single request becomes one followable story across every component it touches. Redaction keeps secrets and PII out of the logs by replacing known-sensitive keys at the logger itself, where a careless call site cannot leak them. You build both by hand rather than importing structlog, so the behaviour is yours to reason about.

The track closes with an interview rung on production logging judgement — levels used with intent, log volume and cost, and knowing when a log is the wrong tool (and a metric or a trace is right), which is exactly where the metrics-traces track picks up.

Structured recordfields, not a sentenceBind contextservice + request idRedact secretsnever log PIIThen: metrics & tracesthe other two pillars
A log a machine can read, and a request you can follow.