Azure Monitor Metrics vs Logs: Data Collection Rules and the Azure Monitor Agent

Azure Monitor is the collection layer underneath almost everything else you’ll configure for observability on the AZ-104 exam, and it splits every piece of telemetry it ingests into one of two fundamentally different data types. Metrics are numeric values sampled at regular intervals: CPU percentage, disk IOPS, queue length, the kind of thing you’d plot on a line chart and alert on when it crosses a threshold. Logs are structured or semi-structured records, timestamped events with varying properties, stored in a Log Analytics workspace and queried with Kusto Query Language (KQL). An administrator who can’t tell these two apart will misconfigure alert rules, retention, and data collection scope, which is exactly why the exam tests the distinction directly and repeatedly.

Metrics: lightweight, numeric, near real-time

Platform metrics are collected automatically for most Azure resources the moment they’re created, with no agent and no configuration required. They live in Azure Monitor’s own time-series database, not in a Log Analytics workspace, which means metric queries through Metrics Explorer don’t touch KQL at all and don’t incur Log Analytics ingestion charges. Because the collection cadence is fixed and the storage format is compact, metrics are what you reach for when you need fast, near-real-time charting or alerting, evaluating a threshold like “CPU over 90% for five minutes” is a metric alert’s job, not a log query’s.

Metrics have a real limitation, though: they can’t carry arbitrary structured detail. A metric is a number with a timestamp and a handful of dimensions, not a rich record you can filter on twenty different properties. When a scenario needs correlation across multiple fields, freeform text search, or joining data from different sources, that requirement points you toward logs instead.

Logs: structured records, queried with KQL, in a workspace

Logs need a Log Analytics workspace to land in. Activity log entries, resource logs routed through a diagnostic setting, and guest-OS telemetry collected from inside a VM all converge there as structured or unstructured records with properties that vary by data type. Once data is in a workspace, KQL is the query language you use against it, purpose-built for filtering, joining, and summarizing large volumes of timestamped, semi-structured data. This is a different tool from a relational language like SQL and a different tool from an automation shell like PowerShell, and the exam likes to offer both as wrong-answer distractors next to KQL.

Two workspace properties matter beyond “where logs go”:

• Region fixes data residency. Wherever you create the workspace is where the underlying log data is physically stored, which is how you satisfy an in-country residency requirement, not through any setting configured after the fact.
• Retention is configurable, with an interactive window you can extend and long-term archive retention layered on top for compliance needs that outlast what you want to pay full interactive-query rates for.

If several subscriptions need diagnostic data searchable from one place with a single query, the fix is configuring all of them to send data into the same workspace. That’s a many-to-one relationship: a workspace can receive data from many resources across many subscriptions, and a single resource can send data to multiple destinations if the scenario calls for it.

Metrics vs. logs at a glance

Aspect	Metrics	Logs
Format	Numeric time-series values	Structured or semi-structured records
Collection cadence	Regular, fixed intervals	Event-driven, on ingestion
Query method	Metrics Explorer	Kusto Query Language (KQL)
Storage	Azure Monitor’s time-series store, no workspace needed	Log Analytics workspace
Best suited for	Fast threshold-based charting and alerting	Deep investigation, correlation, custom queries

Data Collection Rules and the Azure Monitor Agent

Getting guest-OS data (Windows Event Logs, Syslog, performance counters, file-based logs, IIS logs) out of a VM and into Azure Monitor requires an agent running inside the guest, because without one Azure only sees the Resource Manager layer, not what’s happening inside the operating system. The current, supported agent for this is the Azure Monitor Agent (AMA). AMA doesn’t get configured per-machine the old way; instead, it applies Data Collection Rules (DCRs), centrally managed Azure resources that specify what data to collect, how to transform it, and where to send it. A single DCR can be associated with many machines through a data collection rule association (DCRA), and a single machine can carry up to 30 DCR associations, which is what makes AMA’s configuration model scale across a fleet in a way the older, per-agent configuration approach didn’t.

This matters on the exam because the agent AMA replaced, the legacy Log Analytics agent (also called the Microsoft Monitoring Agent, or MMA), is no longer a valid design choice. It was retired on August 31, 2024, and Microsoft has since gone further: cloud ingestion services for the legacy agent are being shut down entirely, and after March 2, 2026, data upload from any still-running legacy agent can stop at any time without further notice. If a current AZ-104 scenario describes deploying an agent to collect guest-level telemetry from a VM, the answer is the Azure Monitor Agent configured through a Data Collection Rule, full stop. The legacy agent should be read as a retired, unsupported option even if it appears as a plausible-sounding answer choice.

Alert rules: signals and action groups

An alert rule pairs a condition, evaluated against monitoring data, with one or more action groups that define the response. Azure Monitor supports several distinct signal types for that condition, and matching the right one to a scenario’s shape is a recurring exam pattern:

• Metric alerts evaluate a numeric threshold over an evaluation window on a near-real-time schedule. The classic case is CPU exceeding a percentage for several consecutive minutes.
• Log search (scheduled query) alerts run a KQL query against a workspace on a recurring schedule and fire when the result set meets a defined criterion, for example, more than five failed sign-ins within 15 minutes. Anything requiring counting or pattern-matching custom log data needs this signal type, not a metric alert.
• Activity log alerts react to subscription-level management operations, a resource being created, modified, or deleted, rather than continuous telemetry. Wanting notification whenever someone deletes a resource group is an activity log alert watching the delete operation. To prevent that deletion outright instead of just hearing about it, use a resource lock.

An action group is the reusable half of the pair: a named bundle of notification methods (email, SMS, voice, webhook) and automated actions (an Azure Function, a Logic App) that any number of alert rules can reference, so a team defines its notification preferences once instead of duplicating them per rule. Creating an alert rule requires Read permission on the target resource and Write permission on the resource group where the rule is created; the built-in Monitoring Contributor and Monitoring Reader roles cover most of this without needing broader access.

How the AZ-104 exam tests this

• Metrics vs. logs discrimination. A stem describes “numeric values at regular intervals” (metrics) or “structured records queried with KQL” (logs), sometimes with the roles swapped, testing whether you match the description to the correct term rather than the term you expect.
• Choosing the right alert signal. A numeric threshold (“CPU over 90% for five minutes”) wants a metric alert; counting custom events in application or security logs wants a log search alert; a management-plane action like a resource deletion wants an activity log alert.
• Agent selection for VM-level data. A scenario asking how to collect Windows Event Log or Syslog data from a VM wants Azure Monitor Agent configured with a Data Collection Rule. Any answer describing the legacy Log Analytics agent (MMA) as the solution is describing a retired, unsupported path.
• Workspace residency and retention. A scenario combining a data-sovereignty requirement with a multi-year retention mandate tests whether you know workspace region controls residency and archive retention on top of interactive retention satisfies long-term needs cost-effectively.
• Scaling data collection across a fleet. A scenario describing dozens or hundreds of VMs needing consistent monitoring configuration points to Data Collection Rules and DCR associations, not per-VM manual agent configuration.

Metrics, logs, DCRs, and alert signal types show up together constantly on the real exam, usually inside one scenario that expects you to separate which piece solves which part of the requirement. For the broader governance context these monitoring controls sit inside, see the AZ-104 study guide.