2.3 Azure Monitor Metrics & Alerting Design

Why This Topic Matters on AZ-305

Recommend a monitoring solution is a single official Microsoft bullet broad enough that this guide splits it into two sections; this section covers the metrics and alerting half. Detecting a problem is only useful if someone gets notified fast enough to act — AZ-305 scenarios routinely test whether you picked the right alert signal type, the right evaluation configuration, and the right notification/automation mechanism for a given business requirement (for example, "notify the on-call engineer within five minutes" versus "open a ticket automatically").

Core Concepts: Alert Rules, Alerts, and Action Groups

An alert rule combines three things: the resource(s) monitored, the signal/data source, and the condition that must be met. When conditions are met, the rule fires an alert, which triggers an associated action group. Alerts in the portal are retained for 30 days.

Azure Monitor supports several alert types, and choosing the right one is the most heavily tested part of this topic:

Alert State Behavior

Alerts are either stateful or stateless, and the exam expects you to reason about when notifications repeat and when an alert is considered resolved:

• Stateless (all Activity Log alerts): fires every time the condition is met, with no concept of "already notified."
• Stateful (metric and log search alerts): fires once, stays in a fired state, and suppresses repeat notifications until the underlying condition clears and the rule marks it resolved.
  • A metric alert resolves after the condition is not met for three consecutive evaluation checks.
  • A log search alert resolves based on its frequency: at 1-minute frequency, after 10 minutes of the condition not being met; at 5-15 minute frequency, after three frequency periods; at 15 minutes-11 hours, after two frequency periods.

Exam trap: for a stateless metric alert configured with a frequency under 5 minutes, a repeat notification can arrive 1-6 minutes after the condition continues to be true; at 5 minutes or more, expect a notification somewhere between the configured frequency and double that frequency (a 15-minute rule can take up to 30 minutes to notify again).

Action Groups: Notifications and Automation

An action group is a reusable bundle of response actions triggered by one or more alert rules. It supports two categories:

• Notifications: email, SMS, voice call, push notification (via the Azure mobile app).
• Actions: Automation runbooks, Azure Functions, ITSM (IT Service Management) connector incidents, Logic Apps, secure webhooks, plain webhooks, and Event Hubs.

Alert processing rules sit on top of action groups and let you modify triggered alerts in flight — for example, suppressing notifications for a defined maintenance window, or adding an extra action group temporarily — without editing every underlying alert rule.

Alerting at Scale

Three patterns matter for enterprise-scale AZ-305 designs:

1. One metric alert rule across many resources of the same type in the same Azure region (for example, one rule watching CPU across an entire VM Scale Set fleet), with a separate notification fired per resource.
2. Workspace-wide log search alerts that can span resources across subscriptions and regions, as long as they send data to the same Log Analytics workspace; use splitting by dimensions on the resourceId column to get one alert per resource instead of one alert for the whole query.
3. Azure Policy-driven alerting, deploying the same alert rule definition across many subscriptions at once (for example, via the Azure Monitor Baseline Alerts pattern) — trades easy at-scale rollout for the ongoing maintenance overhead of a larger managed rule set.

Microsoft also ships recommended out-of-the-box alert rules for VMs, AKS clusters, and Log Analytics workspaces, which can shortcut initial designs before custom tuning.

Scenario Walkthrough

An application team needs to know within minutes if any VM in a 50-instance scale set exceeds 85% CPU for five sustained minutes, and they want an Automation runbook to automatically scale out the set, plus an email to the on-call engineer. The design uses one metric alert rule targeting the scale set as a whole (satisfying "one resource type, one region"), a static threshold of 85% over a 5-minute aggregation window, and an action group combining an Automation runbook action (auto-scale) with an email notification — a single alert rule and a single action group cover the entire fleet instead of 50 separate rules.

Key Takeaways

• Match the alert type to the signal: metric alerts for fast numeric thresholds, log search alerts for KQL-driven correlation, activity log alerts for control-plane/service-health events, smart detection for automatic Application Insights anomalies.
• Stateful alerts (metric, log search) suppress repeat notifications until resolved; stateless activity log alerts fire every time.
• Action groups separate notification channels (email/SMS/voice/push) from automated actions (runbooks, Functions, Logic Apps, ITSM, webhooks); alert processing rules modify in-flight behavior like maintenance-window suppression.
• Use dynamic thresholds for noisy or seasonal metrics instead of hand-tuned static numbers.
• Scale alerting with one multi-resource metric rule per region/type, or workspace-wide log search alerts split by resourceId, rather than duplicating rules per resource.