# 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. ## Prometheus-Architektur: Metriken über das Pull-Prinzip erfassen Prometheus ist ein [Open-Source](https://www.ionos.de/digitalguide/server/knowhow/was-ist-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](https://www.ionos.de/digitalguide/server/knowhow/was-ist-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](https://www.ionos.de/digitalguide/hosting/hosting-technik/was-ist-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](https://www.ionos.de/digitalguide/server/knowhow/cpu/)-Auslastung, [Arbeitsspeicher](https://www.ionos.de/digitalguide/server/knowhow/was-ist-ein-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: ```yaml 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: 1. Öffnen Sie in Grafana den Bereich „**Connections**“. 2. Drücken Sie auf „**Add new connection**“, suchen Sie nach „Prometheus“ und wählen Sie „**Prometheus data source**“ aus. 3. 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. Hinweis Alternativ lässt sich der Stack auch über [Docker Compose](https://www.ionos.de/digitalguide/server/konfiguration/docker-compose-tutorial/) 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: ```bash 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-namespace ``` Durch `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. Hinweis 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](https://github.com/orgs/prometheus-community/packages/container/package/charts%2Fkube-prometheus-stack "GitHub Container Registry: kube-prometheus-stack") 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: ```yaml 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: 15s ``` In 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. Hinweis 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: ```bash kubectl get secret -n monitoring \ -l app.kubernetes.io/name=grafana ``` Anschließend können Sie das in diesem Secret gespeicherte `admin-password` auslesen: ```bash kubectl get secret monitoring-grafana -n monitoring -o jsonpath="{.data.admin-password}" | base64 -d ``` Hinweis Fü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: ```bash kubectl get svc -n monitoring ``` Danach leiten Sie den Grafana-Port folgendermaßen auf Ihren Rechner weiter: ```bash kubectl port-forward -n monitoring svc/monitoring-grafana 3000:80 ``` Grafana 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](https://www.ionos.de/digitalguide/server/konfiguration/kubernetes-node/), [Pods](https://www.ionos.de/digitalguide/server/konfiguration/kubernetes-pod/) 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](https://www.ionos.de/digitalguide/websites/web-entwicklung/was-ist-eine-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: ```yaml 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](https://www.ionos.de/digitalguide/websites/web-entwicklung/was-ist-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. This is a markdown version of: [https://www.ionos.de/digitalguide/server/konfiguration/prometheus-grafana-stack/](https://www.ionos.de/digitalguide/server/konfiguration/prometheus-grafana-stack/) for AI/LLM consumption.