Kubernetes Monitoring einfach erklärt – Prometheus und Grafana

Du betreibst einen Cluster und willst Probleme sehen, bevor Nutzer sie spüren. Genau hier hilft ein sauberes Kubernetes Monitoring. Es sammelt Metriken, wertet sie mit PromQL aus und macht den Zustand deines Systems in Dashboards sichtbar.

Der Klassiker dafür ist Prometheus zum Scrapen und Speichern von Zeitreihen und Grafana für Visualisierung und Alerting. In diesem Guide bekommst du einen klaren Einstieg: Du lernst die Bausteine kennen, richtest eine Minimalinstallation ein, schreibst erste PromQL-Abfragen und baust Alerts, die wirklich helfen.

Was in Kubernetes überwacht werden sollte

Ein gutes Monitoring deckt Infrastruktur, Plattform und Anwendung ab. Auf der Infrastruktur siehst du Node CPU, Speicher, Platten-I/O und Netzwerk. Auf der Plattform beobachtest du Pods, Deployments, Jobs und Requests an API-Server, Scheduler und Controller. In der Anwendung misst du Durchsatz, Fehlerquoten, Latenzen und Business-Kennzahlen. Je klarer deine Metriken und Labels, desto genauer kannst du Probleme eingrenzen.

Prometheus und Grafana in Kubernetes – die Idee dahinter

Prometheus zieht Metriken per HTTP Pull vom /metrics-Endpoint. Jeder Datenpunkt hat Name, Wert, Zeitstempel und Labels. Mit Labels wie namespace, pod, container oder route filterst und gruppierst du flexibel. Grafana verbindet sich als Datasource auf Prometheus und rendert Dashboards und Alerts. Für Kubernetes kommt meist der Prometheus Operator samt kube-prometheus-stack zum Einsatz. Damit definierst du Scrapes mit ServiceMonitor und PodMonitor CRDs statt mit statischen Dateien.

Schnellstart – eine schlanke Installation

Für Tests reicht eine Standardinstallation mit Helm. Sie bringt Prometheus, Alertmanager, kube-state-metrics, node-exporter und Grafana mit.

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring prometheus-community/kube-prometheus-stack -n monitoring --create-namespace

Nach der Installation erreichst du Grafana per Port-Forward oder Ingress. Das Standard-Login wird in den Secrets hinterlegt. Lege direkt eine Persistenz für Prometheus an, damit Daten Neustarts überleben. Für produktive Umgebungen definierst du Retention, Ressourcenlimits und Storage bewusst.

Scraping verstehen – vom Pod zur Metrik

Es gibt zwei Wege, Endpoints zu scrapen. Entweder über ServiceMonitor und PodMonitor oder über einfache Annotations an Services, wenn du keinen Operator nutzt. Mit Operator sieht das so aus:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: demo-svcmon
  namespace: app
spec:
  selector:
    matchLabels:
      app: demo
  namespaceSelector:
    matchNames: [app]
  endpoints:
    - port: http
      path: /metrics
      interval: 30s

Damit findet Prometheus den Service app/demo, ruft /metrics ab und schreibt die Zeitreihen in seine TSDB. Wichtig sind stabile Labels. Vermeide überflüssige Hohe Kardinalität wie frei kombinierte User-IDs im Label, sonst wächst die Datenmenge explosiv.

Erste PromQL-Abfragen – Schritt für Schritt

PromQL arbeitet mit Operatoren, Aggregationen und Funktionen auf Zeitreihen. Du rechnest häufig mit Rate über Counter und mit Quantilen über Histogramme.

CPU-Auslastung pro Node über 5 Minuten gleitend:

1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))

HTTP-Fehlerquote deiner App:

sum(rate(http_requests_total{job="demo",status=~"5.."}[5m]))
/
sum(rate(http_requests_total{job="demo"}[5m]))

p95 Latenz aus einem Histogramm:

histogram_quantile(0.95,
  sum by (le) (rate(http_request_duration_seconds_bucket{job="demo"}[5m]))
)

Nutze by und without, um nach namespace oder service zu gruppieren. So findest du schnell heraus, wo es brennt.

Dashboards in Grafana – verständlich aufbauen

Lege in Grafana eine Prometheus Datasource an und gib die URL deines Prometheus-Services an. Starte mit einem Cluster-Überblick: Nodes, Pods, CPU, Memory, Disk, Network. Ergänze für jede App ein Panel-Set mit Traffic, Fehlerquote, p95 Latenz und Sättigung. Verwende Variables wie namespace und service, damit ein Dashboard wiederverwendbar wird. Wähle klare Einheiten und Farben konsequent. Ein gutes Dashboard zeigt normal vs kaputt auf einen Blick.

Alerting – von der Metrik zur Benachrichtigung

Prometheus wertet Alerting Rules aus und sendet Treffer an den Alertmanager. Dieser leitet an Mail, Chat oder Pager weiter und kann gruppieren oder dämpfen.

Ein einfaches Beispiel für hohe Fehlerquote:

groups:
- name: app.rules
  rules:
  - alert: DemoHighErrorRate
    expr: |
      sum(rate(http_requests_total{job="demo",status=~"5.."}[5m]))
      /
      sum(rate(http_requests_total{job="demo"}[5m]))
      > 0.05
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "Demo Service hohe Fehlerquote"
      description: "Mehr als 5 Prozent 5xx in den letzten 10 Minuten."

Setze for so, dass Flattern ausbleibt. Ergänze Runbooks im description, damit das Team sofort weiß, was zu prüfen ist.

Logs, Traces und Korrelation – kurzer Überblick

Metriken zeigen was aus dem Ruder läuft. Logs erklären warum, Traces zeigen wo es hakt. Grafana kann mit Loki und Tempo alle drei verbinden. Wenn du Labels wie trace_id in Metriken und Logs verwendest, klickst du von Panel zu Logsuche oder Trace und bist schneller bei der Ursache.

Sicherheit, Ressourcen und Betrieb

Schütze die UIs von Prometheus, Alertmanager und Grafana mit Auth. Begrenze Retention auf das, was du wirklich brauchst. Plane Persistent Volumes für Prometheus und Requests/Limits für alle Monitoring-Pods. Prüfe regelmäßig Cardinality. Große Schuldige sind oft unlimitierte path oder user Labels. Dokumentiere Dashboards, Alerts und SLOs, damit neue Teammitglieder sofort anknüpfen können.

Dein Startplan

Installiere kube-prometheus-stack in einem eigenen Namespace. Aktiviere eine App-Metrik mit ServiceMonitor. Baue ein kleines App-Dashboard mit Traffic, Fehlern und p95. Lege zwei Alerts an: Fehlerquote und hohe Latenz. Prüfe Alert-Fluss bis zum Kanal. Danach erweiterst du schrittweise: Persistenz, SLO-Alerts und Teamspezifische Dashboards.

Fazit

Mit Prometheus und Grafana bekommst du in Kubernetes sichtbare Zustände, klare Alarme und bessere Entscheidungen. Wenn du saubere Labels, sinnvolle Retention und fokussierte Dashboards kombinierst, erkennst du Anomalien früh und löst sie, bevor Nutzer es merken. Starte klein, standardisiere, und wachse mit deinem Cluster – so bleibt dein Monitoring nützlich statt laut.