Kubernetes Monitoring bedeutet in der Praxis fast immer denselben Stapel: Prometheus sammelt Metriken, Grafana zeigt sie an, Alertmanager schickt Alarme, wenn etwas aus dem Ruder läuft. Am schnellsten kommst du dorthin über das Helm-Chart kube-prometheus-stack, das alle drei Komponenten zusammen mit den nötigen Exportern und passenden Grundeinstellungen ausrollt, statt dass du jedes Teil einzeln zusammenbaust.
Ich betreibe Kubernetes-Cluster in Produktion und habe das Kubernetes-Praxisbuch bei Rheinwerk geschrieben (2024). Monitoring ist bei mir keine Kür, sondern die Voraussetzung dafür, dass ich überhaupt weiß, ob ein Cluster gesund ist, bevor ein Kunde es merkt. Alle meine Beiträge rund um den Betrieb von Kubernetes-Clustern findest du auf der Seite Kubernetes.
Wichtig ist dabei, drei Aufgaben auseinanderzuhalten, die im Alltag gern zu „Monitoring" verschmelzen. Die Erfassung holt Metriken ein und speichert sie: Das macht ausschließlich Prometheus, über seine Scrape-Konfiguration. Das Alerting wertet diese gespeicherten Daten gegen Regeln aus und meldet Verstöße, dafür sind die Alertregeln in Prometheus und der Alertmanager zuständig. Die Visualisierung liest die gespeicherten Daten nur noch aus, und das ist Grafanas Rolle. Grafana ist damit kein Teil der Scrape-Logik: Fällt Grafana aus, sammelt Prometheus weiter und Alarme laufen weiter.
Was Kubernetes Monitoring überhaupt abdecken muss
Drei Ebenen brauchen Aufmerksamkeit, und alle drei landen bei einem guten Monitoring-Aufbau in derselben Zeitreihendatenbank. Die Node-Ebene zeigt dir CPU, Memory, Festplatte und Netzwerk der zugrunde liegenden Maschinen. Die Kubernetes-Ebene zeigt den Zustand der Objekte selbst: Wie viele Replikas eines Deployments laufen tatsächlich, wie oft startet ein Pod neu, wie viele Nodes sind erreichbar. Die Anwendungsebene schließlich zeigt, was für deine Nutzer zählt, etwa Antwortzeiten, Fehlerraten oder die Länge einer Warteschlange.
Prometheus deckt alle drei Ebenen über verschiedene Quellen ab. Node Exporter liefert die Hardware- und Betriebssystemmetriken jeder Maschine. Kube State Metrics übersetzt den Zustand von Kubernetes-Objekten wie Deployments, Pods und Nodes in Metriken, die Prometheus verstehen kann. Deine eigenen Anwendungen liefern ihre Metriken selbst, wenn sie ein Prometheus-kompatibles Format über einen HTTP-Endpunkt bereitstellen, meist unter dem Pfad /metrics.
kube-prometheus-stack per Helm ausrollen
Statt Prometheus, Grafana, Alertmanager, Node Exporter und Kube State Metrics einzeln zu installieren und miteinander zu verdrahten, nutze ich in allen meinen Clustern das Community-Helm-Chart kube-prometheus-stack. Es bringt sinnvolle Grundeinstellungen mit, installiert den Prometheus-Operator gleich mit, und liefert bereits ein Set an Standard-Dashboards und Alertregeln für den Cluster selbst.
# values.yaml für kube-prometheus-stack
grafana:
adminPassword: "wird-per-secret-ueberschrieben"
prometheus:
prometheusSpec:
retention: 15d
resources:
requests:
cpu: 250m
memory: 512Mi
limits:
memory: 1Gi
storageSpec:
volumeClaimTemplate:
spec:
resources:
requests:
storage: 20Gi
alertmanager:
alertmanagerSpec:
resources:
requests:
cpu: 50m
memory: 64Mi
Rollst du das Chart über ArgoCD statt über ein manuelles helm install aus, landet diese values.yaml in Git und wird bei jeder Änderung automatisch synchronisiert. Das Passwort für Grafana gehört dabei in ein per SOPS verschlüsseltes Secret, niemals im Klartext in die Werte-Datei. Nach dem Rollout meldet dir kubectl get pods -n monitoring die laufenden Komponenten, und ein Port-Forward auf den Grafana-Service zeigt dir sofort die mitgelieferten Dashboards für Nodes, Namespaces und einzelne Workloads.
Eigene Anwendungen mit einem ServiceMonitor anbinden
Der Prometheus-Operator, den kube-prometheus-stack mitbringt, ersetzt das manuelle Bearbeiten der Prometheus-Konfiguration durch ein eigenes Kubernetes-Objekt: den ServiceMonitor. Statt eine ConfigMap zu editieren und den Prometheus-Pod neu zu starten, legst du für jede Anwendung, die überwacht werden soll, einfach ein solches Objekt an, und der Operator sorgt dafür, dass Prometheus die passende Scrape-Konfiguration übernimmt.
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: shop-api
namespace: shop
labels:
release: kube-prometheus-stack
spec:
selector:
matchLabels:
app: shop-api
endpoints:
- port: metrics
path: /metrics
interval: 30s
Wichtig ist das Label release, das dem Namen deiner Helm-Installation entsprechen muss: Das Chart setzt den serviceMonitorSelector der erzeugten Prometheus-Instanz standardmäßig auf genau dieses Label, und ohne passenden Wert wird dein ServiceMonitor schlicht nicht ausgewählt. Der selector verweist auf die Labels des Kubernetes-Service vor deiner Anwendung, nicht auf den Pod direkt, und endpoints.port muss den benannten Port aus deinem Service-Manifest treffen. Ob Prometheus die Anwendung tatsächlich abfragt, prüfst du in der Prometheus-Oberfläche unter Status und Targets, dort taucht dein ServiceMonitor mit dem letzten Scrape-Status auf. Ein ServiceMonitor ändert ausschließlich die Erfassung; ein Dashboard entsteht dadurch noch nicht, das baust du danach in Grafana auf den neu vorhandenen Metriken auf.
Die Alerts, die in Produktion tatsächlich zählen
Ein frisch installierter kube-prometheus-stack bringt bereits viele Alertregeln für den Cluster mit, etwa für ausgefallene Nodes oder einen vollen etcd-Speicher. Für die eigenen Anwendungen lohnt es sich, wenige, aber aussagekräftige Regeln selbst zu ergänzen, statt alles zu überwachen, was sich messen lässt. In meinen Clustern haben sich vor allem diese Fälle als wirklich alarmwürdig erwiesen: ein Deployment mit weniger laufenden als gewünschten Replikas über mehrere Minuten, ein Pod, der wiederholt neu startet, ein Namespace, der kurz vor seinem Ressourcenlimit steht, und eine Fehlerrate, die über einen klar definierten Schwellwert steigt.
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: shop-api-alerts
namespace: shop
labels:
release: kube-prometheus-stack
spec:
groups:
- name: shop-api
rules:
- alert: ShopApiReplicasNiedrig
expr: kube_deployment_status_replicas_available{deployment="shop-api"} < 2
for: 5m
labels:
severity: warning
annotations:
summary: "Weniger als zwei laufende Replikas bei shop-api"
Jede Regel braucht ein for, damit ein kurzer Ausschlag nicht sofort einen Alarm auslöst, und eine klare summary, die im Alarm selbst schon sagt, was los ist, ohne dass jemand erst ein Dashboard öffnen muss. Zu viele Alerts mit zu niedriger Schwelle führen dazu, dass echte Probleme im Rauschen untergehen, das ist in meinen Projekten der häufigste Fehler bei neu aufgesetztem Monitoring.
Alertmanager an Mail oder Chat anbinden
Alertmanager selbst versendet keine Alarme automatisch, er braucht dafür einen Receiver, der festlegt, wohin eine Benachrichtigung geht. Für kleinere Teams reicht oft ein einzelner Chat-Webhook, für größere Umgebungen lohnt sich eine Aufteilung nach Schweregrad, damit ein reiner Hinweis nicht denselben Kanal erreicht wie ein Alarm mitten in der Nacht.
route:
receiver: chat-standard
routes:
- matchers:
- severity="critical"
receiver: chat-dringend
receivers:
- name: chat-standard
webhook_configs:
- url: "https://beispiel-webhook.invalid/standard"
- name: chat-dringend
webhook_configs:
- url: "https://beispiel-webhook.invalid/dringend"
Diese Konfiguration landet in kube-prometheus-stack unter dem Schlüssel alertmanager.config in der values.yaml, die Webhook-URLs gehören wieder in ein verschlüsseltes Secret. Teste die Anbindung nach jeder Änderung mit einem harmlosen Testalarm, bevor du dich auf sie verlässt, ein Alertmanager, der still vor sich hin schweigt, ist gefährlicher als gar kein Monitoring, weil er ein falsches Sicherheitsgefühl erzeugt.
Ressourcenbedarf und Aufbewahrung auf kleinen Clustern
Prometheus hält seine Zeitreihen im Arbeitsspeicher, bevor sie auf die Festplatte geschrieben werden, deshalb wächst der Speicherbedarf mit der Anzahl an Metriken und Labels, nicht nur mit der Clustergröße. Auf meinen kleineren Hetzner-Clustern reichen für Prometheus meist 512 Mebibyte als Request und rund ein Gigabyte als Limit, bei deutlich mehr überwachten Anwendungen wächst das entsprechend, und du solltest den tatsächlichen Verbrauch über das eigene Monitoring beobachten, statt zu raten.
Die Aufbewahrungsdauer, retention in der values.yaml, bestimmt, wie lange Prometheus Daten lokal vorhält, bevor sie überschrieben werden. Zwei bis vier Wochen reichen für die meisten Fragestellungen im Betrieb aus, für längere Trendanalysen lohnt sich eine externe Anbindung, etwa an ein Objektspeicher-kompatibles Langzeitarchiv, statt die lokale Aufbewahrung immer weiter zu erhöhen. Der Speicherplatz für die Zeitreihen selbst hängt direkt an dieser Einstellung und sollte großzügig statt knapp bemessen sein, ein volles Volume lässt Prometheus schlicht keine neuen Daten mehr schreiben.
Häufige Fragen
Wie viel Arbeitsspeicher braucht Prometheus?
Das hängt stark von der Anzahl der Metriken und Labels ab, nicht nur von der Clustergröße. Für kleinere Cluster mit überschaubarer Anzahl Anwendungen reichen oft schon wenige hundert Megabyte, größere Umgebungen mit vielen Labels und kurzen Scrape-Intervallen brauchen deutlich mehr. Beobachte den tatsächlichen Verbrauch des Prometheus-Pods selbst über sein eigenes Dashboard.
Wie lange sollte ich Metriken aufbewahren?
Für den täglichen Betrieb reichen zwei bis vier Wochen fast immer aus. Willst du saisonale Trends über Monate vergleichen, lohnt sich eine externe Langzeitablage statt einer sehr langen lokalen Aufbewahrung, die vor allem Speicherplatz und Ressourcen kostet.
Prometheus selbst betreiben oder eine gehostete Lösung nutzen?
Beides hat seinen Platz. Selbst betrieben bleibt jede Metrik im eigenen Cluster, was mir bei Kunden mit Datenschutzanforderungen wichtig ist, kostet aber Betriebsaufwand für Updates und Storage. Eine gehostete Lösung nimmt dir diesen Aufwand ab, bindet dich aber an einen weiteren externen Dienst und dessen Preismodell.
Wie überwache ich eigene Anwendungen zusätzlich zum Cluster?
Über einen ServiceMonitor, der auf den Service deiner Anwendung zeigt, vorausgesetzt die Anwendung liefert selbst Metriken in einem Prometheus-kompatiblen Format über einen HTTP-Endpunkt. Für Anwendungen, die das nicht von sich aus können, gibt es passende Exporter, die die Übersetzung übernehmen.
Brauche ich zusätzlich Logging neben dem Metriken-Monitoring?
Ja, Metriken zeigen dir, dass etwas nicht stimmt, Logs zeigen dir meist erst, warum. Ich kombiniere Prometheus deshalb in jedem Cluster mit einem Logging-Stack, mehr dazu in Kubernetes Logging mit Loki und Grafana.
Wie du weitermachst
Sobald Monitoring läuft, lohnt sich der Blick auf automatische Skalierung: In Kubernetes Autoscaling mit HPA zeige ich, wie du die gerade gesammelten Metriken auch für automatische Skalierungsentscheidungen nutzt. Und wenn du wissen willst, ob deine Anwendungen überhaupt gesund starten, bevor Prometheus sie das erste Mal misst, hilft dir Liveness und Readiness Probes erklärt.
Mein Vorschlag: Installiere kube-prometheus-stack zuerst mit den mitgelieferten Standardwerten in einem Test-Namespace, sieh dir die vorhandenen Dashboards an, und ergänze erst danach einen ServiceMonitor für die erste eigene Anwendung. Details zum Chart selbst findest du im GitHub-Repository von kube-prometheus-stack, die Grundlagen zu PromQL und der Prometheus-Architektur stehen in der offiziellen Prometheus-Dokumentation.
Ausführlich mit allen Beispielen, von Node Exporter bis zum eigenen Grafana-Dashboard, steht das in Kapitel 8.4 meines Kubernetes-Praxisbuchs bei Rheinwerk.
