The Stonemason's Deliberate Strike: On the Necessity of the Unmeasured Column
We spend our days building cathedrals of data. Every service is a stone, every endpoint a joint, and our monitoring systems are the plumb lines and levels we use to ensure everything stands true. The received wisdom is to measure everything, to leave no stone unturned, no metric uncollected. We believe that a perfect, uninterrupted stream of data is the very essence of observability. But what if this ceaseless measurement, this obsession with illuminating every dark corner, is itself a structural flaw? What if, like a stonemason carefully chiseling away excess stone, we must sometimes choose what *not* to measure to ensure the integrity of the whole edifice?
The common argument is that more data equals more insight. If a service slows by ten milliseconds, we want to know. If a specific user action in a rarely-used feature fails, we want an alert. This creates a system of perfect, noisy accountability. But this approach ignores the weight of the measurement itself. Every metric collected, every log line indexed, every trace sampled is not free. It imposes a tax on the system being observed—a tax of CPU cycles, network bandwidth, and storage. More subtly, it imposes a cognitive tax on the engineers who must sift through the resulting avalanche of information. In our quest to eliminate all uncertainty, we risk burying the signal—the truly critical failure—under an avalanche of insignificant noise.
The Load-Bearing Silence
Consider the architecture of an old stone bridge. Its strength doesn't come from a perfect, homogenous surface. It comes from the keystone, the carefully shaped arches, and, crucially, the voids between the stones. These empty spaces are not failures of construction; they are essential to the structure's resilience, allowing it to flex and redistribute force without shattering.
An unmeasured system component is one of these load-bearing silences. It is a deliberate choice to accept strategic ambiguity. Perhaps it’s a non-critical, internal caching service that is so simple its only failure mode is a complete outage—an event that would be glaringly obvious from the failure of the services that depend on it. Instrumenting it with complex latency and error-rate dashboards adds negligible value but increases system complexity and operational toil. By choosing not to measure it with fine-grained detail, we grant ourselves the freedom to focus our finite attention on the true keystones of our architecture.
This is not an argument for negligence. It is an argument for thoughtful, ruthless prioritization. It asks us to shift from a mindset of "what can we measure?" to "what must we know?" and, more importantly, "what can we afford to not know immediately?" It requires a deep understanding of the system's anatomy, identifying which parts are the decorative gargoyles and which are the foundational piers. The goal is not a perfect, shimmering pane of glass showing every flicker, but a sturdy, reliable structure whose vital signs are so clear and unobstructed that they can be understood at a glance. Sometimes, building that kind of resilience means putting down the measuring tape and trusting the strength of the stone.
Notes & further reading
A few pages I came back to while writing this: