The Three Pillars Are Not the Point. Cardinality Is, and It Is What You Get Billed For.

Ask a team whether they have observability and you will usually be told about the three pillars: logs, metrics, traces. All three present, therefore observable.

That reasoning does not hold, because the three pillars are a taxonomy of data formats and observability is a capability. Owning three shapes of data tells you nothing about whether you can answer a question nobody thought to ask in advance, which is the only test that matters at three in the morning.

Charity Majors, who has argued this longer and more bluntly than anyone, puts it as: there are no three pillars, the pillars are nonsense. The framing spread around 2020 as vendors moved into the space, and the definition broadened until it could describe almost any tooling.^[1]

The Distinction That Actually Separates Them

The cleanest formulation, and it is worth memorising because it settles most arguments: monitoring handles known unknowns; observability handles unknown unknowns.^[2]

Monitoring answers “is the thing I predicted happening?” You decided in advance that CPU above 80% matters, so you built a dashboard and an alert. That is genuinely valuable and it is not observability, because it can only ever tell you about failures you already imagined.

Observability answers “why is this specific requestslow, when nobody predicted this?”^[2] Nobody built a dashboard for it. There is no alert. It is happening anyway, and the question is whether you can investigate it right now or whether you have to ship instrumentation first and wait for it to recur.

That last clause is the practical test. If diagnosing a novel problem requires a deploy, you have monitoring.

The Unit That Makes It Work

If not pillars, then what? The functional unit is the arbitrarily wide structured event: one record per request, carrying every attribute that was true at the moment it happened.^[3]

User ID. Build ID. Request ID. Tenant. Region. Feature flag state. Whatever else was in scope.^[3] Not three separate systems you correlate afterwards by squinting at timestamps, but one wide row you can slice by any of those fields after the fact.

Why that shape rather than metrics: because metrics are pre-aggregated, and aggregation is lossy in exactly the direction that hurts. A p99 latency number tells you something is slow for someone. It cannot tell you that the someone is customers on build 4823, in eu-west, with one flag enabled, because that information was averaged away at write time. You cannot recover a dimension you did not keep. The distinction between throughput and responsiveness in latency versus bandwidth is the same lesson at a different layer: the aggregate hides the thing you are hunting.

Cardinality, and the Bill

Cardinality is the number of distinct values a field can take.^[3]Region is low cardinality, maybe a dozen values. User ID is high cardinality, one per user.

High-cardinality fields are the ones that make novel questions answerable, because narrowing to which requests are failing requires a field with enough distinct values to isolate them. Low-cardinality data supports low-resolution answers.

Now the part that deserves to be said plainly, because vendor documentation puts it delicately. The main cost drivers in observability tooling are the number of tools, the cardinality of the data, and its dimensionality, meaning how much context you keep per record.^[4]

Those are the same three properties that make the data useful. You are billed in direct proportion to the capability you are buying, which means the pricing model runs against the reason you bought the tool.

None of which means do not sample. It means sample deliberately, keeping errors and slow outliers at a much higher rate than successful fast requests, rather than uniformly at 1% because that was the default. The decision is which questions you are willing to become unable to answer, and it should be made explicitly rather than by a config value nobody revisited.

What To Do With This

Test the capability, not the inventory. Pick a real question you could not have predicted, such as which customers saw elevated errors after the last deploy, and try to answer it with what you have. If you cannot, adding a fourth log aggregator will not help.

Instrument wide, not deep. One event per unit of work with many attributes beats many narrow log lines you later try to reassemble. Put the identifiers on it at the time, because you cannot add a field retroactively to an event that has already been written.

Keep build ID and feature flag state.These are the two highest-value fields most teams omit, and they are the ones that turn “something changed” into “this change did it”. The second matters more than it looks, because a flag flip changes production without a deploy, so an incident where nothing was deployed can still have a cause.

Sample by value, not uniformly. Keep every error and every slow request. Sample the boring successes hard. Your bill barely notices and your incidents get much shorter.

Remember what this is for. Observability is how you find out that a dependency has become intermittently slow in a way that never trips a threshold, which is exactly the failure a circuit breaker cannot detect and a bulkhead only contains. The tooling and the resilience patterns are answers to the same problem from opposite ends.