What Is OpenTelemetry, Anyway?
At its heart, OpenTelemetry (often called OTel) is a standardized toolkit for a practice known as observability. It gives developers a single, open-source way to get data—specifically metrics, logs, and traces—out of their applications. Before OTel, this
was often a messy, fragmented process. Every monitoring tool had its own proprietary agent and way of collecting data. If you wanted to switch from one vendor to another, you’d have to rip out all your instrumentation and start over. OTel was created by merging two existing projects, OpenTracing and OpenCensus, to provide a common language for observability and end vendor lock-in. The idea is simple: instrument your code once, and then send that data to any backend tool you choose.
The Argument for Going All-In
For many senior engineers and architects, adopting OpenTelemetry is a strategic no-brainer. The primary benefit is vendor neutrality. By using an open standard, teams can avoid getting locked into a single provider’s ecosystem, giving them the flexibility to switch tools as their needs or budgets change. This puts control back in the hands of the engineers. Another major advantage is standardization across a company's systems. Instead of having different teams using different tools and creating inconsistent data, OTel provides a unified library and a single standard, which significantly improves data quality and simplifies collaboration. This big-picture, long-term vision is compelling: a future where observability data is as portable and standardized as any other core piece of infrastructure.
Why Many Experienced Engineers Are Skeptical
Despite the promise, many senior engineers remain cautious, and their skepticism is rooted in practical experience. One of the most common complaints is about maturity and stability. The OpenTelemetry project is constantly evolving, with frequent updates and changes to conventions that can break existing dashboards or require tedious updates across large systems. Engineers who have been burned by half-baked standards in the past are wary of committing to something that still feels like it’s in flux. Others worry about performance overhead. Instrumenting code always adds some load, and critics argue that OTel's one-size-fits-all approach can be bloated and inefficient compared to highly optimized, vendor-specific agents, especially in performance-critical environments. Some benchmark studies have shown that enabling OTel can increase CPU usage by a noticeable margin.
The 'Lowest Common Denominator' Problem
A more philosophical critique from seasoned developers is the fear of the "lowest common denominator." The argument is that in trying to be a universal standard that works for everyone, OpenTelemetry can't excel at anything in particular. Specialized vendors often innovate with unique, powerful features—like advanced profiling or deep auto-discovery—that might not fit into the OTel standard. By committing fully to OpenTelemetry, teams risk losing access to these best-in-class features, settling for a tool that's just "good enough" rather than great. This feeling is compounded by a sense that OTel can feel overly complex and engineered, with a steep learning curve and a dizzying number of components like collectors, exporters, and propagators that can be difficult to navigate.
