Last updated: April 17, 2026
Code RED Newsletter #29
If you’ve been around the cloud-native ecosystem for a while, you’ve probably noticed a pattern: almost every project now “supports OpenTelemetry.” It sounds meaningful. It feels reassuring.
And yet… it tells you almost nothing.
Because once you dig in, that phrase can mean anything from “we export a few spans” to “we provide production-grade, multi-signal, semantically correct telemetry.” That’s a pretty big range and we don’t really have a shared way of describing it.
This issue is about that gap and what maturity actually looks like in practice.
In focus: Beyond "Supports OpenTelemetry"
“Supports OpenTelemetry” is quickly becoming the new “cloud-native compatible” - technically true, but not very helpful. Some projects export traces via OTLP and call it done. Others cover three signals, align with semantic conventions, provide stable resource attributes, and think carefully about who their telemetry is for and how it’s actually used.
This issue is about that gap and the people working to close it. From a maturity model framework, to a real-world evaluation of ingress controllers, to how Adobe and Bloomberg approach OpenTelemetry at enterprise scale, and a conversation about what “platform maturity” actually looks like.
A Maturity Model for OpenTelemetry Support
This one's by me (yes, I'm biased - but hear me out). I proposed a 7-dimension descriptive maturity model for evaluating how well projects actually integrate with OTel. It's not a scorecard, just a shared vocabulary. I tested it against CNCF ingress and gateway projects, and the results were… illuminating. If this resonates, there's an open discussion in the OTel community repo (issue #3247). Jump in and help shape it.
The Model Applied: Observability at the Edge of Kubernetes
Frameworks are nice. Data is better. In this PlatformEngineering.org webinar, I applied the maturity model to five Kubernetes ingress controllers. The takeaway? Tracing is strong everywhere, but metrics remain Prometheus-first across the board, except Traefik. Log-trace correlation is hit or miss. Resource identity is weak almost universally. And the metric count range - 11 in Traefik vs. 486 in Contour - tells you just how differently projects interpret "observability support."
Inside Adobe's OpenTelemetry Pipeline: Simplicity at Scale
What does OTel maturity look like at enterprise scale? Adobe built a three-tier Collector architecture serving thousands of deployments. Teams onboard with two Kubernetes annotations. "People add two lines in their deployment and it just works." The real gem: a custom circuit breaker extension that surfaces downstream failures masked by OTLP's 200 responses in chained Collector setups. The kind of operational maturity that "supports OpenTelemetry" doesn't begin to capture.
Read the case study on the OTel blog
From Dependency Management to Stewardship: Bloomberg's OTel Investment
Bloomberg argues that passive OTel consumption isn't sustainable. Their answer: a Q2 2026 cohort of 30-45 engineers contributing ~2 hours per week to the OTel instrumentation, Collector components, SDKs, docs, and semantic conventions. Not a sponsorship check. Structured contributor capacity. If your organization runs OTel in production, this post should make you think about what you're putting back.
Read the post on the CNCF blog
Code RED Podcast: Platform as a Product with Abby Bangser
Fresh off her KubeCon EU keynote, Abby Bangser joins me to dig into why internal platforms fail and how platform-as-product thinking can fix them. The parallel to this issue's theme: just as "supports OpenTelemetry" isn't enough for telemetry, "we have a platform" isn't enough for developer experience. Surface-level adoption without maturity leads to tools that exist but don't work for the people using them.
Choice cuts
Pour yourself a coffee and settle in. Here are a few more things worth your attention between deploys.
Taming Complexity: Observable Workflows with Dapr and OpenTelemetry
My KubeCon talk with Mauricio "Salaboy" Salatino is now on YouTube. We live-demoed a distributed pizza ordering app with four AI agents using Dapr Workflows, the A2A protocol, and MCP - all instrumented with OpenTelemetry. The result is 275+ spans per order, non-deterministic execution paths, and context propagation that breaks the moment you cross a protocol boundary or shell out to a bash script. Auto-instrumentation gets you started. It does not get you done.
PromQL Finally Handles Missing Series Gracefully
If you've ever written a PromQL binary operation and wondered why half your results vanished - congratulations, you've hit one of Prometheus's oldest papercuts. Julius Volz (PromLabs) explains the problem and the solution: the new fill modifier that lets you substitute default values for missing series with fill(<value>), fill_left(<value>), and fill_right(<value>). Dash0 shipped support for this in collaboration with the Prometheus community. Your dashboards and alerts will thank you.
Related Logs: Reconstruct What Happened Without Leaving the Sidebar
New in Dash0: the Related Logs tab automatically surfaces logs from the same resource and trace within a 30-minute window around a selected log record. You can toggle between two correlation modes, resource-level and trace-level, independently. It's the kind of small UX improvement that saves real debugging time when you're trying to piece together what happened at 2 AM.
Span Events to Log Records - Automatically
OTel is deprecating span events in favor of log records with trace context, but migrating instrumentation takes time. Dash0 now offers an opt-in setting that automatically converts span events to correlated log records during ingestion. No code changes. No pricing impact. Tagged with dash0.span_event.converted = true so you know what's converted. Pragmatic bridge for teams navigating the ecosystem transition.
The thread running through this issue is simple: maturity matters more than checkboxes. Whether it’s how a CNCF project integrates with OpenTelemetry, how an enterprise runs its Collector fleet, how a financial institution invests in open source, or how a platform team delivers developer experience, the gap between "we support it" and "we do it well" is where the real work lives.
Oh, and if you're heading to Google Cloud Next in Las Vegas or DevOpsCon in Amsterdam, the Dash0 team will be at the booth in full swing. I'll personally be in Amsterdam, if you happen to be there stop by and say hello!
Until then: may your semantic conventions be stable, your resource attributes be enriched, and your maturity never be measured in checkboxes.
Kasper, out.
Hi, my name is Kasper!
I'm Kasper Borg Nissen, Director of Product Marketing & Developer Relations at Dash0. I'm passionate about Observability and bridging the gap toward developers through Platform Engineering. I've previously worked 8 years as a platform engineer, I'm a former co-chair of KubeCon+CloudNativeCon, and I'm genuinely obsessed with all things cloud-native and open standards.
