Observability Summit North America 2026

AI is accelerating software development at an exponential pace, but we have no idea what our AI systems are actually doing. Agents operate across distributed frameworks. One request spawns dozens of hops with zero visibility. The OpenSearch Observability Stack closes that gap—built for open source contributors, with a growing focus on developers and operators using these systems every day. Open source. Linux Foundation-governed. One pipeline. Every framework. Every model. Every hop visible. The agentic era deserves open infrastructure, and we’ll share how this is a step towards building it together.

Today, many organizations are pushing beyond existing limits for telemetry volume. Systems are ever-more distributed and generative AI workloads produce enormous amounts of data. As telemetry volumes grow, observability pipelines must become more efficient.

At scale, telemetry egress directly impacts observability spend. Cloud providers charge per gigabyte of data transferred across regions or providers, and those bytes add up quickly. The protocol used to encode telemetry determines how much data is sent over the network. Even modest improvements in encoding efficiency (i.e. the protocol) can translate into significant cost savings. However, the OpenTelemetry Protocol (OTLP) was not initially optimized for performance. Instead, it prioritized interoperability and easy adoption.

Today the OpenTelemetry community is exploring OTAP, a new stateful protocol for transmitting OpenTelemetry data based on Apache Arrow. By using columnar encoding and maintaining state throughout a stream, OTAP avoids repeatedly sending the same metadata, reducing payload size and network transfer. However, because OTAP relies on long-lived stateful streams rather than independent requests, there is additional architectural and operational complexity in its implementation. There are further challenges to larger adoption by the community; for example, Apache Arrow support varies significantly across languages.

Protocol design today is critical to efficiently scaling your systems. In this talk we will explore how protocol design affects telemetry egress and overall observability cost. We will go over some strategies for improving encoding efficiency, compare stateless and stateful approaches, and discuss the potential benefits and drawbacks of adopting a protocol like OTAP. Join us to learn more about how your protocol decisions can influence your costs over time.

Production AI agents make thousands of tool-calling decisions daily, yet observability stops at the model boundary. OpenTelemetry's GenAI semantic conventions capture token counts and latencies—what the LLM processed—but not why an agent selected a specific tool. Research (McKenzie et al., 2023) demonstrates inverse scaling: more capable models exhibit unpredictable tool selection patterns. This gap leaves engineers guessing during critical production failures.

We present gen-ai-otel, an open-source OpenTelemetry extension introducing decision-level telemetry for MCP agents. A new attribute namespace (gen_ai.agent.*) captures tool selection confidence, session context, permission scope validation, and baseline deviations. The zero-sidecar architecture routes telemetry through standard Collector pipelines to existing backends—Jaeger, Prometheus, or graph databases—with low overhead and cardinality-aware attributes.

A live demo reconstructs an agent's decision chain, revealing anomalies invisible to token metrics—reducing decision-debugging time. Attendees leave with: 1) Collector configs, 2) Grafana dashboards for confidence tracking, 3) demo code and repo—all Apache 2.0 licensed.

You may have heard of the pillars of observability: metrics, logs, traces, and, depending on who you ask, profiles. As systems grow in complexity, the need to both individually understand and correlate these signals becomes paramount for rapid incident detection, root cause analysis, and performance optimization. Yet, even with advances like OpenTelemetry, making sense of your own data often requires learning specialized query languages and navigating complex toolchains, which is a barrier for many users.

While AI tools like ChatGPT can offer general advice, they lack access to your specific observability data. This is where Model Context Protocol (MCP) servers come in. MCP servers provide a standardized way for AI assistants and other tools to securely connect to your observability data, making it easier to investigate and diagnose issues faster using natural language.

In this talk, we’ll cover MCP and demonstrate how to explore your observability data using Grafana MCP, while also touching on how the same approach can work with other MCP-compatible tools or custom MCP servers.

Today, observability platforms can process massive volumes of telemetry, but practitioners struggle to determine what matters during incidents, unnecessarily increasing usage bills.

