Wer in Azure Monitor mit immer mehr Ressourcen, Workloads und Plattformdiensten arbeitet, merkt schnell, wie die Benachrichtigungen überhandnehmen. Vor allem bei geplanten Wartungsfenstern oder bekannten Änderungen laufen oft Hunderte Alerts auf, die niemand braucht und die über kurz oder lang zu Alert Fatigue führen. In vielen Tenants, die ich betreue, ist das ein Dauerthema. Die meisten Verantwortlichen reagieren zu spät oder löschen die Alerts einfach von Hand. Genau dafür gibt es Alert Processing Rules in Azure Monitor. Mit ihnen lassen sich Benachrichtigungen gezielt unterdrücken, umleiten oder verändern, bevor sie bei den eigentlichen Action Groups ankommen.
Alert Processing Rules greifen direkt nach dem Auslösen eines Alerts
Alert Processing Rules (kurz APR, früher auch Smart Detection Rules genannt) liegen im Azure Portal unter Azure Monitor → Alerts → Alert processing rules. Ihr großer Vorteil: Sie wirken unmittelbar, nachdem ein Alert ausgelöst wurde, und lassen sich auf sämtliche oder auf ausgewählte Ressourcen anwenden. Typische Einsatzfälle sind das automatische Unterdrücken von Alerts während eines Wartungsfensters oder die vorübergehende Umleitung an ein anderes Incident-Team. Sehr praktisch finde ich die zeitliche Steuerung, mit der sich bei geplanten Deployments die zahlreichen metrik- oder logbasierten Warnungen von vornherein ausblenden lassen. Mehr dazu habe ich im Beitrag Azure Monitor Baseline Alerts in der Praxis geschrieben.
Damit der Unterschied greifbar wird, habe ich ein kleines Ablaufdiagramm erstellt. Daran sieht man, an welcher Stelle die Alert Processing Rules gegenüber den Action Groups ansetzen:
flowchart TD
AlertGen["Alert ausgelöst"] --> APR["Alert Processing Rule geprüft"]
APR -->|"Regel: Alert unterdrücken"| EndSuppressed["Alert unterdrückt"]
APR -->|"Regel: Action Group ändern"| AG["Benachrichtigung an Action Group"]
AG --> Notify["Empfänger erhält Benachrichtigung"]
Abbildung: Ablauf von Alert, Alert Processing Rule und Action Group in Azure Monitor.
Nützlich sind APR vor allem dort, wo mehrere Teams mit eigenen Eskalationswegen zusammenarbeiten oder wo bei sensiblen Systemen nachts nicht jeder Alert sofort zählt. Bei geplanten Wartungen, etwa mit Azure Update Manager, lasse ich damit häufig nur die kritischen Alerts durch und blende den Rest gezielt aus. Weil die Regeln zentral im Portal gepflegt werden, baut sich nicht jeder Ressourceneigentümer seine eigenen zusammen, bis keiner mehr durchblickt.
Ein durchdachter Aufbau der Action Groups erspart viel Ärger
Über Action Groups läuft in Azure Monitor die gesamte Alarmierung. Sie bestimmen, auf welchem Weg und an wen ein Alert geht: per E-Mail, SMS, Push-Benachrichtigung, Webhook oder über eine Logic App. In größeren Umgebungen kommen schnell viele Action Groups zusammen. Deshalb gliedere ich sie konsequent nach Funktion (z. B. Datenbanken, Netzwerk, Anwendung) und nach Empfängerkreis (On-Call, Betriebsrat, Service Desk). Häufig sehe ich Kombinationen wie diese:
- E-Mail an das On-Call-Team
- Logic App → Kanal in Microsoft Teams
- ITSM-Connector, etwa für ServiceNow
- Automatische Azure-Aktion (z. B. Runbook-Trigger)
Ob Empfänger und Workflows wirklich funktionieren, sollte man regelmäßig testen. Kaum etwas ärgert mehr als ein Alarm, der ins Leere läuft, weil jemand den Teams-Kanal umbenannt hat oder die ServiceNow-Integration abgelaufen ist. Unter Azure Monitor → Alerts → Action groups lassen sich Testbenachrichtigungen verschicken, mit denen man die komplette Kette überprüft. Mit Logic Apps bildet man auch aufwendigere Eskalationswege oder Formatierungen ab. Ausführliche Informationen zu Action Groups findet ihr in der Dokumentation von Microsoft.
Mein Tipp aus der Praxis: Legt für jede produktive Action Group im ITSM-System eine Kontaktliste mit Verantwortlichen und Ablaufdatum an. Wenn etwas hakt oder ein Empfänger nicht mehr aktuell ist, habt ihr den richtigen Ansprechpartner dann schnell zur Hand.
Severity und Zustandslogik bestimmen, welcher Alarm wirklich zählt
Im Alltag sehe ich oft, dass alle Alerts als gleich „wichtig“ gelten. Dabei bietet Azure Monitor eine frei wählbare Severity von 0 (Critical) bis 4 (Verbose). Ich empfehle, diese Skala konsequent zu nutzen und die Alert Processing Rules darauf auszurichten. Während einer Wartung kommen dann beispielsweise nur Alerts mit Severity 0 und 1 durch, alle niedrigeren Stufen bleiben vorübergehend ausgeblendet. Der Bereitschaftsdienst wird entlastet, und das Monitoring findet mehr Akzeptanz.
Auch der Alert-Typ verdient Aufmerksamkeit. Stateful Alerts bleiben aktiv, solange die auslösende Bedingung zutrifft (z. B. dauerhaft hohe CPU-Last). Stateless Alerts lösen dagegen bei jedem Ereignis einmal aus. In Wartungsfenstern gehen die meisten Fehlalarme auf Stateless-Regeln zurück, deshalb lohnt es sich, APR gezielt auf diese Typen zu beschränken.
Im Portal ist eine Alert Processing Rule in fünf Schritten angelegt
Wer Alerts während eines Wartungsfensters per Alert Processing Rule unterdrücken will, erstellt in der Regel nur eine neue Regel mit Zeitplan und wählt die passenden Ressourcen und Severities aus:
- Azure Monitor → Alerts → Alert processing rules → Create
- „Suppress alerts“ auswählen
- Zeitplan und Zielressourcen festlegen
- Bei Bedarf nach Severity filtern
- Speichern und testen
Soll später für alle Alerts eines bestimmten Typs eine weitere Action Group hinzukommen, etwa für ein neues SOC-Team, geht das im selben Menü über „Add Action Group“. Für bestimmte Ressourcentypen klappt das auch tenantweit.
Jede Action Group wird vor der Freigabe getestet und dokumentiert
Neue Action Groups und APR nehme ich grundsätzlich erst in Betrieb, nachdem ich sie mit einem simulierten Alert geprüft habe. Unter Azure Portal → Alerts → Action groups → Test lässt sich für E-Mail, Logic App oder ITSM-Connector direkt ein Test-Alert auslösen. Freigegeben wird die Regel erst, wenn die Benachrichtigungen bei allen Empfängern und über jeden Eskalationspfad sauber ankommen. Welche Alerts auf welche Weise verarbeitet wurden, zeigen die Activity Logs. Alternativ legt man eigene Monitor-Logs an.
Best Practices zu Basis-Alerts und Tipps gegen Alarmmüdigkeit findet ihr in meinem Beitrag Azure Monitor Baseline Alerts in der Praxis.
Alert Processing Rules sind ein unterschätztes Werkzeug gegen Alert Fatigue
Ich halte Alert Processing Rules für das wichtigste Mittel, um Alert Fatigue in Azure-Umgebungen dauerhaft einzudämmen. Sie schaffen einen zentralen Überblick, verhindern Fehlalarme während der Wartung und erleichtern spürbar die Zusammenarbeit zwischen mehreren Teams. Bei komplexen Workloads oder vielen Action Groups kommt es allerdings auf saubere Dokumentation, regelmäßige Tests und einen bewussten Umgang mit der Severity-Skala an. Wer APR und Action Groups richtig einsetzt, erhält weniger Benachrichtigungen, die dafür wirklich relevant sind, und hat im Monitoring-Alltag endlich wieder seine Ruhe.
