Prometheus und Grafana überwachen Metriken vieler Server zentral

Wer nur wenige Server betreibt, merkt eine Überlastung oft selbst: Eine Seite lädt spürbar langsamer, ein Hintergrundjob braucht länger als sonst. Bei mehreren Dutzend unabhängigen Anwendungen fällt genau das niemandem mehr auf, bis sich ein Kunde meldet oder ein Dienst komplett ausfällt. Ein einfacher Verfügbarkeits-Check wie Uptime Kuma beantwortet nur, ob ein Server gerade erreichbar ist und ob sein Sicherheitszertifikat bald abläuft. Mehr nicht. Er sagt nichts darüber, wie stark die Antwortzeit einer Anwendung in den letzten drei Wochen gestiegen ist, wie voll eine Warteschlange kurz vor einem Absturz stand, oder welcher Server im Portfolio seinem Arbeitsspeicherlimit am nächsten kommt.

Prometheus und Grafana schließen diese Lücke. Prometheus ist eine quelloffene Software, die Kennzahlen wie CPU-Auslastung, Arbeitsspeicherverbrauch, Antwortzeiten und Fehlerraten in festen Abständen von jedem überwachten Server einsammelt und über Wochen hinweg als Zeitreihe speichert. Grafana ist das zugehörige, ebenfalls quelloffene Dashboard-Werkzeug, das diese gespeicherten Werte abfragt und als Verlaufsgrafik darstellt. Eine einzige Installation aus beiden Programmen überwacht ein ganzes Server-Portfolio zentral, ohne dass für jede einzelne Anwendung ein eigenes, oft kostenpflichtiges Beobachtungswerkzeug nötig wird.

Systemvoraussetzungen

Eine gemeinsame Prometheus- und Grafana-Installation kommt mit drei Bausteinen aus: dem Prometheus-Server selbst, Grafana für die Darstellung und mindestens einem Exporter je überwachtem Host. Die folgende Tabelle listet die aktuellen Versions- und Konfigurationsangaben laut den Release-Übersichten der jeweiligen GitHub-Repositories und der offiziellen Projektdokumentation, abgerufen am 26. August 2026.

Komponente	Version oder Anforderung	Zweck
Prometheus-Server (Image)	`prom/prometheus`, aktuell Version 3.14.0 (17. August 2026)	Fragt alle Ziele per Scraping ab, speichert die Werte als Zeitreihe und beantwortet PromQL-Abfragen
Grafana (Image)	`grafana/grafana`, aktuell Version 13.2.0 (18. August 2026)	Fragt Prometheus ab und zeigt die Verläufe als Dashboard
node_exporter (Image je Host)	`prom/node-exporter`, aktuell Version 1.12.1 (14. Juli 2026)	Liest CPU-, Arbeitsspeicher- und Festplattenwerte des Hosts aus und stellt sie im Prometheus-Textformat bereit
Docker Engine	ab Version 20.10 mit Compose-Plugin (`docker compose`)	Betrieb und automatischer Neustart der drei Container
Offene Ports	TCP 9090 (Prometheus), TCP 3000 (Grafana), TCP 9100 (node_exporter je Host)	Zugriff auf Weboberflächen und Metrik-Endpunkte
Persistente Datenverzeichnisse	Docker-Volumes auf `/prometheus` und `/var/lib/grafana`	Speichert die Zeitreihen-Datenbank und die Dashboard-Konfiguration über Container-Neustarts hinweg

Systemarchitektur

Prometheus holt sich seine Daten aktiv selbst, statt darauf zu warten, dass eine Anwendung sie schickt. Dieses Verfahren heißt Scraping, vom englischen "to scrape", zu Deutsch etwa abschöpfen: Der Prometheus-Server ruft in einem festen Intervall den Metrik-Endpunkt jeder überwachten Anwendung unter dem Pfad /metrics per HTTP auf und liest den aktuellen Wert jeder Kennzahl aus. Dieses Pull-Modell ist laut der eigenen Prometheus-Dokumentation das Standardverfahren der Software. Für kurzlebige Stapelverarbeitungsjobs, die selbst keinen dauerhaften Endpunkt betreiben können, gibt es zusätzlich einen optionalen Pushgateway als Ausnahme von der Regel.

