Hi,

For a long time, observability felt like a tooling choice.

Your team picked Datadog, Grafana, New Relic, Honeycomb, Elastic, Dynatrace, or another platform, then routed logs, metrics, and traces into whichever system made the most sense.

That model is starting to shift.

In May, the Cloud Native Computing Foundation announced that OpenTelemetry has officially graduated, calling it the de facto vendor-neutral standard for collecting and exporting telemetry data. According to CNCF, the project now has more than 12,000 contributors from over 2,800 companies, and its JavaScript and Python API packages were downloaded more than 2.6 billion times over the past year.

That matters because OpenTelemetry is no longer just another observability project. It is becoming the shared instrumentation layer underneath modern software. DevOps.com put it clearly: OTel has moved beyond applications into infrastructure and security tooling, and it is now positioned to play an important role in instrumenting AI agents as they generate much larger volumes of telemetry.

The shift is subtle, but important.

Observability used to mean, “Can we see what broke?”

Now it increasingly means, “Can every part of the system produce standardized signals that platforms, engineers, and AI systems can reason over?”

That is why OpenTelemetry’s graduation feels less like an open-source milestone and more like an architectural one.

This is happening as observability itself expands beyond the classic three signals. In March, OpenTelemetry Profiles entered public alpha, bringing profiling data into the same ecosystem as logs, metrics, and traces. The goal is to connect resource consumption and code execution back to the services, traces, and infrastructure already producing telemetry.

In simpler terms: performance debugging is becoming part of the same shared signal layer, instead of remaining a separate specialist workflow.

OpenTelemetry is also moving closer to the user experience layer. CNCF recently accepted a Kotlin Multiplatform API and SDK for OpenTelemetry, extending vendor-neutral telemetry across Android, iOS, web, and server-side Kotlin environments.

That is a meaningful signal. Observability is no longer just backend infrastructure. It is moving into mobile apps, client-side experiences, and cross-platform products.

The business pressure points in the same direction. LogicMonitor’s 2026 observability and AI outlook found that 96% of surveyed IT leaders expect observability spending to hold steady or increase. At the same time, 84% are pursuing or considering tool consolidation, and 67% are likely to switch observability platforms within one to two years.

That says a lot. Teams are not spending less on visibility. They are questioning fragmented tooling stacks.

AI is making this even more urgent. Elastic’s 2026 observability research says GenAI and OpenTelemetry are becoming foundational requirements for observability platforms. Organizations increasingly expect integrated AI, full OTel support, LLM observability, and security controls as part of vendor evaluation.

​Datadog’s 2026 AI engineering report makes a similar point from the operational side: scaling AI requires real-time visibility across GPU utilization, model behavior, and agent workflows, not just traditional application metrics.

So the bigger story is not simply that OpenTelemetry graduated.

The bigger story is that observability is becoming a shared substrate for modern engineering.

Old observability looked something like this:

The new model looks more like this:

That is a very different world.

It means the real competitive advantage may shift away from “which observability vendor do you use?” and toward “how clean, portable, complete, and useful is your telemetry layer?”

In a world shaped by cloud-native systems, platform engineering, and AI agents, visibility is no longer just for debugging.

Observability is becoming infrastructure.