Career & Craft
Observability
The ability to understand a system's internal state from its external outputs — the three pillars of metrics, logs and traces working together — so you can ask new questions about unforeseen problems, not just watch predefined dashboards. Monitoring tells you that something broke; observability helps you find why. It becomes essential once systems are distributed.
Purpose
Observability is the ability to understand what a system is doing internally from what it emits externally — the three pillars of metrics (how much), logs (what exactly) and traces (where in the call graph) joined together. Where monitoring answers questions you predicted, observability lets you ask ones you did not.
When to Use It
Debugging novel production incidents ('why are checkouts from one region slow since 14:00?'), understanding emergent behaviour in distributed systems, and validating releases — watching a canary's real behaviour rather than hoping. It becomes essential the moment a request crosses more than one service.
Trade-offs
Telemetry has real costs — instrumentation effort, storage bills, cardinality explosions in metrics — and tooling sprawl is common: three disconnected systems for the three pillars answer questions more slowly than one connected one. The joining keys (trace and correlation IDs) are what turn data into answers.
Implementation
Instrument once with OpenTelemetry and export everywhere; propagate trace IDs through every hop and stamp them into logs so pillars cross-link. Define SLOs so 'healthy' is a number, keep metric cardinality deliberate, and judge the stack by one metric: how fast an engineer goes from 'something is wrong' to 'here is why'.