Kubernetes Monitoring Tools for Small Teams (2026)

Kubernetes makes monitoring harder in a specific way: the things you care about — a Deployment, a service — are made of pods that come and go. A tool that tracks pods tells you a lot about the last ten minutes and little about the last week. This guide is for small teams running a cluster or two without a dedicated platform team, and it's ordered from the simplest option to the most complete.

A disclosure: we build Archynt and it's on the list. Prices are left out on purpose — they change too often; check each vendor's page.

What to monitor in a cluster

• Nodes: CPU, memory and disk pressure.
• Pods: restarts, OOM kills, CrashLoopBackOff, pods stuck in Pending.
• Workloads: Deployments and StatefulSets with fewer ready replicas than desired, HPA behaviour, failed Jobs.
• Services: request rate, error rate and latency, and which services depend on which.
• Logs and events: container logs and Kubernetes events, searchable after the pod is gone.

At a glance

1. kubectl top and metrics-server

Install metrics-server and kubectl top nodes and kubectl top pods show current CPU and memory. It's also what the Horizontal Pod Autoscaler reads.

Watch out for: only the latest reading — no history, no alerts, no application metrics. A diagnostic tool, not monitoring.

2. k9s

A terminal UI for Kubernetes: browse workloads, tail logs, describe resources and see pod CPU and memory without typing kubectl commands. Many engineers keep it open all day.

Watch out for: it's interactive. Nobody is watching when you close it, and nothing alerts.

3. kube-prometheus-stack

The Helm chart that installs the Prometheus Operator, Prometheus, Alertmanager, Grafana, node-exporter and kube-state-metrics with a set of default dashboards and alert rules. The open-source standard, and the data format most other tools understand.

Watch out for: you operate it: storage sizing, retention, upgrades, and tuning alert rules that are noisy out of the box. Logs need another component, such as Loki.

4. Grafana Cloud

The same Prometheus-compatible metrics, Loki logs and Grafana dashboards, run for you, with a Kubernetes monitoring app that ships the cluster's data from an agent you install.

Watch out for: usage-based billing makes high-cardinality metrics and verbose logs worth watching.

5. SigNoz

An open-source, OpenTelemetry-native platform for metrics, logs and traces, self-hosted or managed. A good fit if your services already emit OpenTelemetry data.

Watch out for: traces and application metrics depend on instrumenting your services.

6. Datadog

A broad commercial platform with deep Kubernetes integration — cluster and node views, APM, logs and much more — correlated in one place.

Watch out for: the breadth brings complexity, and the bill grows with hosts, containers and products. Archynt vs Datadog covers where the two differ.

7. groundcover

A Kubernetes-focused observability platform built on eBPF, collecting metrics, logs and traces from the kernel without changing application code.

Watch out for: it's designed around Kubernetes; if part of your stack runs on plain Docker hosts, check how it covers them.

8. Archynt

A read-only agent for Kubernetes and Docker. In a cluster, a watcher (two replicas, one elected leader) follows workloads, pods, nodes, services, ingresses, HPAs and events, and a DaemonSet reads each node's container metrics, pod logs, TCP connections and an eBPF sensor for request, error and latency rates. The unit is the workload, so a Deployment keeps its metrics, logs and alerts across a rollout that replaces every pod. Alerts compare each service against its own baseline and go to email, Slack or a webhook. It installs with Helm or one manifest, and the ClusterRole only grants get, list and watch. It also reads your repositories to draw class diagrams, C4 views and sequence diagrams.

Watch out for: no distributed tracing, uptime checks or on-call. Not supported on GKE Autopilot or Windows nodes.

How to choose

• "I just need to look at the cluster." k9s plus metrics-server.
• "We want open source and have time to run it." kube-prometheus-stack, plus Loki for logs.
• "Open source, but not operated by us." Grafana Cloud, or SigNoz Cloud if you use OpenTelemetry.
• "One vendor for everything." Datadog.
• "Metrics, logs, alerts and a map of how services connect, without instrumenting." groundcover or Archynt — Archynt if you also want the architecture from your code. For plain Docker hosts, see Docker monitoring.

FAQ

What should I monitor in Kubernetes?

Node CPU, memory and disk; pod restarts, OOM kills and pods stuck pending; workloads with fewer ready replicas than desired; cluster events; and for each service its request rate, error rate and latency, plus its logs. Those cover the large majority of incidents.

Is metrics-server enough for monitoring?

No. metrics-server keeps only the latest CPU and memory reading so the autoscaler and kubectl top can use it. It has no history, no alerts and no application metrics.

Do I need Prometheus to monitor Kubernetes?

Not necessarily. Prometheus is the open-source standard and many tools read its data, but managed and agent-based tools can collect the same signals without you running Prometheus.

What is eBPF-based Kubernetes monitoring?

Tools that use eBPF observe network calls in the kernel, so they can measure each service's requests, errors and latency without adding an SDK or sidecar to your applications.

Originally published on archynt.com.