Monitoring mit Prometheus und Grafana

Ein ungepatchter Dienst läuft seit Monaten unauffällig, bis er mitten in der Nacht 100 Prozent CPU frisst und alle Nutzer aussperrt. Ohne Monitoring merkst du das erst, wenn das Telefon klingelt. Mit einem sauberen Setup aus Prometheus und Grafana siehst du die Entwicklung vorher, nicht erst im Notfall.

Warum Monitoring vor dem Notfall kommen muss

Monitoring ist kein Luxus, sondern eine Versicherung für deinen Betrieb. Drei Punkte sind entscheidend:

• Du erkennst Trends: Speicher füllt sich nicht plötzlich, sondern über Wochen.
• Du findest Ursachen: „Server langsam“ wird zu „Datenbank-Queries dauern seit 14 Uhr doppelt so lange“.
• Du kannst belegen: Kapazitätsplanung basiert auf Zahlen, nicht auf Bauchgefühl.

Gerade in heterogenen Umgebungen mit Linux-Servern, Containern, Datenbanken und Cloud-Diensten brauchst du ein zentrales System, das Metriken einsammelt, speichert, abfragt und visualisiert. Genau hier passt das Duo Prometheus und Grafana.

Prometheus kümmert sich um das Sammeln, Speichern und Abfragen von Metriken. Grafana visualisiert und alarmiert auf Basis dieser Daten. Beides zusammen ergibt ein flexibles, gut verständliches Monitoring, das sich von ein paar Servern bis zu großen Umgebungen in Münchner Rechenzentren skalieren lässt.

Prometheus-Grundprinzip: Pull statt Push

Prometheus arbeitet anders als viele klassische Monitoring-Systeme: Es „scraped“ Metriken periodisch von Endpunkten, anstatt dass Agenten Daten aktiv irgendwohin schicken.

Die wichtigsten Konzepte:

• Target: Ein Endpunkt, den Prometheus abfragt, zum Beispiel http://app-server:9100/metrics.
• Scrape-Intervall: Wie oft Prometheus ein Target abfragt, etwa alle 15 Sekunden.
• Metrik: Zeitreihe mit Namen, Labels und Werten, zum Beispiel http_requests_total{method="GET",status="200"}.
• Label: Schlüssel-Wert-Paar zur Unterscheidung von Instanzen, Services, Umgebungen.

Ein typischer Metrik-Eintrag sieht im Klartext etwa so aus:

http_requests_total{method="GET",handler="/login",status="200"} 12345

Jeder neue Scrape erzeugt einen neuen Datenpunkt in dieser Zeitreihe. So kannst du später Auslastung, Fehlerquoten und Latenzen über die Zeit analysieren.

Exporter: Metriken aus Systemen herausziehen

Nicht jeder Dienst spricht nativ „Prometheus“. Deshalb gibt es Exporter, die Metriken in das Prometheus-Format übersetzen und unter einem /metrics-Endpunkt bereitstellen.

Typische Exporter:

• Node Exporter: Systemmetriken eines Linux-Servers wie CPU, RAM, Plattenplatz, Netzwerk.
• Blackbox Exporter: Prüft Erreichbarkeit und Antwortzeiten von HTTP, TCP, ICMP.
• MySQL/PostgreSQL Exporter: Datenbankmetriken wie Verbindungen, Query-Dauer, Buffer-Usage.
• cAdvisor / kube-state-metrics: Container- und Kubernetes-Metriken.

Die Grundidee ist immer gleich: Exporter läuft lokal oder in der Nähe des Dienstes, sammelt relevante Kennzahlen und stellt sie Prometheus lesbar zur Verfügung.

Beim Design deines Monitorings solltest du dir früh überlegen:

• Welche Schichten willst du überwachen? Hardware, OS, Middleware, Applikation.
• Welche Metriken sind wirklich relevant? Besser wenige gute als 5000, die niemand versteht.
• Welche Labels brauchst du für sinnvolle Auswertungen? Zum Beispiel env, region, service.

Eine einfache Tabelle hilft dir bei der Planung:

Ebene	Beispiel-Metriken	Typischer Exporter
Host	CPU, RAM, Disk, Netzwerk	Node Exporter
Netzwerk / Ping	Latenz, Erreichbarkeit	Blackbox Exporter
Datenbank	Queries/s, Slow Queries, Connections	DB-spezifischer Exporter
Anwendung	Requests/s, Fehlerquote, Antwortzeit	App-eigene / clientlibs
Container	CPU/Memory pro Pod, Restarts, Status	cAdvisor, kube-state-metrics

