The Three Pillars Are a Lie: What Observability Actually Means

Walk into any observability conference today and you'll hear the same mantra, repeated like a catechism: logs, metrics, traces. Three pillars. Three solutions. Three bills.

I used to repeat it too. It was a clean story — each pillar answers a different question, use the right tool for the job, everyone's happy. It's also, on reflection, a narrative that conveniently maps to how vendors wanted to sell you tools.

Observability is not three things. It's one thing. And mistaking that is why most teams' "observability strategy" is really just a procurement strategy with a buzzword on top.

Where the frame came from

The three-pillars model was a pedagogical win when it arrived. Metrics came from the ops world — pre-aggregated numbers stuffed into time-series databases, cheap to store, fast to chart. Logs came from every application ever written. Traces came late, with microservices, when nobody could figure out why a request took three seconds and the metrics all looked fine.

The pillars were a way of saying: "here are the three kinds of data you already have. Stop ignoring any of them." That was genuinely useful. In 2017.

Then it ossified. Vendors built products per pillar. Conferences ran tracks per pillar. Teams hired engineers per pillar. And the frame stopped describing reality and started enforcing it.

The actual question

Observability, as Charity Majors keeps pointing out, is the ability to ask arbitrary questions of your running system without having predicted those questions in advance. That's the test. If you have to ship new code, add a new metric, or redeploy a dashboard to answer a novel question, you don't have observability. You have monitoring with good marketing.

Notice what that definition doesn't mention: logs, metrics, traces. Those are implementation details of how you produce the underlying data. They are not the product.

What the pillar frame costs you

Three concrete failure modes I've seen in every mature team that bought into pillar-based tooling:

1. Correlation gaps. An alert fires on a metric. You pivot to the trace view in a different tool. You find the request ID. You go to the logging tool, paste the ID in, and it returns nothing — because the log got sampled away, or was written in a different format, or lives in a different retention tier. The three systems don't share identity. The "pivot" is a lie.
2. Query language fatigue. PromQL for metrics, LogQL or vendor-flavored search for logs, something else for traces. Even if you're expert in all three, you context-switch every time you debug. Junior engineers just stop asking questions.
3. Incentive misalignment. Each pillar is billed separately, so each team optimizes its pillar separately. Cardinality gets stripped from metrics to save money. Logs get sampled to save money. Trace retention gets cut to save money. Every cost-saving choice destroys the ability to correlate — the one thing that would have actually helped an incident.

What unified observability looks like

Imagine a single data model: an event is a structured record with a timestamp, a set of key-value dimensions, and a causal link (a trace ID and parent span). That's it. Everything else is a view over that data.

• A "metric" is just COUNT(events) or PERCENTILE(events, duration) grouped by dimensions.
• A "log" is an event where you happened to include a message field.
• A "trace" is the set of events sharing a trace ID, ordered by their causal links.

Built this way, the pivot from "high p99 alert" to "show me the ten slowest requests and their tags and their full span tree" isn't a pivot at all. It's the same query, with different GROUP BY and SELECT clauses, against the same dataset.

This is not hypothetical. Honeycomb built on exactly this idea. ClickHouse and the OpenTelemetry Collector let you do it yourself. Observability 2.0 — the wide-event model — is the industry quietly catching up to what the frame should have been in the first place.

"But we already have three tools"

Fair. Nobody throws out a working stack on a blog post. Two pragmatic moves you can make without ripping anything out:

• Standardize identity. Pick a trace ID format (OpenTelemetry is the obvious one) and propagate it through logs, metrics exemplars, and traces. The pivot between tools becomes mechanical, not heroic.
• Push structure upstream. Stop writing log lines like "user 1234 failed checkout: invalid_card" and start emitting structured events with user_id=1234, event=checkout_failed, reason=invalid_card. This is the single highest-ROI change you can make in observability — and it has nothing to do with which pillar the data lives in.

The vendor part

I am not cynical about observability vendors as a class. Several of them are run by people who understand this perfectly well and are actively trying to collapse the pillar model. But the ones with "all three pillars in one platform!" on their homepage and three SKUs in the contract — read the contract. Understand that the unification is UI-deep and the data is still siloed. You'll feel it the first time you try to follow a trace into a log into a metric and the identifiers don't line up.

What to do this quarter

1. Audit the pivot path. Take a real incident from last month. Walk through it. Count the times you had to open a new tab, paste an ID, or guess at how one system's data maps to another's. That count is your observability debt.
2. Adopt OpenTelemetry end-to-end for instrumentation, even if your backends stay disparate. At minimum you'll standardize the identifiers and the data shape, which makes every future migration cheaper.
3. Stop saying "three pillars" in your architecture docs. Start saying "events" and "views over events." The language shapes the thinking, and the thinking shapes the budget.

The pillars were scaffolding. Scaffolding is useful when you're putting up a building, and embarrassing when it's still there a decade later.