So funktioniert Alerting¶

Die Plattform erstellt ihre Alerts mit Azure Policy und Terraform, nicht von Hand. Diese Seite erklärt die Bausteine und wie ein Alert von einer Ressource zu einer Person gelangt. Die Liste der Alerts steht im Alert-Katalog. Die Schritte, um dein eigenes On-Call-Tool anzubinden, stehen unter Monitoring ausrollen.

Die Bausteine¶

Baustein	Was es ist	Erstellt von
Alert-Initiativen	Azure-Policy-Initiativen, die die Alert-Definitionen enthalten. Sie folgen der Best Practice der Azure Monitor Baseline Alerts (AMBA), die Microsoft aus Felderfahrung gesammelt hat. Es gibt fünf: `Alerting-ServiceHealth`, `Alerting-Management`, `Alerting-Connectivity`, `Alerting-Identity` und `Alerting-LandingZone`	Definitionen im `foundation` layer
Assignments	Ein Assignment pro management group, eingeschaltet durch `alerting_management_groups`	Der `postdeployment` layer
Activity-Log-Alerts	Alerts auf Ereignisse der Plattform-subscriptions, aktiviert durch `enable_activity_log_alerts` (standardmäßig an)	Der `foundation` layer
Action Groups	Die Empfänger: E-Mail-Adressen und Webhooks. Zwei pro Region: eine allgemeine (`ag-<company>-mgmtgeneral-<env>-<region>-001`) und eine für die Alerts der landing-zone-Assignments (`ag-<company>-mgmtxpirit-<env>-<region>-001`)	Der `foundation` layer
Alert Processing Rules	Regeln, die anhand der Severity entscheiden, welche Alerts an welche Action Group gehen	Die layers `connectivity`, `identity`, `management` und die landing-zone-Initiative in jeder landing-zone-subscription
24/7-Route für den hub (optional)	Eine eigene Action Group und Processing Rule für Alerts außerhalb der Geschäftszeiten auf ausgewählten hub-Komponenten	Der `connectivity` layer, eingeschaltet mit `hub_247_support`

Wie die Assignments eingeschaltet werden, woher der Spoke seine Regeln bekommt und wie man sie wieder entfernt, steht unter Monitoring-Regeln. Die Namen der Action Groups stehen in der Namensreferenz.

Warum Policy¶

Alerts, die per Policy deployt werden, folgen den Ressourcen:

Wenn eine Ressource erstellt oder geändert wird, erstellt die deployIfNotExists-Policy die Alert-Regel. Niemand muss daran denken.
Eine Regel kann nicht unbemerkt fehlen: Die Compliance der Alert-Policies ist in Azure Policy sichtbar und Teil des monatlichen Health Checks.
Für Ressourcen, die schon existieren, wenn ein Assignment eingeschaltet wird, erscheinen die Regeln erst nach einem Remediation Task (Monitoring-Regeln, Schritt 4).

Severity¶

Azure Monitor kennt fünf Severities. Sie zu unterscheiden verhindert Alert Fatigue: Wenn das Team wegen Dingen alarmiert wird, die keine Probleme sind, beginnen die Leute, die Meldungen zu ignorieren, und eines Tages ignorieren sie die, auf die es ankommt. Ein kritischer Alert braucht eine schnelle Reaktion. Ein informativer Alert kann im Backlog warten.

Severity	Name	Bedeutung	Was passiert
0	Critical	Der Service fällt aus oder die Sicherheit ist gefährdet. Handle sofort.	Wird verarbeitet und an die Action Group gesendet. Rufe die On-Call-Person an, wenn dein Service Level es verlangt
1	Error	Deutliche Beeinträchtigung	Wird verarbeitet und gesendet
2	Warning	Ein Schwellenwert für Performance oder Kapazität ist überschritten	Wird verarbeitet und gesendet
3	Informational	Betriebliche Information	In Azure Monitor protokolliert. Keine Benachrichtigung
4	Verbose	Audit-Trail: administrative und Sicherheitsereignisse	In Azure Monitor protokolliert. Keine Benachrichtigung

Severity 0 bis 2 werden von den Alert Processing Rules geroutet. Severity 3 und 4 bleiben in Azure Monitor für Historie und Compliance-Reporting. Alle Alerts werden in Azure Monitor protokolliert, unabhängig vom Routing.

Wie du jede Stufe behandelst, entscheidest du

Die Tabelle zeigt das Standard-Routing. Reaktionszeiten für Severity 0 bis 2 und ob sie auch außerhalb der Geschäftszeiten gelten, gehören in deine Service Levels (Service-Level-Management). Im Modell Managed Service stammen sie aus dem Vertrag.

