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

Azure Monitor is the single Azure service that collects telemetry from Azure resources, the platform itself, guest operating systems and applications, then lets you chart it, query it, alert on it and automate responses. Everything it collects is one of two data types, and most monitoring questions turn on picking the right one.

Metrics are lightweight numeric values captured at regular intervals, such as a percentage, a count or a number of bytes, stored in a time-series database built for fast charting. Platform metrics are collected automatically, with no agent and no configuration, and arrive in near real time. Logs are richer, structured records of discrete events, 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".

Platform logs come in three layers that are easy to confuse: the activity log (control-plane operations on resources, collected automatically), resource logs (what happens inside a resource, the data plane, collected only through a diagnostic setting) and Microsoft Entra logs (sign-ins and directory changes, part of Microsoft Entra ID rather than a subscription). The next sections cover each.

Metrics explorer is where you interpret metrics: you pick a scope (a resource), a metric namespace, a metric, an aggregation and a time granularity, and Azure draws the chart. Platform metrics such as Percentage CPU for a VM or Transactions for a storage account exist from the moment the resource is created.

The aggregation decides what the chart can show. Each point on the chart summarizes the raw samples inside one time grain:

• Avg shows the typical level, but smooths away short peaks and averages one hot instance with several idle ones.
• Max (and Min) expose spikes and troughs that Avg hides; use Max when you are hunting for a saturated resource.
• Sum adds the values in each grain, so it gives totals such as bytes sent or requests served per hour.
• Count is the number of samples (measurements) taken in the grain, not the total of their values.

Filtering and splitting both use dimensions, but they do opposite things. A dimension is a name-value pair attached to a metric, such as ApiName or ResponseType on storage transactions, or the instance name on a scale set.

For a scale set whose average CPU looks healthy while users complain, switch to Max and split by instance: one pinned instance then stands out as its own line.

Namespaces and retention. Platform (host) metrics live in the resource's standard namespace. Guest operating system counters that the Azure Monitor Agent sends to Azure Monitor Metrics through a data collection rule appear under a separate guest metrics namespace (for example azure.vm.windows.guestmetrics), so you must switch namespace to find them. Platform metrics are kept for a fixed 93 days, and one metrics explorer chart can span at most 30 days. For longer history, or to query metrics with KQL alongside other data, export them with a diagnostic setting to a Log Analytics workspace (they land in the AzureMetrics table) and set the retention there.

Azure Monitor Logs stores structured records in a Log Analytics workspace, the container you query to investigate behaviour across many resources at once. Each table holds rows with many columns: AzureActivity for the activity log, Event for Windows event logs, Heartbeat for agent check-ins, AzureDiagnostics or resource-specific tables for resource logs, AzureMetrics for exported metrics.

You query that data in Log Analytics with KQL, a read-only language where a query starts with a table and pipes it through operators: where to filter rows (for example where EventLevelName == "Error" to keep only error events, or contains to find text in a message), summarize to aggregate, project to choose columns, sort to order and render to chart. Two patterns come up repeatedly:

• A trend over time: summarize count() by bin(TimeGenerated, 1h) groups rows into hourly buckets, ready to render as a time chart.
• Machines that stopped reporting: a machine that sends nothing produces no rows, and KQL never invents a zero for a group that has no rows. So a query that counts recent records per computer and looks for a count of zero returns nothing. Instead, look back over a longer period, use summarize with max() (or arg_max()) to get each computer's most recent record time, and then keep the computers whose latest record is older than your silence threshold, for example an hour.

Retention is set per workspace and per table. Interactive (analytics) retention defaults to 30 days (the AzureActivity table keeps 90 days by default) and can be raised to two years; ordinary KQL queries reach that period. Beyond it, long-term (total) retention keeps data for up to 12 years at lower cost, but you reach it with a search job or by restoring the data, not with a normal query. Tables on the Basic plan cost less to ingest in exchange for limited query features. The workspace is also the boundary for access control and pricing.

The activity log is the subscription-level record of control-plane operations, every create, update, delete or action call made through Azure Resource Manager, together with the caller, the time and the status. It is collected automatically for every subscription with no setup and kept for 90 days.

• Recorded: creating or deleting a VM, editing an NSG rule, assigning a role, regenerating or listing storage account keys, starting or stopping resources.
• Not recorded: data-plane activity such as reading a blob or getting a key vault secret (those are resource logs, which need a diagnostic setting), and user sign-ins (those are Microsoft Entra sign-in logs).

