Prometheus & Grafana

Entstehung und Beteiligte

Prometheus wurde ab 2012 bei SoundCloud von Matt Proud und Julius Volz entwickelt. Es orientierte sich an Googles internem Borgmon. 2016 wurde Prometheus nach Kubernetes das zweite Projekt der Cloud Native Computing Foundation.

Welches Problem sollte gelöst werden?

Dynamische Dienste und kurzlebige Instanzen passten schlecht zu statisch konfiguriertem Monitoring. Ein System sollte Ziele entdecken, Metriken regelmäßig abrufen und flexibel abfragen.

Technische Hürden und Lösungen

Prometheus ist pull-basiert und lokal autonom. Hohe Kardinalität kann Speicher und Abfragen überlasten. Langzeitaufbewahrung und globale Sicht benötigen Zusatzsysteme. Alertmanager gruppiert und routet Alarme, Grafana visualisiert Daten.

Standardisierung und Einordnung

Monitoring entwickelte sich vom einfachen Prüfen erreichbarer Geräte zu einer eigenen Disziplin aus Metriken, Ereignissen, Protokollen und Traces. Die zentrale Schwierigkeit besteht nicht im Sammeln möglichst vieler Daten, sondern im Erkennen relevanter Abweichungen. Zeitstempel, eindeutige Identitäten, Aufbewahrung, Normalisierung und sinnvoll gesetzte Alarmgrenzen entscheiden darüber, ob Messdaten im Störungsfall helfen.

Technik im praktischen Betrieb

Ein Messwert benötigt Kontext: Einheit, Quelle, Intervall, Aggregation und erwarteten Normalbereich. Durchschnittswerte können kurze Spitzen verdecken, Maximalwerte kleine Ausreißer überbetonen. Aufbewahrung und Auflösung sollten zum Diagnoseziel passen. Alarme müssen einen klaren Besitzer, eine Handlungsanweisung und eine Eskalation besitzen. Regelmäßige Tests mit absichtlich ausgelösten Fehlern zeigen, ob Benachrichtigung, Bereitschaft und Runbook wirklich funktionieren.

Warum das Thema heute noch relevant ist

Historische Daten schaffen erst dann Wert, wenn sie vergleichbar bleiben. Änderungen an Geräten, Namen, Intervallen oder Messdefinitionen müssen deshalb nachvollziehbar sein. Langfristige Trends beantworten Kapazitätsfragen, detaillierte kurze Daten helfen bei Störungen. Beide Ziele verlangen unterschiedliche Auflösung. Monitoring ist zugleich Teil der Beweiskette: Ohne unabhängige Zeit, unveränderte Logs und bekannte Datenlücken lässt sich nach einem Vorfall nur schwer unterscheiden, was tatsächlich geschah und was lediglich vermutet wird.

Daten und Meilensteine

• 2012 beginnt Prometheus bei SoundCloud.
• 2016 wird es CNCF-Projekt.
• PromQL ist die Abfragesprache.
• Labels ermöglichen flexible Dimensionen, können aber Kardinalität explodieren lassen.

Prometheus – Zeitreihen-Monitoring

Prometheus wurde 2012 bei SoundCloud entwickelt und ist heute das führende Open-Source-Monitoring-System für Cloud-Native-Umgebungen. Es wurde 2016 als zweites Projekt (nach Kubernetes) in die Cloud Native Computing Foundation (CNCF) aufgenommen.

Das Pull-Modell ist Prometheus' Kernkonzept: Prometheus scraped aktiv HTTP-Endpunkte (/metrics) der überwachten Systeme, anstatt darauf zu warten, dass Metriken eingeschickt werden. Dies macht die Konfiguration einfacher und zeigt sofort, wenn ein Service nicht erreichbar ist.

Metrik-Typen

Prometheus kennt vier Metrik-Typen:

• Counter: Monoton steigender Zähler (z.B. Gesamtzahl HTTP-Requests). Nur Resets zurück auf 0.
• Gauge: Beliebig steigender/fallender Wert (z.B. aktueller Speicherverbrauch, CPU-Last)
• Histogram: Verteilt Beobachtungen in Buckets (z.B. Request-Latenz: <10ms, <50ms, <200ms)
• Summary: Ähnlich wie Histogram, berechnet aber Quantile (p50, p95, p99) clientseitig

PromQL – Abfragesprache

PromQL (Prometheus Query Language) ist eine funktionale Abfragesprache für Zeitreihen. Beispiele:

rate(http_requests_total[5m]) – Durchschnittliche Anfragerate der letzten 5 Minuten. histogram_quantile(0.95, rate(latency_bucket[5m])) – 95. Perzentile der Latenz. up == 0 – Alle ausgefallenen Services. sum by (pod) (container_memory_usage_bytes) – Speicherverbrauch nach Pod.

PromQL kann in Grafana-Dashboards, Alert-Rules und Recording-Rules verwendet werden.

Alertmanager und Grafana

Prometheus-Alerts werden in YAML-Regeln definiert: "Wenn HTTP-Fehlerrate > 1% für >5min, feuere Alert." Der Alertmanager empfängt diese Alerts und routing sie zu Empfängern: Slack, PagerDuty, OpsGenie, E-Mail.

Grafana verbindet sich mit Prometheus als Datasource und ermöglicht das Erstellen von Dashboards per Drag-and-Drop oder JSON. Grafana Loki ergänzt den Stack um Log-Aggregation, Grafana Tempo für Distributed Tracing – zusammen der "PLG-Stack" (Prometheus, Loki, Grafana).