Damit auch Server, die von Natur aus keine Prometheus-Sprache sprechen, überwacht werden können, läuft auf jedem Host zusätzlich ein sogenannter Exporter. Ein Exporter ist ein kleines, eigenständiges Zusatzprogramm, das Systemwerte ausliest und im Prometheus-Textformat auf einem eigenen Port bereitstellt. Der bekannteste Exporter heißt node_exporter, ein von der Prometheus-Organisation selbst gepflegtes Werkzeug für Hardware- und Betriebssystemkennzahlen von Linux- und Unix-Systemen. Er liefert unter anderem CPU-Zeit je Kern und Modus, Arbeitsspeicherbelegung, Festplattenauslastung, Netzwerkdurchsatz und Systemlast, standardmäßig über Port 9100.

flowchart TD
    A[Server 1 mit Anwendung und node_exporter] -->|Scrape alle 15 Sekunden| P[Ein gemeinsamer Prometheus Server]
    B[Server 2 mit Anwendung und node_exporter] -->|Scrape alle 15 Sekunden| P
    C[Server N mit Anwendung und node_exporter] -->|Scrape alle 15 Sekunden| P
    P --> D[Lokale Zeitreihen Datenbank auf der Festplatte]
    D --> E[Grafana fragt Prometheus per PromQL ab]
    E --> F[Dashboards zeigen CPU Arbeitsspeicher Latenz und Fehlerrate je Server]
    P --> G[Alerting Regeln werten dieselben Werte fortlaufend aus]
    G -->|Regel erfuellt| H[Alertmanager buendelt und leitet die Warnung weiter]
    H --> I[Benachrichtigungskanal fuer das zustaendige Team]

Mehrere Server laufen dabei über denselben Prometheus-Server. In der Konfigurationsdatei stehen alle Ziele, die zusammengehören, unter einem gemeinsamen job_name, aber mit jeweils eigenem Eintrag unter targets. Prometheus vergibt an jede erfasste Kennzahl automatisch ein instance-Label mit der Adresse des jeweiligen Ziels. So lässt sich in Grafana später nach einzelnen Servern filtern oder gruppieren, obwohl alle Werte in derselben Datenbank liegen. Zusätzliche eigene Label, etwa für Standort oder Umgebung, lassen sich in derselben Konfiguration ergänzen.

Für Warnungen wertet Prometheus dieselben gespeicherten Werte laufend gegen hinterlegte Regeln aus. Erfüllt eine Regel über die festgelegte Mindestdauer hinweg, schickt Prometheus die Warnung an eine eigene, separate Komponente namens Alertmanager. Der Alertmanager bündelt mehrere gleichzeitig eintreffende Warnungen, unterdrückt Duplikate und leitet das Ergebnis an den zuständigen Kanal weiter.

Schritt-für-Schritt-Umsetzung

Prometheus, Grafana und node_exporter per Docker Compose bereitstellen

Drei Dienste, eine Datei. Eine gemeinsame Compose-Datei startet Prometheus, Grafana und node_exporter mit den offiziellen Images der jeweiligen Projekte. Prometheus bekommt seine eigene Konfigurationsdatei als Bind-Mount, Prometheus und Grafana bekommen je ein persistentes Datenverzeichnis.

services:
  prometheus:
    image: prom/prometheus
    restart: unless-stopped
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana
    restart: unless-stopped
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"

  node-exporter:
    image: prom/node-exporter
    restart: unless-stopped
    ports:
      - "9100:9100"

volumes:
  prometheus_data:
  grafana_data:

docker compose up -d

Nach dem Start ist Prometheus unter http://server-adresse:9090 erreichbar, Grafana unter http://server-adresse:3000. Grafana legt beim ersten Aufruf ein Administratorkonto mit dem Standardpasswort admin an, das direkt danach geändert werden sollte. node_exporter läuft in dieser einfachen Fassung im selben Docker-Netzwerk und misst zunächst vor allem Werte des eigenen Containers; für vollständige Kennzahlen des dahinterliegenden Host-Systems braucht der Container zusätzliche Freigaben für Host-Netzwerk, Prozessliste und Dateisystem, wie sie die offizielle Dokumentation des Projekts für den produktiven Einsatz beschreibt.

Mehrere Server in der Datei prometheus.yml eintragen

