What is observability in one sentence?

Observability is the ability to understand what is happening inside a system — and ask new questions about it — purely from the data it emits, such as logs, metrics, and traces, without having to ship new instrumentation first.

What are the three pillars of observability?

Logs (timestamped records of discrete events), metrics (numeric measurements aggregated over time), and traces (the path of a single request across services). Together they let you move from 'something is wrong' to 'here is exactly where and why.'

What is the difference between observability and monitoring?

Monitoring tells you whether known conditions are happening — dashboards and alerts for things you predicted. Observability lets you investigate problems you did not predict by querying rich data after the fact. Monitoring is a subset of observability.

What is OpenTelemetry?

OpenTelemetry (OTel) is a vendor-neutral open standard and set of libraries for generating and exporting logs, metrics, and traces. It lets you instrument code once and send the data to any compatible backend, avoiding lock-in.

What are SLIs, SLOs, and error budgets?

An SLI is a service level indicator — a measurement like request latency. An SLO is the target for that indicator, like 99.9% of requests under 300ms. The error budget is how much you are allowed to miss the SLO before you must stop shipping risky changes.

Glossary · Infrastructure

What is Observability?

Observability is how well you can understand what is happening inside a running system just from the data it emits — its logs, metrics, and traces — so that when something breaks in a way nobody predicted, you can ask new questions of that data and find the answer without first shipping new code to go look.

The term, borrowed from control theory

"Observability" comes from control theory, where it measures how well a system's internal state can be inferred from its external outputs. The software industry adopted the word as architectures shifted from a handful of servers to sprawling distributed systems of microservices, queues, and managed cloud services. In that world, the old question "is the server up?" stopped being useful; the hard problems became "why is this one request slow?" and "why is this customer seeing errors when nobody else is?" — questions you cannot answer with a binary health check.

Observability vs. monitoring

The two are often conflated, but the distinction is real. Monitoring watches for conditions you already know to look for: CPU over 90%, error rate above a threshold, disk nearly full. It is about known unknowns. Observability is about unknown unknowns — the failure modes you did not anticipate. A monitored system tells you that something is wrong; an observable system lets you explore the rich data it emits to discover why, even for a problem you have never seen before. Monitoring is best understood as a subset of observability, not a competitor to it.

The three pillars

Most observability practice rests on three kinds of telemetry. Logs are timestamped records of discrete events — useful for the detail of what happened at a specific moment. Metrics are numeric measurements aggregated over time — request counts, latencies, queue depths — cheap to store and ideal for dashboards and alerts. Traces follow a single request as it travels across every service it touches, which is the only way to see where latency actually accumulates in a distributed call. The deep version of traces gets its own treatment under distributed tracing.

OpenTelemetry and avoiding lock-in

For years, instrumenting an application meant committing to a specific vendor's agent and SDK. OpenTelemetry — usually shortened to OTel — changed that. It is a vendor-neutral open standard, now a CNCF project, that defines how to generate and export logs, metrics, and traces. You instrument your code against OTel once and can send the resulting telemetry to Datadog, Grafana, Honeycomb, New Relic, or an open-source stack, switching backends without re-instrumenting. For teams that care about not being locked into a single observability vendor, OTel is the practical foundation.

SLIs, SLOs, and error budgets

Observability data becomes a management tool through service level objectives. A service level indicator (SLI) is a measurement that reflects user experience — the fraction of requests served under 300 milliseconds, say. A service level objective (SLO) is the target for that indicator over a window, such as 99.9% over thirty days. The gap between the target and 100% is the error budget: how much unreliability you can spend. When the budget is healthy, ship fast; when it is exhausted, slow down and stabilize. This reframes reliability from a vague aspiration into a number teams can plan against.

At QUANT LAB

We build observability into systems from the start rather than bolting it on after the first outage. The platforms we ship under DevOps engineering and cloud infrastructure come instrumented with structured logs, meaningful metrics, and traces tied to real user journeys, so when something goes wrong the client can find it in minutes instead of guessing. Good observability also pairs naturally with chaos engineering and load testing: there is no point breaking a system deliberately or pushing it to its limits if you cannot see what happened.

Long-form deep-dives that use this term

All posts

Related terms

Flying blind in production?

We instrument systems with logs, metrics, and traces so you can find and fix problems before customers do. Book a 30-minute call.

DevOps engineering