Skip to content
FR

Azure Monitor: Metrics, Logs, Alerts and Network Watcher

Step 27 of 30

Azure Monitor for AZ-104: Metrics, Logs, Alerts and Network Watcher

Introduction

Azure Monitor for AZ-104 connects metrics, collected logs and alerts with the operational question you need to answer. This lesson opens the AZ-104 skills area Monitor and maintain Azure resources (10–15% of the exam). The study guide objective is monitor resources by using Azure Monitor: configure and interpret metrics, configure Azure Monitor logs, query and analyze logs, set up alert rules, action groups and alert processing rules, configure and interpret monitoring of VMs, storage accounts and networks by using Azure Monitor Insights, and use Network Watcher and Connection monitor.

Monitoring answers three questions: is it healthy now (metrics), what happened and why (logs), and who needs to know (alerts). Exam questions usually describe an operational symptom, such as a VM at 95% CPU, a missing audit trail or an alert that fires but nobody is notified, and ask which Azure Monitor component fixes it.

After this lesson you will be able to choose between metrics and logs, route platform data to a Log Analytics workspace with diagnostic settings, collect guest data with the Azure Monitor Agent and data collection rules, write basic Kusto (KQL) queries, build alert rules with action groups and processing rules, and troubleshoot connectivity with Network Watcher.

Learning objectives

  • Distinguish platform metrics, resource logs, the activity log and guest OS data.
  • Create a Log Analytics workspace and configure diagnostic settings.
  • Install the Azure Monitor Agent and associate a data collection rule (DCR).
  • Write KQL queries with where, project, summarize, render and take.
  • Create metric, log search and activity log alert rules; attach action groups; suppress notifications with alert processing rules.
  • Use VM insights, storage insights and network insights.
  • Use Network Watcher tools and Connection monitor to diagnose connectivity.

The Azure Monitor data platform

Azure Monitor stores two main kinds of telemetry.

Metrics Logs
Shape Numeric values at regular intervals, stored in a time-series database Records with many properties, stored in a Log Analytics workspace
Latency Near real time (about one minute) Minutes of ingestion delay
Retention 93 days for platform metrics Workspace setting (30 days by default for interactive retention, configurable)
Query Metrics Explorer KQL in Log Analytics
Cost Standard platform collection is included; advanced/custom metrics, export and alerting can incur charges Depends on ingestion, table plan, retention and query features; some data is included
Best for Dashboards, threshold alerts, autoscale Investigation, correlation, auditing, complex alerts

Data comes from several sources:

  • Platform metrics: available automatically for supported resource types and metric definitions (CPU percentage of a VM host, Transactions of a storage account).
  • Activity log: a subscription-level record of control-plane operations (who deleted a VM, who changed a role assignment). It is kept for 90 days and is available without configuration. Send it to a workspace to keep it longer.
  • Resource logs: data-plane details (storage read requests, NSG rule counters, key vault access). They are not collected by default. You create a diagnostic setting to send them to a workspace, storage account or event hub.
  • Guest OS data: performance counters, Windows events and Syslog from inside a VM. They require the Azure Monitor Agent (AMA).

2026 note. The Log Analytics agent (MMA/OMS) retired in August 2024; Azure Diagnostics extensions (WAD/LAD) reached end of support on March 31, 2026. The Azure Monitor Agent with data collection rules is the supported way to collect guest data, and exam content refers to it.

Metrics

Open Monitor > Metrics or the Metrics blade of any resource. You pick a scope, a metric, an aggregation (average, minimum, maximum, sum, count) and a time range, and can split by a dimension. For a storage account, Transactions can be split by ResponseType to find throttling; for an App Service plan, CpuPercentage shows pressure.

Key points:

  • Metrics have a time grain (such as one minute); aggregation applies across that grain.
  • Dimensions allow filtering and splitting (for example by ApiName or instance).
  • Distinguish the metric namespace and the data destination. For detailed guest counters in Log Analytics, install AMA and configure a DCR (for example Windows \Memory\Available MBytes). The VM metric reference also lists available-memory signals: inspect the metrics actually populated for your VM rather than assuming every memory signal is absent. A platform chart is not a substitute for configuring the guest counters and workspace required by a question.
  • A chart can be pinned to a dashboard or workbook, and a metric can be turned into an alert rule.

Before changing capacity, relate the measurements to Azure VM sizing, disks and availability.

