Kubernetes monitoring: Best practices, alerting, and solutions

Kubernetes is one of the fastest-growing DevOps frameworks, owing largely to its flexibility and scalability. That same flexibility complicates monitoring. Unlike a simple two-server deployment, a Kubernetes cluster manages hundreds or thousands of pods that are rapidly created and destroyed, and you have to pay attention to both standard metrics (CPU, memory, disk I/O) and Kubernetes-specific ones (pod counts, failing containers, network usage).

In this guide we'll cover why monitoring matters, seven monitoring best practices, the open source tools worth reaching for in 2026, and how to approach alerting.

Why should you monitor Kubernetes?

Monitoring is the process of logging the data related to a system's resource consumption and performance output. A well-executed Kubernetes monitoring strategy gives you insight into improper container management, helps you allocate resources between clusters more efficiently, and makes sure errors in your infrastructure are picked up and dealt with on time.

Monitoring gives you real-time performance data you can act on. Observability goes further, correlating that data to identify larger infrastructure problems that no single metric reveals on its own.

7 Kubernetes monitoring best practices

1. Identify the right metrics

You cannot monitor everything, so start with what matters. Track the number of active pods, core resource metrics like CPU, memory, and disk I/O, container-native metrics, and application-specific metrics that tell you whether your service is actually doing its job. The right set depends on your workload, so be deliberate about it rather than collecting data for its own sake.

2. Use labels and tags extensively

Attach descriptive labels to your pods and containers so you can filter by application, team, environment, or location. Document your naming strategy and apply it consistently across your infrastructure so everyone reads the same signals the same way.

3. Aim for observability over monitoring

Basic metrics tell you that something is wrong, observability helps you understand why. Push beyond surface-level metrics to gather finer data at the kernel level: running processes, file access traffic, network traffic, and more. That context lets you correlate symptoms across services and find root causes.

4. Capture historical data

Retain your performance history. Trends only show up over time, and historical data lets you predict future issues, plan capacity, and run proper root cause analyses after an incident. A metric is far more useful when you can compare today against last week and last month.

5. Pay attention to the control plane

The control plane is your cluster's central management hub, so treat it as a first-class monitoring target. Latencies and errors here ripple out into everything your cluster does, and they are easy to miss if you only watch workloads. Keep an eye on the API server, scheduler, controller manager, and etcd.

6. Prefer out-of-the-box dashboards

You do not need to build everything from scratch. Pre-built dashboards get you to a useful view faster, especially if you are new to monitoring. Start with what the tools give you, then customise once you know what you want to see.

7. Keep end user experience in mind

Internal metrics alone will not tell you whether your users are happy. Implement end-to-end and HTTP monitoring so you can see your application the way its users do.

Kubernetes monitoring open source tools and solutions

A visual dashboard is still the fastest way to read a cluster's state at a glance. One thing has changed since this article was first published: the Kubernetes Dashboard project has been retired. Its repository is archived, its last release was v7.14.0 in October 2025, and its maintainers now point users at Headlamp. The tools below are all actively maintained.

Headlamp (the maintained web dashboard)

Headlamp is a CNCF project under Kubernetes SIG UI and the web dashboard the retired Kubernetes Dashboard now recommends. It gives you a multi-cluster view, a plugin system, and a desktop app if you prefer not to run it in-cluster.

We'll install the in-cluster version with Helm:

1helm repo add headlamp https://kubernetes-sigs.github.io/headlamp/
2helm install headlamp headlamp/headlamp --namespace kube-system

Confirm it is running and open it:

1kubectl -n kube-system get pods -l app.kubernetes.io/name=headlamp
2kubectl -n kube-system port-forward svc/headlamp 8080:80

Browse to http://localhost:8080.

The Headlamp homepage, showing its cluster overview UI. Website capture.

k9s (terminal UI)

k9s is a terminal UI that lets you navigate, observe, and manage a cluster with single-key shortcuts, without leaving the terminal. It reads your existing kubeconfig, so there is nothing to deploy into the cluster.

We'll install the client and launch it:

1brew install derailed/k9s/k9s
2k9s

Press : then type a resource (for example pods, deploy, or svc) to jump straight to it.

The k9s project homepage. Website capture.

Prometheus and Grafana (kube-prometheus-stack)

Prometheus remains the de facto standard for Kubernetes metrics, and it pairs with Grafana for dashboards. The kube-prometheus-stack Helm chart installs Prometheus, Grafana, Alertmanager, node-exporter, and kube-state-metrics together, already wired up.

We'll install the whole stack:

1helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
2helm repo update
3helm install monitoring prometheus-community/kube-prometheus-stack \
4  --create-namespace --namespace monitoring

Check the components and open Grafana:

1kubectl -n monitoring get pods
2kubectl -n monitoring port-forward svc/monitoring-grafana 3000:80

Open http://localhost:3000. The default login is admin, and you can read the generated password with:

1kubectl -n monitoring get secret monitoring-grafana \
2  -o jsonpath="{.data.admin-password}" | base64 -d; echo

The Grafana product page, showing a dashboard. Website capture.

Jaeger, Tempo and OpenTelemetry (tracing)

Jaeger, originally built at Uber, is an open source tracing backend for root cause analysis and following requests across services. If you already run Grafana, Tempo is the trace store that slots straight into it, alongside Loki for logs and Mimir for long-term metrics (together, the Grafana LGTM stack). Whichever backend you pick, emit traces with OpenTelemetry: it is the vendor-neutral standard for instrumenting traces, metrics, and logs, and its Collector and Operator make it the default plumbing for new clusters.

The Jaeger project homepage. Website capture.

For desktop users: OpenLens stopped receiving updates after Lens closed its source. Freelens is the actively maintained open source fork.

The importance of Kubernetes alerting

Alerts are notifications sent out when your metrics exceed a certain, pre-set threshold. In most cases an alert indicates something wrong with your system that needs immediate attention, though you can also use them for routine checks. You can configure multi-channel delivery and build escalation strategies based on how severe an issue is, so the right person hears about the right thing at the right time.

It is important not to overdo it, however. Alerts can get overwhelming quite easily, and alert fatigue makes it more likely that important alerts get missed. To keep alerting healthy:

• Correlate related issues so you reduce duplicate alerts for a single underlying problem.
• Limit alert timing so you are not paged repeatedly for the same condition.
• Avoid sending non-urgent alerts outside working hours.
• Make sure every alert carries actionable context, so the responder knows what to do next.

Wrapping up

Kubernetes is, without doubt, one of the leading container orchestration technologies in the market. However, it is not among the simplest ones to monitor. In this guide, we showed you some of the best practices and tools you can use to set up an effective Kubernetes monitoring strategy. Alerting is an essential part of monitoring, and you should ensure that you plan and implement a robust alerting strategy alongside your monitoring setup.