An all-green dashboard doesn’t prove your information system is healthy. It proves that the part of your IS your tools can see is healthy. The rest, sometimes critical, has no indicator at all. This article explains why that blind spot exists, why it is structural, and why closing it means reconciling two worlds we were wrong to set against each other.
I’ve already written a lot here on the subject: on the distinction between monitoring and observability, on the all-in-one trap, on the two-pole approach. And, in more depth, in the white paper “From monitoring to observability”. Those pieces tell a journey: the one the market makes everyone take, from monitoring to observability, the way you pass from one age to the next. This article begins with a question nobody asks once they’ve arrived: what if the journey left something behind?
What’s at stake, before any technique
Let’s put it plainly, without a word of jargon. Over the past decade or so, the way we watch an information system has improved enormously. We moved from tools that signalled that one element had gone down to tools that explain why a whole service is degrading. This evolution — from monitoring to observability — is real, and it is desirable.
But it comes with a counterpart that few IT departments see coming, and that is what interests me here. These modern tools can only observe what you can equip: recent applications, containerised environments, everything designed, from the outset, to be instrumented. The rest — network equipment, hardware, industrial systems, regulated or legacy environments — remains invisible to them. Not poorly covered: structurally out of reach.
The danger, for a decision-maker, is therefore not that an indicator turns red. It’s that there is no indicator at all. The absence of an alert is not the absence of a problem: it is the absence of a sensor. In a hospital, a factory, a local authority or a sovereign infrastructure, the part the tool cannot see is often the very part that carries service continuity and regulatory exposure — precisely where you cannot afford a gap. Our company sums up its promise in a few words: see everything, act fast, depend on no one. This article starts from a practitioner’s admission: today, something still prevents us from seeing everything. And that something is not a backlog to catch up on.
I’ve spent my career at the hinge between these two worlds — historical monitoring, which stayed in contact with hardware and the network, and modern observability, which I run in production. It’s from that position, not from a soapbox, that I write.
To understand that this really is a structural blind spot — and not just one more technology fad — you have to follow, briefly, how observability was built. The reader in a hurry, or the decision-maker who has already grasped the point, can skip straight to the section “The blind spot isn’t in the debate.”
Fifteen years perfecting the same answer
Modern observability has a short and remarkably consistent history. In 2018, in Distributed Systems Observability (O’Reilly), Cindy Sridharan gave the field its reference vocabulary — logs, metrics, traces — while already noting that platforms like Kubernetes had produced partial, diffuse failure modes that classical monitoring could no longer name. Her earlier essay, “Monitoring and Observability” (2017), draws the line between the two notions. But look at the frame: from the outset, it is that of the distributed application. The founding question is: why does a request that crosses forty services come back slow?
Internal criticism arrives fast — a sign of the field’s maturity — but it never leaves the frame. Faulting the “three pillars” for being consumed in silos rather than correlated with each other (an argument found under the title “The Three Pillars — Revisited,” o11ytime) is still debating the right way to organise application telemetry. “More data doesn’t make more observability,” it’s rightly said — but we’re always talking about the same data.
Then comes the avant-garde. In 2024, in “There Is Only One Key Difference Between Observability 1.0 and 2.0” (Honeycomb), Charity Majors buries the three pillars and proposes an “observability 2.0”: a single source of truth, the wide, structured event, from which everything else — metrics, traces, dashboards — is derived. It is, today, the field’s sharpest debate. And it must be seen for what it is: a debate about the storage model for application telemetry. The wide event is born of the request. The frontier of innovation, in 2025, pits two ways of modelling what an application produces about itself.
There is indeed a tradition that never left the machine. Brendan Gregg — the USE method, Systems Performance (2nd ed., 2020), BPF Performance Tools (2019) — has always practised an observability that starts from the kernel and the hardware, not from the request. And a generation of tools built the bridge: thanks to eBPF, obtaining infrastructure-grade visibility without instrumenting the code. Coroot, Netdata, Pixie, Parca (Polar Signals), Cilium/Hubble — each in its way attaches probes to the system rather than to the software. Coroot even named the cost they remove: the “observability tax,” the price in time and resources of manual instrumentation, which leaves blind spots on third-party and legacy services.
But look at where the bridge stops. eBPF attaches probes to the Linux kernel of a host you control. Gregg analyses the performance of a system you have a hand on. All this ingenuity — from the three pillars to the wide event, from the USE method to eBPF — shares an assumption no camp states, because none of them sees it: it assumes that the thing to be observed is instrumentable.
The blind spot isn’t in the debate. It’s beneath the debate.
This is where it all turns. While the industry refines, generation after generation, the way it models telemetry it has already managed to collect, no one is fighting over what it cannot collect at all.
Yet a real company’s information system is not a homogeneous fleet of cooperative Linux containers. It’s a heterogeneous assembly, a substantial part of which is, by construction, closed to instrumentation.
Definition. I call the non-instrumentable part of the information system the set of components that cannot, by nature, host an agent, a probe, an SDK or a trace: network equipment queried over SNMP, physical hardware and sensors, storage arrays and appliances, industrial controllers and sensors (OT/IIoT), IBM i systems, third-party vendors’ black boxes, regulated or isolated environments where you install neither agent nor probe. For these objects there is no kernel to attach a probe to, no SDK to integrate, no request to trace. They therefore remain beyond the reach of any instrumentation-based observability — whatever its generation. This is what I also call, plainly, the blind spot of observability.
On this part, Coroot’s “observability tax” doesn’t become expensive: it becomes infinite. No amount of time or resources lets you instrument something that has no instrumentation surface.
And it is not a vanishing remnant. For a hospital, an industrial site, a local authority, a sovereign infrastructure, this non-instrumentable part is not a technical debt soon to be retired: it’s the load-bearing majority of the system, the part on which real operational risk rests. The dominant discourse treats it as legacy on borrowed time. But you cannot observe what you’ve declared obsolete — and declaring the backbone of a hospital or industrial IS obsolete is not an observability strategy, it’s a governance blindness.
Observability, by building itself against monitoring, gained correlation, high cardinality, the ability to answer the “why.” But it lost coverage. Monitoring, for its part, never let go of covering the real IS — it merely paid for it with analytical poverty: thresholds, states, little correlation, almost no “why.” Each kept half the answer. This is exactly the trap I described in “No single tool covers everything”, but seen one layer down: no longer between products, but between two entire philosophies of measurement.
The loop, not the line
Hence this article’s thesis. The honest movement is not monitoring → observability — that arrow which dismisses one world in favour of the other. It’s a loop: observability must come back to the infrastructure it left behind. Not to become monitoring again, but to bring its lens — correlation, cardinality, the “why” — to the part of the IS that neither observability 1.0 nor 2.0 will ever reach, because both assume you can instrument what you observe.
monitoring ⋃ observability. The union, not the succession. It’s the only complete frame for a real information system. It’s not a soft compromise between two camps: it’s the recognition that each held the other’s missing half. It is also, very concretely, the two-pole approach that shapes the way we work — the precision of modern observability and the coverage of field monitoring, held together rather than opposed.
And it’s precisely the gap that a long practice of monitoring, extended by a production observability stack, lets you occupy. Not because we picked the right camp, but because we refused to choose.
Seeing everything means retracing your steps
Back to the green dashboard. The decision-maker looking at it doesn’t need to know eBPF, SNMP or the three pillars to grasp the essential: the serenity that green inspires depends entirely on what the tool is able to capture. As long as the observability strategy is limited to what is instrumentable, the green covers a hole — and the hole sits, statistically, exactly where the risk is heaviest: service continuity, compliance, sovereignty.
“See everything” is therefore not a slogan: it’s a coverage requirement, and it forces you to retrace your steps, back toward the infrastructure you thought you’d left behind. The right question to ask of any observability setup is not “how much data do you collect?” but “what fraction of my real IS do you remain, by construction, unable to see?”
On the tooling side, this reintegration already has concrete forms — it’s the layer that “Two holes in the open source observability stack” describes in detail, and that this article sits conceptually above: SenHub Agent, an OpenTelemetry-native agent that collects in a unified way, including what has no SDK to offer; and Toise, the living, queryable map of the infrastructure — the part you couldn’t see, reintroduced into the graph. But the tool comes after. It’s the thesis that matters: as long as you reason in a line, you perfect half an answer. You have to reason in a loop.
If you want the beginning of the story, it’s all in the series: “Monitoring vs observability”, then the white paper “From monitoring to observability”.
Sources
- Cindy Sridharan, Distributed Systems Observability, O’Reilly, 2018 — oreilly.com
- Cindy Sridharan, “Monitoring and Observability,” 2017 — copyconstruct.medium.com
- “The Three Pillars — Revisited,” o11ytime — o11ytime.com
- Brendan Gregg, “The USE Method” — brendangregg.com; Systems Performance (2nd ed., 2020), BPF Performance Tools (2019)
- Coroot, “Using eBPF and predefined inspections to minimize observability tax” — coroot.com
- Charity Majors, “There Is Only One Key Difference Between Observability 1.0 and 2.0,” Honeycomb, 2024 — honeycomb.io
- eBPF ecosystem cited: Netdata, Pixie, Parca / Polar Signals, Cilium / Hubble.
