There’s a fundamental design flaw at the heart of how OpenTelemetry instruments libraries.
The current approach relies on external instrumentation: separate packages that hook into, intercept, and monkey-patch other libraries from the outside. Sounds clever. In practice? It’s fragile, expensive, and fighting an uphill battle.
Take the Node.js ecosystem as an example. Hooking into library calls requires import-in-the-middle — a fragile and expensive mechanism that adds real runtime overhead. And if you bundle your application? Instrumentation silently breaks. The hooks rely on intercepting Node's module loading, which bundlers bypass entirely.
The better path was always the simpler one: let the libraries themselves expose telemetry natively.
Think about it, who understands a library’s internals better than its own maintainers? Instead of reverse-engineering call patterns from the outside, the people who wrote the code can emit traces and metrics at exactly the right points, with exactly the right context. No interception. No patching. No guessing.
“But that means every library needs to add support!”. yes, and that’s actually fine. These are open-source projects. Anyone can open a PR. And a few lines of native instrumentation inside a library will always be more reliable than an elaborate external hook trying to do the same thing from the outside.
But actually, this design flaw stems from a deeper flawed concept: treating observability as an afterthought. Instead of observability being a first-class feature, something the person writing the code owns and takes responsibility for, it’s something we accept bolting on from the outside at runtime. That mindset is the root of the problem.
As long as we treat observability as someone else’s job, we’ll keep building systems that are harder to understand, debug, and operate than they need to be.