Log Alerts vs Metric Alerts vs Activity Log Alerts

Azure Monitor Alerts are a unified alerting system that proactively notifies you when conditions are met across your Azure resources. The system consists of three distinct alert types: Metric Alerts, Log Alerts, and Activity Log Alerts. Each type monitors a different data source and uses a different evaluation engine. The exam expects you to know exactly which data source feeds each alert type and the associated latency, cost, and configuration nuances.

Metric Alerts evaluate numeric time-series data collected by Azure Monitor Metrics. Metrics are lightweight, numerical values emitted by Azure resources at regular intervals (typically every 1 minute for most resources, but some emit every 5 minutes or 30 seconds for premium tiers). Metric Alerts can monitor a single metric (e.g., CPU percentage) or multiple metrics using dynamic thresholds. The evaluation engine runs every 1 minute for static thresholds and every 5 minutes for dynamic thresholds. The key characteristics: - Data source: Azure Monitor Metrics (time-series database) - Latency: Alert fires within 1-5 minutes of condition being met (typically <3 minutes) - Cost: Free for basic metrics; additional cost for custom metrics and multi-resource alerts - Supported conditions: Greater than, less than, greater than or equal, less than or equal, between, dynamic threshold (uses machine learning) - Frequency: Evaluation frequency is 1 minute for static thresholds, 5 minutes for dynamic thresholds - Number of dimensions: Up to 10 dimensions per metric - State: Fired/Resolved (stateful) – once fired, it stays fired until the condition is no longer met

Metric Alerts are ideal for real-time performance monitoring where low latency is critical. For example, you want to be alerted within 2 minutes if CPU exceeds 90%. They are not suitable for detecting patterns in log data or monitoring text-based events.

Log Alerts evaluate queries against Log Analytics workspaces. These queries can be complex, using Kusto Query Language (KQL) to search for specific text, aggregate counts, or detect anomalies over time. The evaluation engine runs the query at a defined frequency (from every 5 minutes to every 24 hours) and triggers an alert if the results meet a threshold. Key characteristics: - Data source: Log Analytics workspace (log data from Azure Monitor Logs) - Latency: Alert fires within 5-15 minutes (depends on query complexity and ingestion delay) - Cost: Pay per query execution (based on data scanned and frequency) - Supported conditions: Number of results >, <, =, or based on metric measurement (aggregate values) - Frequency: Configurable from 5 minutes to 24 hours - Query scope: Can span multiple workspaces, resources, or subscriptions using cross-resource queries - State: Stateful (fired/resolved) or stateless (each evaluation is independent) – configurable

Log Alerts are powerful for security monitoring, compliance, and custom scenarios where you need to analyze log content. For example, you might create a log alert that fires when more than 10 failed login attempts occur in 5 minutes. The trade-off is higher latency and cost.

Activity Log Alerts monitor events recorded in the Azure Activity Log. The Activity Log is a subscription-level log that records all control plane operations (e.g., create, update, delete resources) and service health events. These alerts do not monitor resource logs (e.g., IIS logs, application logs). Key characteristics: - Data source: Azure Activity Log (subscription-level, control plane) - Latency: Alert fires within 5-15 minutes (typical 5 minutes) - Cost: Free - Supported conditions: Specific operation name, status, resource type, resource group, event severity, and more - Frequency: Not configurable – evaluated continuously as events are written - Scope: Subscription-level or resource group-level - State: Fired/Resolved – stateful for most conditions

Activity Log Alerts are used for operational compliance, security monitoring (e.g., alert when someone deletes a resource), and service health notifications. They do NOT monitor data plane operations (e.g., reading blob data) – only control plane.

Each alert type has a separate evaluation engine: - Metric Alerts: The Metric Alerts engine runs inside Azure Monitor and checks the metric time-series data every 1 minute (static) or 5 minutes (dynamic). It uses a sliding window of the last N minutes (defined by the aggregation granularity). If the condition is met for the duration of the window, the alert fires. The engine is stateful: once fired, it remains fired until the metric returns to a non-alerting state. - Log Alerts: The Log Alerts engine submits a KQL query to the Log Analytics workspace at the configured frequency. The query runs against the ingested log data. The engine evaluates the query results (number of rows or a calculated metric) against the threshold. It can be stateful (fires until resolved) or stateless (each evaluation independent). The latency depends on ingestion delay (typically 30 seconds to 15 minutes) plus query execution time. - Activity Log Alerts: The Activity Log Alerts engine is an event-driven system that listens to the Activity Log stream. When a new event is written, it is matched against the alert rule conditions. If matched, the alert fires. There is no periodic evaluation; it is real-time with a small processing delay.

- Default evaluation frequency: 1 minute (static), 5 minutes (dynamic) - Default aggregation: Average over the last 5 minutes (configurable) - Cooldown period: None – alert fires immediately when condition is met - Maximum number of conditions per rule: 1 (but you can create multiple rules) - Log Alert:

- Default frequency: 5 minutes - Minimum frequency: 5 minutes (cannot be lower) - Maximum query time range: 1440 minutes (24 hours) - Number of results threshold: >0 by default - Activity Log Alert:

- No configurable frequency – event-driven - Maximum 100 active alert rules per subscription - Can filter by: Operation name, status, severity, resource type, resource group, resource, event initiated by