Jeder überwachte Host bekommt einen eigenen node_exporter und einen eigenen Eintrag in der scrape_configs-Sektion von Prometheus. Mehrere Server derselben Art stehen dabei unter einem gemeinsamen job_name, jeweils als eigene Adresse in der targets-Liste.

scrape_configs:
  - job_name: node
    static_configs:
      - targets:
          - "server-a.internal:9100"
          - "server-b.internal:9100"
          - "server-c.internal:9100"
        labels:
          umgebung: produktion

Prometheus vergibt jedem der drei Ziele automatisch ein eigenes instance-Label mit der jeweiligen Adresse, obwohl alle drei unter demselben job_name stehen. Das zusätzliche Label umgebung steht danach an jeder Kennzahl aus dieser Gruppe und lässt sich in Grafana als Filter verwenden, etwa um Test- von Produktionsservern zu trennen. Nach jeder Änderung an dieser Datei muss der Prometheus-Container neu gestartet werden, damit die neuen Ziele erscheinen.

docker compose restart prometheus

Grafana als Datenquelle mit Prometheus verbinden

Datenquelle anlegen. In Grafana über Connections und Data sources eine neue Datenquelle vom Typ Prometheus anlegen.
Serveradresse eintragen. Als Prometheus server URL den Servicenamen aus der Compose-Datei verwenden, hier http://prometheus:9090, weil Grafana und Prometheus im selben Docker-Netzwerk laufen.
Verbindung speichern und testen. Über Save and test prüft Grafana, ob es Prometheus unter der eingetragenen Adresse erreicht.
Dashboard-Panel anlegen. Ein neues Panel bekommt eine PromQL-Abfrage, die Abfragesprache von Prometheus, als Datenquelle.

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

Diese Abfrage berechnet für jeden Server einzeln, wie viel CPU-Zeit pro Sekunde im Systemmodus des Betriebssystems verbraucht wurde, gemittelt über die letzten fünf Minuten. Die Gruppierung by (instance) sorgt dafür, dass das Panel für jeden der drei eingetragenen Server eine eigene Linie zeichnet, obwohl alle Werte aus derselben Abfrage stammen. Dieselbe Technik funktioniert für jede andere von node_exporter oder einer selbst instrumentierten Anwendung bereitgestellte Kennzahl, etwa freien Festplattenspeicher oder Anfragerate.

Häufige Fehlerquellen

Ein Scrape-Ziel bleibt unerreichbar, weil eine Firewall den Port blockiert. Die Zielübersicht unter /targets zeigt das betroffene Ziel dauerhaft als DOWN, obwohl der überwachte Dienst normal läuft, und Prometheus setzt für dieses Ziel automatisch die Kennzahl up auf 0. Fix: Prüfen, ob der Scrape-Port, etwa 9100 für node_exporter, von der Prometheus-Instanz aus erreichbar ist, zum Beispiel mit curl direkt aus dem Prometheus-Container heraus.
Grafana zeigt in der neuen Datenquelle keine Daten an. Ursache ist meist eine URL, die auf localhost zeigt, obwohl Grafana und Prometheus in getrennten Containern laufen; innerhalb eines Containers bezeichnet localhost immer den Container selbst, nie einen Nachbarcontainer. Fix: Als URL den Servicenamen aus der Docker-Compose-Datei verwenden, etwa http://prometheus:9090, statt http://localhost:9090.
Eine Änderung an prometheus.yml wirkt sich nicht aus. Prometheus liest seine Konfigurationsdatei nur beim Start oder nach einem gezielten Neuladen ein, nicht automatisch bei jeder Änderung der Datei. Fix: Nach jeder Änderung den Container neu starten oder das Neuladen über den dafür vorgesehenen Weg der Software auslösen.
Die lokale Zeitreihen-Datenbank füllt langsam die Festplatte. Prometheus speichert alle Werte standardmäßig nur wenige Wochen lang lokal auf der Festplatte des eigenen Servers, danach werden ältere Blöcke automatisch gelöscht. Fix: Wer länger zurückblicken will, erhöht die Aufbewahrungsdauer beim Start der Software oder schreibt die Werte zusätzlich in einen externen Langzeitspeicher.
Warnungen erscheinen in Prometheus, aber niemand wird benachrichtigt. Eine Alerting-Regel kann feuern, ohne dass eine Nachricht ankommt, wenn Prometheus keinen Alertmanager kennt oder die Verbindung zu ihm in der Konfiguration fehlt. Fix: Im Abschnitt alerting von prometheus.yml die Adresse des Alertmanagers eintragen und danach prüfen, ob der Alertmanager selbst einen funktionierenden Benachrichtigungskanal konfiguriert hat.
Zwei Server überschreiben sich gegenseitig im Dashboard. Prometheus vergibt das instance-Label automatisch aus der Zieladresse; tragen zwei Server intern denselben Hostnamen ein, lassen sich ihre Werte in Grafana nicht mehr sauber trennen. Fix: In targets eindeutige, sprechende Adressen verwenden oder zusätzliche eigene Label wie standort oder umgebung je Servergruppe vergeben.

