Updated: 2026-07-07

cAdvisor democratised container monitoring and remains relevant: kubelet includes it internally. But in 2024, observing containers well requires more layers: cluster state metrics, eBPF for deep visibility, APM for application context. This article maps what to combine and how to avoid the over-engineering that turns the observability stack into the most expensive thing to maintain.

Key takeaways

  • The modern minimum stack is cAdvisor + kube-state-metrics + node-exporter + Prometheus + Grafana: covers 80% of what is needed.

  • cAdvisor gives surface metrics (CPU, RAM, network, disk); eBPF adds syscall latency, per-pod network latencies, and CPU profiling.

  • The reference eBPF tools are Pixie (CNCF sandbox), Grafana Beyla, and Parca for continuous profiling.

  • OpenTelemetry is the APM standard: instrument critical apps, not all of them.

  • The trap is over-engineering: more tools equals more maintenance and more alert noise.

The modern minimum stack

For serious Kubernetes in 2024, the OSS baseline that covers most of the work:

  • kubelet / cAdvisor: CPU, memory, network, and disk metrics per container.

  • kube-state-metrics: state of Deployments, Pods, ReplicaSets, and HPAs.

  • node-exporter: metrics for the underlying nodes.

  • Prometheus: scraping and aggregation engine.

  • Grafana: dashboards and alerting.

This stack carries roughly a 5% overhead on cluster CPU/RAM, acceptable for any production installation.

What is missing without eBPF

cAdvisor gives surface metrics but cannot answer: is the pod blocked on filesystem I/O? What is the network latency between pods A and B? Which specific function consumes 80% of CPU? For those questions, eBPF is the correct tool.

eBPF: the layer that changes diagnostics

Pixie[1]: auto-instrumentation of HTTP, gRPC, and DNS without sidecar or code changes. Live flame graphs, automatic service map, and PxL queries. One eBPF agent per node plus a web UI. The most accessible entry point for eBPF newcomers.

Grafana Beyla[2]: auto-instrumentation for Go, Java, and Node apps generating OpenTelemetry traces without code modification. Simpler than Pixie, focused on traces and metrics, and integrates directly with an existing Grafana stack.

Parca[3]: continuous CPU profiling of the entire cluster via eBPF, specifically for identifying CPU hotpaths. Integrates with Grafana.

APM: the application layer

eBPF gives infrastructure visibility; APM gives business logic visibility. OpenTelemetry is the modern standard:

  • Request spans with per-operation latency.

  • Business metrics correlated with infrastructure.

  • Logs correlated with trace IDs so you can navigate from a metric to a log without switching tools.

Beyla can auto-generate spans for many cases; for business-specific metrics (orders processed, average transaction value), the SDK is needed. Common trace backends: Jaeger and Grafana Tempo.

Combining without overloading

The most common mistake is installing every tool at once. The right approach:

  • cAdvisor + kube-state-metrics + node-exporter: lightweight base, always active.

  • eBPF (Pixie or Beyla): add when deep visibility is needed for debugging or performance diagnosis.

  • APM with OTel: for critical business apps, not every microservice.

  • Commercial APM (Datadog, New Relic, Dynatrace): only when the use case justifies the cost over the OSS stack.

Each layer must deliver distinct value. Duplication is waste.

Essential per-container metrics

Always monitor, without exception: CPU throttling, memory working set, OOM kills, network errors, restart count. For Kubernetes additionally: pod phase, readiness probe failures, HPA desired vs current, PVC usage.

Useful alerts

Few but effective: pod restart > N in Y minutes (flapping), sustained CPU throttling > 50% (insufficient sizing), OOM kills (always investigate), memory > 90% of limit sustained (leak or sizing), node not ready, HPA at max replicas.

Fewer useful alerts always beats many ignored ones.

Frequently asked questions

Do I need eBPF if I already have Prometheus and Grafana?

Not necessarily from the start. Prometheus with cAdvisor and kube-state-metrics covers 80% of common cases. eBPF pays off when you encounter problems that surface metrics cannot explain: inter-pod latencies, syscall blocks, or CPU hotpaths with no obvious origin.

What is the difference between Pixie and Grafana Beyla?

Pixie is more comprehensive: automatic service map, live flame graphs, and its own query language (PxL). Beyla is simpler and lighter, focused on generating OpenTelemetry traces and integrating naturally into an existing Grafana stack. For teams already running Grafana, Beyla is the more direct entry point.

Conclusion

Monitoring containers well in 2024 requires more than cAdvisor, but not everything at once. The OSS base (Prometheus + kube-state-metrics + node-exporter + Grafana) is solid and sufficient for most teams. eBPF adds deep visibility when the problem justifies it. APM with OpenTelemetry completes the picture for critical business apps. The discipline is in adding layers only when the use case demands it, and keeping alerts few and well thought out.

Sources

  1. Pixie
  2. Grafana Beyla
  3. Parca