Observability Is Not a Dashboard

Monitoring is the set of questions you decided in advance were worth watching: is CPU above 80%, is the error rate above 1%, is the queue deeper than 10,000. It is enormously useful and it is not the same thing as observability. A monitored system tells you *that* one of your pre-chosen thresholds moved. It says nothing about the failure mode you never imagined.

Observability is the property that you can reconstruct internal behavior from the telemetry you already emit. The working definition for an engineer on call: can I ask a new question and get an answer without deploying code? If the answer requires adding a log line and waiting for a release, the system is monitored but not observable — and the failure is happening now, not after the release.

The practical difference is dimensionality. A counter of http_requests_total{status="500"} tells you errors went up. It cannot tell you they are all on one endpoint, from one client version, in one region, hitting one shard — unless those dimensions were captured at emission time. Which dimensions to capture is a design decision with a real cost (see Cardinality: The Label That Took Down Monitoring), and it is the decision that determines what you can ask later.

The useful mental exercise is to write down a question you have never asked before, then check whether your telemetry answers it. "Is p99 worse for requests that also touched the recommendations service?" "Do the slow requests correlate with a specific database replica?" "Is the regression only on clients running the old SDK?" Each of these needs a *dimension* captured at emission time and a way to slice by it after the fact.

This is why the three-signal split matters (see Metrics, Logs, Traces, Profiles). Metrics answer questions about aggregates cheaply but only along the dimensions you pre-declared. Traces answer questions about one request across services, including questions you invent later, because a span carries arbitrary attributes. Logs answer questions about discrete events with full context. Profiles answer questions about cost *inside* a process. A system with only metrics is a system that can only be asked yesterday's questions.

None of this requires a specific vendor. The properties that make a system observable are: high-dimensional context attached to events, correlation identifiers that survive every hop (see Correlation IDs: Turning Lines Into a Story), and the ability to slice arbitrarily after collection. A team can have all three with open tooling and none of them with an expensive platform.

Every dimension you capture costs storage, query time and money, and some of them cost production latency. A team that responds to "we need observability" by capturing everything discovers the second failure mode: a telemetry pipeline that costs more than the service it watches, and a metrics backend that falls over when someone adds a user id to a label (see Cardinality: The Label That Took Down Monitoring).

The discipline is to buy dimensionality where questions actually get asked. Request-scoped attributes on traces are cheap and high-value because tracing is sampled. Metric labels are expensive because every combination is a time series stored forever. Logs sit in between and are usually the line item that surprises finance (see The Log Bill and What It Is Buying).

A reasonable starting posture for a service: the four golden signals as metrics with low-cardinality labels (see The Four Golden Signals), traces on a sampled fraction of requests with rich attributes, structured logs for errors and state transitions, and continuous profiling at a low sample rate. That combination answers most new questions without an unbounded bill — and it is a starting point to revise, not a rule.