KubeCon Europe 2026: OpenTelemetry Recap from Amsterdam

The reason why I like writing recap articles is because AIs don’t have enough context to write them for us. You have to be there, in person, listen to sessions, interact in the hallways with the community, and absorb as much new knowledge as possible.

That’s what I did last week in Amsterdam at KubeCon + CloudNativeCon Europe ‘26. Well, at least I tried to. Let me break down what I consider the most interesting topics were last week.

OpenTelemetry: What’s New and Where Things Are Going

Much has been talked about stability since both KubeCon in Atlanta, and OTel Unplugged in Brussels. Well… we’re very close.

Here are a few highlights:

• Declarative Configuration (Stable) — Single YAML file to configure SDKs and instrumentation across languages. The fragmentation era is over.
• Collector heading to 1.0 — Stable config and API components, batch processor moved to exporters, pdata saw 40% reduction in allocations, 23 new components.
• Go Metrics SDK — 30x performance improvement.
• Entities — New concept this year. An entity represents an object of interest tied to your telemetry signals.
• Profiles (Alpha) — New signal type. Continuous profiling is becoming a first-class OTel citizen.
• Weaver — Actively used by the community, stable release imminent.
• OpenTelemetry Injector (Alpha) — Auto-inject instrumentation via LD_PRELOAD. Zero-touch instrumentation is getting real.
• New website — Redesigned with UX improvements.
• New collector distribution for the eBPF profiler.

2026 Roadmap: Stability by Default

The road ahead is about closing the loop on everything the project started. "Stable by default" is the focus, and CNCF graduation is the target.

• Collector 1.0 — Needs stable config and API to get there. Kubernetes focus is SemConv standardization and performance.
• OpenTelemetry eBPF Instrumentation (OBI) — Chasing a release candidate this year.
• OpenTelemetry Collector Builder (OCB) — Active push to increase adoption and improve the user experience.
• Weaver stable release — Soon.
• Entities and Profiles — Both early, both worth watching closely. They'll change how you think about correlating telemetry.
• CNCF Graduation — The whole project is pushing toward it. When it lands, it's a meaningful signal for production adoption.

Observability Day Vibes

The Observability Day co-located event at this year’s KubeCon Europe was better than ever. I saw amazing presentations and had invaluable hallway conversations. But, what I like most is seeing maintainers interacting with end users.

Here are the talks that stood out for me.

Dan Gomez Blanco & John Clark — Unpacking Your OTel Baggage

If you've ever passed contextual metadata across services you've probably done it with a custom header and a company-wide Slack asking everyone to please use the thing. Dan and John showed there's a better way: OpenTelemetry Baggage. W3C-standardised, propagates automatically with trace context, no custom plumbing required.

They’ve used it in a real production system at 60 million requests per minute. Key advice: use a custom propagator to make sure baggage never leaks to external calls.

I walked away thinking baggage is one of the most underused parts of the OTel spec, and you should definitely start using it.

Juliano Costa — How to Use the OpenTelemetry Demo and Why It Matters

The OTel Demo ships with 20 microservices, all instrumented with OTel, a collector, and a full open source observability stack out of the box. Every language is covered. Navigate to any service and see exactly how instrumentation is done for that language.

The use cases go deeper than learning. 42 vendors have their setup documented in the README, making it the de facto standard for vendor evaluation. Want to compare the same trace in Jaeger vs. observability vendors? The OTel Demo can do it for you.

Juliano also highlighted that maintainers use it for finding bugs. Every dependency bump gets stress-tested against a real multi-service app, with issues reported back to the relevant SIGs.

People bring the demo to customer meetings, use it for workshops, and you can send the exact same payload to 40+ vendors and compare what you get. Genuinely powerful evaluation tool.

The OTel Demo isn't just a demo. It's infrastructure for the community. Well done Juliano!

Evan Bradley & Pablo Baeyens — Observability Without Borders: The OpenTelemetry Collector in a WebAssembly World

