Most Cloud Native Teams Run Three Observability Stacks Because Nobody Told Them How to Run One

In Brief

A CNCF-published survey of 407 practitioners reveals that observability tool fragmentation persists despite mature, interoperable projects like OpenTelemetry and Prometheus. The primary blocker is not missing features but configuration friction: 54% cite dashboard and alert setup as their top challenge. For Bulgarian teams operating in increasingly regulated environments (NIS2, DORA), this fragmentation creates compliance risk and operational overhead that compounds with every additional tool.

The Tooling Matured. The Integration Work Did Not.

OpenTelemetry provides vendor-agnostic instrumentation. Prometheus handles metrics. Jaeger and Tempo cover distributed tracing. Fluentd and Loki manage log aggregation. The CNCF (Cloud Native Computing Foundation) ecosystem has spent years building consensus around these projects. The standards exist. The documentation exists. The Helm charts exist.

So why are teams still running three stacks?

The survey data points to an uncomfortable truth: tool adoption happens incrementally, across different time periods, for different use cases. A team adopts Prometheus in 2023 for Kubernetes metrics. In 2024, someone adds Jaeger for tracing a particularly nasty latency issue. By 2025, there’s a Loki deployment because the security team needed centralized logs for an audit. Each tool solves a real problem. None of them talk to each other without significant integration work.

That integration work does not happen on its own. It requires dedicated engineering time, clear ownership, and organizational buy-in. Most teams have none of these in sufficient quantity.

Configuration Friction Outweighs Feature Gaps

The survey asked practitioners what single improvement would most benefit their observability setup. The answer was not more features or better AI. The top response across all company sizes: a unified solution.

When asked about specific pain points, 54% identified dashboard and alert configuration as their primary challenge. Integration complexity followed at 46.4%. Data pipeline setup came in at 33.2%.

These numbers tell a story about where the actual work happens. Connecting an OpenTelemetry collector to a backend analysis system is not difficult in isolation. Propagating trace context across a service mesh is documented. Correlating logs with trace IDs is a solved problem in theory.

In practice, each of these tasks requires understanding the specific quirks of the specific versions of the specific tools in the specific environment. The OpenTelemetry Operator for Kubernetes has made progress on automating instrumentation injection and collector management, but progress is not the same as solved.

The gap is not between what the tools can do and what teams need. The gap is between what the tools can do and what teams can realistically configure, deploy, and maintain without burning their entire sprint on YAML archaeology.

AI-Assisted Observability: High Demand, Measured Expectations

The survey found that 59.5% of respondents want AI-powered anomaly detection as a built-in capability. Automated incident summaries and predictive alerting ranked as top priorities.

But here is the nuance that matters: 48.3% of respondents want human oversight maintained before any fully autonomous remediation action.

This is not a rejection of automation. This is practitioners who have seen what happens when automated systems take action in production without guardrails. The blast radius of a misconfigured auto-remediation script is not theoretical. It is a 3 AM page and a very long postmortem.

The workflows that add value are those that surface anomalies, correlate signals across telemetry types, and generate actionable context. The remediation decision stays with humans until the behavior of automated responses is well-understood and well-tested.

OpenTelemetry’s semantic conventions and standardized telemetry schemas are foundational here. AI anomaly detection is only as good as the consistency and richness of the underlying telemetry. Garbage in, garbage out, but with machine learning.

Integration Quality Drives Switching Decisions

Here is a finding that should concern anyone building proprietary observability tooling: 81% of teams report being satisfied with their current setup, yet 63% remain open to switching.

The primary driver? Integration quality, cited by 55.5% of respondents as the top reason they would consider a change. Features, cost, and support all ranked lower.

Teams that have invested in OpenTelemetry-native instrumentation are building a more durable foundation than those relying on proprietary integrations. When the integration layer is open and standardized, switching costs decrease. Composability increases. Optionality is preserved.

This is not an abstract architectural principle. It is a concrete business decision. The team running OTel-native instrumentation can evaluate new backends without rewriting their instrumentation layer. The team locked into a proprietary agent cannot.

What This Means for Bulgaria

Bulgarian tech teams face a specific set of pressures that make observability fragmentation particularly costly.

Regulatory compliance is tightening. NIS2 (Network and Information Security Directive 2) and DORA (Digital Operational Resilience Act) both require demonstrable incident detection and response capabilities. Running three observability stacks means three sets of audit trails, three sets of access controls, and three sets of documentation to maintain. Unified observability is not just an operational efficiency play; it is a compliance simplification play.

The talent market is constrained. Finding engineers who can operate one observability stack well is hard enough. Finding engineers who can operate three is harder. Consolidation reduces the surface area of expertise required.

Cloud region availability matters. Bulgarian teams often operate workloads across multiple cloud providers and regions. OpenTelemetry’s vendor-agnostic approach means instrumentation does not need to change when the backend does. This is particularly relevant for teams serving both EU and non-EU markets with different data residency requirements.

Cost pressure is real. Observability tooling costs scale with data volume. Running three stacks means paying for three sets of data ingestion, storage, and retention. Consolidation is a direct cost reduction.

The Path Forward: Reference Architectures and Better Defaults

The survey data suggests three areas where investment would have the clearest downstream impact.

Setup friction is the most immediate opportunity. Better operator tooling, improved default configurations, and reference architectures for common cloud native stack combinations would lower time-to-value for the majority of teams. The OpenTelemetry community has made progress here, but progress is not done.

OpenTelemetry remains the highest-leverage foundation. Teams running OTel-native stacks are better positioned to adopt AI-assisted tooling, reduce integration debt, and preserve optionality. The investment in standardized instrumentation pays dividends across every other observability decision.

AI-assisted observability needs a nuanced framing. Practitioners want help surfacing anomalies and generating incident context. They do not want fully autonomous remediation without human oversight. Community resources that help teams build confidence in specific automated responses before moving toward autonomy align more closely with how people are actually approaching this in practice.

The cloud native observability ecosystem is, by most measures, in a good place. The standards exist. The projects have matured. What remains is closing the gap between what is technically possible and what teams can realistically deploy, configure, and operate with confidence.

That gap is not a tooling problem. It is a documentation problem, an adoption problem, and an organizational problem. The tools are ready. The teams are not. And the path from here to there runs through better defaults, clearer reference architectures, and the kind of opinionated guidance that helps practitioners make decisions instead of drowning in options.