Customer value: One observability store instead of Prometheus + Loki + Tempo — and keep PromQL where you already use it.
A typical Grafana stack spreads logs, metrics, and traces across three databases with three query languages. That slows humans in incidents and forces AI agents into multi-tool hops. On price, Elastic Serverless is modeled ~33% lower than Grafana Cloud on Prom workloads (see Challenge 3). This lab starts with Prom cost levers you can drop: scrape starvation, remote-write fan-out, and HA Prom + Thanos/Mimir ops — then one managed remote-write / OTLP path on Elastic.
PromQL → LogQL → TraceQL. Manual joins, clipboard IDs, and Agent Builder needs three tool calls.
15s → 60s scrapes · extra remote-write paths · relabel YAML · recording rules · shard the TSDB.
One remote-write / OTLP endpoint · Streams Drop · lifecycle — PromQL kept, one investigation path.
Customer value: Familiar boards on Kibana — and a path to migrate a few real Grafana exports without a rewrite project.
Open Horizon — Grafana continuity, the sample board migrated with obs-migrate, then Horizon — Dashboard sprawl — which boards still query which indexes (Grafana folder sprawl).
Time series, stat, table → same story on the continuity board.
Sample: Prometheus Basics + PromQL alerts → Dashboards on live Horizon metrics.
Keep PromQL in Kibana rules (ES|QL PROMQL) — one project, no Alertmanager sidecar.
Grafana folder sprawl: Elastic inventories which dashboards still query which indexes, and alerts if a schema change would blank a widget.
Customer value: Same PromQL workloads — modeled ~33% lower than Grafana Cloud, plus one store instead of three.
On the Grafana stack worksheet (12-month retention, Prometheus-sized samples): 100k samples/sec @ 296B → Grafana Cloud ~$33K/mo vs Elastic Serverless ~$22K/mo (~33% lower). Same ratio on a smaller footprint (~$3.1K → ~$2.1K). Pair with Challenge 1: multi-store inefficiency for humans and AI — and yes, we are cheaper. In the lab: Drop /debug/pprof, open Horizon — Streams savings, then open the sheet with your samples/sec.
Modeled list-rate · 12-mo Elastic retention vs Grafana Cloud’s included ~13-mo · ~33% lower in pricing analysis · tco-calc.o11ybot.app/?scenario=grafana-stack · confirm with measured usage
Cut scrape/debug noise before ingest — keep resolution without starving scrapes to control Grafana Cloud billable series.
One observability store, one investigation query language, PromQL preserved — and ~33% lower than Grafana Cloud on modeled workloads.
Customer value: Keep PromQL for dashboards — but stop exporting host lists and trace IDs between Loki, Prometheus, and Tempo.
In a typical Grafana stack, logs, metrics, and traces sit in three stores with three query languages. ES|QL subqueries (WHERE field IN (subquery)) keep the intermediate cohort inside Elasticsearch — saturated hosts, erroring hosts, or 500 slow trace IDs never land in a clipboard. One query answers questions like “what did the saturated hosts log?” or “470 of 500 slow traces share the same lock wait.” (Observability Labs · Aug 2026)
PromQL chart → copy host names → LogQL → copy trace IDs → Tempo. Stale lists, manual joins, negative checks skipped.
Metrics → logs, logs → metrics, traces → logs, or all three nested — OTel fields kept on ingest, one time picker.
One ES|QL string anyone can re-run in Discover — not a join that lives in one engineer’s head during the incident.