Honeycomb was excited to attend KubeCon + CloudNativeCon Europe, where one theme stood out across sessions: as AI reshapes how software is built and run, teams are being pushed to rethink how they understand their systems. Without strong observability and feedback loops, AI can accelerate confusion, misalignment, and operational risk.

From telemetry design to AI-assisted development, the following sessions reinforced a core idea aligned with Honeycomb’s perspective: the teams that win are those that can quickly understand what their systems are doing and why.

Redefining SLIs for LLM inference: managing hybrid cloud with vLLM & LLM-D

Abstract Link
Hilliary Lipsig, Senior Principal Site Reliability Engineer at Red Hat and Christopher Nuland, AI Principal Architect at Red Hat

This session explored how traditional reliability practices break down in AI systems. Unlike deterministic services, LLMs introduce new dimensions such as batching, token generation phases, and cache-aware routing. These fundamentally change how performance and reliability should be measured.

The speakers emphasized that metrics like time to first token, decode speed, and cache hit rates are now critical indicators of user experience. Observability must evolve alongside system architecture. AI systems require end-to-end visibility across multiple components, and teams must rethink SLIs to reflect real user experience rather than isolated infrastructure metrics.

From a Honeycomb perspective, this reinforces that AI amplifies both engineering excellence and gaps. Without fast feedback loops, teams cannot validate whether system changes are improving or degrading performance.

Banking on reliability: cloud-native SRE practices in financial services

Abstract Link
Clément Nussbaumer, Systems Engineer at PostFinance

This talk provided a concrete example of how SLOs transform reliability practices. The speaker described moving from subjective observations of performance to clearly defined Service Level Objectives, enabling teams to detect and investigate issues systematically.

One of the most compelling examples involved uneven load distribution across API servers due to persistent HTTP/2 connections. Despite having multiple servers available, one node handled disproportionate load, creating hidden bottlenecks. This issue only became visible after implementing SLOs and analyzing telemetry.

The broader takeaway is that you can’t improve what you can’t measure clearly. SLOs created the feedback loop needed to uncover systemic issues and drive meaningful improvements.

The <meta /> trick: connecting page load to backend traces

Abstract Link
Wolfgang Therrien, Staff Software Engineer at Honeycomb

This session addressed a common gap in observability: the disconnect between frontend and backend traces. Even when systems are instrumented, telemetry often exists in silos, making it difficult to understand the full user experience.

Wolfgang introduced a simple but powerful approach: embedding trace context into HTML using a <meta /> tag. This allows frontend telemetry to inherit backend trace context, creating a unified, end-to-end trace, giving a complete view of the user journey from initial request through rendering and subsequent API calls. Instead of manually correlating traces, engineers can immediately identify the root cause of performance issues.

Connected telemetry is more valuable than more telemetry.

Let me be your OpenTelemetry champ

Abstract Link
Pavol Loffay, Principal Software Engineer at Red Hat and Nicolas Wörner, Founding Software Engineer at OllyGarden

This session explored how AI coding agents can accelerate OpenTelemetry adoption while also introducing new risks. AI can quickly generate instrumentation and configurations, but the results are often inconsistent or incorrect, like outdated SDK versions, incorrect Semantic Conventions, and overly permissive configurations. While these issues may not immediately break systems, they degrade quality over time.

AI increases productivity but does not replace expertise. Engineers must validate and refine AI-generated outputs to ensure correctness.

AI is an amplifier. With strong feedback loops, it accelerates progress. Without them, it accelerates mistakes. Our own Austin Parker recently hosted a webinar that covers just that.

Naming things is hard: a guide to naming using network science

Abstract Link
Nick Travaglini, Senior Technical Customer Success Manager at Honeycomb

Nick examined how teams develop naming conventions for telemetry and why it is harder than it appears. Using principles from network science, Nick showed that team structure directly impacts how effectively naming standards emerge. Fully distributed teams converge quickly but produce ambiguous names, while centralized teams produce higher-quality names but move slowly. The optimal model—a “connected broker” structure—balances speed and quality by combining diverse input with centralized synthesis.

One YAML to rule them all: declarative config

Abstract Link
Jamie Danielson, Senior Software Engineer at Honeycomb

This session focused on simplifying observability in polyglot environments through declarative configuration. Instead of managing language-specific instrumentation, teams can define behavior once in a shared YAML file that applies across all services.

This approach reduces configuration drift, eliminates duplication, and makes observability more accessible across teams. Simplifying configuration increases consistency, which in turn improves the reliability and usability of telemetry data.

Metrics that lie: understanding OpenTelemetry's cardinality capping and its implications

Abstract Link
Cijo Thomas, Principal Software Engineer at Microsoft

This talk highlighted a subtle but critical issue: telemetry systems can produce misleading results when cardinality limits are exceeded. When this happens, data is aggregated into overflow buckets, causing metrics to underreport or completely hide issues. For example, systems may report zero failures even when failures are occurring, simply because those events were dropped due to cardinality constraints.

Not all telemetry is trustworthy by default! Teams must understand how their systems handle data under load and actively monitor for conditions like overflow. This reinforces Honeycomb’s focus on high-quality context-rich telemetry as the foundation for effective observability.

How to responsibly and effectively contribute to open source using AI

Abstract Link
Tyler Helmuth, Staff Software Engineer at Honeycomb

Tyler’s talk explored how AI is changing open source contribution. While AI tools lower the barrier to entry, they also introduce the risk of low-quality contributions that burden maintainers.

He emphasized that effective use of AI requires understanding project context, adhering to conventions, and validating outputs. AI should be treated as an assistant, not an autopilot.

Tyler also wrote a helpful blog on the topic. Read it now to understand how to be a good contributor.

When OTTL goes off the rails: debugging transformations with confidence

Abstract Link
Tyler Helmuth, Staff Software Engineer at Honeycomb and Edmo Vamerlatti Costa, Principal Software Engineer at Elastic

This session focused on the challenges of working with the OpenTelemetry Transformation Language (OTTL). While powerful, OTTL can be difficult to debug, and small mistakes can lead to incorrect or misleading telemetry.

Telemetry pipelines require the same rigor as application code. Without testing and validation, teams risk corrupting the data they rely on for decision-making.

See you next year!

The message from KubeCon was clear: AI is an amplifier, and observability is what determines whether it amplifies success or chaos. Fast feedback loops aren't just a ‘nice to have’ anymore. They're the foundation when you’re working with black boxes like LLMs.