Monitoring mit Prometheus und Visualisierung in Grafana sind mächtige Werkzeuge — aber schlecht konfigurierte Alerts verwandeln sie schnell in einen lauten, unbrauchbaren Alarmtrichter. Ich habe in Projekten gelernt, dass gute Alerts nicht nur Probleme melden, sondern kontextualisieren, priorisieren und vor allem: praktisch handhabbar sind. In diesem Artikel zeige ich dir, wie ich Prometheus und Grafana so einrichte, dass ich echte Alerts statt permanenten Noise bekomme.

Warum viele Alerts sinnlos sind

Bevor wir in die Konfiguration einsteigen: Ursachen für "Alert-Noise" sind meist nicht technische Einschränkungen der Tools, sondern Designfehler in der Art, wie Alerts formuliert werden.

  • Zu enge Schwellen: Ein kurzer Spike in CPU oder Latenz löst sofort einen Alarm aus.
  • Fehlender Kontext: Alerts kommen ohne Hinweise auf Ursache, Impact oder betroffene Services.
  • Keine Aggregation: Viele ähnliche Alerts aus mehreren Instanzen fluten den Kanal.
  • Keine Prüfsicherungen: Flapping-Probleme werden nicht gedrosselt (z. B. keine for-Zeiten in Prometheus).
  • Keine Eskalationslogik oder Deduplizierung: dasselbe Problem generiert wiederholt neue Tickets.

Grundprinzipien meiner Alert-Strategie

Meine Regeln sind einfach und anwendbar:

  • Mehr Kontext, weniger Trigger: Alerts zeigen Ursache, betroffene Umgebung und Anlaufstelle.
  • Schwellen an echten Auswirkungen ausrichten: Was bedeutet 90% CPU wirklich für den Service?
  • Aggregation und Deduplizierung: Gruppenbildung und Recording Rules statt viele Einzelchecks.
  • Silencing und Inhibition: temporäre Wartungen und abhängige Alerts ausschließen.
  • Testbarkeit: Alerts sind testbar (synthetische Probes, Fire Drill).

Prometheus: Recording Rules und sinnvolle Alerts

Ich beginne oft mit Recording Rules, weil sie die Grundlage für stabile Alerts bilden. Statt komplexe Expressions in jeder Alert-Rule zu duplizieren, berechne ich wichtige Metriken vorab:

  • Durchschnittliche Latenz pro Service über 5 Minuten
  • Fehlerrate pro Endpoint (5m rolling)
  • Prozentualer Anteil fehlerhafter Instanzen

Beispiel einer Recording Rule (YAML, verkürzt):

<code> my_service:latency:95th_rate:5m = histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))</code>

Für Alerts nutze ich:

  • for: mindestens 5–10 Minuten, um kurzfristige Spikes zu ignorieren.
  • Labels: severity, team, service, environment — damit Routing und Inhibition in Alertmanager möglich sind.

Ein Beispiel für eine Alert-Rule:

<code>- alert: HighServiceErrorRate expr: rate(http_requests_total{job="myservice",code=~"5.."}[5m]) / rate(http_requests_total{job="myservice"}[5m]) > 0.02 for: 10m labels: severity: page team: backend annotations: summary: "Service {{ $labels.service }} hat hohe Error-Rate" description: "5xx Fehler > 2% über 10 Minuten für {{ $labels.service }}"</code>

Alertmanager: Routing, Inhibition und Escalation

Alertmanager ist der Koch, der entscheidet, welche Warnung wohin geht. Ich konfiguriere drei Dinge konsequent:

  • Routing nach Team und Severity: PagerDuty/Slack/Email je nach Schwere.
  • Inhibition: Wenn ein Host-Down-Alert vorhanden ist, sollen viele Service-Alerts für diese Host-IP unterdrückt werden (abhängige Alerts).
  • Silences: Wartungsfenster über API oder UI anlegen, automatisiert bei Deployments.

