End-to-End Observability

End-to-End Observability on Elastic Content Share means answering one question under load: is this Business Critical Service (BCS) healthy across every layer that makes it work? That is not the same as following one APM waterfall inside one application.

A BCS such as TV streaming, checkout, or subscriber attach usually spans user experience, CDN or edge, origin applications, network path, and platform. Many hops are async. Often there is no single trace.id from browser to CDN to packaging worker. This hub is the curated path from that problem to a working Elastic composition—using several packs on purpose, then stitching them with shared join keys and a clear investigation order.

Read this page as a guide. Every link below exists because it fills a specific gap; skip the reason and you will collect files without an operating model.

Why you need more than one download

Other solutions often package “journeys” or “business flows” as one product surface. Elastic already has the pillars (RUM, Synthetics, APM/OpenTelemetry, logs, metrics, network, SLOs). What practitioners still need is a reusable BCS model plus layer evidence they can import and adapt.

No single ZIP can honestly be “all of E2E.” Correlation conventions, a multi-layer scoreboard, async ES|QL bridges, proactive UX checks, and error budgets are different jobs. Network and Kubernetes packs are drill-downs when those layers turn red. This hub tells you which pack for which job and in what order to compose them.

Mental model: TV streaming BCS

Use streaming as the teaching example; remap later to retail, banking, or telco.

1. Experience — search, find, play, QoE (session + subscriber). Own the customer-felt outcome.
2. Edge / CDN — cache hits, origin fetches, PoP errors (session/content/cache key; often no frontend trace).
3. Origin / apps — package once, serve many; queues and workers (content/message IDs; hop-local traces).
4. Network — client path, DNS/TLS, connectivity when geography or ASN patterns dominate.
5. Platform — Kubernetes/host health under origin and dependencies when capacity is the story.

Each layer should publish a stable labels.critical_service, at least one cross-layer join key, health signals, and optional hop-local trace.id.

Step-by-step: from zero to a working BCS outcome

Follow these steps in order. Later packs assume earlier conventions.

1. Name the BCS and capabilities. Pick one vocabulary (for example tv_streaming) and a short capability list (discover, play, CDN delivery, origin package, network path). Without this, dashboards and SLOs will disagree forever.
2. Adopt correlation keys (async joins). Download E2E Observability Correlation Keys so UX, CDN, origin, and workers agree on session, content/entity, and message bridges. This pack exists because stitching fails when every team invents field names—or assumes one global trace.id.
3. Stand up the multi-layer scoreboard. Import Business Critical Service Health Dashboard and load the demo events (or your labeled data). This pack exists to answer DORA-style “is the service OK?” before anyone opens a single waterfall.
4. Practice cross-layer investigation with ES|QL. Use ES|QL Business Transaction Queries for session bridges, content-entity joins, message correlation, and multi-layer failure sessions. This pack exists because the dashboard shows which capability is red; ES|QL proves the join across async boundaries.
5. Add proactive experience checks. Deploy Synthetics Critical Journey Templates for the UX path you care about. This pack is only the experience layer of the BCS—not the whole service—but it catches play/login-style breaks before customers flood support.
6. Wire error budgets. Adapt User Journey SLO Templates so layer SLIs (and later a composite BCS view) burn budget intentionally. This pack exists so “healthy” is measurable, not a dashboard vibe.
7. Attach layer drill-downs before the first real incident. From a red capability, continue into Network or Kubernetes packs (below)—do not stop at the app team’s APM UI by default.
8. Deepen the architecture narrative when onboarding others. Share the Business Critical Services end-to-end article so CX, SRE, edge, network, and platform share the same W-questions and anti-patterns.

How the packs stitch together

Think of a single spine, not a pile of bookmarks:

• Keys → Dashboard → ES|QL share the same BCS name and join fields. Labels from the correlation pack should appear in demo or live data the dashboard and queries filter on.
• Synthetics → SLOs feed the experience capability; they do not replace CDN, origin, or network evidence.
• Investigation order: BCS scoreboard → red capability → session/content/message join → hop-local trace.id inside that hop → Network or Kubernetes evidence if path or capacity is implicated.
• Anti-pattern: importing only synthetics or only APM and calling it “end to end.”

Start-here packs (with purpose)

1. Correlation keys (BCS / async joins) — Why: shared field vocabulary and join patterns when no single trace spans the service.
2. BCS health dashboard — Why: multi-layer scoreboard + demo data so you can rehearse composite health.
3. ES|QL cross-layer / async queries — Why: prove session, entity, and message bridges during investigation.
4. Journey / SLO templates — Why: turn layer signals into error budgets you can defend to stakeholders.
5. Synthetics templates — Why: proactive UX path checks as one controlled input to the BCS, not the whole story.
6. RUM journey and conversion pack — Why: real-user funnel, CWV, and session-aware experience evidence beside synthetics.
7. Distributed tracing investigation pack — Why: hop-local dependency/span runbook once origin is the red capability.

Go deeper by layer (when the scoreboard points there)

Experience and application hops

Use these when play/QoE or origin workers are implicated—after correlation keys exist so labels match.

• RUM User Journey and Conversion Pack — funnel and CWV conventions for the experience capability.
• Distributed Tracing Investigation Pack — ES|QL + runbook from red origin capability to span/dependency.
• APM downloads — additional hop-local service and trace evidence inside origin or app tiers.
• OpenTelemetry downloads — instrumentation patterns that carry BCS labels into Elastic.
• Synthetics downloads — broader proactive checks beyond the critical-journey starter pack.
• Architecture article: BCS end to end — full what/why/who/when/where/how narrative and failure-mode map for onboarding.
• From Elastic demo apps to E2E content — map Elastiflix/OTel demos onto this hub’s pack path.

Physical / platform

Open this path when origin latency and cluster pressure move together—not as the first alert on every UX blip.

• Kubernetes Observability hub — platform drill-down guide when capacity or orchestration is the red layer.
• K8s OTel SLO Templates — error budgets for the platform slice that sits under the BCS origin.

Network / edge path

Open this path when PoP, ASN, DNS, or TLS patterns dominate and apps look green.

• Network Observability hub — path-focused guide for connectivity evidence.
• Network Monitoring Suite — packaged network visibility to attach after the BCS view implicates the path.
• Network Analyzer Agents — agent-side network analytics when you need deeper packet/flow style evidence.

Recommended investigation path (incident day)

1. Open the BCS health view for critical_service (composite and per capability).
2. Identify the red capability (experience vs CDN vs origin vs network vs platform).
3. Join with session, content, or message IDs across that boundary—not only trace.id.
4. Use hop-local APM traces inside the failing layer.
5. If path or PoP related, continue into Network packs; if capacity, into Kubernetes packs.
6. Update the composite SLI / error-budget narrative for stakeholders who will not open Discover.

Related collections

Browse broader libraries after the guided path above—not instead of it:

Elastic Observability (solution archive) · SLO (budget-related packs) · End-to-end observability (tagged BCS assets) · Explore (site-wide starting points)