6.1.2.2. Configure Action Groups

6.1.2.2. Configure Action Groups

💡 First Principle: Action groups are the fundamental mechanism for orchestrating automated responses to alerts, ensuring that operational issues are communicated to the right people and systems for rapid and efficient resolution.

Scenario: You need to configure an Azure Monitor alert for high CPU utilization on your production Virtual Machines. When this alert triggers, you want to receive an email notification, send an SMS message to the on-call engineer, and automatically trigger an Azure Automation runbook to restart the affected VM.

What It Is: An action group is a collection of notification and action preferences that are triggered by an Azure alert.

Purpose:

• When an alert fires, an action group determines the set of responses.

Common Action Types:

• Notification types:
  • Email, SMS, Push, Voice: Instantly notify individuals or teams.
  • ITSM Connector: Create tickets in tools like ServiceNow.
• Action types:
  • Webhook: Send alert data to external systems.
  • Automation Runbook: Launch scripts for automated remediation.
  • Logic App: Trigger complex workflows.
  • Azure Function: Execute custom code.
  • Event Hubs: Stream alert data to SIEMs.

Practical Implementation: Creating an Action Group with Azure CLI

# Create an action group
az monitor action-group create \
  --name "High-CPU-Actions" \
  --resource-group MyResourceGroup

# Add an email receiver to the action group
az monitor action-group update \
  --name "High-CPU-Actions" \
  --resource-group MyResourceGroup \
  --add-action email my-email-action myadmin@contoso.com

⚠️ Common Pitfall: Relying solely on email notifications. Emails can be easily missed. For critical alerts, use more intrusive methods like SMS or push notifications, and integrate with on-call management systems.

Key Trade-Offs:

• Notification vs. Automation: Notifications require human intervention. Automated actions (like restarting a VM) can resolve issues faster but carry a risk if the automation is not well-tested.

Alert Processing Rules: Changing What Fired Alerts Do

💡 First Principle: Alert rules decide when something is wrong. Alert processing rules decide what happens next for alerts that have already fired, across many alert rules at once.

Scenario: Every Saturday night the production VMs are patched and the on-call phone rings dozens of times. You want silence during the window without disabling alert rules that also cover other resources.

What It Is: An alert processing rule (formerly an action rule, so its resource type is still Microsoft.AlertsManagement/actionRules) modifies fired alerts as they fire. It doesn't create alerts and doesn't change how alert rules evaluate.

The two actions:

• Suppression: removes all action groups from the matching fired alerts, including the alert rule's own. The alerts still fire and remain visible in the portal, Resource Graph, API, and PowerShell.
• Apply action groups: adds one or more action groups to the matching fired alerts. This is also how you route alert types that can't choose an action group, such as Azure Backup alerts.
• If one fired alert matches rules of both types, suppression wins.

Scope, filters, and schedule:

• Scope: specific resources, a resource group, or an entire subscription, within the rule's own subscription.
• Filters (optional): alert rule ID or name, description, alert context, monitor condition, monitor service, resource, resource group, resource type, severity. Different filters combine with AND; up to five values within one filter combine with OR.
• Schedule: always on (default), a one-time window, or a recurring window such as weekly.
• A new or updated rule can take up to 30 minutes to take effect. Alert processing rules don't affect Azure Service Health alerts.

How to create one: In Azure Monitor > Alerts, select Alert processing rules (or Create > Alert processing rule), then work through the Scope, Rule settings (Suppress notifications or Apply action group), Scheduling, and Details tabs. From the CLI, az monitor alert-processing-rule create (in the alertsmanagement extension) takes --rule-type AddActionGroups or RemoveAllActionGroups.

Visual: Where Alert Processing Rules Act

⚠️ Exam Trap: Disabling an alert rule and suppressing its notifications aren't the same thing. A disabled rule creates no alerts at all, for every resource it covers. A suppression rule keeps the alert record and silences notifications only for the scope and time you choose.

Reflection Question: How do Azure Monitor action groups, by orchestrating automated responses with various notification types and action types, fundamentally ensure that operational issues are addressed quickly and efficiently, minimizing downtime and manual effort?