Prometheus-Grafana-Stack: Systemmetriken erfassen, speichern und visualisieren
Wenn Sie Anwendungen und Infrastruktur in der Cloud betreiben, ist ein kontinuierlicher Überblick über Auslastung, Verfügbarkeit und mögliche Störungen hilfreich. Ein Prometheus-Grafana-Stack kombiniert die Erfassung und Speicherung von Systemmetriken mit deren visueller Auswertung und bildet damit eine verbreitete Grundlage für das Monitoring von Kubernetes-Clustern, Servern und Cloud-Anwendungen.
Was ist ein Prometheus-Grafana-Stack?
Ein Prometheus-Grafana-Stack ist eine verbreitete Open-Source-Lösung für Cloud-Native-Monitoring. Prometheus sammelt Metriken im Pull-Verfahren und speichert sie als Zeitreihen, während Grafana diese Daten in anpassbaren Dashboards visualisiert. Gemeinsam ermöglichen beide Werkzeuge Echtzeit-Einblicke in Performance und Kapazität sowie die frühzeitige Erkennung von Störungen in komplexen Infrastrukturen und Anwendungen.
Im Kontext der Cloud-Observability konzentriert sich Prometheus vor allem auf Metriken wie CPU-Auslastung, Speicherverbrauch oder Anfragezeiten. Für eine umfassendere Analyse werden häufig zusätzlich Logs (zum Beispiel mit Grafana Loki) und Traces (zum Beispiel mit Grafana Tempo) betrachtet. Dadurch lassen sich Systemzustände überwachen, Fehlerursachen analysieren und Zusammenhänge zwischen verschiedenen Komponenten einer Anwendung nachvollziehen.
IONOS CLOUD Managed Kubernetes ist die ideale Plattform für performante und hochskalierbare Container-Anwendungen – rund um die Uhr professionell betreut. Ab sofort profitieren Sie von einer automatischen CPU-Zuweisung für Dedicated Cores und kosteneffizienten vCPUs für weniger performance-intensive Workloads. So nutzen Sie Ihre Ressourcen optimal, senken Kosten und behalten jederzeit volle Kontrolle über Ihre Anwendungsperformance.
Prometheus-Architektur: Metriken über das Pull-Prinzip erfassen
Prometheus ist ein Open-Source-Monitoring-System mit einer integrierten Zeitreihendatenbank (Time Series Database, TSDB). Messwerte werden als Zeitreihen gespeichert. Eine Zeitreihe wird durch einen Metriknamen und optionale Labels identifiziert. Jedes Sample darin besteht aus einem Zeitstempel und einem Wert. Mithilfe der Labels lassen sich beispielsweise Server, Anwendungen, Regionen oder Kubernetes-Namespaces unterscheiden.
Prometheus arbeitet standardmäßig nach dem sogenannten Pull-Prinzip. Das bedeutet, dass nicht die überwachte Anwendung ihre Messwerte aktiv an Prometheus übermittelt. Stattdessen ruft Prometheus die Metriken regelmäßig selbst über HTTP-Endpunkte ab. Diese Endpunkte stellen ihre Daten üblicherweise in einem von Prometheus unterstützten Metrikformat bereit. Ist dies nicht der Fall, kommen Exporter zum Einsatz. Für Linux-Server wird beispielsweise häufig der Node Exporter verwendet. Er stellt Systemdaten wie CPU-Auslastung, Arbeitsspeicher, Dateisysteme und Netzwerkstatistiken als Metriken zur Verfügung. Prometheus ruft diese Werte anschließend in festgelegten Intervallen ab.
Welche Ziele überwacht werden sollen, wird über sogenannte Scrape-Jobs festgelegt. In einem klassischen Prometheus-Setup befindet sich diese Konfiguration in der Datei prometheus.yml. Ein einfacher Job für einen Node Exporter kann beispielsweise folgendermaßen aussehen:
global:
scrape_interval: 15s
scrape_configs:
- job_name: "node"
static_configs:
- targets:
- "node-exporter:9100"Prometheus ruft in diesem Beispiel alle 15 Sekunden die Metriken des angegebenen Exporters ab. Neben statisch eingetragenen Zielen unterstützt Prometheus verschiedene Service-Discovery-Mechanismen, über die Ziele dynamisch gefunden werden können.
Gerade in dynamischen Cloud- und Kubernetes-Umgebungen bietet das Pull-Modell Vorteile. Prometheus kontrolliert zentral, welche Ziele abgefragt werden, und kann anhand jedes Scrape-Vorgangs auch feststellen, ob ein Ziel überhaupt erreichbar ist. Dafür erzeugt Prometheus unter anderem die Metrik up. Verschwindet eine Instanz, verschwinden außerdem ihre regulär abgefragten Metriken, ohne dass zusätzlich veraltete Push-Daten bereinigt werden müssen.
Grafana integrieren: Prometheus als Data Source verwenden
Während Prometheus für das Sammeln, Speichern und Abfragen der Metriken zuständig ist, übernimmt Grafana deren Visualisierung. Die Prometheus-Datenquelle ist in Grafana bereits enthalten und muss nicht separat installiert werden. Beim Einsatz des kube-prometheus-stack wird sie außerdem normalerweise automatisch für die Verbindung mit der installierten Prometheus-Instanz provisioniert.
Falls Sie Grafana mit einer eigenen Prometheus-Instanz verbinden möchten, können Sie die Datenquelle alternativ folgendermaßen konfigurieren:
- Öffnen Sie in Grafana den Bereich „Connections“.
- Drücken Sie auf „Add new connection“, suchen Sie nach „Prometheus“ und wählen Sie „Prometheus data source“ aus.
- Klicken Sie auf „Add new data source“, tragen Sie die URL Ihres Prometheus-Servers ein und speichern Sie die Konfiguration. In einem Kubernetes-Cluster kann dies beispielsweise die interne Service-Adresse des Prometheus-Dienstes sein.
Die Daten werden anschließend über PromQL, die Abfragesprache von Prometheus, ausgewertet. Eine PromQL-Abfrage kann beispielsweise die CPU-Auslastung eines Servers berechnen oder den Speicherverbrauch mehrerer Pods miteinander vergleichen. Grafana bietet dafür verschiedene Visualisierungstypen. Für Infrastruktur-Monitoring sind insbesondere folgende Panels relevant:
| Visualisierung | Darstellung | Typischer Anwendungsfall |
|---|---|---|
| Time series | Werte im Zeitverlauf | CPU, RAM, Netzwerktraffic, Request-Raten |
| Stat | Einzelner aktueller oder aggregierter Wert | CPU-Last, aktive Pods, Antwortzeit |
| Gauge | Wert innerhalb eines definierten Bereichs | CPU- oder Speicherauslastung in Prozent |
Prometheus und Grafana mit Helm in Kubernetes einrichten
Für Kubernetes ist der kube-prometheus-stack der Prometheus Community ein verbreiteter Einstieg. Das Helm-Chart stellt unter anderem Prometheus, Alertmanager, Grafana, den Prometheus Operator sowie vorkonfigurierte Monitoring-Regeln und Dashboards bereit. Helm und Prometheus Operator sind dabei keine konkurrierenden Installationswege: Das Helm-Chart installiert und konfiguriert den Operator als Bestandteil des Stacks.
Alternativ lässt sich der Stack auch über Docker Compose mit separaten Containern für Prometheus, Grafana und Alertmanager betreiben.
Schritt 1: Prometheus und Alertmanager installieren
Fügen Sie zunächst das Helm-Repository der Prometheus Community hinzu und installieren Sie anschließend den Stack:
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm upgrade --install monitoring \
prometheus-community/kube-prometheus-stack \
--namespace monitoring \
--create-namespaceDurch upgrade --install kann derselbe Befehl sowohl für eine Erstinstallation als auch für spätere Aktualisierungen verwendet werden. Das Chart bringt neben Prometheus auch den Alertmanager sowie verschiedene Komponenten für das Kubernetes-Monitoring mit.
Das Chart ist zusätzlich als OCI-Artefakt verfügbar. Alternativ zur Installation über das Helm-Repository kann es direkt aus der GitHub Container Registry bezogen werden.
Schritt 2: Scrape-Jobs konfigurieren
Bei einer Standalone- oder Docker-Installation werden Scrape-Ziele direkt über scrape_configs in der prometheus.yml definiert. Bei einem Kubernetes-Deployment mit Prometheus Operator sollten Sie diese Datei dagegen normalerweise nicht manuell bearbeiten. Stattdessen erzeugt der Operator die Prometheus-Konfiguration aus Kubernetes-Ressourcen wie ServiceMonitor und PodMonitor. Ein ServiceMonitor beschreibt beispielsweise, welche Services Prometheus anhand ihrer Labels erkennen und überwachen soll.
Ein einfaches Beispiel kann folgendermaßen aussehen:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: example-app
namespace: monitoring
labels:
release: monitoring
spec:
selector:
matchLabels:
app: example-app
endpoints:
- port: metrics
path: /metrics
interval: 15sIn diesem Beispiel überwacht Prometheus einen Kubernetes-Service mit dem Label app: example-app und ruft dessen Metriken alle 15 Sekunden ab.
Beim kube-prometheus-stack ist relevant, welche Labels der Prometheus-Instanz für die Auswahl von ServiceMonitor-Ressourcen zugewiesen sind. Bei einem Helm-Release mit dem Namen monitoring wird hierfür standardmäßig das Release-Label release: monitoring verwendet.
Bei Anwendungen in anderen Namespaces sollten Sie prüfen, ob die Prometheus-Instanz die entsprechenden ServiceMonitor-Ressourcen berücksichtigt. Entscheidend sind die im Prometheus-Objekt gesetzten Selektoren für Labels und Namespaces. Je nach Konfiguration können dafür Anpassungen an den Helm-Werten des kube-prometheus-stack erforderlich sein.
Schritt 3: Grafana öffnen und den Admin-Zugang konfigurieren
Grafana wird bei Verwendung des kube-prometheus-stack zusammen mit dem übrigen Monitoring-Stack installiert. Seit Chart-Version 79.0.0 wird kein allgemein bekanntes Standardpasswort mehr verwendet. Wird kein eigenes Passwort angegeben, erzeugt das Chart stattdessen ein zufälliges Admin-Passwort und speichert dieses in einem Kubernetes Secret.
Die vorhandenen Grafana-Ressourcen können Sie mit folgendem Befehl anzeigen:
kubectl get secret -n monitoring \
-l app.kubernetes.io/name=grafanaAnschließend können Sie das in diesem Secret gespeicherte admin-password auslesen:
kubectl get secret monitoring-grafana -n monitoring -o jsonpath="{.data.admin-password}" | base64 -dFür produktive Umgebungen sollten Sie das Admin-Passwort nicht automatisch generieren lassen, sondern ein eigenes Passwort oder ein bestehendes Kubernetes Secret verwenden. Beim kube-prometheus-stack lässt sich letzteres beispielsweise über die Helm-Option grafana.admin.existingSecret konfigurieren.
Für einen lokalen Zugriff auf Grafana können Sie den Grafana-Service außerdem über kubectl port-forward erreichbar machen. Lassen Sie sich dazu zunächst den konkreten Servicenamen anzeigen:
kubectl get svc -n monitoringDanach leiten Sie den Grafana-Port folgendermaßen auf Ihren Rechner weiter:
kubectl port-forward -n monitoring svc/monitoring-grafana 3000:80Grafana ist anschließend lokal über Port 3000 erreichbar. Prüfen Sie dort unter den Data Sources, ob die Prometheus-Verbindung wie gewünscht eingerichtet ist.
Schritt 4: Standard-Dashboards verwenden und erweitern
Der kube-prometheus-stack enthält bereits eine Sammlung von Kubernetes-Dashboards und Prometheus-Regeln. Dadurch stehen unmittelbar nach dem Setup unter anderem Ansichten zu Nodes, Pods und Kubernetes-Systemkomponenten zur Verfügung.
Zusätzliche Dashboards können Sie über „Dashboards“ → „New“ → „Import“ in Grafana importieren. Die Grafana-Dashboard-Bibliothek bietet beispielsweise fertige Ansichten für Kubernetes-Pods, Namespaces oder den API-Server. Bevor Sie ein fremdes Dashboard produktiv einsetzen, sollten Sie jedoch prüfen, welche Metriken, Labels und Data Sources darin erwartet werden. Nicht jedes Dashboard passt ohne Anpassungen zur eigenen Kubernetes- oder Prometheus-Konfiguration.
Alerting mit Prometheus und Alertmanager
Monitoring ist besonders dann hilfreich, wenn kritische Zustände nicht erst in einem Dashboard entdeckt werden müssen. Prometheus unterstützt deshalb Alerting Rules, deren Bedingungen ebenfalls mit PromQL formuliert werden.
Beim Einsatz des kube-prometheus-stack mit dem Prometheus Operator werden Alerting Rules üblicherweise als PrometheusRule-Custom-Resources definiert. Diese Ressourcen enthalten die PromQL-Bedingungen, anhand derer Prometheus kritische Zustände erkennt. Eine Regel kann beispielsweise auslösen, wenn die durchschnittliche CPU-Auslastung einer Instanz länger als zehn Minuten über 85 Prozent liegt:
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: infrastructure-alerts
namespace: monitoring
labels:
release: monitoring
spec:
groups:
- name: infrastructure
rules:
- alert: HighCPUUsage
expr: >
100 * (
1 - avg by (instance)
(rate(node_cpu_seconds_total{mode="idle"}[5m]))
) > 85
for: 10m
labels:
severity: warning
annotations:
summary: "Hohe CPU-Auslastung auf {{ $labels.instance }}"Das Label release: monitoring stellt sicher, dass die Regel der zuvor installierten Prometheus-Instanz aus dem Helm-Release monitoring zugeordnet wird. Die Angabe for: 10m verhindert, dass bereits eine sehr kurze Lastspitze den Alert unmittelbar auslöst. Prometheus betrachtet den Alert zunächst als ausstehend und setzt ihn erst auf den Status firing, wenn die Bedingung über den angegebenen Zeitraum bestehen bleibt.
Technisch übernimmt dabei Prometheus die Auswertung der Alarmbedingung. Der Alertmanager erkennt den kritischen Zustand also nicht selbst, sondern erhält die von Prometheus ausgelösten Alerts. Anschließend kann er diese gruppieren, Duplikate unterdrücken, Benachrichtigungen zeitweise stummschalten und abhängig von Labels an unterschiedliche Empfänger weiterleiten.
Als Empfänger unterstützt Alertmanager unter anderem E-Mail, Chat-Systeme und On-Call-Dienste. So können beispielsweise Warnungen an Slack oder kritische Produktionsalarme an PagerDuty weitergeleitet werden. Dadurch müssen DevOps-Teams Dashboards nicht permanent manuell beobachten. Stattdessen werden sie gezielt informiert, wenn definierte Schwellenwerte oder andere PromQL-Bedingungen tatsächlich erfüllt sind.
Fazit
Prometheus und Grafana decken gemeinsam die zentralen Schritte des metrischen Infrastruktur-Monitorings ab. Prometheus erfasst und speichert Messwerte und ermöglicht deren Auswertung mit PromQL, während Grafana daraus übersichtliche Dashboards erstellt. Alerting Rules und Alertmanager ergänzen den Stack um automatisierte Benachrichtigungen bei kritischen Zuständen.
Für Kubernetes bietet sich der kube-prometheus-stack als Einstieg an, da er Prometheus, Grafana, Alertmanager und den Prometheus Operator in einem Helm-Deployment zusammenführt. Durch ServiceMonitor- und PodMonitor-Ressourcen lässt sich das Monitoring anschließend dynamisch an neue Anwendungen und Services im Cluster anpassen.