When platform engineers promise developers self-service observability, the reality often falls short. Traces start midstory, logs live in isolation, and metrics require separate pipelines. The culprit? Incomplete telemetry at the edge, where every request begins.

Main insights

• A new draft maturity model evaluates OpenTelemetry support across seven dimensions, revealing that most ingress controllers excel at tracing but struggle with unified metrics and log correlation
• Five popular ingress controllers were tested in identical environments, exposing significant differences in how telemetry is modeled at the source versus in downstream pipelines
• Platform teams currently compensate for incomplete telemetry through collector transforms and enrichment, but this operational burden could shift as projects mature their OpenTelemetry implementations
• The future of AI-native observability depends on consistent semantic conventions and stable telemetry models, making maturity evaluation critical for architectural decisions

Kasper Borg Nissen, Director of Product Marketing and Developer Relations at Dash0, brings deep expertise to this topic as a former KubeCon+CloudNativeCon Co-Chair, CNCF Ambassador, and Golden Kubestronaut. He co-authored "OpenTelemetry for Dummies" and actively shapes OpenTelemetry adoption across the cloud-native ecosystem.

You can watch the full discussion here if you missed it: https://www.youtube.com/live/-SXg48o_SJw

The platform engineer's observability reality

Platform engineers aim to deliver observability as a self-service capability. Developers shouldn't think about pipelines, formats, or correlation. They should just get useful insights. But the reality looks different. Traces often start midstory because the ingress layer isn't properly instrumented. Logs aren't correlated with traces. Metrics require separate pipelines.

"As platform engineers, we try to compensate," Nissen explained. "We build collector transforms. We add enrichment in pipelines. We stitch signals together so they look consistent. Eventually observability works, but only because the platform team is building and holding it all together."

This compensation work happens because ingress controllers and gateways sit at a critical boundary. Every backend request starts here. Before your instrumented services see anything, TLS termination happens, routing decisions are made, retries occur, and rate limiting may apply. If you don't observe this layer properly, your traces literally start midstory.

The timing for this conversation is particularly relevant. In November 2024, the Kubernetes project announced that ingress-nginx would be deprecated in March 2025. This forced many platform teams to reassess their ingress choices. Observability must be part of that architectural evaluation, not an afterthought.

According to the latest CNCF survey, 49% of respondents run OpenTelemetry in production, with another 26% evaluating it. OpenTelemetry is no longer an optional integration. It's becoming a platform contract, similar to how Kubernetes became the standard for container orchestration.

But the phrase "we support OpenTelemetry" hides meaningful differences. Does it mean traces are exported via OTLP? Are metrics also supported, or is it still Prometheus-only? What about semantic conventions? Are they following the latest standards? Can you configure everything using standard OpenTelemetry environment variables? How much work do you need to do in your collector pipeline to correlate signals?

"This binary label of 'supports OpenTelemetry' hides a lot of meaningful differences," Nissen noted. "Those differences are what platform teams discover the hard way when they start implementing these projects."

The OpenTelemetry integrations page doesn't help much either. It lists projects but doesn't indicate whether traces, metrics, or logs are supported, whether they use OTLP export, or how mature the implementation is.

A maturity model for OpenTelemetry support

To make these differences easier to discuss, Nissen proposed a draft maturity model. The goal isn't to rank projects or create certification. It's to provide shared vocabulary for describing how OpenTelemetry support evolves.

The model evaluates support across seven dimensions:

• Integration surface: How you connect the system to your pipeline
• Semantic conventions: Whether telemetry follows OpenTelemetry standards
• Resource attributes: How identity is described and whether it is modeled at the source
• Trace modeling: How traces are structured and how context flows
• Multi-signal behavior: How traces, logs, and metrics work together
• Signal quality: Usability, noise levels, and whether signals are designed for operators
• Stability and change management: How telemetry evolves over time

Within each dimension, four maturity levels are defined:

• Level 0: Telemetry exists but is mainly for debugging
• Level 1: Supported but influenced by legacy models
• Level 2: OpenTelemetry becomes the primary integration surface
• Level 3: Telemetry is treated as a product and continuously improved

Most projects sit somewhere in between, depending on the dimension. This isn't a certification, ranking, or graduation requirement. It's a community-driven framework for discussion and improvement.

Real-world evaluations: Five ingress controllers tested

Nissen evaluated five widely used ingress controllers using a replicable setup: a simple kind cluster, identical backend services, and consistent request patterns. The controllers tested were K Gateway, Contour, Traefik, Emissary, and Istio Gateway. All test configurations are available in the Dash0 examples repository.

K Gateway: Strong tracing and logs, hybrid metrics

K Gateway showed strong OpenTelemetry support for traces and logs. Tracing is configured declaratively using the Gateway API, and spans are exported via OTLP. When a request enters the system, the gateway creates a root span if needed or participates in an existing trace. Logs are also exported via OTLP and include trace ID and span ID directly, meaning correlation happens at the source without pipeline enrichment.

However, metrics follow a different path. They're Prometheus-native and exposed through scraping, with no OTLP export option. This creates a split in how signals are handled. There are also minor gaps in semantic conventions, inherited from the Envoy project. Overall, K Gateway is close to being OpenTelemetry-native for traces and logs, but metrics remain in a hybrid setup.

Contour: Solid tracing, requires correlation work

Contour also provides strong tracing support with OTLP export and predictable trace structure. Logs are structured JSON with useful request and response details, but correlation with traces isn't automatic. You need collector-side parsing to extract trace context and connect logs with spans. Metrics follow the Prometheus-native model with no OTLP export path. Contour exposes 486 Envoy metrics, which Nissen noted is "quite a lot" for a platform engineer to comprehend.

