What does "observability" mean, and what can it do that predefined monitoring cannot?

Observability is the ability to infer a system's internal state from its external signals — logs, metrics and traces — which lets you investigate problems nobody anticipated, without changing the code first.

Monitoring answers questions you thought of in advance: you defined the metric, set the threshold, built the dashboard. That works for known unknowns — the failure modes you expected. It is useless for the failure you have never seen, because there is no dashboard for it.

Observability targets exactly those "unknown unknowns". Because the system continuously emits rich, correlated signals — quantitative time series (metrics), detailed event records (logs) and end-to-end request paths (traces) — you can ask a new question of data already collected: "show me requests from Swiss mobile clients that hit version 4.2 of the checkout service and took over two seconds." Nobody built that view in advance; it is derived on demand.

The phrase "without code changes" is the practical payoff. In a poorly observable system, diagnosing a novel problem means adding logging, deploying, waiting for it to recur — hours or days per hypothesis. In an observable one, the hypothesis is tested against existing data in seconds.

Its stated goals follow from that: detect problems faster, simplify root-cause analysis, improve the user experience and reduce downtime.

Go deeper:

• OpenTelemetry: Observability Primer — a compact introduction to the signals and the vocabulary.
• CNCF Observability Whitepaper — the cloud-native community's reference document on the concepts and the maturity path.
• Observability Engineering (O'Reilly) — free copy via Honeycomb — the book behind the "unknown unknowns" framing.