Häufig gestellte Fragen

Wie unterscheiden sich Prometheus und Grafana von einem einfachen Verfügbarkeits-Check wie Uptime Kuma?

Prometheus und Grafana speichern jede Kennzahl über Wochen und Monate als Zeitreihe, während ein einfacher Verfügbarkeits-Check wie Uptime Kuma nur den aktuellen Status eines Servers meldet. Ein Verfügbarkeits-Check erkennt einen Totalausfall zuverlässig, ein Blick auf CPU-Auslastung oder Antwortzeit über die letzten Wochen zeigt dagegen, ob sich ein Engpass schon länger anbahnt. Beide Werkzeuge ergänzen sich in der Praxis: Ein Portfolio kann einen einfachen Check für die schnelle Ausfallmeldung behalten und Prometheus mit Grafana zusätzlich für die Verlaufsanalyse und die Ursachensuche nach einem Vorfall einsetzen.

Wie oft fragt Prometheus die Metriken der überwachten Server ab?

Prometheus fragt die Metriken der überwachten Server in dem Abstand ab, der in der Konfigurationsdatei prometheus.yml für jeden Job festgelegt ist. Ohne eigene Angabe verwendet Prometheus laut eigener Dokumentation ein Standardintervall von einer Minute je Ziel; in der Praxis stellen viele Portfolios für Server-Kennzahlen ein kürzeres Intervall von 15 bis 30 Sekunden ein, um kurze Ausschläge nicht zu verpassen. Das Intervall lässt sich pro Job einzeln setzen, sodass wichtige Anwendungen häufiger und weniger wichtige seltener abgefragt werden.

Was ist der Unterschied zwischen einem Exporter und einer selbst instrumentierten Anwendung?

Ein Exporter und eine selbst instrumentierte Anwendung unterscheiden sich darin, wer die Prometheus-Kennzahlen erzeugt. Ein Exporter wie node_exporter ist ein eigenständiges Zusatzprogramm, das Werte eines Systems ausliest, das selbst keine Prometheus-Unterstützung mitbringt, etwa den Kernel eines Linux-Hosts, und sie im Prometheus-Textformat auf einem eigenen Port bereitstellt. Eine selbst instrumentierte Anwendung bindet stattdessen eine Prometheus-Client-Bibliothek direkt in den eigenen Code ein und stellt ihre Kennzahlen unter ihrem eigenen /metrics-Pfad bereit, ohne einen zusätzlichen Prozess zu benötigen. Für Prometheus sind beide Fälle gleich: Es ruft in beiden Fällen eine HTTP-Adresse ab und liest den Text aus, der dort steht.

Wie leitet Prometheus eine Warnung an ein zuständiges Team weiter?

Prometheus leitet eine Warnung nicht direkt an ein Team, sondern zuerst an eine eigene Komponente namens Alertmanager weiter, sobald eine hinterlegte Alerting-Regel für die festgelegte Mindestdauer erfüllt bleibt. Der Alertmanager bündelt mehrere gleichzeitig eintreffende Warnungen, unterdrückt Duplikate und leitet das Ergebnis an einen konfigurierten Kanal weiter, etwa E-Mail, Slack oder einen Pager-Dienst. Diese Aufteilung erlaubt es, dieselbe Alertmanager-Instanz für mehrere Prometheus-Server im selben Portfolio zu verwenden, statt die Zustellungslogik in jeder Prometheus-Konfiguration einzeln zu wiederholen.

Der Content wurde mit Hilfe von KI erstellt, vor allem in der Recherche und Vorformulierung. Prüfung und Abnahme durch unsere Redaktion.