F-02 — Intro to Elastic

Shared Foundations

Presenter: Roberto Pantoja

Date: 2026-07-22

SLB × Elastic Workshop Program

Overview

Platform overview — labs use Serverless; the same observability capabilities apply on ECH and self-managed deployments.

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

  • Elastic Observability — Serverless, ECH, and self-managed (same Kibana value)
  • Streams, ES|QL, and unified Observability
  • SLB SRE's journey with Elastic — current state
  • AI Assistant and Agent Builder introduction

Why these features?

☁Observability everywhereSame value on Serverless, ECH, and self-managed
⎇Elastic StreamsManaged routing and processing for telemetry
⌘ES|QLOne query language for logs, metrics, and traces
◎Unified ObservabilityLogs, metrics, and traces in one place
✦AI AssistantNatural language over your live telemetry
🤖Agent BuilderRepeatable AI workflows with guardrails

Use → to see why each feature matters for SLB.

Why Observability everywhere?

Same value on Serverless, ECH, and self-managed

Without it

Teams treat deployment choice as a feature fork — assuming Serverless skills won't transfer to ECH or on-prem, or that only one model fits SLB.

With Observability everywhere

Serverless, Elastic Cloud Hosted, and self-managed share the same Observability UX. Labs use Serverless to skip cluster toil; you apply the same ES|QL, Streams, and AI workflows wherever Elastic runs.

  • Serverless: Elastic manages scaling, upgrades, ILM, and Fleet overhead
  • ECH / on-prem: same capabilities when you need full infrastructure control
  • Choose deployment for ops burden — not for observability feature access
Your deployment
Same Kibana
Same skills

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 Unified Observability?

Logs, metrics, and traces in one place

Without it

Three tabs, three tools, manual correlation — "which deploy caused this spike?" takes too long.

With Unified Observability

APM, Logs Explorer, and Metrics views link the same service context — pivot from error log to trace to CPU in clicks.

  • Shorter MTTR when signals share service.name and trace.id
  • Deploy validation: check all three pillars after a release
  • One Observability overview for leadership and SRE review
Logs
Metrics
Traces

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

Why Agent Builder?

Repeatable AI workflows with guardrails

Without it

Ad-hoc ChatGPT sessions with no access to SLB data, no audit trail, and inconsistent answers per engineer.

With Agent Builder

Build agents that use observability context, tools, and retrieval — tuned prompts your team can trust and share.

  • Standardize "investigate service X" and "summarize deploy" playbooks
  • Connect tools (ES|QL, alerts, docs) instead of copy-paste context
  • Govern who can publish agents — architecture-friendly AI ops
Agent
Tools + data
Action

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-shared-foundations

Resources

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