Loading...
Quick Definition
Observability is the ability to understand a system's internal state from its external outputs, metrics, logs, and traces. Going beyond monitoring, it helps teams investigate unknown issues and ask new questions of complex, distributed systems to diagnose problems quickly.
Observability is the property of a system that lets you understand its internal state from the outside, well enough to debug problems you never anticipated. It rests on three signal types: metrics (numbers over time), logs (event records), and traces (the path of a single request across services).
It differs from monitoring in the questions it can answer. Monitoring checks known conditions: is latency above 200 milliseconds? Observability supports open investigation: why are checkout requests from one region slow only when the cart has more than ten items? In distributed systems full of microservices, that investigative power is the difference between minutes and days of debugging.
Example. An engineer chasing a mysterious slowdown follows one trace and sees the request fan out to eleven services, with one retrying a slow dependency four times. The culprit is found in ten minutes without touching a single server.
Observability data has real cost, high-cardinality metrics and full tracing add up fast, so sample deliberately and tier retention. The monitoring tools roundup and the Datadog pricing guide cover the platform economics.
Metrics, logs, and traces. Together they show what changed, what happened, and where time went across services.
Simple systems live happily on monitoring. Distributed architectures need observability because failures emerge in the gaps between services.
Volume. Traces and high-cardinality metrics multiply with traffic and services. Sampling and retention tiers keep it proportionate.