Worked example 1: find why a VM feels slow

Scenario. The Windows VM vm-erp01 (Standard_D4s_v5) is slow every weekday at 09:00. You need evidence, and you must find out whether memory is involved.

Step 1. In Metrics, scope to vm-erp01, choose Percentage CPU, aggregation Max, time range last 7 days. The chart shows peaks around 92% at 09:00 daily.

Step 2. Add Data Disk IOPS Consumed Percentage to check for storage throttling. It stays under 40%, so that disk IOPS limit is not the binding constraint. Check disk latency, bandwidth limits and queues as well before ruling storage out.

Step 3. The required detailed guest memory counter is not collected in the workspace. Install AMA, verify the VM identity and create a classic performance-counter DCR that collects \Memory\% Committed Bytes In Use to a Log Analytics workspace, then associate it with the VM.

Step 4. After a day, run a KQL query on Perf to confirm that committed memory reaches 95% at 09:00.

Solution. The CPU trend and high committed-memory percentage suggest pressure at start-of-day load. Check average CPU over the busy interval, available physical memory and paging before selecting a larger VM or scale-set architecture. Committed memory is measured against the commit limit; 95% committed is not automatically 95% physical RAM used. Increasing disk size alone does not address a confirmed CPU bottleneck. Why not enable autoscale on a single VM? Autoscale needs a scale set, not a single VM.

Log Analytics workspace and diagnostic settings

A Log Analytics workspace is the log store. Choices that matter:

  • Region: create it in a region that suits data residency; ingestion from other regions is possible but cross-region egress can be charged.
  • Access control: workspace access mode can use resource-context RBAC so teams only see logs from resources they can access.
  • Retention and table plan: Analytics tables normally start with 30-day query retention, with 90-day defaults for certain tables such as AzureActivity and Application Insights. Analytics retention can extend to 730 days; total retention can extend to 12 years. Basic and Auxiliary plans have different query, alert and retention capabilities: Basic normally provides a 30-day query window, while Auxiliary can query its total retention. Choose by required investigations and features, not ingestion price alone.
  • Daily cap: a safeguard that stops covered billable Analytics/Basic ingestion until the workspace’s reset time; Auxiliary is not covered. Overshoot is possible and billed, so this is not a hard spending limit. Data omitted during the pause cannot be recovered by raising retention. Prefer filtering and transformations to repeatedly hitting the cap.

A diagnostic setting belongs to a single resource (or the subscription activity log). It has a source (selected log categories and metrics) and up to several destinations.

Destination Use
Log Analytics workspace Query with KQL, alerts, workbooks
Storage account Cheap long-term archive; must be in the same region as the resource for resource logs
Event hub Stream to SIEM or third-party tools; for a regional source use a same-region Event Hubs destination
Partner solution Direct integration with supported partners

A resource can have up to five diagnostic settings, but one destination type cannot be targeted twice by the same setting. In resource-specific mode, tables are dedicated per category (cleaner schema and cost); the legacy AzureDiagnostics table is a shared table.

Bash
az monitor log-analytics workspace create -g rg-mon -n law-prod --location westeurope --retention-time 90

az monitor diagnostic-settings create --name to-law \
  --resource "$(az network nsg show -g rg-net -n nsg-web --query id -o tsv)" \
  --workspace "$(az monitor log-analytics workspace show -g rg-mon -n law-prod --query id -o tsv)" \
  --logs '[{"category":"NetworkSecurityGroupEvent","enabled":true}]'

These Bash examples assume the source resources and groups exist. Use full destination IDs across resource groups; list the source’s diagnostic categories before enabling them. The NSG event category above is a diagnostic log, not packet-flow logging. Subscription activity-log export uses a subscription-scope diagnostic setting.

Azure Monitor Agent and data collection rules

The Azure Monitor Agent is installed as a VM extension (AzureMonitorWindowsAgent or AzureMonitorLinuxAgent). It requires an appropriate managed identity and an installed agent extension as well as a DCR association. Guided portal onboarding can configure these together; creating only a DCR association through an API does not install the extension or ensure its identity and network connectivity.

A data collection rule (DCR) defines what to collect, optional transformations, and where to send it. You attach a DCR to a VM with a data collection rule association. One VM can have several DCRs, and one DCR can serve many VMs.

