Monitoring-Regeln (für einen spoke zuweisen / entfernen)¶

Wie Alerting funktioniert und wie du es ausrollst: Monitoring und Alerting.

Standardänderung: Verwaltete Monitoring-Regeln zuweisen/löschen (die standardmäßig verwalteten Monitoring-Regeln) auf einem bestehenden spoke.

Auswirkung: Die subscription und die Ressourcen des spokes erhalten die standardmäßigen Azure-Monitor-Alertregeln der Plattform, oder erhalten sie nicht mehr.

Wie das Monitoring aufgebaut ist¶

Die standardmäßigen Monitoring-Regeln sind Azure Monitor Baseline Alerts (AMBA), die mit Azure Policy deployt werden:

Definitionen: infra/deploy/foundation/policies/policy_definitions/alerts/** (87 Definitionen) und fünf Initiativen in infra/deploy/foundation/policies/policy_set_definitions/alerts/: Alerting-ServiceHealth, Alerting-Management, Alerting-Connectivity, Alerting-Identity, Alerting-LandingZone.
Zuweisungen: infra/deploy/postdeployment/main_policies_alerts.tf, eine pro Management Group, aktiviert über alerting_management_groups in <env-folder>/<primary region>/postdeployment.auto.tfvars:

alerting_management_groups = {
  cloudplatform = { id = "cloudplatform",                       deploy_alerting_servicehealth = true }
  landingzones  = { id = "cloudplatform-landingzones",          deploy_alerting_landingzone   = true }
  connectivity  = { id = "cloudplatform-platform-connectivity", deploy_alerting_connectivity  = true }
  management    = { id = "cloudplatform-platform-management",   deploy_alerting_management    = true }
  identity      = { id = "cloudplatform-platform-identity",     deploy_alerting_identity      = true }
}

Die Schlüssel cloudplatform und landingzones sind erforderlich, weil der Code auf sie verweist.

Routing: Die landing-zone-Initiative deployt in jeder landing-zone-subscription eine alert processing rule. Die Regel leitet Sev0–Sev2-Alerts an die action group der Plattform ag-<company>-mgmtxpirit-<env>-<region>-001 weiter.

Im spoke-JSON gibt es keinen Monitoring-Schalter pro spoke. Ein spoke erhält die landing-zone-Regeln, weil seine subscription unter der Management Group landingzones liegt, wo Alerting-LandingZone mit dem Zuweisungsnamen alerting_landingzone zugewiesen ist.

Die Policies verwenden deployIfNotExists. Alertregeln werden für neue oder geänderte Ressourcen erstellt, und für bestehende Ressourcen nur über einen remediation task.

Anfragefelder¶

Feld	Verwendung
Monitoring Rule name	`all` (das Standardset) oder bestimmte Regeln, z. B. VM CPU, Storage availability
Begründung	pull request / Change-Record
Environment	spoke-Umgebung / subscription
Scope	spoke-subscription, resource group oder Ressource
Kommentare

Die Standardregeln einem spoke zuweisen¶

Platzierung prüfen. Die managementGroupId des spokes muss eine Management Group unter landingzones sein (landingzones_corp, landingzones_online oder deren Kinder). Falls nicht, ändere sie mit Change spoke.
Prüfen, ob die Zuweisung existiert. In postdeployment.auto.tfvars gilt landingzones.deploy_alerting_landingzone = true.
Opt-outs entfernen. Stelle sicher, dass die spoke-subscription und ihre Ressourcen nicht den Tag MonitorDisable mit dem Wert true tragen (siehe unten).
Bestehende Ressourcen mit remediation nachziehen. remediation tasks werden nur dann automatisch erstellt, wenn automatically_start_policy_remediation = true gilt, und nur wenn sich die Zuweisung ändert (ADR-0010). Für einen bestehenden spoke startest du selbst einen:
Azure portal → Policy → Assignments → Xebia Custom - Alerting - Landing Zone → Create remediation task. Setze den Scope auf die spoke-subscription und führe die remediation für jede benötigte Policy aus. Oder:

Azure CLI, pro Policy-Referenz:

az policy remediation create \
  --name "rem-alerting-<spoke>-<policy>" \
  --policy-assignment "/providers/Microsoft.Management/managementGroups/<landingzones id>/providers/Microsoft.Authorization/policyAssignments/alerting_landingzone" \
  --definition-reference-id "<policyDefinitionReferenceId>" \
  --subscription "<spoke subscription id>"

Die Standardregeln von einem spoke entfernen¶

Wähle den schmalsten Mechanismus, der passt:

Mechanismus	Scope	Vorgehen	Hinweise
`MonitorDisable` tag	subscription oder einzelne Ressource	Füge `"MonitorDisable": "true"` zu den `tags` im spoke-JSON hinzu (subscription und canvas-Ressourcen) oder zu den eigenen Ressourcen des Workloads	76 der 87 Alert-Definitionen überspringen Ressourcen, deren Tag `MonitorDisable` gleich `true` ist. Regeln auf subscription-Ebene (service health, resource health, alert processing rule) prüfen den Tag der subscription. Ressourcenregeln prüfen den eigenen Tag der Ressource. 11 der 13 VM-Alert-Definitionen (`Compute/virtualMachines`) prüfen diesen Tag nicht.
Policy-Ausnahme	subscription / resource group / Ressource	Ausnahme auf die Zuweisung `alerting_landingzone` (siehe Policy-Zuweisungen → Ausnahmen)	Funktioniert für jede Definition, einschließlich der VM-Alerts. Kann mit `policy_definition_ids` auf bestimmte Policies beschränkt werden.
Management Group wechseln	gesamte subscription	`managementGroupId` außerhalb von `landingzones`	Ändert auch, welche Governance-Policies gelten. Meist nicht das, was du willst.

Bestehende Alertregeln werden von keinem dieser Mechanismen gelöscht. deployIfNotExists hört nur auf, sie zu erstellen. Lösche die bereits deployten Regeln von Hand: Azure portal → Monitor → Alerts → Alert rules, gefiltert auf die spoke-subscription.

Das Verhalten des MonitorDisable-Tags stammt aus den Policy-Definitionen selbst. Die Beispielkonfigurationen verwenden es nicht. Teste es zuerst in canary.

Regeln für alle spokes ändern¶

Das Umschalten von deploy_alerting_landingzone ändert das Monitoring für jede subscription unter landingzones. Behandle das als Plattformänderung, nicht als Standardänderung pro spoke.

Hub-24/7-Alert-Routing¶

Optional, nur für hub-Ressourcen (ADR-0007). In <env-folder>/<region>/connectivity.auto.tfvars:

hub_247_support = {
  enabled          = true
  webhook_url      = "https://<your-on-call-tool>/webhook/<id>"   # required when enabled
  time_zone        = "W. Europe Standard Time"                    # default
  daily_start_time = "18:00:00"                                   # default
  daily_end_time   = "08:00:00"                                   # default
}

Das erstellt eine action group ag-<company>-hub247-<env>-<region>-001 und eine alert processing rule apr-<company>-hub247-<env>-<region>-001 in der connectivity-subscription. Standardmäßig deckt die Regel die Alertnamen ResourceHealthUnhealthyAlert und ServiceHealthIncident ab, für Firewall-, Virtual-WAN-, virtual-hub-, VPN-Gateway- und Application-Gateway-Ressourcen (variables_hub_247_support.tf).

Prüfen¶

Azure portal → Monitor → Alerts → Alert rules, gefiltert auf die subscription: Die Regeln existieren (zuweisen) bzw. es werden keine neuen erstellt (entfernen).
Policy → Compliance für Xebia Custom - Alerting - Landing Zone auf der subscription.

Rollback¶

Entferne den Tag oder die Ausnahme bzw. stelle die Management Group wieder her und führe die passende pipeline aus. Führe die remediation erneut aus, um gelöschte Regeln wieder anzulegen.