observability
termops culturecloud
How well you can understand what a system is doing internally from the signals it emits.
Often summarized as logs, metrics, and traces, observability is about being able to ask new questions of a running system without shipping new code, especially when something breaks in a way you did not anticipate. It is what turns a mystery outage into a diagnosable one.
Observability asks whether you can understand what a system is doing from the outside, without shipping new code to answer a question. Monitoring tells you that a known thing broke; observability is about being able to investigate the thing nobody predicted, which is the situation every real incident presents.
The three signals are conventional and complementary. Metrics are cheap, aggregated and good at showing that something changed. Logs carry detail and context but cost storage and are hard to query at scale. Traces follow one request across services, which is the only practical way to find where latency actually accumulates in a distributed system. Each answers a question the others answer badly.
The failure mode is collecting all three and understanding none. High cardinality is the usual technical cause, since a label with unbounded values multiplies series until the system storing them becomes the outage. The organizational cause is instrumenting comprehensively rather than deliberately, which produces dashboards nobody reads and bills nobody expected. Instrumenting for the questions you actually ask during incidents produces less data and more answers.
Also known as: o11y, logs metrics traces, three pillars