Typical DCR content:

  • Windows event logs (for example Security!*[System[(EventID=4625)]]).
  • Syslog facilities and severities for Linux.
  • Performance counters with a sampling rate.
  • Destinations and streams appropriate to the selected data source. The examples below use classic performance counters sent to Log Analytics Perf; VM insights uses InsightsMetrics. New OpenTelemetry guest-metric collection has its own destination and schema, so do not apply a Perf query to every metrics pipeline.

Arc-enabled servers use the same agent, so on-premises servers can be monitored the same way.

Exam tip. If a question asks how to collect memory or event logs from inside a VM and send them to a workspace, the answer is AMA plus a DCR, not a diagnostic setting.

Querying logs with KQL

A standard AMA Windows-events DCR sends events, including selected Security events, to Event. The Microsoft Sentinel Windows Security Events via AMA connector instead writes SecurityEvent. Confirm the collection path and table before querying.

KQL pipelines tables through operators separated by |. The operators to know:

Operator Purpose
where Filter rows
project Choose and rename columns
summarize Aggregate (count(), avg(), max()) by columns or bin(TimeGenerated, 5m)
sort by / order by Order results
top N by Highest rows
take N Any N rows (quick peek)
extend Add calculated column
render timechart Draw a chart
ago(1h) Relative time
KQL
// Security events collected by a standard Windows-events DCR into Event
Event
| where TimeGenerated > ago(24h) and EventID == 4625
| summarize failures = count() by Computer
| sort by failures desc
KQL
// Average CPU per 5 minutes
Perf
| where TimeGenerated > ago(24h)
| where ObjectName == "Processor" and CounterName == "% Processor Time"
| where InstanceName == "_Total"
| summarize avg(CounterValue) by bin(TimeGenerated, 5m), Computer
| render timechart
KQL
// Who deleted resources? (activity log sent to the workspace)
AzureActivity
| where OperationNameValue endswith "DELETE" and ActivityStatusValue == "Success"
| project TimeGenerated, Caller, ResourceGroup, Resource

The scope of a query is a workspace or a single resource. Saved queries and workbooks make results reusable.

Worked example 2: investigate blocked traffic

Scenario. Users report that a database port cannot be reached through an NSG. Virtual network flow logs with Traffic Analytics feed law-prod. Investigate inbound denials to the database VM at 10.0.2.10, by destination port, for a completed one-hour processing interval.

Step 1. Confirm VNet flow logs write to Storage and Traffic Analytics feeds NTANetAnalytics. A diagnostic setting on the NSG does not create these flow records. Allow for the configured 10- or 60-minute processing interval and subsequent ingestion delay.

Step 2. Query the right table, select the completed hour and denied inbound flows, and aggregate:

KQL
let intervalEnd = bin(ago(1h), 1h);
NTANetAnalytics
| where SubType == "FlowLog"
| where FlowIntervalStartTime >= intervalEnd - 1h and FlowIntervalEndTime <= intervalEnd
| where FlowDirection == "I" and DestIp == "10.0.2.10" and FlowStatus == "D"
| summarize denied = sum(DeniedInFlows) by DestPort
| sort by denied desc

Step 3. If port 1433 dominates, inspect the recorded ACL/rule and test the intended source flow before changing policy. A denial can be expected security behavior. Traffic Analytics aggregates records: count() counts aggregation rows, not original flows, so sum the appropriate flow-count field. Use a completed interval aligned with your collection window; processing delays can leave the newest interval incomplete.

Why not Metrics? Metrics cannot show which ports were denied; this requires log data and summarize by a property.

Alerts

An alert rule combines a scope (what to watch), a condition (signal and logic) and actions (via an action group). When the condition is met an alert is created with the rule’s severity (Sev0 critical to Sev4 verbose). Distinguish its monitor condition (Fired/Resolved) from its user response state (New/Acknowledged/Closed). Acknowledging an alert does not fix the monitored condition.

Alert rule types

Type Signal Typical use
Metric alert Platform or custom metric CPU above 85% for 10 minutes
Log search alert KQL query result More than 5 failed logons in 15 minutes
Activity log alert Control-plane event or Service Health Someone deleted a resource group
Service Health alert Azure incidents and planned maintenance Region degradation
Resource Health alert Health state of a single resource VM became unavailable
Smart detection Anomalies in Application Insights Failure rate spike