To keep activity log entries longer than 90 days or query them with KQL, create a diagnostic setting on the activity log itself (configured at subscription level, separately from any resource's settings) and send it to a Log Analytics workspace, where it lands in AzureActivity and retention can be extended; a storage account or event hub works for archive or streaming. The activity log is also the signal for activity log alerts, described below.

A diagnostic setting is the configuration that sends a resource's resource logs and platform metrics somewhere you can keep or query them. Without one, resource logs are not collected at all. You choose the log categories (or a category group) and whether to include metrics, then the destinations.

Structure rules:

• One setting can send to several destinations, but holds at most one destination of each type. Sending the same logs to two workspaces therefore needs two settings; a resource can have up to five.
• The category groups allLogs (every category) and audit (the audit-relevant subset) are maintained by Microsoft, so categories added later are collected automatically. Individually ticked categories stay exactly as ticked.
• Settings are per resource and are not inherited from a resource group or subscription. To cover many resources, including ones created later, assign an Azure Policy with the DeployIfNotExists effect (built-in definitions exist per resource type) and run a remediation task to apply it to resources that already exist.
• Storage accounts are a special case: resource logs are configured on each service sub-resource (blob, file, queue, table) with the categories StorageRead, StorageWrite and StorageDelete; a setting on the account itself only exports metrics.
• The activity log has its own subscription-level diagnostic setting, covered in the previous section.

An alert rule watches one signal on a scope and fires when its condition is met. Each rule sets the condition, how often it is evaluated, a severity from Sev0 (critical) to Sev4 (verbose) and the action groups to call. The signal decides the rule type:

Service Health versus Resource Health: a Service Health alert reports Azure platform issues, planned maintenance and advisories affecting a service in a region you use; a Resource Health alert reports when one of your resources becomes unavailable or degraded.

Static versus dynamic thresholds. A static threshold is a fixed value you choose (CPU above 90%). A dynamic threshold lets machine learning learn the metric's normal pattern, including hourly, daily and weekly seasonality, and fires when the value leaves that band, above, below or either. You tune it with sensitivity (High fires on smaller deviations, Low only on large ones). It needs at least three days and 30 samples of history to start, and about three weeks to learn weekly seasonality. Persistence is a separate setting: the number of violations required within a number of evaluation periods (for example 4 of 4 five-minute periods = 20 minutes), which is how you ignore a single brief dip.

Dimensions in metric alerts. As in metrics explorer, you can filter a dimension to restrict what is counted (for example only the Authentication values you care about, so other traffic never reaches the threshold) or split by a dimension so each value (for example each scale set instance, or each storage GeoType) is evaluated as its own time series and fires its own alert naming that value. Filtering changes which data feeds one series; splitting changes how many series are watched. Choosing all current and future values makes the rule cover values that appear later without editing it.

An action group is a reusable list of who is notified and what runs when an alert fires: notifications (email, SMS, Azure mobile app push, voice) and actions (automation runbook, Azure Function, Logic App, webhook, secure webhook, ITSM, Event Hubs). Alert rules do not hold recipients themselves; they reference one or more action groups, and one action group can serve many rules. Turning on the common alert schema for an action gives one consistent payload format whether the alert came from a metric, log search or activity log rule, so a single Logic App or webhook can parse them all.

An alert processing rule changes what happens to fired alerts without editing the alert rules. It has a scope (subscription, resource group or resources), optional filters (severity, alert rule, monitor service, resource type and more; several filters must all match), one action and an optional schedule:

• Suppression stops action groups being called (for example during patching). Rules keep evaluating and alerts are still recorded, so nothing is lost; only notifications and actions are muted.
• Apply action groups adds an action group to every matching alert, so one rule can route alerts from many rules to a team.
• The schedule is always on, a one-time window, or recurring (daily or weekly), such as every weekday from 01:00 to 02:00 for a nightly backup job.

Processing rules cannot define recipients or actions of their own (they only suppress or apply existing action groups), do not change the alert payload and do not apply to Service Health alerts. Because filters narrow which alerts a rule touches, a suppression rule with a severity filter mutes only the severities it matches; alerts of any other severity keep calling their action groups as normal.

Insights are curated Azure Monitor experiences that pre-build the charts, queries and workbooks for one resource type, so you start from a finished view rather than a blank chart.

Virtual machines. Host platform metrics need no agent: CPU, network in/out, disk read/write bytes and operations, and now available memory (Available Memory Bytes and Available Memory Percentage). Anything only the guest operating system can see, such as free space per logical disk, page file usage, per-process counters, Windows event logs and Linux syslog, requires the Azure Monitor Agent plus a data collection rule (DCR) that says what to collect and where to send it (a Log Analytics workspace, Azure Monitor Metrics or both). The legacy Log Analytics agent was retired in August 2024; the Azure Monitor Agent is now the only supported agent for collecting guest logs and performance data. VM insights uses it to add guest performance charts, and its optional Map of processes and dependencies additionally needs the Dependency agent. Boot diagnostics is different again: it captures the serial log and a screenshot to troubleshoot a VM that will not start.

Storage accounts. Storage insights is built on aggregated platform metrics: capacity, transactions, availability, latency and throttling, across accounts. Compare two latency metrics: Success Server Latency is the time Azure Storage spent processing a request, while Success E2E Latency also includes the time to read the request from and send the response to the client. High end-to-end latency with low server latency points to the network or the client, not the storage service. Insights cannot show who made an individual request; for caller IP, authentication type or object URL per request you need storage resource logs sent through a diagnostic setting.

Networks. Network insights needs no setup: it shows the health and key metrics of network resources (virtual networks, load balancers, gateways, application gateways, public IPs and more) across subscriptions in one view, with a topology view of how they connect, and links to Network Watcher tools for diagnosis.

Azure Network Watcher is the regional toolkit for diagnosing network paths in and between virtual networks. Each tool answers a different question:

Reading the results. IP flow verify evaluates the NSGs on both the subnet and the NIC, but it ignores routing and appliances. If it returns Allow while the connection still fails, the cause is past the NSGs, so look at routing: run next hop to see whether a user-defined route sends the packets (or the replies) to a network virtual appliance, which might be down, lack IP forwarding, or be a stateful device that drops a flow because it sees only one of its directions. Next hop type None means the traffic is dropped, and has two sources: a System Route result comes from Azure's default routes for private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10) that are not in your address space or reachable through a peering or gateway, while a result showing a route table resource ID means a user-defined route with next hop None is dropping it.

Flow logs have changed. New NSG flow logs cannot be created since 30 June 2025 and the feature retires on 30 September 2027; virtual network flow logs replace them and cover traffic for the whole virtual network.

Connection monitor versus connection troubleshoot: connection troubleshoot is a single check you run now; Connection monitor runs tests on a schedule (for example every 30 seconds) between sources such as Azure VMs or on-premises machines and destinations such as VMs, URLs or IP:port endpoints, stores round-trip time and check-failure history, and raises alerts when a path degrades.