Ein praktisches Pattern: Wenn mehrere Instanzen eines Services ausfallen, möchte ich nur einen "Service degraded"-Alert, nicht 20 Host-Alerts. Das gelingt, indem ich in Prometheus eine Rule für den Anteil ausgefallener Instanzen schreibe und Alertmanager so routes, dass diese Alert priorisiert wird. Zusätzlich nutze ich Inhibition, um Host-Alerts zu unterdrücken, wenn der Service-Alert feuert.

Grafana: Dashboards + Alerts (wenn gewünscht)

Grafana hat inzwischen mächtige Alerting-Funktionalitäten und kann direkt Alerts an ähnliche Kanäle senden wie Alertmanager. Ich nutze Grafana für:

  • Kontextsensitive Dashboards, die zu einem Alert springen
  • Visuelle Heatmaps und Logs (Loki) in Verbindung mit einem Alert
  • Optionales Alerting für Business-KPIs, während Prometheus/Alertmanager infra-kritische Alerts übernimmt

Wichtig: Wenn du sowohl Alertmanager als auch Grafana Alerts verwendest, stelle sicher, dass sie sich nicht überlappen. Ich trenne gerne Infrastruktur-Alerts (Prometheus -> Alertmanager) von Produkt- oder SLO-Alerts (Grafana -> Slack/Teams), damit Verantwortlichkeiten klar bleiben.

Praktische Regeln für weniger Noise

  • Benutze "for" bewusst: 5–10 Minuten verhindern Flapping; länger bei sporadischen Problemen.
  • Schreibe Alerts aus der Perspektive des Betroffenen: "Payment-Service zahlungsunfähig" statt "CPU > 90%".
  • Nutze pro Service ein globales Team-Label: Routing einfacher, Deduplizierung möglich.
  • Recording Rules zur Voraggregation: Vermeide teure Querys in Live-Alerts.
  • Rate-Limit Benachrichtigungen: Alertmanager kann wiederholte Benachrichtigungen drosseln.
  • Synthetische Checks: End-to-end Tests für die wichtigsten Pfade (Login, Checkout) sind oft aussagekräftiger als reine Infrastrukturmetrik.

Beispiel-Workflow: Von Problem zu Actionable Alert

So sieht bei mir ein typischer Ablauf aus:

  • Synthetischer Check schlägt fehl -> Prometheus registriert Fehlerzunahme
  • Recording Rule erhöht "service_error_rate"
  • Alert "HighServiceErrorRate" feuert nach 10 Minuten
  • Alert hat labels: team=payments, severity=page, service=payment-api
  • Alertmanager routet an PagerDuty on-call von payments
  • In Alert-Annotationen: Link zum Grafana-Dashboard + zu letzten 200 Logs in Loki

Tabelle: Arten von Alerts und wie ich damit umgehe

Alert-TypBeispielVorgehen
Infrastructure Host down, Disk full Prometheus + Alertmanager, schnelle Pager-Duty-Benachrichtigung, Inhibition von abhängigen Alerts
Service API Error Rate > 2% Recorded Metric, 10m "for", Team-OnCall, Dashboard-Link
Business Checkout success rate sinkt Grafana Alerts, Product Owner notifizieren, Playbook mit Kundenkommunikation

Tools und Erweiterungen, die ich empfehle

  • Prometheus Operator: vereinfacht Rule- und ServiceMonitor-Management in Kubernetes.
  • Alertmanager: für Deduplizierung, Routing, Inhibition und Silences.
  • Grafana + Loki: Dashboards + Logs gemeinsam für schnellen Kontext.
  • Thanos/VictoriaMetrics: für Langzeit-Storage und skalierbare Metriken.
  • Synthetic monitoring: Pingdom, Grafana Cloud Synthetic Monitoring oder selbst gehostete Puppeteer-Checks.

Zum Schluss ein praktischer Tipp: mache regelmäßig einen "Alert Review" — einmal im Monat gehe ich mit dem Team die gefeuerten Alerts durch, markiere falsche Alarme, passe Thresholds an und schließe unnötige Regeln. Das ist der effizienteste Weg, um langfristig Lärm zu reduzieren und die Reaktionsfähigkeit zu erhöhen.