In vielen Tenants, die ich betreue, läuft Monitoring nebenher – bis zum ersten ernsthaften Ausfall. Dann will plötzlich jeder wissen, welche Alerts es überhaupt gibt, wer sie bekommt und ob sie zuverlässig auslösen. An dieser Stelle kommen die Azure Monitor Baseline Alerts (AMBA) ins Spiel. Microsoft pflegt damit eine offene Sammlung empfohlener Warnregeln und Richtlinien, die eigens für Azure Landing Zones entwickelt wurde. Mit einer x-beliebigen Vorlage von GitHub ist AMBA nicht zu vergleichen. Das Regelwerk ist durchdacht und deckt Service Health und Resource Health ebenso ab wie Plattformmetriken für zentrale Ressourcen wie VMs, Storage, Networking oder Key Vault. Wer seine Azure-Umgebung sauber und reproduzierbar aufbauen möchte, kommt an AMBA kaum vorbei.

AMBA liefert eine verbindliche Grundüberwachung für Azure

Hinter Azure Monitor Baseline Alerts steckt eine kuratierte Sammlung von Alert Rules, Action Groups und Alert Processing Rules, die Microsoft offen pflegt (Azure Monitor Baseline Alerts). Sie soll eine tragfähige Grundüberwachung schaffen, auf der Projekte und Betriebsmodelle ihre eigenen Anforderungen aufsetzen können. Gerade in größeren Umgebungen kommt es darauf an, mit einer verbindlichen Baseline zu beginnen – und fast jeder Enterprise-Tenant verteilt sich heute auf mehrere Subscriptions und Landing Zones. Den größten Nutzen sehe ich darin, dass das übliche Durcheinander aus verstreuten, uneinheitlichen oder fehlenden Warnungen gar nicht erst entsteht. Gleichzeitig sinkt die Gefahr einer Alert Fatigue, weil weniger unnötiger Lärm ankommt. Neben klassischen Metriken wie CPU-Auslastung oder Storage-Kapazität berücksichtigt AMBA auch Warnungen auf Basis von Service Health und Resource Health.

AMBA lässt sich über das Portal oder direkt mit der Landing Zone ausrollen

Für den produktiven Einsatz gibt es zwei realistische Wege. Über das AMBA-Portal lässt sich das Regelset als Accelerator direkt auf ausgewählte Subscriptions oder Management Groups ausrollen. Ein übersichtlicher Wizard führt durch die Einrichtung, und Action Groups für den Versand können gleich mit hinterlegt werden. Alternativ wird die Baseline schon beim Aufbau der Landing Zone mitprovisioniert, was vor allem in IaC-Szenarien mit Bicep oder Terraform gut funktioniert. Spätestens dann sollte man sich ansehen, wie AMBA mit den Standards der Landing Zone zusammenspielt und wie die Diagnosedaten zentral gesammelt werden. Fehlen konsistente Diagnostic Settings, laufen viele Alerts ins Leere, weil die Ressourcen nicht sauber in den zentralen Log Analytics Workspace schreiben. Die Regeln greifen erst, wenn beides zusammenpasst.

Vor der Einführung hilft es zu wissen, dass die von AMBA empfohlenen Service-Health-Alerts ohne zusätzlichen Log Analytics Workspace auskommen, denn sie beruhen direkt auf Ereignissen der Azure-Plattform. Bei metrikbasierten Alerts, etwa zur VM-Performance, sieht es anders aus. Hier muss die jeweilige Ressource ins Monitoring eingebunden sein, und die benötigten Metriken müssen aktiviert sein. Wer nachbessern muss, sollte vor allem Storage Accounts, VMs und Key Vaults prüfen.

Zentrale Action Groups und Processing Rules halten das Rauschen klein

In Projekten sehe ich immer wieder, dass Alerts eingerichtet werden, ohne dass sich jemand Gedanken über die Empfänger macht. In größeren Tenants wird das schnell chaotisch, weil Mails in persönlichen Postfächern oder bei Service Accounts landen oder schlicht niemand reagiert. Es braucht daher konsistente Action Groups (zentrale Mailadressen, Teams-Channels, Webhooks) und Alert Processing Rules, die Lärm herausfiltern und Eskalationen sinnvoll steuern. AMBA macht dazu klare Vorgaben:

  • Gesundheitswarnungen (Service/Resource Health) gehen immer an zentrale Betriebsadressen
  • Metrikbasierte Warnungen richten sich nach der Serviceverantwortung
  • Alert Processing Rules regeln Wartungszeiten und Priorisierung
  • Duplikate und irrelevante Schwellenwerte erzeugen keine Alert-Flut
  • Action Groups werden regelmäßig überprüft, damit keine verwaisten Empfänger übrig bleiben