This talk resolves the question: “Which telemetry data should we keep?” Learn how one team achieved 30% log reduction by flipping the script and asking “what did we actually use?” instead of “what should we collect?” They conducted a forensic audit of incident resolutions to find receipts proving which data sources truly mattered.

You’ll learn techniques for tracing backward from resolved incidents to identify which telemetry is deemed valuable and see how to map incidents to telemetry data that enabled resolution, revealing which sources proved critical, redundant, or unused.

Using OpenTelemetry (OTel) and Vector, an open-source tool for building fast and scalable observability pipelines, this approach provides a replicable pattern that the community can adapt across different environments.

You’ll leave with a framework for measuring telemetry value based on usage patterns, plus a repeatable audit process. The key question: “Where are the receipts?”

N-ATLaS is a multilingual African-language LLM we took from research to production on Kubernetes. This talk shows the end-to-end path we used to make it reproducible, observable, and affordable: data + finetune pipelines (artifacts, seeds, checkpoints), Argo-orchestrated training on mixed GPU pools, and a serving stack with Triton + KServe tuned for real traffic. I’ll walk through SRE guardrails that mattered for N-ATLaS (SLOs, golden signals, error budgets), supply-chain hygiene (image signing, provenance, model versioning), and the levers that cut cost-per-token while improving latency and uptime under pre-emptions. We’ll cover autoscaling, caching, model rollout strategies, and incident playbooks plus what we’d change after thousands of downloads and weeks of live usage. Expect hard-learned patterns, YAML you can run, and a plain-English checklist you can lift into your own cluster; whether you’re serving English or a low-resource language model.

Existing cloud and Kubernetes cost management tools struggle to track expenses at a granular level, leaving engineers unable to answer critical questions like: How much is one specific customer costing us in DynamoDB usage? Or, which system component is consuming the most of our Kafka cluster?1


This lightning talk demonstrates how to leverage existing observability frameworks to gain detailed, low-level cost insights. Attendees will learn basic techniques to instrument standard metrics—such as component name, customer ID, and team—with custom labels for fine-grained cost allocation.1


This session includes a practical case study from Red Canary, who has used this exact methodology for over five years to transform their tactical decision-making and better manage cloud spend. By treating cost allocation as an observability problem, engineers can provide the finance team with the deep data required for effective resource management.1


Attendees will leave with an actionable plan for implementing a metrics-based cost tracking system (likely with the tooling you already have), independent of high-level cloud billing tools, to drive significant operational efficiency.

This talk introduces observability debt as an operational issue that develops over time in evolving systems. Teams often instrument services early using observability frameworks, define metrics, dashboards, alerts, and SLOs, and initially gain confidence in their ability to understand system behavior. However, production systems rarely remain static. As systems evolve through refactoring, scaling, architectural changes, asynchronous processing, and organizational shifts. Observability artifacts frequently remain unchanged, creating a mismatch between what telemetry is assumed to represent and how the system actually behaves. This mismatch, referred to as observability debt, does not result from missing data but from telemetry whose meaning has drifted due to unmaintained assumptions, leading to dashboards that appear healthy, alerts that lack context, and slower incident understanding. To make this concrete, the talk uses a minimal personal system intentionally designed to model common production patterns. Starting from a low-debt state where telemetry reflects user impact, the system evolves while observability remains static, resulting in metrics that hide localized failures.

Menu:

Smoked Turkey-Honey Dijon Wedge; Smoked Turkey, Honey-Dijon Cream Cheese, Lettuce, Marble Pumpernickel Focaccia (GF)
Ham & Swiss Wedge; Smoked Ham, Mustard Aioli, Lettuce, Egg Focaccia
Roasted Veggie Wrap (vg) 
Corn Chowder Soup (v, GF)

Blueberry Cheesecake (V) and Apple Spice Cake (vg, GF)

The future of observability isn't better dashboards—it's AI agents that reason across metrics, logs, and traces alongside your engineering team.

Engineers spend hours correlating signals across Grafana, Kibana, and Jaeger, mentally stitching together what happened and why. What if an agent could do that correlation automatically?