Metrik-Typen verstehen: Counter, Gauge, Histogramm

Bevor du mit PromQL arbeitest, musst du verstehen, welche Metrik-Typen es gibt. Sie bestimmen, wie du später sinnvoll rechnest.

• Counter: Zähler, der nur steigt, zum Beispiel http_requests_total. Auswertungen immer über Raten, nicht direkt.
• Gauge: Wert, der steigt und fällt, etwa aktuelle Speicherauslastung oder Queue-Länge.
• Histogramm / Summary: Verteilungen von Werten, typischerweise für Latenzen. Du bekommst Buckets wie request_duration_seconds_bucket{le="0.5"}.

Die häufigsten Fehler im Monitoring kommen nicht von PromQL, sondern von falsch interpretierten Metriktypen. Beispiel: Wenn du einen Counter direkt vergleichst, ohne rate(), bekommst du keine Aussage über aktuelle Last.

PromQL-Grundlagen: Von Rohdaten zu sinnvollen Kennzahlen

PromQL ist die Abfragesprache von Prometheus. Sie wirkt anfangs ungewohnt, lässt sich aber gut schrittweise lernen.

Ein paar typische Grundmuster:

1. Aktuellen Wert eines Gauges anzeigen

Zum Beispiel aktuelle CPU-Auslastung pro Host:

node_load1

Sobald du mehr als einen Host hast, solltest du aggregieren:

avg by (instance) (node_load1)

by (instance) sorgt dafür, dass du pro Host einen Wert bekommst.

2. Rate eines Counters berechnen

Für Counter brauchst du fast immer rate() oder irate():

rate(http_requests_total[5m])

Das berechnet die durchschnittliche Rate der Requests pro Sekunde über die letzten 5 Minuten.

Mit Labels gruppieren:

sum by (status) (rate(http_requests_total[5m]))

So siehst du, wie viele 2xx, 4xx und 5xx du pro Sekunde hast.

3. Fehlerquote berechnen

Du willst nicht nur absolute Fehler sehen, sondern einen Anteil an allen Requests:

sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Mit * 100 bekommst du eine Prozentzahl. Das ist eine typische Kennzahl für Dashboards und Alerting.

4. Latenzen aus Histogrammen

Wenn deine Anwendung Latenzen als Histogramm ausgibt, zum Beispiel http_request_duration_seconds_bucket, kannst du 95- oder 99-Perzentile berechnen:

