Skip to main content
RunBook Academy

KubernetesLXXXV · Cluster ObservabilityCluster observability

Cluster-level vs workload-level observability

Advanced⏱ ~12 minkubectlprometheusloki

What you'll learn

  • Distinguish cluster-level and workload-level observability
  • Identify the signals per scope
  • Configure the tools per scope
  • Plan the observability for both scopes

Prerequisites

Verified against Kubernetes 1.34.x · kubeadm 1.34.x · kubectl 1.34.x · etcd 3.6.x · CoreDNS 1.11.x · containerd 1.7.x / 2.x · 2026-08-16

Not yet marked complete on this device.

Cluster observability has two scopes: cluster-level (the cluster’s health, the API server, the kubelet, etcd) and workload-level (the application’s behavior). The signals, the tools, and the operators differ. This lesson walks the two scopes, the signals, the tools, and the production patterns.

The two scopes

flowchart LR
    A[Observability] --> B[Cluster-level]
    A --> C[Workload-level]
    B --> D[API server, kubelet, etcd]
    C --> E[Application behavior]

The two scopes are different. The cluster-level is the infrastructure; the workload-level is the application.

The cluster-level signals

The cluster-level signals:

# API server request rate
apiserver_request_total

# Kubelet runtime operations
kubelet_runtime_operations_total

# etcd disk fsync
etcd_disk_wal_fsync_duration_seconds

# Node CPU usage
node_cpu_usage_seconds_total

The cluster-level signals are emitted by the cluster components.

The workload-level signals

The workload-level signals:

# Application HTTP requests
http_requests_total

# Application latency
http_request_duration_seconds

# Application error rate
http_errors_total

# Database query duration
db_query_duration_seconds

The workload-level signals are emitted by the application.

The cluster-level tools

The cluster-level tools:

flowchart LR
    A[Cluster] --> B[Prometheus]
    A --> C[event-exporter]
    A --> D[kubelet logs]
    B --> E[Grafana]
    C --> E
    D --> E
  • kube-state-metrics: the cluster’s resource requests.
  • cAdvisor: the per-container resource usage.
  • node_exporter: the host’s metrics.
  • Prometheus: the cluster’s metrics database.
  • event-exporter: the cluster’s events to S3.

The workload-level tools

The workload-level tools:

flowchart LR
    A[Application] --> B[Prometheus]
    A --> C[Promtail/Fluent Bit]
    A --> D[OpenTelemetry]
    B --> E[Grafana]
    C --> E
    D --> E
  • Application metrics: the application’s Prometheus metrics endpoint.
  • Promtail/Fluent Bit: the application’s stdout collector.
  • OpenTelemetry SDK: the application’s trace emitter.
  • Grafana: the application’s dashboards.

The cluster-level operators

The cluster-level operators are the cluster administrators:

  • Cluster SRE: the cluster’s health, the API server, the kubelet.
  • Network engineer: the CNI, the network policies.
  • Storage engineer: the CSI, the storage classes.

The cluster-level operators care about the cluster’s health.

The workload-level operators

The workload-level operators are the application developers:

  • Application developer: the application’s behavior.
  • Application SRE: the application’s SLOs, the alerts.
  • Product owner: the application’s business metrics.

The workload-level operators care about the application’s behavior.

The cluster-level dashboards

The cluster-level dashboards:

# Cluster CPU usage
sum(rate(container_cpu_usage_seconds_total[5m])) by (node)

# Node memory usage
sum(container_memory_working_set_bytes) by (node)

# Pod count
count(kube_pod_info) by (namespace)

# API server request rate
apiserver_request_total

The cluster-level dashboards are operator-facing.

The workload-level dashboards

The workload-level dashboards:

# HTTP request rate
rate(http_requests_total[5m])

# HTTP request latency (p99)
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

# HTTP error rate
rate(http_errors_total[5m])

# Database query latency
histogram_quantile(0.99, rate(db_query_duration_seconds_bucket[5m]))

The workload-level dashboards are developer-facing.

The division of responsibility

The division of responsibility:

ScopeOwnerTools
Cluster-levelCluster SREPrometheus, event-exporter, kubelet logs
Workload-levelApplication developerApp metrics, Promtail, OTel
SharedPlatform teamGrafana, alerting

The division is per scope.

The cross-cutting concerns

The cross-cutting concerns:

  • Networking: the CNI metrics, the network policies.
  • Storage: the CSI metrics, the PVC latencies.
  • Security: the audit logs, the admission logs.

The cross-cutting concerns are shared between the two scopes.

Cross-course references

  • The kube-state-metrics course (Part LXXXVI) covers the cluster’s metrics.
  • The Prometheus course (Part LXXXVIII) covers the metrics database.
  • The Loki course (Part LXXXIX) covers the logs.

Quiz

Knowledge check · 4 questions

  1. Q1. What is the difference between cluster-level and workload-level observability?

  2. Q2. Networking, storage, and security observability are shared between the cluster-level and workload-level scopes.

  3. Q3. Walk the observability setup for a cluster with 5 workloads.

    Cluster with 5 workloads (nginx, api, db, batch, monitoring). The team is configuring observability for both scopes.

  4. Q4. What is the division of responsibility between cluster-level and workload-level observability?

Passing score: 75%. Answers are checked in this browser.

Production discipline

  • Configure both scopes. Cluster-level and workload-level.
  • Identify the owners. Cluster SRE for cluster; developers for workloads.
  • Use the canonical tools. Prometheus, Loki, Jaeger, event-exporter.
  • Configure the dashboards. Per scope.
  • Configure the alerts. Per scope.
  • Document the division. The owners, the tools, the dashboards.

The two scopes are the cluster’s observability. Operating it well is configuring both, identifying the owners, and using the canonical tools.