Monitoring vs Observability: Knowns and Unknowns

People treat monitoring and observability as the same thing, but they solve different problems. Getting the distinction right is foundational.

Monitoring watches predefined metrics and fires alerts when known thresholds break — CPU over 90%, error rate over 1%.

Monitoring handles known unknowns: the failures you anticipated and built dashboards or alerts for ahead of time.

Observability is the property of a system whose internal state you can read from its outputs — letting you ask brand-new questions without shipping code.

Observability targets unknown unknowns: novel failure modes you never predicted. You explore the data to discover what actually went wrong.

In microservices, one request crosses many services. An up/down check can't explain a slowdown three hops away — you need to trace and correlate.

Observability thrives on high-cardinality context like user ID, request ID, and region — so you can slice data along dimensions you never planned for.

Monitoring is dashboard-driven and reactive. Observability is exploratory: start from a symptom, drill through the data, land on root cause.

They're not rivals. Monitoring tells you something is wrong; observability helps you discover why. Mature systems lean on both.

A simple test: can you answer an unplanned question from existing telemetry? If yes, your system is observable. If you must add code first, it's only monitored.

Logs, metrics, and traces are the raw materials — the pillars that make a system observable rather than merely monitored.

Which class of problems does observability primarily address?

The core split: monitoring alerts on known unknowns, observability explores outputs for new questions, and distributed systems demand both.