Kubernetes Observability

Kubernetes Observability on Elastic Content Share is the platform-layer guide for teams who need cluster, workload, and SLO evidence—especially when an End-to-End Observability Business Critical Service scoreboard points at origin capacity or orchestration as the red layer.

Elastic already collects Kubernetes metrics, logs, and traces through Elastic Agent, Beats, OpenTelemetry, EKS integrations, and ECK. What this hub adds is the operating path: which packs to start with, why you need more than one, how they stitch to APM and BCS labels, and when to stop treating “pods yellow” as the whole outage story.

Why Kubernetes alone is not end-to-end

Platform health is necessary for many Business Critical Services. It is rarely sufficient. A green cluster can still ship a broken play experience; a red node can be unrelated to the sessions burning error budget. Use this hub when capacity, scheduling, or cluster networking is implicated—after correlation keys and the BCS scoreboard tell you the platform capability is red.

What “good” looks like on the platform layer

• Workload SLIs (availability, latency, error rate) tied to service.name and, when possible, labels.critical_service
• Cluster/node saturation visible without drowning responders in every namespace alert
• OpenTelemetry or Elastic APM traces for hop-local origin drill-down under the same services
• SLO error budgets for the platform slice that sits under the BCS origin—not only raw CPU charts

Why several Kubernetes downloads exist

One ZIP cannot cover managed EKS operations, self-managed ECK, generic monitoring examples, and OTel-based SLO templates at once. Each pack fills a distinct gap:

• OTel SLO templates — measurable budgets for K8s/OTel signals you can wire into a BCS composite later
• EKS monitoring pack — AWS managed Kubernetes operational views
• ECK observability — Elastic Stack on Kubernetes as the platform under observation
• Generic K8s monitoring examples — broader dashboards/patterns when you are not on a single vendor path

Step-by-step: platform drill-down from a BCS alert

1. Confirm the red capability is platform/origin capacity. Start from the E2E hub scoreboard and investigation order—do not jump straight into every namespace.
2. Identify implicated services. Use hop-local APM/OpenTelemetry evidence for the origin services behind the failing capability.
3. Import or open Kubernetes OTel SLO templates. Kubernetes OTel SLO Templates exist to turn platform signals into error budgets you can defend—not just dashboards you glance at.
4. Match your runtime path. On EKS, use Elastic EKS Monitoring Pack. On ECK-managed Elastic, use Elastic Kubernetes Observability with ECK. For broader examples, use Elastic examples: monitoring Kubernetes.
5. Stitch labels upward. Keep service.name and BCS labels consistent with the correlation keys pack so platform evidence joins the same critical service name.
6. Decide if network is also implicated. If pod-to-pod or ingress/DNS patterns dominate, continue into Network Observability rather than restarting nodes first.
7. Feed the composite narrative. Update the BCS/platform SLI story for stakeholders who will not open Discover.

How these packs stitch together

• E2E BCS view → service.name → K8s workload metrics is the primary join. Traces remain hop-local under origin.
• SLO templates → journey/BCS budgets let platform burn sit beside experience burn without pretending they are the same SLI.
• EKS vs ECK vs generic examples are alternate runtime entry points—pick one primary path, then deepen.
• Anti-pattern: paging only on node CPU while session/content joins show the failure is CDN or client-side.

Start here (with purpose)

1. Kubernetes OTel SLO Templates — Why: error budgets for the platform slice under your BCS origin.
2. Elastic EKS Monitoring Pack — Why: managed Kubernetes operational pack when you run on EKS.
3. Elastic Kubernetes Observability with ECK — Why: observe Elastic-on-K8s and related platform patterns.
4. Monitoring Kubernetes examples — Why: broader starter dashboards/patterns beyond one cloud path.
5. End-to-End Observability hub — Why: return to the multi-layer BCS path when platform is only one capability.

Go deeper

• OpenTelemetry downloads — instrumentation that carries service and BCS labels into Elastic.
• SLO downloads — journey and platform budget building blocks.
• APM downloads — hop-local origin investigation after the cluster view implicates a service.
• Network Observability — when path, DNS, or ingress evidence is the next layer.
• Elastic Observability category — broader archive after the guided path.

Related collections

Explore · End-to-end observability tag · BCS architecture article