histogram_quantile(
 0.95,
 sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

Das ergibt: 95 Prozent aller Requests sind schneller als der ausgegebene Wert.

Dashboards mit Grafana: Vom Metrik-Chaos zur Übersicht

Prometheus alleine ist sperrig, wenn du nicht gerne Rohabfragen schreibst. Grafana setzt genau dort an: Du verbindest Grafana mit deiner Prometheus-Instanz und baust daraus Dashboards.

Ein paar bewährte Praktiken:

• Trenne Infrastruktur und Anwendung: Ein Dashboard für Hosts, eines für die Applikation, eines für Datenbanken. Kein All-in-one-Monster.
• Nutze Variablen: Zum Beispiel eine Variable instance, damit du per Dropdown zwischen Servern wechseln kannst.
• Zeige nicht zu viele Panels: 6 bis 12 sinnvolle Panels pro Dashboard sind meist genug. Der Rest wird ignoriert.
• Einheitliche Zeiträume: Standard-Zeitraum z. B. letzte 6 Stunden, für Fehleranalysen gerne letzte 24 Stunden.

Typische Panels, die sich in vielen Projekten bewähren:

• System: CPU-Load, RAM, Disk-Usage, Netzwerkauslastung pro Host.
• Anwendung: Requests/s, Fehlerquote, Latenz-Perzentile, aktive Sessions.
• Datenbank: Connections, Queries/s, langsame Queries, Buffer-Hit-Rate.
• Verfügbarkeit: Uptime, HTTP-Status, Pings von außen.

Grafana bringt fertige Dashboards mit, und die Community stellt viele Beispiele bereit. Trotzdem lohnt es sich, eigene Dashboards bewusst zu planen, statt einfach alles Importierte hinzuklatschen.

Alerting: Vom Dashboard zur Benachrichtigung

Dashboards sind gut für Analyse und Überblick. Für den Notfall brauchst du jedoch aktives Alerting. Das bedeutet:

• Du definierst Regeln, wann ein Zustand kritisch ist.
• Alerts werden an einen Alertmanager gesendet.
• Alertmanager verschickt Benachrichtigungen, zum Beispiel per E-Mail, Teams, Slack oder Pager.

Wichtige Grundsätze für sinnvolles Alerting:

• Alert nur auf Symptome, nicht auf alles: Beispiel „Fehlerquote über 5 Prozent für 10 Minuten“, nicht „CPU über 70 Prozent für 1 Minute“.
• Nutze „for“-Zeiten: Ein Alert sollte erst feuern, wenn der Zustand eine gewisse Zeit anhält. So vermeidest du Flatter-Alerts.
• Schichten unterscheiden: Kritische Alerts für Betriebsbereitschaft, Warnungen für Trends und Kapazität.

Beispiele für sinnvolle Alerts:

• Fehlerquote HTTP 5xx über 2 Prozent länger als 10 Minuten.
• Antwortzeit P95 über 1 Sekunde länger als 15 Minuten.
• Disk-Usage über 90 Prozent, anhaltend über 30 Minuten.
• Node Exporter nicht erreichbar seit 5 Minuten.

Achte darauf, dass jeder Alert eine klare Handlung nach sich zieht. „CPU hoch“ ohne Kontext ist nutzlos. „CPU hoch, dazu Load hoch und viele blockierte DB-Queries“ gibt dir eine konkrete Richtung.

Monitoring in der Praxis planen: klein anfangen, gut strukturieren

Ein typisches Einführungsprojekt für Prometheus und Grafana kannst du in überschaubaren Schritten angehen:

1. Ziel definieren Beispiel: „Wir wollen alle produktiven Linux-Server und die Hauptanwendung überwachen, inklusive Fehlerquote und Latenzen.“

2. Minimalen Kern aufsetzen

• Prometheus-Server
• Node Exporter auf den relevanten Hosts
• Einfache Scrape-Konfiguration
• Grafana mit Prometheus als Datenquelle

3. Erste Dashboards bauen

• System-Dashboard mit CPU, RAM, Disk, Netz
• App-Dashboard mit Requests/s, Fehlerquote, Latenz

4. Alerting hinzufügen

• Alertmanager installieren und anbinden
• 3 bis 5 wirklich wichtige Alerts definieren
• Benachrichtigungsweg testen

5. Iterativ erweitern

• Weitere Exporter (Datenbank, Blackbox)
• Applikationsmetriken integrieren
• Dashboards und Alerts verfeinern

Wichtig ist, dass du Monitoring nicht als einmaliges Projekt siehst. Es ist ein lebendiges System. Neue Services kommen dazu, alte verschwinden, Kennzahlen ändern sich. Plane Zeit ein, um Dashboards und Alerts regelmäßig zu überprüfen, insbesondere nach größeren Architekturänderungen.

Wenn du das Thema strukturiert und praxisnah vertiefen willst oder Unterstützung beim Aufsetzen eines Monitorings für deine Umgebung in München suchst, findest du passende Schulungen und Workshops bei cmt.de.

Typische Stolperfallen und wie du sie vermeidest

Ein paar Fehler tauchen in fast jedem Prometheus-Grafana-Projekt irgendwann auf:

• Zu viele Metriken, zu wenig Fokus Exporter liefern tausende Metriken. Filtere, was für dich wirklich relevant ist. Lieber wenige, gut verstandene Kennzahlen.

• Fehlende Label-Strategie Ohne saubere Labels wie env, service, instance kannst du später nicht sinnvoll gruppieren oder filtern. Lege einheitliche Namenskonventionen fest.

• Alerts ohne Priorität Wenn alles „kritisch“ ist, ist am Ende nichts kritisch. Führe Schweregrade ein und gestalte Benachrichtigungen entsprechend.

• Keine Tests Alerts sollten bewusst getestet werden. Zum Beispiel durch das Abschalten eines Exporters oder künstlich erzeugte Fehler. Nur so merkst du, ob Benachrichtigungen tatsächlich ankommen und verstanden werden.

• Monitoring nicht mitversioniert Konfigurationen für Prometheus, Alertmanager und Grafana-Dashboards solltest du versionieren, zum Beispiel in Git. Das macht Änderungen nachvollziehbar und reproduzierbar.

Fazit: Monitoring als Teil deiner Betriebsstrategie

Prometheus und Grafana liefern dir alles, was du für modernes Monitoring brauchst: Metriken sammeln, sinnvoll abfragen, anschaulich darstellen und rechtzeitig alarmieren. Der entscheidende Punkt ist, dass du damit nicht wartest, bis der erste große Ausfall passiert. Wenn du früh beginnst, klein startest und deine Metriken, Labels und Alerts bewusst planst, wird Monitoring vom lästigen Pflichtprogramm zum wertvollen Werkzeug im Alltag.