They compiled the OTel Collector to WebAssembly and ran it in a browser. Yes, even the Collector can run in a JavaScript environment. Atwood's Law applies here too. The collector is apparently no exception.

The motivation makes sense. WASM is portable, performant for compute-heavy workloads, and breaks the hard dependency on Go. The current state is surprisingly mature. JSWasm is tier 3 and WASI is unofficially supported, with around 90% of collector components already compiling to target. Main friction is binary size (~38MB minimum, ~66MB for the JS collector), though compression helps significantly.

Seems running the OTel Collector in a browser isn't a gimmick, it's apparently where the world is headed with edge observability.

SIG Meetings Galore

The OpenTelemetry Collector and OpAMP SIGs saw more members than ever join and discuss the future of the projects. I sat in on both, and my colleague Andy, one of the OpAMP maintainers, was thrilled to see so many community members show up.

The OpAMP SIG had a lot to chew on. The big questions:

1. How to expand the OpAMP extension?
2. Should we build more features into the supervisor?
3. What’s the future of collector hot reloads?

There's an active debate between two OpAMP approaches. The current extension-based method, which has a smoother migration path for going from unmanaged to managed, versus a supervisor-based V2 that's more aligned with where the spec is heading. I managed to get a thought in that was a head-scratcher for the community and sparked a discussion:

No firm decisions yet, but it’s clear the community is deeply invested in getting this right.

Honorable Mentions — The future of OBI

My favorite presentation, by far, on the main track of KubeCon was about OpenTelemetry eBPF Instrumentation (OBI).

Nikola Grcevski & Endre Sara — DNS Tracing & Metrics via eBPF in OpenTelemetry

"It's always DNS" got a few laughs, and ended up being a universal truth. Nikola and Endre showed that DNS is one of the biggest blind spots in modern observability. Your instrumentation only kicks in after you know what you're connecting to. Everything before that, including lookups, latency, and silent failures are invisible.

OpenTelemetry eBPF Instrumentation (OBI) solves this by capturing DNS queries at the kernel level with virtually zero overhead. Drop it into an existing environment, no restarts, no code changes. It works with or without existing OTel instrumentation, and exports both a DNS lookup duration metric (histogram with service attribution, Kubernetes metadata, and standard OTel attributes) and optional traces that nest correctly as children of parent HTTP calls.

I walked away thinking OBI is quietly becoming one of the most important projects in the OTel ecosystem, and DNS support is just the beginning.

Bindplane Community Updates

We shipped something at KubeCon too. The otel-distro-builder hit a stable release. With the major community push for using OCB to build custom collectors, now’s the time to give the otel-distro-builder a try.

First, it's now a no-dependency CLI. Nothing extra to install and no setup friction. Download and run it. Second, you can now generate a manifest directly from an existing collector config.yaml. If you already have a collector running in production, that's your starting point. No need to rebuild your config from scratch to start using the builder.

We also launched the OpAMP Gateway Extension (alpha). It’s a new collector extension that brings OpAMP fleet management to firewalled and network-segmented environments where collectors can't reach the OpAMP server directly.

Collectors don’t need direct connectivity. They connect to a gateway collector at the network boundary, which fans their connections into an upstream pool. Thousands of collector WebSockets become a handful of server-side connections. It's not a separate binary, it runs inside a standard collector, and auth is fully delegated to the upstream OpAMP server — no auth logic lives in the gateway itself. Andy wrote a deep dive on how it works and was a guest on the OpenObservabilityTalks podcast, if you want the full picture.

Final Thoughts

Amsterdam delivered. Between Observability Day, the SIG meetings, and the hallway conversations, it's clear that OpenTelemetry is maturing fast — and the community is doing the hard work to make sure it matures right.

Stability is finally within reach. The collector is heading to 1.0, declarative config is stable, and projects like OBI and Profiles are pushing the boundaries of what OTel can do. If you've been waiting for the ecosystem to settle before going all-in, that moment is getting very close.