You can create alerts via Azure portal, CLI, PowerShell, or ARM templates.

Create a Metric Alert using Azure CLI:

az monitor metrics alert create \
  --name "High CPU Alert" \
  --resource-group "myRG" \
  --scopes "/subscriptions/sub-id/resourceGroups/myRG/providers/Microsoft.Compute/virtualMachines/myVM" \
  --condition "avg Percentage CPU > 90" \
  --description "Alert when CPU exceeds 90%" \
  --action "/subscriptions/sub-id/resourceGroups/myRG/providers/microsoft.insights/actionGroups/myActionGroup"

Create a Log Alert using Azure CLI:

az monitor scheduled-query create \
  --name "Failed Logins Alert" \
  --resource-group "myRG" \
  --scopes "/subscriptions/sub-id/resourceGroups/myRG/providers/Microsoft.OperationalInsights/workspaces/myWorkspace" \
  --condition "count 
  | where ResultType != 'Success' 
  | where TimeGenerated > ago(5m) 
  | count > 10" \
  --description "Alert when more than 10 failed logins in 5 minutes" \
  --action "/subscriptions/sub-id/resourceGroups/myRG/providers/microsoft.insights/actionGroups/myActionGroup"

Create an Activity Log Alert using Azure CLI:

az monitor activity-log alert create \
  --name "Delete Resource Alert" \
  --resource-group "myRG" \
  --scopes "/subscriptions/sub-id" \
  --condition category=Administrative operationName=Microsoft.Compute/virtualMachines/delete \
  --description "Alert when a VM is deleted" \
  --action "/subscriptions/sub-id/resourceGroups/myRG/providers/microsoft.insights/actionGroups/myActionGroup"

Alerts are closely integrated with Action Groups, which define the notification actions (email, SMS, webhook, ITSM, etc.). All three alert types can use the same action group. Alerts also integrate with Azure Monitor Workbooks, Dashboards, and Azure Automation runbooks for auto-remediation. For example, a Metric Alert can trigger an Automation runbook to scale out a VMSS.

Candidates often confuse the data sources:

Another common trap: thinking that Activity Log Alerts can monitor data plane operations like blob reads. They cannot; only control plane operations are recorded in the Activity Log. For data plane operations, you need resource logs (diagnostic settings) and Log Alerts.

Also, candidates often think Metric Alerts can evaluate complex KQL queries – they cannot. Metric Alerts only support simple numeric conditions. For complex queries, use Log Alerts.

Finally, latency: Metric Alerts are the fastest (1-5 minutes), Log Alerts are slower (5-15 minutes), and Activity Log Alerts are moderate (5-15 minutes). The exam may ask which alert type is best for time-critical scenarios.

| Feature | Metric Alert | Log Alert | Activity Log Alert | |---------|--------------|-----------|-------------------| | Data Source | Metrics | Logs | Activity Log | | Latency | 1-5 min | 5-15 min | 5-15 min | | Cost | Free (basic) | Pay per query | Free | | Complexity | Simple thresholds | Complex KQL queries | Simple filters | | Stateful | Yes | Configurable | Yes | | Use Case | Performance | Security, custom | Compliance, ops |

A large e-commerce company runs thousands of virtual machines (VMs) in a VMSS behind a load balancer. They need real-time alerts for CPU utilization exceeding 90% and memory usage exceeding 80%. They use Metric Alerts because latency is critical – if a VM is overloaded, they need to scale out within minutes. Each VM has a metric alert rule with a static threshold. They also use dynamic thresholds to automatically adjust for seasonal traffic spikes. In production, they found that static thresholds caused false positives during flash sales, so they switched to dynamic thresholds. The alerts trigger an Automation Runbook that adds more VM instances to the scale set. Misconfiguration: initially, they set the evaluation frequency to 5 minutes, which was too slow; they changed to 1 minute for faster response.

A financial institution needs to detect brute-force attacks on their Azure SQL databases. They use Log Alerts because the detection requires analyzing log patterns – failed login attempts over time. They send SQL Server audit logs to a Log Analytics workspace. The alert rule runs a KQL query every 5 minutes that counts failed logins per IP address in the last 5 minutes and alerts if the count exceeds 20. They also set up a stateless alert (each evaluation independent) to avoid missing repeated attacks. In production, the ingestion delay of logs (up to 5 minutes) plus query execution time means alerts fire 10-15 minutes after the attack begins. They accept this latency because the alternative (Metric Alerts) cannot analyze log content. Misconfiguration: they initially used a stateful alert, which caused the alert to not re-fire for the same IP address until resolved, missing subsequent attacks.

A healthcare organization must comply with HIPAA and needs to be alerted whenever a resource group is deleted or a VM is stopped. They use Activity Log Alerts because these are control plane operations recorded in the Activity Log. They create an alert rule that fires when the operation name equals 'Microsoft.Resources/subscriptions/resourceGroups/delete' or 'Microsoft.Compute/virtualMachines/deallocate'. The alert sends an email to the compliance team. In production, they also monitor 'Service Health' events to be notified of Azure outages. Misconfiguration: they tried to monitor blob reads (data plane) using Activity Log Alerts, which failed because data plane operations are not in the Activity Log. They had to use resource logs and Log Alerts instead.