Having spent considerable time working with cloud-native infrastructure, I can say we’ve gotten pretty solid at agreeing on the theory. OpenTelemetry handles instrumentation, Prometheus manages metrics, Jaeger and Tempo cover distributed tracing, and Fluentd or Loki take care of log aggregation — over the years, the community has genuinely rallied around these tools. The technology has matured, and the standards are in place. So where does that leave teams right now?
A February 2026 survey of 407 professionals — including DevOps engineers, SREs, platform engineers, cloud architects, and engineering leaders from over 20 industries — gives us one of the most revealing pictures we’ve had of the current landscape. Some findings are genuinely encouraging. Others tell us there’s still plenty of ground to cover.
Tool sprawl is still the norm
Even with mature, interoperable cloud-native observability projects readily available, close to 46.7% of organizations are still running two to three observability tools side by side. A mere 7.4% have managed to consolidate everything into a single, unified observability experience.
When asked which single improvement would make the biggest difference to their observability setup, the absence of a unified solution came out on top across organizations of every size, from small startups to large enterprises.
This isn’t really a tooling problem — at least not on the surface. OpenTelemetry has put in serious effort to deliver a vendor-neutral, consistent instrumentation layer that works across languages and runtimes. The real issue seems to be organizational and operational: teams pick up tools gradually, at different times and for different purposes, and the work needed to stitch all those data streams together doesn’t just happen automatically.
For the cloud-native community, this looks like both a documentation problem and an adoption problem. More straightforward guidance on how to combine OpenTelemetry, Prometheus, and distributed tracing tools into well-functioning, manageable stacks — along with reference architectures that demonstrate these integrations in real-world scenarios — would likely make a significant dent in the fragmentation so many teams are dealing with.
Getting things set up is harder than missing features
One theme came through loud and clear in the survey: teams aren’t frustrated by what their observability tools are capable of. They’re frustrated by how much effort it takes to configure and maintain them.
54% of respondents pointed to dashboard and alert configuration as their single biggest setup headache, placing it above any missing product feature. Integration complexity came in second at 46.4%, with data pipeline setup at 33.2%.
In cloud-native environments, this friction typically surfaces at the seams between systems: hooking OpenTelemetry collectors up to backend analysis platforms, passing trace context across service meshes, making sure logs are correlated with trace IDs, or setting up alert rules that reflect how dynamic, container-based workloads actually behave rather than relying on assumptions built for static infrastructure. If you’ve spent any meaningful time in a Kubernetes-heavy setup, this probably hits close to home.
Initiatives like the OpenTelemetry Operator for Kubernetes have made real headway here — automating instrumentation injection and collector management within Kubernetes environments. Even so, the numbers indicate there’s still plenty of room for the community to shorten the path to value through smarter default configurations, better alert management tooling, and more opinionated starter templates tailored to common cloud-native stack combinations.
AI-assisted observability: real demand, grounded expectations
The desire for smarter automation in observability tools comes through unmistakably in the data: 59.5% of respondents want AI-powered anomaly detection as a native feature. Automated incident summaries and predictive alerting rounded out the top priorities.
But the data also reveals an important caveat: 48.3% of respondents want a human in the loop before any fully autonomous remediation takes place. That’s not a dismissal of AI-assisted automation — it’s more likely a sensible, measured response to the complexity and potential blast radius of production systems.
For the cloud-native community, this maps closely to where observability meets the broader AIOps and platform engineering landscape. The workflows that seem to deliver the most value are the ones that flag anomalies, correlate signals across different telemetry types, and produce actionable context — while keeping remediation decisions in human hands until the behavior of automated responses is thoroughly understood.
OpenTelemetry’s semantic conventions and standardized telemetry schemas are foundational to making this work: AI anomaly detection is only as effective as the consistency and richness of the telemetry feeding it. Community investment in broadening and enforcing semantic conventions is directly powering the AI-assisted capabilities teams are asking for.
Integration quality determines long-term commitment
The survey uncovered a finding that will likely ring true for anyone involved in cloud-native project adoption: 81% of teams say they’re satisfied with their current observability setup, yet 63% are still open to switching.
What’s driving that willingness to switch? Integration quality, cited by 55.5% of respondents as the top reason they’d consider a change — ahead of features, cost, or support.
This feels like a signal for the broader cloud-native ecosystem, not just for individual tool choices. Teams that have invested in OpenTelemetry-native instrumentation and operate within an ecosystem of interoperable, standards-based tools appear to be laying a more lasting foundation than those depending on proprietary integrations. When the integration layer is open and standardized, switching costs tend to drop, composability improves, and teams keep more options open as the landscape evolves.
The community’s continued push to expand OpenTelemetry adoption across projects — ensuring that CNCF-hosted observability tools natively emit and consume OpenTelemetry data — directly addresses the integration quality concerns teams are voicing.
What this means for the cloud-native observability community
Stepping back, the data highlights a few areas where community investment could have the most direct impact on the practitioners who rely on these projects every day.
Setup friction is probably the most pressing opportunity. Stronger operator tooling, better default configurations, and reference architectures for common cloud-native stack combinations would shorten the time-to-value for the majority of teams that haven’t yet achieved a unified observability experience — which, according to the data, is most teams.
There’s also a compelling argument that OpenTelemetry remains the highest-leverage foundation for building composable, interoperable observability. Teams running OTel-native stacks seem better equipped to adopt AI-assisted tooling, reduce integration debt, and maintain flexibility as the ecosystem continues to evolve.
And the AI conversation calls for a balanced perspective. The data suggests practitioners aren’t asking for fully autonomous systems — they want help identifying anomalies and generating incident context, with humans remaining in control of remediation decisions. Community resources that help teams build trust in specific automated responses before moving toward greater autonomy align much more closely with how people are actually handling this in practice.
By most measures, the cloud-native observability ecosystem is in a strong position. The standards are in place. The projects have matured. What’s left — and what the data makes clear is the real work ahead — is narrowing the gap between what’s technically achievable and what teams can realistically deploy, configure, and operate with confidence.
Survey data referenced in this post comes from a February 2026 observability survey (n=407) examining observability practices across cloud-native environments.
