What's changed about OpenTelemetry® vendor lock-in since 2024

In late 2024, David Allen and I co-authored a post on the Grafana blog about OpenTelemetry and vendor neutrality. The argument was straightforward: OpenTelemetry removes vendor lock-in at the instrumentation and collection layers, but the storage, visualization, and alerting layers are a different story. Most of that argument still holds. What has changed, and changed quickly, is the practical experience of moving from one observability vendor to another. In 2025 and 2026, that experience became noticeably less painful, and the reason has less to do with OpenTelemetry itself than with how engineers now interact with their telemetry.

It is worth being precise about what was ever promised. Nobody in the OpenTelemetry community claimed that switching vendors would be easy or effortless. OpenTelemetry came with a narrower promise: the lock-in that lived in the instrumentation and collection layers, where proprietary agents tied data collection to a specific backend, would be removed. Storage, visualization, alerting, dashboarding, and everything that sits on top of the raw telemetry are deliberately outside the project's scope. They always were. Treating OpenTelemetry as if it guaranteed zero lock-in across the entire stack is reading a promise that was never made.

Data portability, not dashboard portability

The part of that post that has aged best is the observation that an engineer's experience with a tool is not portable. OpenTelemetry makes your data portable. It does not make your familiarity portable. If you have spent two years learning where to look in a particular backend, which queries answer which questions, and how to read a specific waterfall view under pressure, that knowledge does not transfer when you switch. It has to be rebuilt, and rebuilding it takes real time.

The same is true for the artifacts a team accumulates around a backend: dashboards, saved queries, alert definitions, runbooks that reference specific views. None of that moves with the data. The sunk cost of all that work is a genuine form of lock-in, and it is the form OpenTelemetry was never going to solve, because it lives above the layer OpenTelemetry standardizes.

What changed

What shifted is the interface between engineers and their telemetry. For most of observability's history, that interface was a web UI: you logged into a backend and looked at dashboards someone had built. The dashboards were the product, and rebuilding them somewhere else was the cost of leaving.

Engineers living a little ahead of the curve now interact with telemetry differently. At OllyGarden, we increasingly reach for coding agents wired into Model Context Protocol (MCP) servers and command-line interfaces (CLIs) rather than opening a dashboard first. Tools like gcx or pup let us pull telemetry, connect it to other systems, and reshape it on the fly. MCP servers and CLIs make moving data between systems, and connecting systems together, easier than it has ever been. When the interface is a CLI and an agent rather than a vendor's bespoke UI, the question of which backend stores the data starts to matter less.

A concrete example: I have a daily digest skill that, among other things, gives me the state of our critical services every morning. It tells me which customers deserve attention based on the traffic they are sending and, just as importantly, the shape of that traffic. Are they sending more logs today than they ever have? Did their metrics drop off? Instead of opening a static dashboard and scanning for anomalies myself, I get a pre-triaged "what's important right now" view, assembled by an agent against the raw telemetry.

The shift goes further than telemetry, though, and that is the part that matters most for how a workday actually flows. Because the operational picture now arrives through the same interface as everything else, it gets triaged alongside the rest of my work rather than in a separate tab. Is there an urgent Linear issue waiting for me, or is a system on the verge of breaking? Should I be reading an email thread instead, or does a Slack message need my attention right now? Those used to be questions I answered by checking several different places, each with its own UI and its own mental context switch. Now there is one interface to all of them, and the agent helps me weigh a service trending toward trouble against a customer email and an open issue, in one place, with one ranking.

The caveat

This is not a story about agents replacing observability backends. The agents are not perfect. They require constant supervision and double-checking, and they make mistakes that a human reading a dashboard would (hopefully) not. Having access to the raw telemetry does not replace the real engineering that goes into a full observability solution: the curation, the correlation, the years of accumulated judgment about what matters. We are nowhere near the point where raw data access makes a mature backend irrelevant.

What we are seeing is that access to the raw telemetry is more valuable, and more usable, than it used to be. The case in point is recent and direct: we experimented with moving from one observability vendor to another. The result was not perfect. But it was good enough that we did not feel the same level of lock-in we would have felt a couple of years ago. The data came across, the agents and CLIs let us keep working in familiar ways, and the parts that were hard were the parts the 2024 post predicted would be hard: relearning a new tool's way of surfacing information.

The boundary I would draw today is between consuming telemetry and operating the infrastructure behind it. Teams can already build observability tools around their own workflows and preferences. For bounded failures, especially in low-criticality services, a capable model can investigate the telemetry, identify a likely cause, and sometimes arrive at a pull request. We have done this ourselves. Manual, dashboard-first triage is no longer the only practical default.

What has not become easy is maintaining a scalable and reliable telemetry store and query engine. Agents still need durable data, fast queries, and trustworthy evidence against which their conclusions can be checked. Proactive alerts also remain necessary; the agent-generated morning brief complements them rather than replacing them. Agents are changing the consumption and triage layers, not eliminating the backend that makes those workflows possible.

Where this goes next

Eighteen months ago, nobody could have predicted where we would be today, and it is just as impossible to predict where we will be eighteen months from now. One thing seems safe to bet on, though. OpenTelemetry's work on standardizing instrumentation and collection, combined with the increasingly important standardization of the shape of telemetry through semantic conventions, means that good telemetry will be even easier for agents to consume in the future. Consistent attribute names and predictable structures are what an agent needs to reason about data it has never seen before.

As a result, telemetry is becoming accessible to more than dedicated observability specialists. When agents can reach it through application programming interfaces (APIs), CLIs, and MCP servers, the same data can inform software development, capacity planning, customer support, and routine operational decisions. Portability therefore matters not only because it lowers switching costs, but because it allows telemetry to participate in more workflows.

We are starting to see artificial intelligence (AI) agents for site reliability engineering (SRE) become useful for triage and remediation. The next step is to use telemetry for one of observability's original promises: improving running systems, rather than only helping people explain why they failed. Diagnosis produces an answer. A closed loop uses that answer to make the system better.

Experiments are already moving in that direction. Autonomous agents continuously query telemetry, form hypotheses, make changes, run tests, open pull requests, merge and deploy within defined guardrails, observe the results, and roll back when a new version does not improve on the one before it. Then the loop starts again. This may sound too futuristic to some teams, but it already describes experiments happening today.

The lock-in conversation has been stuck on the cost of leaving a backend. The more interesting shift is that standardized, portable telemetry is becoming a substrate for systems that do more than explain failures. They can continuously improve the software producing that telemetry.