Wie ein Alert reist¶

flowchart LR
    r["Resource or activity log"] --> a["Alert rule<br/>(created by policy)"]
    a --> p["Alert processing rule<br/>(severity 0 to 2)"]
    p --> g["Action group<br/>(e-mail, webhook)"]
    g --> t["On-call / incident tool"]
    t --> c["Chat channel"]
    t --> o["On-call engineer<br/>(call, SMS)"]

Eine Alert-Regel löst bei einer Metrik oder einem Activity-Log-Ereignis aus.
Eine Alert Processing Rule wählt Alerts nach Severity aus und sendet sie an eine Action Group.
Die Action Group ruft einen Webhook bei deinem Incident- oder On-Call-Tool auf und sendet optional E-Mails.
Das Tool eröffnet oder aktualisiert einen Incident, postet ihn im Chat-Kanal des Plattform-Teams und benachrichtigt bei kritischen Alerts den On-Call-Engineer per Anruf und SMS, wenn du das konfiguriert hast.
Der Incident-Prozess beginnt (Incident Management).

Lass alle Alerts der Plattform über dieselben Action Groups laufen. Eine zentrale Route lässt sich leichter testen, ändern und auditieren als Empfänger, die über viele Regeln verstreut sind.

Optionale 24/7-Route für den hub¶

Außerhalb der Geschäftszeiten sollen vielleicht nur wenige hub-Alerts jemanden wecken. Die optionale 24/7-Route für den hub (ADR-0007) leistet das, nur für den hub. Pro Plattform aktiviert, erstellt sie eine eigene Action Group und Processing Rule in der connectivity- subscription, mit einem Webhook deiner Wahl und einem täglichen Zeitfenster (Standard 18:00 bis 08:00, westeuropäische Zeit). Standardmäßig deckt die Regel Resource-Health- und Service-Health-Alerts für firewall, Virtual WAN, virtual hub, VPN Gateway und Application Gateway ab.

Warum eine eigene Action Group: Der Webhook eines Kunden bleibt von den gemeinsamen Kanälen getrennt, und sein Aktivieren ändert nicht, wie andere Alerts geroutet werden. Der Preis ist eine zusätzliche Action Group und eine Liste von Alert-Namen, die du pflegst, wenn sich die Namen upstream ändern. Die Einstellungen stehen unter Monitoring-Regeln.

Ein Managed Service kann 24/7-Betreuung mit einer On-Call-Rotation und Runbooks für jeden kritischen Alert anbieten. Ob das für dich gilt, ist eine Vertragsfrage.

Spokes und Workload-Teams¶

Subscriptions unter der management group landingzones bekommen die Alert-Regeln der landing zone, und ihre Alerts der Severity 0 bis 2 gehen an die Action Group der Plattform. Ein Workload-Team kann beantragen, dass die Standardregeln von seinem Spoke entfernt werden, mit dem tag MonitorDisable oder einer Policy-Ausnahme (Monitoring-Regeln).

Die Plattform alarmiert nicht auf das, was die Anwendung tut. Das Workload-Team erstellt diese Alerts, mit eigenen Action Groups und auf seinem eigenen Workspace (Deinen Workload betreiben).

Das Alerting gesund halten¶

Aufgabe	Wie oft	Wo
Die Alerts der Woche prüfen: laute Regeln abstimmen, Work Items für echte Probleme anlegen	Wöchentlich	Wartungskalender
Prüfen, dass die Alert-Policies compliant sind und die im Monat ausgelösten Alerts verwertbar waren	Monatlich	Monatlicher Health Check
Die Empfänger prüfen: Leute sind gegangen, ein Webhook wurde rotiert, das On-Call-Tool hat gewechselt	Vierteljährlich und bei jedem Teamwechsel	Empfänger in `foundation.auto.tfvars` (Monitoring ausrollen)
Prüfen, dass ein kritischer Alert wirklich eine Person erreicht	Nach jeder Änderung an der Route	Monitoring ausrollen

Eine Site-to-Site-Verbindung, die connected meldet, aber keinen Verkehr durchlässt, wird von einem Status-Alert nicht erfasst. Alarmiere auch auf Verkehr (Bekannte Probleme).

Upgrades und alte Alert-Objekte¶

Ältere Versionen deployten Custom-Alert-Policy-Objekte, die von Hand entfernt werden mussten, wenn die Alert-Policies ersetzt wurden. Suche nach ihnen, wenn du über v4.5.1 oder v4.11.x hinweg aktualisierst: Plattform-Upgrade-Leitfäden.