Observability Isn't Three Pillars, It's One Question: What Changed

The three pillars framing, metrics, logs, traces, describes what vendors sell, not what debugging needs. I have been on incidents with dashboards for all three pillars glowing and nobody able to answer the only question that matters at 2AM: what changed?

Because that is the question. Systems that were working break because something changed, a deploy, a config flip, a feature flag, a dependency's deploy, a traffic pattern, a certificate quietly expiring. Incident response is a search through the space of recent changes, and observability is good precisely to the degree it shortens that search. Pillars are inventory. The question is the product.

Judged by the question, priorities reorder. The most valuable telemetry we added last year was not a better tracing setup, it was a change feed: every deploy, flag flip, config change, and scaling event across the org, in one queryable stream, overlaid as annotations on every dashboard. Error rate jumps at 14:02 and there is a vertical line labeled with a deploy at 14:01, most incidents end right there, before anyone opens a trace.

Second priority, high cardinality context on errors, because when the change feed is not enough, the next question is "broken for whom." All requests failing means look at shared infrastructure. Requests failing for one customer, one region, one client version means look at what is special about that slice, and you can only slice on dimensions you recorded. This is where structured, wide events beat grep hoping.

Traces earn their keep third, for the "why is it slow" incidents where the change is a latency shift hiding four hops deep.

Buy whatever pillars you like. Just point them all at the question, and measure your observability by minutes to "what changed," not by gigabytes ingested.