Wer die Action Groups einmal zentral im Portal oder per IaC definiert, kann sie in sämtlichen Regeln wiederverwenden. Das spart eine Menge Aufwand und verhindert Fehlauslösungen. Alert Processing Rules sollten gezielt zum Einsatz kommen, um beispielsweise Wartungsfenster abzudecken oder nur die relevanten Alerts an bestimmte Teams weiterzugeben. An diesem Punkt merkt man in der Praxis sehr schnell, wie ausgereift ein Monitoring-Konzept tatsächlich ist.

Praktischer Tipp: Bevor ihr eine neue Action Group anlegt, schaut im Azure-Portal → Monitor → Action Groups nach, welche Gruppen bereits existieren. Häufig reicht es, vorhandene Empfänger anzupassen, statt Hunderte neue Gruppen zu erstellen.

Service- und Resource-Health-Alerts gehören in jede Umgebung

Service- und Resource-Health-Alerts sind für mich das Minimum, das in keiner Azure-Umgebung fehlen darf. Sie melden Ausfälle von Azure-Diensten, Regionen oder einzelnen Ressourcen, und zwar unabhängig vom eigenen Monitoring. Im Azure-Portal unter Service Health → Health alerts lassen sich die passenden Regeln sehr fein einstellen (hier dokumentiert). Die Empfänger wollen sorgfältig ausgewählt sein, damit im Ernstfall tatsächlich jemand reagiert. Für Produktionsumgebungen rate ich dazu, diese Alerts an zentrale Betriebs- oder Bereitschaftsadressen zu schicken statt an einzelne Personen.

Im Alltag fällt mir auf, dass sich viele Unternehmen zu sehr auf das Monitoring innerhalb der Ressourcen verlassen. Dabei gerät aus dem Blick, dass ein regionaler Azure-Ausfall ganz andere Folgen haben kann. Zuverlässig erfassen lässt sich das nur mit Service-Health-Alerts, die das Risiko böser Überraschungen entsprechend senken. Wer zusätzlich Resource-Health-Alerts aktiviert, bekommt früh Hinweise auf beeinträchtigte VMs, Storage-Ressourcen oder Datenbanken.

# Beispiel: Service Health Alert für Ausfälle in West Europe
# Azure-Portal → Service Health → Health Alerts → Regel erstellen
# Keine PowerShell nötig, aber zur Übersicht aller Regeln:
Get-AzActivityLogAlert | Where-Object { $_.Name -like '*ServiceHealth*' }

AMBA entlastet den Betrieb, ersetzt aber kein Feintuning

Meine Erfahrung zeigt, dass Azure Monitor Baseline Alerts kein Selbstzweck sind. Richtig eingeführt, entlasten sie den Betrieb spürbar. Vor allem in Landing Zones, die mit IaC und zentralen Policies arbeiten, sorgen konsistente Baselines für einen ruhigeren Alltag. Regeln und Action Groups gehören regelmäßig auf den Prüfstand und müssen an veränderte Zuständigkeiten oder Teams angepasst werden. Am schwierigsten bleibt es, die Balance zwischen ausreichender Überwachung und vermeidbarem Lärm zu halten. AMBA ist dafür ein sehr guter Ausgangspunkt, für Spezialanwendungen oder kritische Workloads braucht es aber weiterhin individuelles Feintuning.

Das folgende Diagramm zeigt den typischen Weg eines Alerts für eine VM, von der Metrik bis zur Benachrichtigung. Wer AMBA sauber integriert, behält an jeder Station die Kontrolle.

flowchart TD
    Metrics["VM Metrik"] --> AlertRule["Alert-Regel (AMBA)"]
    AlertRule --> ActionGroup["Action Group"]
    ActionGroup --> AlertProcessing["Alert Processing Rule"]
    AlertProcessing --> Notify["Empfänger/Incident"]

Abbildung: Ablauf einer Alert-Auslösung für eine VM mit Azure Monitor Baseline Alerts

Eine saubere Baseline bringt weniger Alarm und mehr Kontrolle

Ohne eine Baseline für Alerts lässt sich Azure nicht professionell betreiben. AMBA liefert sie in Form eines soliden, gut dokumentierten Ausgangspunkts, der sich sauber in bestehende Betriebsmodelle und IaC-Prozesse einfügt. Fehlen zentrale Action Groups und regelmäßige Pflege, geht allerdings ein großer Teil der Vorteile verloren. Service- und Resource-Health-Alerts sind Pflicht, alles Weitere baut darauf auf. Bei mir gehört AMBA inzwischen in jeden neuen Tenant, und das erspart mir eine Menge Ärger, wenn es wirklich darauf ankommt.