Monitoring Rules (Assign / Remove for a Spoke)

How alerting works and how to roll it out: Monitoring and alerting.

Standard change: Assigning/Deleting managed Monitoring Rules (the standard managed monitoring rules) on an existing spoke.

Effect: the spoke's subscription and resources start, or stop, receiving the platform's standard Azure Monitor alert rules.

How monitoring is wired

The standard monitoring rules are Azure Monitor Baseline Alerts (AMBA) deployed with Azure Policy:

• Definitions: infra/deploy/foundation/policies/policy_definitions/alerts/** (87 definitions) and five initiatives in infra/deploy/foundation/policies/policy_set_definitions/alerts/: Alerting-ServiceHealth, Alerting-Management, Alerting-Connectivity, Alerting-Identity, Alerting-LandingZone.
• Assignments: infra/deploy/postdeployment/main_policies_alerts.tf, one per management group, switched on by 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 }
}

The keys cloudplatform and landingzones are required, because the code refers to them.

• Routing: the landing zone initiative deploys an alert processing rule in each landing zone subscription. The rule routes Sev0–Sev2 alerts to the platform action group ag-<company>-mgmtxpirit-<env>-<region>-001.

There is no per-spoke monitoring switch in the spoke JSON. A spoke gets the landing zone rules because its subscription sits under the landingzones management group, where Alerting-LandingZone is assigned with assignment name alerting_landingzone.

The policies use deployIfNotExists. Alert rules are created for new or changed resources, and for existing resources only through a remediation task.

Request fields

Field	Use
Monitoring Rule name	all (the standard set), or specific rules, e.g. VM CPU, Storage availability
Rationale	pull request / change record
Environment	spoke environment / subscription
Scope	spoke subscription, resource group or resource
Comments

Assign the standard rules to a spoke

1. Check placement. The spoke's managementGroupId must be a management group under landingzones (landingzones_corp, landingzones_online, or their children). If it is not, change it with Change spoke.
2. Check the assignment exists. In postdeployment.auto.tfvars, landingzones.deploy_alerting_landingzone = true.
3. Remove opt-outs. Make sure the spoke subscription and its resources do not carry the tag MonitorDisable with value true (see below).
4. Remediate existing resources. Remediation tasks are created automatically only when automatically_start_policy_remediation = true, and only when the assignment changes (ADR-0010). For an existing spoke, start one yourself:
5. Azure portal → Policy → Assignments → Xebia Custom - Alerting - Landing Zone → Create remediation task. Set the scope to the spoke subscription and remediate each policy you need. Or:

6. Azure CLI, per policy reference:

   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>"
   

Remove the standard rules from a spoke

Choose the narrowest mechanism that fits:

Mechanism	Scope	How	Notes
MonitorDisable tag	subscription, or a single resource	Add "MonitorDisable": "true" to the spoke JSON tags (subscription and canvas resources), or to the workload's own resources	76 of the 87 alert definitions skip resources whose tag MonitorDisable equals true. Subscription-level rules (service health, resource health, alert processing rule) check the subscription's tag. Resource rules check the resource's own tag. 11 of the 13 VM alert definitions (Compute/virtualMachines) do not check this tag.
Policy exemption	subscription / resource group / resource	Exemption on assignment alerting_landingzone (see Policy assignments → Exemptions)	Works for every definition, including the VM alerts. Can be limited to specific policies with policy_definition_ids.
Move management group	whole subscription	managementGroupId outside landingzones	Also changes which governance policies apply. Usually not what you want.

Existing alert rules are not deleted by any of these mechanisms. deployIfNotExists only stops creating them. Delete the rules that were already deployed by hand: Azure portal → Monitor → Alerts → Alert rules, filtered on the spoke subscription.

The MonitorDisable tag behavior comes from the policy definitions themselves. The sample configurations don't use it. Test it in canary first.

Change rules for all spokes

Switching deploy_alerting_landingzone changes monitoring for every subscription under landingzones. Treat that as a platform change, not a per-spoke standard change.

Hub 24/7 alert routing

Optional, for hub resources only (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
}

This creates an action group ag-<company>-hub247-<env>-<region>-001 and an alert processing rule apr-<company>-hub247-<env>-<region>-001 on the connectivity subscription. By default the rule covers the alert names ResourceHealthUnhealthyAlert and ServiceHealthIncident, for Firewall, Virtual WAN, virtual hub, VPN gateway and Application Gateway resources (variables_hub_247_support.tf).

Verify

• Azure portal → Monitor → Alerts → Alert rules, filtered on the subscription: rules exist (assign) or no new ones are created (remove).
• Policy → Compliance for Xebia Custom - Alerting - Landing Zone on the subscription.

Roll back

Remove the tag or exemption, or restore the management group, and run the matching pipeline. Re-run remediation to recreate deleted rules.