Prometheus + Grafana -- Modernes Infrastruktur-Monitoring

Nagios hat uns jahrelang gut gedient. Dann kamen Container, Microservices und dynamische Infrastruktur – und Nagios begann zu ersticken. Der Wechsel zu Prometheus mit Grafana war nicht nur ein Werkzeugwechsel. Es war eine völlig andere Denkweise über Monitoring.

Warum Prometheus¶

Nagios, Zabbix, Icinga – alle funktionieren nach dem Prinzip des Push-Modells. Ein Agent auf dem Server sendet Metriken an eine zentrale Instanz. Das funktioniert hervorragend, solange Sie eine statische Infrastruktur mit benannten Servern haben. Sobald Container auftauchen, die nur Minuten leben und keine stabilen Hostnamen haben, bricht das Push-Modell zusammen.

Prometheus funktioniert umgekehrt – Pull-Modell. Prometheus geht selbst zu den HTTP-Endpoints der Anwendungen und sammelt Metriken. Dank Service Discovery findet es automatisch neue Instanzen in Kubernetes, Consul oder EC2. Container startet, Prometheus entdeckt ihn, beginnt zu scrapen. Container verschwindet, Prometheus hört auf. Keine Konfiguration, keine Agents.

Instrumentierung – Metriken aus erster Hand¶

Das Schlüsselkonzept von Prometheus ist, dass Anwendungen selbst Metriken exportieren. Kein externer Agent, der Logs parst oder Ports überwacht. Die Anwendung stellt einen /metrics-Endpoint mit aktuellen Werten bereit – Anfragenzähler, Latenz, Fehlerrate, Queue-Größe.

# Prometheus + Grafana -- Modernes Infrastruktur-Monitoring
# TYPE http_requests_total counter
http_requests_total{method="GET",path="/api/users",status="200"} 48293
http_requests_total{method="POST",path="/api/orders",status="201"} 7841
http_requests_total{method="GET",path="/api/users",status="500"} 23

# HELP http_request_duration_seconds Request latency
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.1"} 41209
http_request_duration_seconds_bucket{le="0.5"} 47891
http_request_duration_seconds_bucket{le="1.0"} 48102

Client-Bibliotheken gibt es für Go, Java, Python, Node.js, .NET – praktisch alles. Die Instrumentierung eines Service dauert eine Stunde. Und ab diesem Zeitpunkt haben Sie Metriken, die tatsächlich dem entsprechen, was in der Anwendung passiert.

PromQL – Die Sprache, die Ihr Monitoring verändern wird¶

Die meisten Monitoring-Systeme können anzeigen “CPU ist bei 87 %”. Prometheus kann Fragen beantworten wie “Wie hoch ist die 95. Perzentil-Latenz der letzten 5 Minuten für Service X, gefiltert nach HTTP-Methode”.

# Error rate for the last 5 minutes
rate(http_requests_total{status=~"5.."}[5m])
  / rate(http_requests_total[5m]) * 100

# 95th percentile latency
histogram_quantile(0.95,
  rate(http_request_duration_seconds_bucket[5m])
)

# Top 5 slowest endpoints
topk(5,
  avg by (path) (rate(http_request_duration_seconds_sum[5m])
    / rate(http_request_duration_seconds_count[5m]))
)

PromQL hat eine Lernkurve. Aber sobald Sie es verstehen, wollen Sie nichts anderes mehr. Aggregationen, Filter, Rate-Berechnungen – alles in einer Abfrage. Und dieselbe Abfrage verwenden Sie in Dashboards und Alert-Regeln.

Grafana – Visualisierung, die Sinn macht¶

Prometheus hat ein eigenes UI, aber es ist spartanisch. Grafana ist die Visualisierungsschicht, die aus Prometheus-Daten lesbare Dashboards macht. Graphen, Heatmaps, Tabellen, Single-Stat-Panels – alles konfigurierbar, alles teilbar.

Unser Setup: ein Dashboard pro Service (RED-Metriken – Rate, Errors, Duration), ein Infrastruktur-Dashboard (CPU, Speicher, Disk, Netzwerk) und ein “War Room”-Dashboard für den Bereitschaftsingenieur mit einer Übersicht des gesamten Systems. Wir versionieren Dashboards als JSON in Git – Provisioning über Grafana API beim Deployment.

Alerting – Alertmanager in der Praxis¶

Wir definieren Alert-Regeln in der Prometheus-Konfiguration. Wenn eine Bedingung länger als eine festgelegte Zeit gilt, sendet Prometheus einen Alert an den Alertmanager. Dieser kümmert sich um Deduplizierung, Gruppierung, Silencing und Routing – Alerts gehen je nach Severity an Slack, PagerDuty oder E-Mail.

groups:
  - name: sla
    rules:
      - alert: HighErrorRate
        expr: |
          rate(http_requests_total{status=~"5.."}[5m])
          / rate(http_requests_total[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Error rate > 5% on {{ $labels.instance }}"

Wichtige Lektion: Alertieren Sie auf Symptome, nicht auf Ursachen. Alertieren Sie nicht “CPU > 90 %”. Alertieren Sie “p99-Latenz > 2 s” oder “Fehlerrate > 5 %”. Die CPU kann bei 90 % liegen und alles funktioniert einwandfrei. Aber wenn Benutzer 5 Sekunden auf eine Antwort warten, ist das ein Problem.

Kubernetes Service Discovery¶

In Kubernetes-Umgebungen entdeckt Prometheus Pods automatisch über die Kubernetes-API. Fügen Sie einfach Annotationen zum Pod hinzu, und Prometheus beginnt zu scrapen. Keine manuelle Konfiguration, keine Pflege von Target-Listen.

Node Exporter auf jedem Node sammelt Systemmetriken. cAdvisor (integriert in kubelet) liefert Container-Metriken. kube-state-metrics exportiert den Zustand von Kubernetes-Objekten – Deployments, Replica Sets, Pods. Zusammen haben Sie ein komplettes Bild des gesamten Clusters.

Was uns überrascht hat¶

Retention – Prometheus ist kein Langzeitspeicher. Standardmäßig behält es Daten für 15 Tage. Für langfristige Trends brauchen Sie Remote Storage (Thanos, Cortex, VictoriaMetrics). Wir haben mit 30-Tage-Retention begonnen und senden für Kapazitätsplanung aggregierte Daten an InfluxDB.

Hochverfügbarkeit – Prometheus hat kein natives Clustering. Lösung: zwei unabhängige Instanzen scrapen dieselben Targets. Alertmanager hat eigenes Clustering für Deduplizierung. Es funktioniert, aber es ist ein anderes Modell als “ein Cluster, der sich um alles kümmert”.

Kardinalität – zu viele einzigartige Label-Kombinationen bringen Prometheus um. Ein Team hat user_id als Label an HTTP-Metriken hinzugefügt. 50.000 einzigartige Benutzer x 10 Metriken x 3 HTTP-Methoden = Speicherexplosion. Label-Werte müssen niedrige Kardinalität haben.

Monitoring als Kultur¶

Prometheus + Grafana sind nicht nur Werkzeuge – sie sind Katalysatoren für kulturellen Wandel. Entwickler fügen Metriken in den Code ein, weil sie sehen wollen, wie sich ihr Service in der Produktion verhält. Das Ops-Team hat Dashboards statt manuelles SSH. Der Bereitschaftsingenieur sieht Probleme, bevor Kunden anrufen. Beginnen Sie mit einem Service, instrumentieren Sie ihn, erstellen Sie ein Dashboard. Der Rest kommt von selbst.