Traefik: Unified OpenTelemetry approach

Traefik stands out by treating OpenTelemetry as a first-class interface across all three signals. Traces, logs, and metrics can all be exported using OTLP. Tracing is straightforward with proper context propagation. OTLP logging can be enabled, and trace ID and span ID are automatically included in log records. Metrics are also exported via OTLP, removing the friction of separate Prometheus receivers.

"Traefik provides a consistent telemetry model where traces, logs, and metrics can all be exported using OTLP and processed in the same pipeline," Nissen emphasized. "This is really nice."

Traefik only exposes 11 metrics, a stark contrast to Contour's 486. It also uses up-to-date OpenTelemetry semantic conventions. There is some friction around custom schema for field names in logs, which could be improved using OpenTelemetry Weaver, but overall the experience is strong.

Emissary: Tracing works, semantics need attention

Emissary supports OpenTelemetry tracing via OTLP, as expected from an Envoy-based controller. Logs are structured JSON but not correlated with traces out of the box, requiring collector-side processing. There are issues in trace semantics: the ingress span is currently emitted as a client span instead of a server span, which can break semantic interpretation. Nissen created an issue on the repository, and a fix is in progress. Metrics are Prometheus-native with no OTLP export. Resource attributes aren't consistently modeled at the source, requiring enrichment in the collector.

Istio Gateway: Strong mesh integration, mixed signals

Istio Gateway, as part of the Istio service mesh, exports spans via OTLP and follows W3C context propagation. Access logs can also be exported via OTLP and include trace ID and span ID, enabling source-level correlation. However, metrics remain Prometheus-native with no OTLP export path. Access logs are currently emitted as text, requiring parsing to extract value. Istio Gateway provides strong tracing with reliable context propagation across the mesh, but the telemetry model isn't fully unified.

Patterns across implementations

When overlaying all five evaluations, clear patterns emerge. Tracing is the strongest signal across all controllers. All can participate in modern OpenTelemetry pipelines, export spans via OTLP, and follow W3C context propagation. Trace modeling is fairly consistent and works as expected.

Metrics remain Prometheus-first in most implementations. Only Traefik offers OTLP export for metrics. The number of exposed metrics varies wildly, from 11 in Traefik to 486 in Contour, raising questions about signal quality and operator usability.

Resource identity is the weakest dimension. Most controllers provide a service name but rely on downstream enrichment for additional identity attributes like Kubernetes pod ID or namespace. Only Traefik provides resource identity from the source, including attributes like Kubernetes pod ID that make correlation easier.

Logs exist in all controllers, but correlation with traces is inconsistent. Some require OTTL (OpenTelemetry Transformation Language) processing in the collector to extract trace parent headers and link logs to spans. Others, like K Gateway and Traefik, include trace ID and span ID directly in log records.

There's also semantic convention drift. All Envoy-based controllers inherit deprecated semantic conventions from the upstream Envoy project. Work is underway in Envoy to update these, which will eventually benefit downstream controllers.

"The real difference between implementations is not whether telemetry exists," Nissen concluded. "It's where that telemetry is shaped: at the source or in the pipeline."

Why maturity matters for AI-native observability

As the industry moves toward AI-assisted debugging and automated reasoning, consistent telemetry becomes even more critical. AI systems need stable semantics, aligned signals, and consistent resource identity to reason about distributed systems effectively.

"OpenTelemetry is becoming the foundation for what I would call AI-native observability," Nissen explained. "It enables correlation-assisted debugging and automated reasoning, but it requires stable semantics, aligned signals, and consistent resource identity across sources."

Maturity isn't just a technical detail. It determines whether AI-native observability actually works. If telemetry is inconsistent, AI systems can't reliably interpret it. If correlation happens in pipelines rather than at the source, AI tools lose context. If semantic conventions drift, AI reasoning breaks down.

This makes the maturity model more than an evaluation framework. It's a roadmap for building observability infrastructure that supports both human operators and AI-assisted workflows.

If you enjoyed this, find more great insights and events from our Platform Engineering Community.

If you want to dive deeper, explore our instructor-led Platform Engineering Certified Professional course and connect with peers from large-scale enterprises who are driving platform engineering initiatives.

​

Key takeaways

• Evaluate OpenTelemetry support across multiple dimensions, not just binary "yes/no" labels. The draft maturity model provides a structured way to assess integration surface, semantic conventions, resource attributes, trace modeling, multi-signal behavior, signal quality, and stability. This helps platform teams make informed architectural decisions rather than discovering gaps during implementation.
• Expect to do correlation and enrichment work in your collector pipelines, but understand where that burden comes from. Most ingress controllers require downstream processing to link logs with traces, normalize semantics, or enrich resource identity. Knowing which controllers model telemetry at the source versus which push work into pipelines helps you plan collector complexity and operational overhead.
• Prioritize projects that treat OpenTelemetry as a first-class interface, especially if you're building for the future. Controllers like Traefik that export all signals via OTLP and include correlation metadata at the source reduce platform team toil and align better with AI-native observability patterns. As semantic conventions stabilize and AI-assisted debugging becomes standard, this architectural choice will matter more.
• Contribute to the maturity model discussion to help the community converge on shared standards. The model is a draft, and Nissen is actively seeking feedback through the OpenTelemetry community repository. Platform engineers who participate in this conversation can help shape how the ecosystem evaluates and improves OpenTelemetry support, ultimately reducing the burden on all platform teams.