Kubernetes Monitoring mit Grafana und Prometheus macht den Zustand von Cluster, Nodes und Anwendungen sichtbar. Mit dem Helm-Chart kube-prometheus-stack installierst du eine erprobte Basis aus Prometheus, Grafana und Alertmanager. Danach prüfst du gezielt Ressourcen, Verfügbarkeit und Fehler statt nur auf Symptome zu reagieren.
Stand: 13.10.2026
Auf einen Blick
- Prometheus sammelt Metriken per Pull-Verfahren und wertet sie mit PromQL aus.
- Der
kube-prometheus-stackbündelt die üblichen Kubernetes-Komponenten in einem Helm-Release. - Grafana visualisiert Metriken; Alarmregeln und Empfänger konfigurierst du bewusst getrennt.
- Starte mit wenigen, handlungsfähigen Alarmen und sichere den Zugriff auf die Oberflächen.
Warum braucht Kubernetes Monitoring?
Pods werden neu geplant, Deployments skalieren und einzelne Nodes können ausfallen. Daher reicht es nicht, nur den Status einzelner Container zu prüfen. Kubernetes Monitoring verbindet Infrastrukturmetriken mit Signalen aus deinen Workloads.
Beobachte zuerst das, was konkrete Folgen hat: nicht verfügbare Pods, fehlende Kapazität, wiederholte Neustarts und anhaltend hohe Latenzen. So wird aus vielen Messwerten eine Grundlage für Entscheidungen. Einen Überblick über die Grundlagen des Orchestrators findest du auch in Kubernetes und Minikube einfach erklärt.
Welche Aufgaben übernehmen Prometheus und Grafana?
| Komponente | Aufgabe | Beispiel |
|---|---|---|
| Prometheus | Sammelt, speichert und fragt Zeitreihen ab | CPU-, Speicher- und HTTP-Metriken |
| Alertmanager | Gruppiert, unterdrückt und leitet Prometheus-Alarme weiter | Warnung bei nicht verfügbaren Replikas |
| Grafana | Zeigt Datenquellen in Dashboards und kann eigene Alarmierung ausführen | Cluster- und Workload-Ansichten |
| kube-state-metrics | Stellt den Zustand von Kubernetes-Objekten als Metriken bereit | Gewünschte und verfügbare Replicas |
Prometheus entdeckt Ziele in Kubernetes über Service Discovery. Er sammelt Metriken jedoch nur dort, wo du passende Scrape-Konfigurationen oder die vom Operator bereitgestellten Ressourcen einrichtest. Ein Exporter allein ersetzt keine sinnvolle Auswahl von Metriken und Alarmen.
Kubernetes Monitoring mit Grafana und Prometheus installieren
Die folgenden Schritte setzen einen erreichbaren Cluster, kubectl mit passendem Kontext und Helm voraus. Installiere das Monitoring in einem eigenen Namespace. Dadurch bleiben Ressourcen und Berechtigungen nachvollziehbar.
- Helm-Repository hinzufügen und lokale Chart-Informationen aktualisieren.
- Namespace anlegen.
- Stack mit einem eindeutig benannten Release installieren.
- Pods und Services prüfen, bevor du Grafana öffnest.
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
kubectl create namespace monitoring
helm upgrade --install monitoring prometheus-community/kube-prometheus-stack --namespace monitoring
kubectl get pods -n monitoring
Der Chart installiert unter anderem Prometheus, Alertmanager, Grafana, kube-state-metrics und einen Node Exporter. Welche Ressourcen im Detail entstehen, hängt von der Chart-Version und deinen Values ab. Für wiederholbare Änderungen speicherst du eigene Einstellungen in einer Values-Datei und übergibst sie mit -f values.yaml.
Wie prüfst du die Installation sicher?
Warte nicht nur auf einen erfolgreichen Helm-Befehl. Prüfe zunächst, ob die Pods im Namespace bereit sind und ob die Services vorhanden sind. Erst dann leitest du Grafana lokal weiter.
kubectl get pods -n monitoring
kubectl get svc -n monitoring
kubectl port-forward -n monitoring svc/monitoring-grafana 3000:80
Rufe anschließend http://localhost:3000 auf. Der Name des Grafana-Service enthält den Release-Namen; bei einem anderen Release ersetzt du monitoring entsprechend. Das anfängliche Admin-Passwort liegt in einem Kubernetes-Secret. Lies es nur für den lokalen Erstzugriff aus und ändere es danach.
kubectl get secret -n monitoring monitoring-grafana -o jsonpath='{.data.admin-password}' | base64 -d
Für einen dauerhaften Zugang brauchst du TLS, Authentifizierung und eine bewusst konfigurierte Ingress-Regel. Veröffentliche Prometheus und Alertmanager nicht ungeschützt im Internet. Wie du Zugänge und Ingresses planst, ergänzt der Beitrag Traefik ExternalDNS in Kubernetes.
Welche Dashboards und Metriken sind am Anfang sinnvoll?
Die mit dem Stack gelieferten Dashboards geben meist einen guten Startpunkt. Prüfe zunächst Cluster- und Node-Auslastung, dann Namespaces und einzelne Workloads. Passe Ansichten an die Services an, die für dich wichtig sind, statt wahllos Dashboard-IDs aus dem Internet zu importieren.
- Cluster: verfügbare Nodes, nicht planbare Pods und Ressourcen-Requests im Verhältnis zur Kapazität.
- Workloads: gewünschte gegen verfügbare Replicas, Restarts und Status wartender Pods.
- Anwendungen: Fehlerrate, Latenz und Durchsatz aus eigenen Prometheus-Metriken.
- Speicher: Füllstand und Fehler deiner Persistent Volumes, falls sie für den Dienst kritisch sind.
Viele Anwendungen liefern keine Metriken automatisch. Instrumentiere sie mit einer Prometheus-Client-Bibliothek oder nutze einen geeigneten Exporter. Über Helm lassen sich zusätzliche Anwendungen und ihre Konfiguration versionskontrolliert ausrollen; dazu passt Helm Charts erklärt.
Wie richtest du Alarme ohne Alarmflut ein?
Ein Alarm ist nur dann nützlich, wenn jemand ihn bewerten oder beheben kann. Beginne deshalb mit wenigen Regeln, etwa nicht verfügbaren Replikas, dauerhaft hohem Ressourcenverbrauch und einer ausbleibenden Metrik. Ergänze eine klare Beschreibung und einen Link zu einem Runbook.
Alertmanager übernimmt Routing, Gruppierung und Unterdrückung von Prometheus-Alarmen. Grafana bietet ebenfalls ein eigenes Alerting. Entscheide pro Regel bewusst, wo sie gepflegt wird; doppelte Regeln erzeugen doppelte Benachrichtigungen. Teste außerdem Empfänger und Eskalationswege, bevor du sie produktiv nutzt.
kubectl get prometheusrules -n monitoring
kubectl get alertmanagerconfigs -n monitoring
Ein einzelner hoher CPU-Wert ist oft kein Notfall. Kombiniere Grenzwerte mit einer Dauer und dem Kontext des Dienstes. So vermeidest du Benachrichtigungen bei kurzen Lastspitzen und erkennst trotzdem echte Kapazitätsprobleme früh.
Welche Sicherheits- und Betriebsregeln gelten?
Monitoring-Daten können Infrastrukturdetails, Namen von Workloads oder interne Endpunkte offenlegen. Beschränke daher Zugriffe mit Kubernetes-RBAC und Grafana-Rollen. Verschlüssele externe Verbindungen mit TLS und speichere Zugangsdaten nicht in Git-Repositories.
Plane zudem Aufbewahrung und Speicherbedarf. Prometheus ist für lokale Zeitreihenabfragen ausgelegt; eine sehr lange Historie benötigt eine passende Architektur und zusätzlichen Speicher. Sichere wichtige Konfigurationsdateien und prüfe vor Chart-Upgrades die Release Notes sowie deine Values. Für die generelle Absicherung von Containern hilft auch Docker Security: Container sicher betreiben.
Fazit
Kubernetes Monitoring mit Grafana und Prometheus schafft Transparenz, wenn du Installation, Zugriffe und Alarmierung bewusst konfigurierst. Der kube-prometheus-stack spart beim Einstieg Zeit. Entscheidend bleiben aber relevante Metriken, getestete Alarme und ein sicherer Betrieb.
Quellen
- Prometheus: Getting started
- Prometheus Operator: Introduction
- prometheus-community: kube-prometheus-stack
- Grafana-Dokumentation
Häufige Fragen
Prometheus sammelt und speichert Zeitreihen-Metriken. Über Kubernetes Service Discovery findet es konfigurierte Ziele; mit PromQL lassen sich die Daten abfragen und Alarmregeln auswerten.
Der Helm-Chart bündelt üblicherweise Prometheus, Alertmanager, Grafana, kube-state-metrics und einen Node Exporter. Die konkreten Ressourcen und Einstellungen hängen von Chart-Version und Values ab.
Leite den Grafana-Service im Monitoring-Namespace mit kubectl port-forward lokal weiter. Der Service-Name enthält normalerweise den Helm-Release-Namen, zum Beispiel monitoring-grafana.
Lege für jede Regel einen klaren Pflegeort fest. Prometheus-Regeln werden über Alertmanager weitergeleitet; Grafana bietet eigenes Alerting. Doppelte Regeln führen sonst zu doppelten Benachrichtigungen.
2 Pingbacks