Grafana: Alerting mit E-Mail, Microsoft Teams und Webhooks
Auf einen Blick
| Gilt für | Grafana Alerting in Grafana 13.x (Grafana-verwaltete Alarmregeln); Kontaktpunkte E-Mail, Microsoft Teams (Workflows), Webhook, Telegram u. a. |
|---|---|
| Bereich | Server-Software |
| Dauer | Grundeinrichtung ca. 1 Stunde; je Alarmregel ca. 10 Minuten |
| Rechte | Grafana-Rolle Editor (Regeln) bzw. Admin (Kontaktpunkte, Richtlinien); in Microsoft Teams Recht zum Anlegen von Workflows |
| Stand | Oktober 2026 |
Alerting mit Grafana meldet Probleme, bevor Benutzer sie bemerken: Plattenplatz knapp, Server nicht erreichbar, Fehlerflut im Log, Leitung ausgelastet. Grafana bewertet dazu regelmäßig Abfragen auf Prometheus, Loki und anderen Datenquellen und benachrichtigt per E-Mail, Microsoft Teams, Webhook oder Messenger. Diese Anleitung erklärt die Bausteine des Grafana Alerting, zeigt typische Alarmregeln, die Einrichtung von Microsoft Teams über Workflows und Regeln, mit denen Alarme nützlich bleiben statt zu nerven.
Die Bausteine des Grafana Alerting
| Baustein | Aufgabe |
|---|---|
| Alarmregel | Abfrage + Bedingung (z. B. „freier Speicher < 10 %“), ausgewertet in einer Regelgruppe im festen Intervall |
| Labels | Merkmale wie severity=kritisch, team=netzwerk – entscheiden über den Benachrichtigungsweg
|
| Kontaktpunkt | Ziel der Benachrichtigung: E-Mail, Teams, Webhook, Telegram, Slack, PagerDuty u. a. |
| Benachrichtigungsrichtlinie | Baum aus Regeln, der Alarme anhand der Labels an Kontaktpunkte leitet und gruppiert |
| Ruhezeit (Mute timing) | unterdrückt Benachrichtigungen zu festen Zeiten, z. B. im Wartungsfenster |
| Vorlage | passt Betreff und Text der Benachrichtigung an |
Die Bereiche liegen unter Alerts & IRM › Alerting. Grundlagen: Alerting.
Alarmzustände
- Normal – alles in Ordnung.
- Pending – die Bedingung ist erfüllt, aber noch nicht lange genug (Wartezeit, z. B. 5 Minuten) – verhindert Alarme bei kurzen Spitzen.
- Alerting / Firing – Alarm aktiv, Benachrichtigung wird verschickt.
- Recovering – Wert ist zurückgegangen, Alarm wird bei Bestätigung aufgehoben.
- No Data und Error – die Abfrage liefert nichts bzw. schlägt fehl; für jede Regel festlegen, ob das als Alarm, als „OK“ oder als eigener Zustand gilt. Für Erreichbarkeitsregeln ist „No Data = Alarm“ meist richtig.
- Eine Erholungsschwelle (z. B. Alarm bei 90 %, Entwarnung erst unter 85 %) verhindert flatternde Alarme.
Schritt 1: Kontaktpunkte einrichten
E-Mail: SMTP in der Grafana-Konfiguration (GF_SMTP_*) einrichten, dann Contact points › Add contact point, Integration Email, Empfänger wie it-alarm@firma.de.
Microsoft Teams: Die früheren Office-365-Connectors in Teams sind abgelöst; Grafana nutzt einen Workflow mit Webhook:
- In Teams im gewünschten Kanal Workflows öffnen und die Vorlage „Post to a channel when a webhook request is received“ (bzw. „Bei Empfang einer Webhook-Anforderung in einem Kanal posten“) wählen.
- Am Ende die angezeigte Webhook-URL kopieren. Bei privaten Kanälen im Workflow die Aktion „Adaptive Karte posten“ auf Als Benutzer posten umstellen.
- In Grafana Kontaktpunkt mit Integration Microsoft Teams anlegen, URL einfügen, Test und speichern.
- Die Webhook-URL ist ein Geheimnis – wer sie kennt, kann in den Kanal posten.
Webhook: Für Ticketsysteme, n8n oder eigene Skripte; Grafana sendet JSON mit allen Alarmdaten. Authentifizierung per Kopfzeile oder Basic Auth hinterlegen.
Schritt 2: Benachrichtigungsrichtlinien
Notification policies:
| Richtlinie | Label-Bedingung | Kontaktpunkt |
|---|---|---|
| Standard | – | E-Mail IT-Team |
| Kritisch | severity = kritisch |
Teams-Kanal „IT-Alarme“ + E-Mail Bereitschaft |
| Netzwerk | team = netzwerk |
Teams-Kanal „Netzwerk“ |
| Wartung | severity = info |
nur E-Mail, mit Ruhezeit nachts |
- Gruppierung (z. B. nach
alertnameundstandort) fasst gleichartige Alarme zu einer Nachricht zusammen – fällt ein Switch aus, kommt eine Meldung statt zwanzig. - Zeitsteuerung: Erste Nachricht nach Group wait (Standard 30 Sekunden), neue Alarme der Gruppe frühestens nach Group interval (5 Minuten), Erinnerung bei weiter aktivem Alarm nach Repeat interval (4 Stunden).
- Ruhezeiten für bekannte Wartungsfenster; für einmalige Arbeiten Silences (Stummschaltungen) mit Ablaufzeit setzen.
Schritt 3: Typische Alarmregeln
Alert rules › New alert rule, Datenquelle Prometheus bzw. Loki:
| Regel | Abfrage (vereinfacht) | Bedingung | Wartezeit | Labels |
|---|---|---|---|---|
| Server nicht erreichbar | up{job="node"} |
< 1 (No Data = Alarm) | 2 min | severity=kritisch |
| Plattenplatz knapp | node_filesystem_avail_bytes / node_filesystem_size_bytes * 100 |
< 10 | 15 min | severity=warnung |
| CPU dauerhaft hoch | 100 - avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m]))*100 |
> 90 | 15 min | severity=warnung |
| Schnittstelle down | ifOperStatus{ifAlias=~"Uplink.*"} |
≠ 1 | 2 min | team=netzwerk |
| Zertifikat läuft ab | probe_ssl_earliest_cert_expiry - time() (Blackbox Exporter) |
< 14 Tage | 1 h | severity=warnung |
| Fehlerflut im Log | sum by(host)(count_over_time({job="journal"} |= "error" [5m])) |
> 100 | 5 min | severity=info |
- Zusammenfassung und Beschreibung (Annotationen) mit Platzhaltern füllen, z. B.
{{ $labels.instance }}und{{ $values.A }}, dazu ein Link auf das passende Dashboard bzw. eine Anleitung. - Regeln in Ordnern ablegen, die der Ordnerstruktur der Dashboards entsprechen – so greifen dieselben Rechte.
Regeln gegen Alarmmüdigkeit
- Nur handlungsrelevante Alarme: Jeder Alarm braucht jemanden, der etwas tun kann und soll. Alles andere gehört ins Dashboard.
- Wartezeiten und Erholungsschwellen großzügig wählen; kurze Spitzen sind selten Alarme wert.
- Schweregrade klar trennen: kritisch (sofort), Warnung (heute), Info (nur Bericht).
- Regelmäßig aufräumen: Alarme, die immer ignoriert werden, ändern oder löschen.
- Grafana selbst überwachen: Fällt Grafana aus, kommt kein Alarm. Einen externen Erreichbarkeitstest bzw. „Dead Man's Switch“ einrichten.
Hinweise
- Alarme als Code: Kontaktpunkte, Richtlinien und Regeln lassen sich per Provisioning-Dateien oder Terraform verwalten, siehe Grafana: Dashboards als Code mit Provisioning und Git Sync. Ältere Alertmanager-Konfigurations-APIs wurden in Grafana 13 eingeschränkt; Skripte auf die neuen
/apis/notifications.alerting.grafana.app-Schnittstellen umstellen. - Sicherheitsalarme (Anmeldeversuche, Malware, Angriffe) gehören in ein SIEM mit eigener Alarmierung und Bereitschaft.
- Bei Alarmierungskonzepten, Bereitschaft und überwachtem Betrieb unterstützt Sie das Managed SIEM von m.a.x. it.
Siehe auch
- Grafana im Unternehmen – Überblick und alle Artikel der Reihe
- Grafana: Datenquellen und Dashboards erstellen
- Microsoft Teams
- Webhook
Links und Quellen
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
