Monitor VM Metrics and Alerts

You've deployed your virtual machines, configured networking, and locked down access with managed identity. But now your app is running in production—and you have no idea if it's healthy. The disk is filling up, CPU is peaking, and your users are experiencing slowdowns, but you only find out when someone opens a support ticket. This is the classic blind spot that monitoring VM metrics and alerts exists to eliminate. In this lesson, you'll learn how to watch your Azure VMs, set up proactive alerts, and catch problems before they become outages.

The problem this lesson solves

Without monitoring, you're flying blind. Every Azure VM generates a rich stream of metrics—CPU percentage, disk I/O, network throughput, and more—but none of that data helps you if you never look at it. Worse, waiting for users to report an issue means you're always reacting, never preventing.

Consider a typical scenario: you run a web server on a Standard_D2s_v3 VM. Over weeks, memory usage creeps upward due to a small leak. One afternoon, the VM hits 100% memory, swaps excessively, and your app becomes unresponsive. You only notice when the phone starts ringing. If you had been monitoring VM metrics and alerts, you'd have received an alert when memory crossed 80% days earlier, giving you time to investigate and fix the leak before it impacted anyone.

This lesson teaches you to:

• Navigate the metrics you get from Azure Monitor
• Visualize them in the Azure portal or with the CLI
• Create alerts that fire when thresholds are breached
• Troubleshoot common monitoring pitfalls

By the end, you'll turn raw data into actionable signals.

Core concept / mental model

Think of Azure Monitor as your VM's central nervous system. It continuously collects telemetry from your resources and makes it available in one place. VM metrics are the quantitative measurements—like a car's speedometer or fuel gauge. Alerts are the warning lights that turn on when those measurements go out of range.

Here's how the pieces fit together:

• Data source: Your VM sends performance counters (CPU, memory, disk, network) to Azure Monitor, typically every 30–60 seconds.
• Storage: Metrics are stored in a time-series database for 93 days by default, so you can query historical data.
• Query layer: You can view metrics in the portal's Metrics explorer, use az monitor metrics list, or query Log Analytics if you've enabled diagnostics.
• Alerts: Alert rules check conditions against metrics at regular intervals and trigger actions (email, SMS, webhook) when they're met.

Pro tip: Think of metrics as "what is happening right now" and alerts as "what should I care about before it becomes a problem."

How it works step by step

Let's walk through the process of monitoring a VM and setting up an alert.

Step 1: Identify the metrics that matter

Not all metrics are equal. For a typical web server, focus on:

• Percentage CPU: Should stay below 80% sustained
• Available Memory Bytes: Should stay above 1 GB
• Disk Read/Write Operations/Sec: Watch for I/O bottlenecks
• Network In/Out: Look for bandwidth saturation

You can also add guest-level metrics (memory, disk usage) by installing the Azure Monitor Agent and enabling diagnostics.

Step 2: Access the Metrics explorer

In the portal:

1. Navigate to your VM.
2. Select Metrics under Monitoring.
3. Choose a metric from the dropdown, e.g., Percentage CPU.
4. Adjust the time range (e.g., last 24 hours) and aggregation (average, max, min).

Step 3: Create an alert rule

An alert rule has three parts:

1. Scope: The VM you're monitoring.
2. Condition: A metric, operator, threshold, and evaluation frequency.
3. Action: A notification or automated response.

Step 4: Verify and test

After creating an alert, you should verify it fires correctly. You can generate load with a simple tool and check that the alert triggers, then confirm the notification arrives.

Hands-on walkthrough

Time to get your hands dirty. We'll use the Azure CLI for a scriptable, repeatable workflow. First, ensure you're logged in and have a VM running (for example, myVM in resource group myRG).

Create a metric alert

# Create a metric alert for CPU > 80% for 5 minutes
alert_name="my-cpu-alert"
resource_group="myRG"
vm="/subscriptions/$(az account show --query id -ojson | jq -r .)/resourceGroups/$resource_group/providers/Microsoft.Compute/virtualMachines/myVM"

az monitor metrics alert create \
  --name $alert_name \
  --resource-group $resource_group \
  --scopes $vm \
  --condition "Percentage CPU > 80 avg 5m" \
  --description "Alert when CPU is above 80% for 5 minutes" \
  --severity 2

Expected output:

{
  "id": "/subscriptions/.../resourceGroups/myRG/providers/Microsoft.Insights/metricAlerts/my-cpu-alert",
  "name": "my-cpu-alert",
  "severity": 2,
  "enabled": true
}

View metrics from the CLI

# Get average CPU over the last hour
az monitor metrics list \
  --resource "/subscriptions/$(az account show --query id -ojson | jq -r .)/resourceGroups/myRG/providers/Microsoft.Compute/virtualMachines/myVM" \
  --metric "Percentage CPU" \
  --time-grain 01:00:00 \
  --aggregation Average

Expected output shows a timestamp and average value, e.g., "total": 45.2.

Add an action group for notifications

# Create an action group to email your team
echo "your-email@example.com" | az monitor action-group create \
  --name "MyActionGroup" \
  --resource-group $resource_group \
  --short-name "ops" \
  --email receivers@example.com

# Link the alert to the action group
az monitor metrics alert update \
  --name $alert_name \
  --resource-group $resource_group \
  --add "actions" "group_id=/subscriptions/.../resourceGroups/myRG/providers/microsoft.insights/actionGroups/MyActionGroup"

Pro tip: Use an action group with multiple channels (email, SMS, webhook) so you don't miss critical alerts. For production, consider integrating with PagerDuty or Slack via webhooks.

Compare options / when to choose what

Azure provides multiple ways to monitor VMs. Here's a quick comparison:

When to choose what:

• Use portal metrics for a quick glance while debugging.
• Use CLI/API when you need to set up monitoring as part of IaC (e.g., Terraform or Bicep).
• Use Log Analytics when you need guest metrics like memory or when you want to run complex KQL queries.
• Use Application Insights if your focus is on application performance rather than VM health.

Troubleshooting & edge cases

Alert never fires

• Check condition syntax: In the CLI, quotes matter. Use "Percentage CPU > 80 avg 5m" — note the metric name with space and the aggregation at the end.
• Verify time window: Alert evaluations are coarse. A metric that spikes for 30 seconds won't fire a 5-minute window alert. Adjust the window to match your needs.

Metrics missing or empty

• Guest metrics require an agent: The default metrics (CPU, network) are host-level. For memory, you must install the Azure Monitor Agent.
• Data retention: Metrics are stored for 93 days. If you see gaps, check whether the VM was deallocated (metrics stop) or if there were network issues.

Alert fires too often

• Tune the sensitivity: Use a 5-minute window instead of 1-minute to avoid flapping. Also, you can use dynamic thresholds (in the portal) that adapt to normal patterns.

Security and permissions

• Required rights: To configure alerts, you need Microsoft.Insights/metricAlerts/write permission. Ensure your service principal has the Monitoring Contributor role.

What you learned & what's next

In this lesson, you learned to monitor VM metrics and alerts: you can now view CPU, network, and disk metrics in the portal or CLI, and create alerts that notify you before problems escalate. You also learned to compare different monitoring tools and troubleshoot common misconfigurations.

You've now completed the monitoring checkpoint in your Azure journey. The next lesson in this track will focus on automated scaling — using the exact metrics you've monitored to trigger scale-out operations. By understanding the health of your VMs, you're ready to let Azure automatically adjust capacity to match demand.