Azure Monitor: Metrics, Logs, Diagnostic Settings & Alerts (AZ-104)

Azure Monitor is a single service that gathers telemetry from Azure resources, the platform itself, guest operating systems, and applications, then lets you visualize it, alert on it, and automate responses. Everything it collects falls into two fundamental data types, and the exam expects you to tell them apart instantly.

Metrics are lightweight numeric values captured at regular intervals — a percentage, a count, a number of bytes — stored in a time-series database built for fast charting. They are collected automatically for most resources and are available in near real time. Logs are richer, structured records of discrete events — a sign-in, a configuration change, a diagnostic entry — stored in a Log Analytics workspace and queried with Kusto Query Language (KQL). Metrics answer "how much, how fast, right now"; logs answer "what happened, when, and why."

On the exam, a phrase like numeric near-real-time data points to metrics, while query events with KQL points to logs and Log Analytics.

Metrics are collected automatically for nearly every Azure resource the moment it is created — you do not have to turn them on. Each metric is a named numeric value sampled on a schedule, such as Percentage CPU for a virtual machine, Used capacity for a storage account, or request counts for an application. Because the data is numeric and time-stamped, Azure keeps it in a specialized time-series store that returns charts quickly and retains platform metrics for 93 days by default.

You interpret metrics in Metrics Explorer, found under the Monitoring section of any resource or in Azure Monitor itself. There you pick a metric namespace, choose a metric, and apply an aggregation — average, minimum, maximum, sum, or count — over a time grain. For example, charting the average Percentage CPU of a VM over the last hour shows whether it is under load. You can add filters and splitting by dimension to break one metric down, such as splitting transactions by response type.

Metrics shine when you need speed: because they are numeric and near real time, they drive live dashboards and the fastest alert rules. On the exam, remember that interpreting a numeric value over time — CPU, IOPS, latency — is a metrics task handled in Metrics Explorer, and no query language is required to read them.

Azure Monitor Logs stores structured records in a Log Analytics workspace, the central container you query to investigate behavior across many resources at once. Where metrics give you a single number over time, logs let you keep detailed rows — each with many columns — so you can filter, group, join, and correlate events. Platform logs, activity logs, guest operating system logs, and custom application data can all land in the same workspace.

You query that data with Kusto Query Language (KQL), a read-only language built for fast analysis. A KQL query starts with a table name and pipes it through operators: where to filter, summarize to aggregate, project to choose columns, and sort to order. For instance, you might take a heartbeat table, filter to the last day, and summarize a count by computer to find machines that stopped reporting. You run these queries in Log Analytics, then pin the results to a dashboard or turn them into a log alert.

A workspace is also a governance boundary: access control, data retention, and pricing are set per workspace. On the exam, whenever a scenario says you must query events with KQL, correlate records across resources, or retain detailed history, the answer involves Azure Monitor Logs and a Log Analytics workspace — not Metrics Explorer.

Resources emit platform logs and platform metrics, but by default most platform logs are not kept anywhere you can query. A diagnostic setting is the configuration that answers the exam's favorite question: where do the logs go? You create one per resource (or resource type) and choose which log categories and metrics to export, and to which destinations.

There are three destinations, and each maps to a purpose you should memorize:

• Log Analytics workspace — send data here when you want to query it with KQL, build alerts, or correlate across resources. This is the analysis destination.
• Storage account — send data here for cheap, long-term archival and audit retention, where you rarely query but must keep records for months or years.
• Event hub — send data here to stream it out of Azure to a third-party SIEM or external monitoring tool in near real time.

A single diagnostic setting can target more than one destination at once, so it is common to archive to a storage account and analyze in a workspace simultaneously. On the exam, the trigger route platform logs to a workspace means create a diagnostic setting pointing at Log Analytics; storage means archive; event hub means SIEM streaming.

An alert rule watches a signal and fires when a condition is met. The signal can be a metric (for fast, numeric thresholds) or a log query result (for anything you can express in KQL). Each rule defines the target resource, the condition and threshold, an evaluation frequency, and a severity from 0 (critical) to 4 (verbose). When the condition holds, the rule triggers whatever you attach to it — and what it triggers is an action group.

An action group is a reusable collection of notifications and actions: email, SMS, push, or voice notifications, plus actions such as a webhook, an Azure Function, a Logic App, or an automation runbook. It answers "who gets notified and what happens" when an alert fires. Alert processing rules sit on top, letting you suppress alerts during a maintenance window or route them to a different action group at scale, without editing every rule.

Scenario: You need to know the moment a production VM is overloaded. You create a metric alert rule on Percentage CPU with the condition greater than 90% for 5 minutes, severity 1. You attach an action group that emails the on-call engineer and triggers an automation runbook to scale up or restart the machine. During planned patching you add an alert processing rule that suppresses the notifications, so the team is not paged for expected spikes.

Beyond raw metrics and logs, Azure Monitor offers Insights — curated monitoring experiences that pre-build the queries, charts, and workbooks for a specific resource type, so you do not start from a blank page.

VM insights monitors the performance and health of virtual machines and their guest operating systems, and can map process-level dependencies between machines. It relies on the Azure Monitor Agent to collect guest data into a Log Analytics workspace. Separately, boot diagnostics captures a VM's serial console output and a screenshot of the boot screen, which is the first thing to check when a machine will not start. Storage insights surfaces capacity, transaction, availability, and latency metrics for storage accounts in one view, so you can spot throttling or growth trends without hand-building charts.

For networking, Network insights provides a topology view and health metrics across network resources such as load balancers, gateways, and public IP addresses. These Insights experiences are still built on the same two data types underneath — metrics for the numbers, logs for the detail — but packaged for a task. On the exam, when a question asks how to monitor a VM's guest performance, reach for VM insights and the Azure Monitor Agent; boot diagnostics is for diagnosing a machine that fails to boot.

Azure Network Watcher is the toolkit for monitoring and diagnosing network conditions in and between virtual networks. It is a regional service, and its tools answer connectivity questions that metrics alone cannot. Key capabilities to recognize on the exam include:

• Connection troubleshoot and IP flow verify — check whether traffic between two endpoints is allowed and, if blocked, which security rule stopped it.
• Next hop — show where a packet is routed, useful for diagnosing user-defined routes.
• NSG flow logs — record which traffic a network security group allowed or denied for later analysis.
• Packet capture — record actual packets on a VM for deep inspection.

Connection Monitor is the piece to know best: it continuously tests reachability, latency, and packet loss between endpoints — VM to VM, VM to a URL, or on-premises to Azure — over time, and alerts you when a path degrades. Unlike a one-off test, it runs on a schedule and stores results so you can see trends and raise alerts. On the exam, if a scenario needs ongoing measurement of network reachability and latency between endpoints, the answer is Connection Monitor within Network Watcher.