Grafana & Prometheus

Während Nagios und Zabbix aus den 1990ern/2000ern stammen und Status-orientiert arbeiten, ist Prometheus (2012, ursprünglich bei SoundCloud entstanden, heute Teil der Cloud Native Computing Foundation) ein Kind der Container-Ära. Es denkt nicht in „Service ist OK oder kaputt", sondern in Zeitreihen – kontinuierliche Zahlenströme über Zeit, beschriftet mit beliebigen Labels. Kombiniert mit Grafana (Visualisierung) ergibt sich der heute dominierende Stack für Cloud-native Monitoring. In dieser Lektion klärst du das Zusammenspiel beider Werkzeuge, lernst die Grundzüge von PromQL (der Abfragesprache von Prometheus) und siehst, warum „Pull statt Push" hier eine konzeptionelle Aussage ist – nicht nur eine technische.

1) Zwei Werkzeuge, zwei Aufgaben

Beide Namen werden oft im selben Atemzug genannt, aber sie machen unterschiedliche Dinge: Prometheus speichert – es zieht Metriken von Zielen, hält sie in einer eigenen Zeitreihen-Datenbank und beantwortet Abfragen. Grafana visualisiert – es kennt selbst keine Daten, sondern fragt verschiedene Backends (Prometheus, InfluxDB, Loki, SQL, Elasticsearch) ab und stellt die Ergebnisse als Dashboards dar. Stell es dir vor wie Notizbuch und Whiteboard: Prometheus ist das Notizbuch (geschrieben, durchsuchbar, mit Datum versehen), Grafana ist das Whiteboard im Konferenzraum (zeigt zur richtigen Zeit die richtigen Sachen sichtbar an die Wand).

2) Die Architektur

Der ganze Stack ist modular. Klick auf eine Komponente, um zu sehen, wofür sie zuständig ist:

3) Exporter – die universelle Datenquelle

Prometheus zieht Daten von Exportern: kleinen Programmen, die unter /metrics einen einfachen Text-Endpoint bereitstellen. Das Format ist trivial – ein Zeilen-pro-Metrik:

# HELP node_cpu_seconds_total CPU time in seconds
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 12384.21
node_cpu_seconds_total{cpu="0",mode="user"} 847.62
node_memory_MemAvailable_bytes 2147483648

Das Schöne daran: jedes Programm kann das. Der node_exporter für Linux liefert hunderte System-Metriken, der mysqld_exporter kennt MySQL-Internals, der blackbox_exporter probt HTTP-Endpoints. Eigene Anwendungen können selbst einen /metrics-Endpoint exponieren – Bibliotheken gibt es für Java, Python, Go, Node.js, .NET. Damit sind Custom-Metriken (Anzahl Bestellungen pro Minute, Cache-Hit-Rate, ...) ohne Drittsoftware machbar.

4) PromQL – die Abfragesprache

PromQL (Prometheus Query Language) ist das Herzstück. Mit ihr formulierst du, was du sehen willst – egal ob in Grafana-Panel, im Alarm oder in der Web-UI von Prometheus selbst. Klick durch die Beispiele, um die wichtigsten Funktionen zu sehen:

5) Pull statt Push – und warum das wichtig ist

Prometheus pollt – im Standard alle 15 Sekunden, konfigurierbar. Das ist eine bewusste Designentscheidung, mit Konsequenzen:

Der Pull-Ansatz funktioniert hervorragend in Container-Welten: Container haben kurze Lebensdauer, kommen und gehen, und Service Discovery durch Kubernetes erlaubt Prometheus, dynamisch zu finden, was es scrapen soll. In klassischen Mainframe-Welten mit festen Servern bringt es weniger Vorteil – dort haben Zabbix oder Nagios oft die bessere Antwort.

6) Grafana-Dashboards

Grafana fügt dem Setup die visuelle Seite hinzu: einzelne Panels (Graphen, Tabellen, Gauges, Heatmaps), zusammengefasst zu Dashboards, organisiert in Folders. Jeder Panel ist eine PromQL-Abfrage (oder eine Abfrage gegen eine andere Datenquelle), plus Visualisierungs-Optionen. Wichtige Stärken:

• Mehrere Datenquellen. Ein Dashboard kann Prometheus-Daten und MySQL-Daten und Loki-Logs nebeneinander zeigen.
• Templating mit Variablen. Ein „Server"-Auswahlfeld oben, alle Panels filtern sich danach.
• Alerting. Grafana selbst kann ebenfalls Alerts auslösen (eigene Engine seit Version 8), unabhängig vom Alertmanager.
• Annotations. Releases, Deployments oder Incidents als Marker im Graphen darstellen – sehr nützlich für die Root Cause Analysis.

7) Long-Term Storage – die Achillesferse

Prometheus speichert lokal – auf der Disk des Prometheus-Servers, standardmäßig 15 Tage. Das ist bewusst gewählt: lokale Storage ist robust, einfach und braucht kein verteiltes System. Bei großen Setups ist das aber zu wenig. Lösungen: Thanos oder Cortex/Mimir; sie sitzen vor mehreren Prometheus-Instanzen, schreiben Daten in Object Storage (S3) und ermöglichen Multi-Tenancy plus Jahre an Historie. Für mittlere Setups reichen oft auch Federation (Prometheus scraped Prometheus) und ein längerer lokaler Retention-Zeitraum. Mehr zu Cloud-Speicher-Mechaniken in Objektspeicher (S3).

Zusammenfassung

Prometheus ist eine Pull-basierte Zeitreihen-Datenbank für Cloud-native Monitoring; Grafana visualisiert ihre (und anderer Quellen) Daten. Datenerhebung über Exporter mit standardisiertem /metrics-Endpoint. Polling im 15-Sek.-Takt, Discovery dynamisch über Kubernetes/Consul. Abfragesprache: PromQL – mit rate() für Counter, Aggregationen wie sum by (job), Histogramm-Quantilen, mehrdimensionalen Joins. Alertmanager als separate Komponente für Routing und Eskalation. Pushgateway nur als Ausnahme für ephemere Jobs. Long-Term-Storage über Thanos/Cortex/Mimir. Sweetspot: Container, Microservices, hochdynamische Umgebungen – mit Zabbix oder Nagios kombinierbar in heterogenen Setups.

Verwandte Lektionen: Zabbix · Nagios & Icinga · Schwellenwerte & Alerting · und mehrWeitere relevante LektionenMonitoring-KonzeptKapazitätsplanungContainer-GrundlagenCloud-ModelleAnsibleService Level ManagementIncident Management