Open Observability Summit + OTel Community Day 2025

Are you aiming to construct scalable, vendor-agnostic OpenTelemetry (OTel) pipelines? Do you want to leverage your organization's Git repository structure, CI/CD pipelines, and unit and integration testing frameworks? Are you looking to adopt industry-standard engineering best practices? Do you want to promote collaborative contributions from Observability team members to a unified codebase? Explore how the DoorDash observability team implements this approach in their technical talk. The DoorDash Observability team has developed 28 in-house OTel components to power pipelines for logs, traces, and metrics at scale, processing 100TB of log data a day and processing over 15 million spans per second. These pipelines incorporate a mix of different architectures, security tooling, and cost-efficient designs. Through running multiple pipelines, we continuously apply our learnings to improve overall performance. Join us to unlock the strategies for building scalable, maintainable, and collaborative OTel pipelines that grow with your needs!

In a push to standardize observability practices, the cloud-native community has embraced OpenTelemetry, offering a unified framework for metrics, logs, and traces. Prior to this, log processing relied on agents like fluent, evolving into fluentbit. With fluentbit's recent expansion to support additional signals and the OpenTelemetry Collector's emergence, a pertinent question arises: Which is the superior choice for performance?

This session delves into:
- Unveiling the distinctions between Fluent Bit and the OpenTelemetry Collector.
- Sharing the findings derived from a series of benchmark tests.
- Providing valuable insights to empower the community in selecting the most fitting agent for their cloud-native environments.

OpenTelemetry captures database operations from the client perspective, in the context of an originating resource, application and request. How can this insight be matched to observations about the database server? This talk focuses on the sqlcommenter feature in OTel which propagates trace context in SQL queries, so that client- and server-side observations can be correlated to answer questions like “is this request slow due to the state of the database” and “where are the expensive queries to this database coming from".

We’ll briefly describe the challenge of context propagation, give an overview of the current state of sqlcommenter implementation in OTel SDKs, demonstrate the enriched correlation that can be built from it, and highlight limitations and pitfalls found along the way in adapting it into our product.

This talk aims to give viewers a good understanding of the OTel sqlcommenter feature and the integrated performance insight that it makes possible.

Spotify replaced its in-house TSDB (Heroic) with VictoriaMetrics and Prometheus, achieving 10x faster query speeds and significant cost savings. The 2 year migration addressed stability, performance, and stakeholder dissatisfaction with Heroic's slow queries and bespoke nature. After evaluating alternatives, VictoriaMetrics was chosen for its speed, cost efficiency, Prometheus compatibility, and self-hosted flexibility. Challenges included migrating from Heroic's overly flexible data model and often misused HQL to Prometheus's standardized structure and best-practice PromQL, a necessary shift for improved data quality and query efficiency. The migration involved updating metric agents, adapting alert management, and a significant fleetshift. Benefits included improved dashboard loading times, faster alerting, more accurate data, and alignment with industry standards.

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.

In today’s cloud-native world, ensuring visibility, reliability, and security across multi-cloud environments is critical. As GitOps adoption grows, observability must evolve in parallel to support performance, compliance, and resilience.

In this session, I’ll share how we built an observability-first DevSecOps pipeline using OpenTelemetry, Prometheus, Grafana, Terraform, and ArgoCD across GCP, Azure, and AWS. I’ll cover how we embedded telemetry into CI/CD, cut MTTR by 35%, and optimized cloud performance and costs with real-world metrics.

We'll explore common anti-patterns when scaling observability in GitOps workflows—and how to overcome them. I’ll also show how we aligned observability data with business KPIs to drive better stakeholder decisions.

Attendees will leave with a practical blueprint for implementing open-source observability at scale in secure, automated pipelines.

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 best telemetry starts at the source—inside the client libraries.
But in most cases, that means taking a dependency on the OpenTelemetry API from your library. And while it’s stable, minimal, reliable, and safely no-op unless configured—transitive dependencies are still the bane of any library developer’s existence, and most of us try to avoid them.

To work around this, people reach for abstractions, plugins, bridges, or even OTel forks that break context propagation. The result? A poor user experience. Users must find the right plugin, install it, wire it up—and still hit the diamond dependency problem, now it just affects a subset of users.

But what if you could take a truly optional dependency? If OpenTelemetry is on the classpath, instrumentation kicks in. If it’s not, no harm done.
How hard is that to pull off? How reliable? How performant?

Let’s explore that—through the lens of the next generation of Azure SDKs for Java. Spoiler: it’s easy and fast, and as a side-bonus, we can fall back to logs-based tracing if OTel is not found.

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.

Novice observability practitioners are often overly obsessed with performance. They might approach instrumentation with skepticism and have concerns about latency degradation or resource consumption. This talk is a primer on the topic of instrumentation overhead, and it will teach you how to think about overhead in an observability context. We will cover the causes of overhead and why overhead is so hard to measure and even harder to predict reliably. Lastly, we will present some practical techniques for understanding overhead in your environment and some strategies for coping with it.

GenAI Observability is proactive monitoring of your AI apps and cloud infra they run on to understand how to make them work better. The ever evolving landscape of genAI technologies makes it very challenging to manage. Project. Monocle is built for App developers to trace their app code in any environment without lots of custom code decoration. It’s a community driven open source project under Linux Foundation AI&Data, built on top of OpenTelemetry. It provides out of the box support of several genAI tech components. With very little to no code changes, you can generate OpenTelemetry compatible traces and spans of your genAI application. Monocle provides consistent format to describe entities like LLMs and vector stores as well as events like prompts and responses. It can be integrated with apps in personal dev/lab environment as well as cloud deployments.

This session will illustrate challenges of monitoring/tracing genAI applications which is a big problem taking your dev/prototypes to production. It will provide a quick overview of how to use Monocle Python and Typescript libraries in your application with little efforts.

We all have innovative ideas around what has been done on top of Open Source. Sometimes it maybe because of our organization's "specific" need and other times it is because the technology can't simply scale. Sometimes it may be because you are trying new things that are premature to put out. Never the less, it becomes important to manage the constraints effectively. This problem has been the norm at eBay's Observability platform where scale, innovation and organizational demand drives creativity. In this talk we discuss how we have improvised on top technologies like Prometheus, Alertmanager and OpenTelemetry Collector. Some of the ideas we would discuss include:

* enriching alerts using Exemplars
* spanmetrics connector for massively large tracing systems
* scaling tracing backends using clickhouse

At the end of this talk end users would get a sense of new things that can be done on top of existing projects and scaling open source with a little bit of extra love.

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.