Open Observability Summit + OTel Community Day 2025

In the world of distributed systems and observability, spans are the fundamental building blocks that enable us to understand system performance, troubleshoot issues, and optimize our applications. But what really happens when a span is created? How does it flow through an OpenTelemetry pipeline, interact with other spans, and ultimately surface in an observability backend?

In this session, we’ll take a deep dive into the life of an OpenTelemetry span—from its birth in an instrumented application to its final visualization in an observability backend. We’ll explore the various components of OpenTelemetry that interact with spans, including tracers, processors, exporters, and propagators. Using an example application and relying on OpenTelemetry’s default configurations, we’ll follow the span’s journey step by step, gaining insight into how context propagation, data enrichment, and trace exporting work under the hood

As OpenTelemetry adoption grows, so does the volume of telemetry data. But more data doesn’t always mean more insight—it can mean more confusion, higher costs, and longer incident response times. In this session, we’ll explore how engineering teams are evolving their observability practices to manage telemetry sprawl. You’ll learn how to identify the neceesary signals to identify service impacting issues, tune observabiltiy data management strategies, and apply distributed, local processing techniques to observabilty data without losing critical context. We’ll walk through practical examples of what works (and what doesn’t) in modern observability pipelines—and how OpenTelemetry can be used more strategically to improve reliability and performance.

Migrating from proprietary tracing systems to OpenTelemetry can be challenging, especially when applications rely on custom span and resource attributes that do not align with semantic conventions. Organizations need a strategy to unify legacy telemetry with OpenTelemetry standards without disrupting existing queries, visualizations, or alerts.

This session presents a real-world case study from Comcast, highlighting how the OpenTelemetry Weaver tool was used to create a unified schema combining semantic conventions with existing attributes. This approach allows teams to gradually adopt standard attributes while maintaining compatibility with current setups, ensuring continuity and reducing migration friction.

The session details how Weaver was configured using Jinja templates to generate outputs in multiple formats—JSON, YAML, and Markdown—supporting backend ingestion and schema documentation. This enabled consistency across pipelines and improved clarity for engineering teams reviewing trace attribute definitions. The talk also highlights how flexible namespacing integrated domain-specific attributes alongside standardized ones without sacrificing backend compatibility.

Getting started with OTel could be a doozy when you are a newcomer.

Want to skip the frustration and learn how to use OTel to collect, process, export, and visualize telemetry data in 25 minutes?

Join Lisa Jung, the creator of the OTel for Beginners series to:
- auto-instrument an app
- send telemetry data to the OTel collector for simple processing
- configure the OTel collector to send telemetry data to an OTLP compliant backend
- visualize telemetry data

In cloud-native environments, telemetry pipelines are expected to be reliable, especially when everything else isn't. Unfortunately, it's exactly in these critical moments that your observability setup might decide to take an unexpected break.

In this session, we'll explore proven strategies for building robust telemetry pipelines that won't abandon you mid-incident. You'll learn practical techniques for configuring a continuous data ingestion, how to manage telemetry streams effectively, and be resilient enough to survive backend disruptions.

Join us to discover how to keep your observability data flowing smoothly—because your OpenTelemetry Collector should never give you up, never let you down, and certainly never run around and desert you when you need it most.

The year is 2025, and it's pretty safe to assume that most of us have used "Generative AI" (or GenAI) at least once to produce images from prompts. Rumors say that some of us even used that as an excuse to buy a fancy new GPU and run models like Stable Diffusion locally, "For Science!", of course.

In this talk, we'll set aside the feelings (positive or negative!) that we might harbor for generative AI and use them as an excuse, not to buy shiny new GPUs, but to learn how to build a practical Spring + Java application in a GenAI context, deploy it on Kubernetes, and instead of tracing GPU invoices, we’ll trace our application’s behavior using distributed tracing.

Using Spring, we’ll store prompts in a database and submit them to generative models. Image results will be stored and then displayed. The application will take advantage of Kubernetes batch job processing facilities and implement reasonable security policies by leveraging RBAC. We will also look into distributed tracing, using OpenTelemetry, Grafana, and Grafana Tempo, to visualize the lifecycle of our requests as they pass through our application.

As OpenTelemetry adoption expands, one common pain point across the community is metric cardinality. High-cardinality metrics—especially those with user- or host-level tags—can overload backends with unique time series, driving up costs and reducing signal quality. Many teams only notice once the vendor bill arrives.

In this talk, we’ll explore how to use the OpenTelemetry Collector and OTTL (OpenTelemetry Transformation Language) to proactively reduce metric cardinality. Learn how to spot costly metrics, reshape or drop them with the filter processor, test changes with the OTTL Playground, and implement a control plane to safely evolve filtering rules.

Whether you’re using Prometheus, a commercial vendor, or OpenTelemetry-native pipelines, this session offers practical, open-source strategies to reduce noise, improve signal, and keep observability costs sustainable.