SRE 03 — Ingestion Architecture & Troubleshooting

SME Track: SRE & Infra Ops

Presenter: Specialist (DSR)

Date: 2026-10-14

SLB × Elastic Workshop Program

Overview

Ingestion troubleshooting with Streams, ES|QL, and AI Assistant — lab on Serverless, patterns apply everywhere.

Where this applies

These labs run on Observability Serverless — a fully managed project so you can practice without cluster operations.

The same capabilities you explore here — ES|QL, Streams, AI Assistant, Agent Builder, Workflows, and SLOs — are available on Elastic Cloud Hosted (ECH) and self-managed deployments.

Serverless mainly saves operational toil (sizing, ILM, Fleet, upgrades). Your observability skills transfer directly.

Session topics

  • OTel → Elastic OTLP (same pattern on all deployments)
  • Streams troubleshooting and ingest gap detection
  • ES|QL patterns for ingestion health
  • AI-assisted diagnosis of telemetry gaps

Why these features?

📡Managed OTel ingestionSend OTLP once — Elastic handles the rest
Elastic StreamsManaged routing and processing for telemetry
ES|QLOne query language for logs, metrics, and traces
AI AssistantNatural language over your live telemetry

Use → to see why each feature matters for SLB.

Why Managed OTel ingestion?

Send OTLP once — Elastic handles the rest

Without it

Multiple exporters, bespoke endpoints, and glue code to normalize Prometheus, Loki, and Jaeger into one query model.

With Managed OTel ingestion

Point OpenTelemetry collectors at Elastic OTLP endpoints — unified logs, metrics, and traces in any deployment model.

  • One semantic model (OTel) across services and hosts
  • Side-by-side migration: Grafana today, Elastic Streams tomorrow
  • Less custom integration code to maintain
OTel SDK
Managed OTLP
Unified store

Why Elastic Streams?

Managed routing and processing for telemetry

Without it

Custom ingest pipelines, index templates, and rollover policies per team — fragile, hard to govern, and different on every cluster.

With Elastic Streams

Streams define how logs, metrics, and traces are routed, processed, and retained — on Serverless, ECH, and self-managed, with a unified UI.

  • Reduce DIY pipeline + ILM work with declarative stream rules
  • Consistent ownership and naming across SLB domains
  • On self-managed/ECH you may still use ILM — Streams simplify routing either way
Ingest
Streams
Search & alerts

Why ES|QL?

One query language for logs, metrics, and traces

Without it

Different syntax per signal — PromQL for metrics, LogQL for logs, trace UI only — context switching slows incidents.

With ES|QL

ES|QL pipes data through filters, stats, and joins across observability datasets in Logs Explorer and Dev Tools.

  • Faster investigations with reusable query patterns
  • Same syntax in Logs Explorer on Serverless, ECH, and self-managed
  • AI Assistant can draft and explain ES|QL for your team
FROM logs-*
STATS / WHERE
Answer

Why AI Assistant?

Natural language over your live telemetry

Without it

Every investigator rebuilds the same ES|QL, scrolls dashboards, and writes runbook prose from scratch.

With AI Assistant

Ask questions in plain language — get ES|QL, summaries, and correlated logs/traces grounded in your project data.

  • Onboard new engineers without memorizing query syntax
  • Explain spikes and error patterns during live incidents
  • Draft queries you can save, share, and reuse
Question
AI Assistant
Evidence

Hands-on lab

Your lab uses Elastic Observability Serverless for a zero-ops learning environment.

The steps and features are the same on ECH and on-prem — follow the assignment panel when Kibana opens.

Instruqt track: slb-sme-sre-infra-ops

Resources

  • Registration: events.elastic.co/slbworkshops
  • Repo: github.com/poulsbopete/slb-workshops
  • Use ← → arrow keys to navigate slides