Metric alerts can use static thresholds or dynamic thresholds that learn the normal pattern. A metric alert can monitor multiple resources of a supported type in the same Azure region and subscription, and stateful alerts only fire once until resolved.

Key properties: evaluation frequency (how often the rule is checked), window size (how far back it looks), and aggregation. Pricing depends on alert type: metric rules are billed by monitored time series; scheduled log search rules also depend on evaluation frequency and, where applicable, dimension splits. Notification actions can have separate charges.

Action groups

An action group is a reusable list of notifications and actions:

  • Email, SMS, push and voice (limits apply per number and per hour).
  • Azure Function, Logic App, Automation runbook, webhook or Event Hub, according to supported action types.

One action group can be used by many alert rules, and one rule can use several groups. An alert rule without a directly attached action group still creates a portal alert. It has no direct notification action, but an alert processing rule can add an action group at firing time. Email notifications to Azure Resource Manager roles (for example Owner of the subscription) are available as an action type.

Alert processing rules

An alert processing rule (formerly action rule) modifies actions as matching alerts fire, outside the alert rule itself:

  • Suppress notifications during planned maintenance (one-off or recurring schedule).
  • Add an action group to every alert in a scope (for example all production alerts also page the on-call team).

They do not affect Azure Service Health alerts. When add and suppress rules both match, suppression takes precedence. They apply within the same subscription to a scope (subscription, resource group, resource) with optional filters (severity, resource type). The alerts are still created and visible; only the actions are suppressed or added.

Bash
az monitor action-group create -g rg-mon -n ag-oncall --short-name oncall \
  --action email ops ops@contoso.com

az monitor metrics alert create -g rg-mon -n alert-cpu-erp \
  --scopes "$(az vm show -g rg-erp -n vm-erp01 --query id -o tsv)" \
  --condition "avg Percentage CPU > 85" --window-size 10m --evaluation-frequency 5m \
  --severity 2 --action "$(az monitor action-group show -g rg-mon -n ag-oncall --query id -o tsv)"

Worked example 3: maintenance window without alert noise

Scenario. Every Saturday 01:00–03:00 the ERP servers in rg-erp are patched and reboot. Operations is paged for each reboot. Alerts must still be recorded.

Step 1. Do not delete or disable the alert rules; patching is the only time you want silence.

Step 2. Create an alert processing rule scoped to rg-erp, action Suppress notifications, with a recurring schedule on Saturday 01:00–03:00 in the right time zone.

Solution. Alerts are still created and visible for review, but the action groups do not run. Why not disable the rules? You would lose monitoring and may forget to re-enable them. Why not delete the action group? Other rules depend on it.

Azure Monitor Insights

Insights are curated experiences built on metrics and logs.

Insight What it shows Requirements
VM insights Performance monitoring across VMs AMA and a VM insights DCR; see the separate Map retirement note below
Storage insights Capacity, availability, latency and transaction errors across storage accounts Platform metrics only; no agent
Network insights Topology, health and metrics of network resources Platform data; no agent
Container insights AKS and container performance Agent in cluster
Application Insights Application telemetry SDK or auto-instrumentation

VM insights Map and Dependency Agent are deprecated and retire on June 30, 2028. New portal onboarding stopped on September 30, 2025; Microsoft advises against new Dependency Agent installations. Existing map data follows workspace retention. This retirement does not retire VM insights performance monitoring. Use the performance experience for new monitoring and plan a supported replacement for dependency mapping.

Use VM insights when you need a performance view across many VMs; use Metrics Explorer for a quick chart of one resource.

Network Watcher

Combine these tools with effective NSG rules and secure network access and Load Balancer health probes and DNS troubleshooting when metrics show an application connectivity problem.

Network Watcher is enabled per region for a subscription. Its tools support the AZ-104 troubleshooting objectives.

Tool Question it answers
IP flow verify Is a specific packet (protocol, ports, IPs) allowed or denied for a VM NIC, and which NSG rule decides?
Next hop Where is traffic from a VM to an IP routed (VNet, Internet, virtual appliance, none)? Reveals route table mistakes
Effective security rules Combined NSG rules applied to a NIC
Connection troubleshoot Can the source reach a destination, with latency and hops
Packet capture Captures packets on a VM (requires the Network Watcher agent extension)
VPN diagnostics Troubleshoots gateways and connections
VNet flow logs Supported flow records in Storage, optionally aggregated by Traffic Analytics into NTANetAnalytics
Topology Visual map of a virtual network