This session presents a practical architecture for building observability agents that autonomously triage incidents across all three pillars. we'll demonstrate an agent that ingests an alert, queries metrics, searches logs, examines traces, identifies root causes, and recommends remediation—while keeping humans in the loop.

We'll cover:

Why observability is ideal for agentic AI
Agent architecture with LangGraph orchestration
Integration patterns: MCP, REST APIs, and OpenTelemetry
Tool design for metrics, logs, and traces
Live demo: agent triaging a simulated incident
Production considerations: reliability, cost, guardrails
Attendees leave with a working reference architecture built on CNCF ecosystem tools (Prometheus, Jaeger, Loki, Grafana). All code is open source.

Observability data isn't homogeneous. Security logs require needle-in-haystack searches with multi-year compliance retention. Kernel logs are uncompressible text. Structured logs enable fast aggregations, while semi-structured logs explode cardinality. Traces demand different access patterns entirely.

Modern requirements compound this. Observability must join with other data sources. Agentic AI systems generate massive volumes of unstructured and semi-structured logs and traces. Big data platforms have emerged as popular storage alternatives.

Forcing everything into one system creates impossible tradeoffs: slow queries, runaway costs, frustrated users.

At Airbnb and Slack, operating thousands of tenants across hundreds of clusters, we built a polystore architecture routing workloads to specialized engines, unified behind a single query interface. This required changes across the entire stack: instrumentation, collection, storage, and query layers.

This talk shares routing criteria, backend tradeoffs, and techniques for unified querying. Attendees will learn to optimize observability for better performance and lower costs.

Unified observability has lately been regarded as the holy grail by some. One platform, universal observability, for everything. Usually, this would be the default, but when you are at a 30-year-old non-technical enterprise, dealing with a mixture of legacy and modern systems, it's a whole different story.

A consequence of legacy decisions, in some cases, results in having multiple observability platforms for different teams within the company, adding overhead, cost, noise, and audit complexity. This was the case at Emaar, a property developer based in Dubai, until the PE team took on the exciting project of unifying all observability into one platform. This included applications, infrastructure, network, and security. The complexity arises not just from the different data sources, but rather from the number and nature of the deployment sites. This included sites across 10 countries consisting of data centers, hotels, malls, shops, etc.

This talk will outline the experience of implementing a unified observability platform consisting of thousands of network devices, machines, and application workloads using open-source technologies that resulted in 6 figures of cost savings.

Building AI agents is easy, but knowing why they fail is hard. Traditional APM tools were designed for request-response services, not autonomous agents that reason, plan, and execute multi-step workflows. When your agent makes unexpected decisions, standard metrics and traces don't tell you why.

This session introduces Eval-Driven Development, which focuses on building reliable agents through continuous observability and evaluation. Using OpenSearch AgentHealth, a new open-source platform for agent observability, we'll walk you through the full agent lifecycle of building, observing, improving, and repeating. We'll share a case study comparing two production root-cause-analysis agents. One was built with observability from day one and shipped in a 6 weeks, while the other was retrofitted later and took 12 months to reach production. You'll learn how we used agentic evaluation to score agent outputs and improve accuracy over time.

You'll walk away with patterns for instrumenting agents with OpenTelemetry, techniques for evaluating full decision sequences (not just outputs), and a framework for shortening your development timeline by building observability in from the start.

The OpenTelemetry Collector has emerged as one of the project’s most critical pieces for ingesting and processing your app and infrastructure data, but did you know there’s even more you can do with your data before it reaches your backend?

Enter OTTL, or OpenTelemetry Transformation Language, a domain-specific language that can interact with and modify OTel data. Yes, the Collector already comes with dozens of components that can handle a wide range of data processing, BUT using OTTL in conjunction with the components enables even more powerful data manipulation.

In this session, learn about the benefits of OTTL, when to use it, and how to get started with OTTL. Get ready to explore:
* What OTTL is: A breakdown of the syntax and the underlying architecture within the OTel Collector.
* Why it’s useful: practical strategies for cost reduction (filtering noise), compliance (redacting PII), and standardization (normalizing attributes).
* How to use it: A live walkthrough of writing complex transformation statements for the transform and filter processors.