New NSG flow logs have been unavailable since June 30, 2025; existing NSG flow logs retire on September 30, 2027. Migrate new flow analysis to VNet flow logs instead of recommending a new legacy NSG flow-log deployment.

Connection monitor performs continuous tests between sources (Azure VMs, scale sets, Arc machines) and destinations (VMs, URLs, IPs) over TCP, ICMP or HTTP. It records round-trip time and failed checks in metrics and Log Analytics. Configure alert rules to notify on failed thresholds. Azure VM sources require the Network Watcher extension; hybrid sources need the documented Arc/AMA onboarding. Use it for ongoing detection; use Connection troubleshoot for a one-time diagnosis.

Retirement note. The classic Connection Monitor (classic) and Network Performance Monitor are retired. The current Connection monitor is the supported feature.

Common pitfalls and exam tips

  • Resource logs are not on by default. No diagnostic setting means no data-plane logs in a workspace.
  • Required destination matters. Detailed guest counters in Log Analytics need AMA, the correct DCR stream and a workspace destination; verify the actual namespace and table.
  • Activity log retention is 90 days; send it to a workspace for more.
  • Storage account as a diagnostic destination must be in the same region as the monitored resource.
  • Alert without a direct action group has no direct notification; check whether a processing rule adds or suppresses actions.
  • Suppress rather than disable during maintenance: use an alert processing rule.
  • Metrics versus logs for alerts: choose metrics for speed and low cost; choose log alerts for complex conditions.
  • IP flow verify identifies the exact NSG rule; Next hop finds routing mistakes.
  • Daily cap stops ingestion and can hide an incident.

Exam tip. When two answers both "work", choose the one that uses a built-in feature and the least administrative effort, such as an alert processing rule instead of scripts that disable alerts.

Mini case study: Fabrikam Logistics

Fabrikam runs 40 VMs for a warehouse application in rg-wms. Problems: (1) Nobody can prove who stopped a VM last month. (2) The operations team wants an email and a Teams message when average CPU stays above 90% for 15 minutes, but not during the Sunday backup window. (3) A VM cannot reach the SQL managed instance on port 1433 after a route change.

Questions. Which features address each issue?

Solution.

  1. The event from last month should still be in the activity log’s 90-day window; inspect its caller and operation now. Configure subscription export and suitable retention for future long-term auditing, then query exported records in AzureActivity. Export configuration does not recreate expired history.
  2. Create a metric alert (average Percentage CPU > 90, window 15 minutes) targeting the supported VM resource type in the required region(s) of the resource group, with one appropriate multi-resource rule per region. Use an action group with email and a Logic App that formats the Teams message; an arbitrary raw webhook payload is not automatically a Teams-compatible message. Add an alert processing rule that suppresses notifications on Sunday during the backup window.
  3. Use Next hop from the VM to the SQL IP to detect a route to a virtual appliance or None, and IP flow verify for port 1433 to see whether an NSG rule is denying it. Fix the route or rule. Use Connection monitor afterwards to detect regressions.

Why not alternatives? Disabling the alert on Sundays is manual and error-prone; metric explorer cannot show who acted; packet capture is heavier than IP flow verify for a first check.

Key terms

  • Metric / log: numeric time series versus record-based telemetry.
  • Activity log: subscription-level control-plane record, 90 days.
  • Diagnostic setting: routes resource logs and metrics to destinations.
  • Log Analytics workspace: log store queried with KQL.
  • AMA / DCR: agent and rules that collect guest data.
  • Action group: reusable set of notifications and actions.
  • Alert processing rule: modifies actions of fired alerts (suppress or add).
  • Network Watcher / Connection monitor: diagnostic tools and continuous connectivity tests.

Summary checklist

  • I can choose metrics or logs and know their retention and latency.
  • I can create a workspace and diagnostic settings, and name the valid destinations.
  • I know AMA plus a DCR collects guest OS data and legacy agents are retired.
  • I can write KQL with where, summarize, project, sort and render.
  • I can create metric, log and activity log alerts with action groups.
  • I can suppress notifications with an alert processing rule.
  • I can choose between VM, storage and network insights.
  • I can pick the right Network Watcher tool for a symptom and know what Connection monitor adds.

Official sources