Azure Monitor: Metrics, Logs, and Alert Rules

Azure Monitor is the full-stack monitoring platform underneath almost every other observability feature in Azure: it collects telemetry, splits that telemetry into two distinct data types, and lets you query, visualize, or alert on whatever it finds. Metrics are lightweight numeric values sampled at regular intervals — think CPU percentage every minute. Logs are structured or free-form records stored in a Log Analytics workspace and searched with Kusto Query Language (KQL). Everything else in Azure Monitor — Workbooks, alert rules, action groups — sits on top of that metrics/logs split.

What Azure Monitor actually collects

Platform metrics and activity log entries flow in automatically the moment a resource is created — no configuration required. Beyond that baseline, three more sources feed the platform:

• Application telemetry, captured once an app is instrumented with Application Insights (covered in Azure Application Insights for web app performance monitoring).
• Guest OS telemetry from inside a virtual machine, gathered through a monitoring agent installed on the VM itself — this is how Azure Monitor sees inside the operating system, not just the Resource Manager layer.
• Custom resource logs, routed to a destination through a diagnostic setting.

That last point trips people up: without a diagnostic setting configured, a resource’s detailed logs generally aren’t sent anywhere for long-term storage — they evaporate after a short default window instead of reaching a Log Analytics workspace, storage account, or event hub.

Metrics vs. logs: the two core data types

Metrics and logs answer different questions, and the exam leans hard on you knowing which is which.

Aspect	Metrics	Logs
Format	Numeric time-series values	Structured or unstructured records, varying properties per type
Collection cadence	Regular, fixed intervals	Event-driven or on ingestion
Query method	Metrics Explorer, threshold charts	Kusto Query Language (KQL)
Storage location	Time-series database (no workspace needed)	Log Analytics workspace
Best suited for	Fast, near-real-time charting and alerting	Deep, flexible investigation and correlation

A metric doesn’t need a Log Analytics workspace at all — it lives in Azure Monitor’s own time-series store. A log record does need one: it’s collected into a workspace, and that workspace is what you query. Mixing these two up — for example, assuming metrics require KQL, or that logs are queried in Metrics Explorer — is one of the most reliably tested confusions on the exam.

Log Analytics workspaces and KQL

A Log Analytics workspace is the container where collected log data lands and becomes queryable. Two properties of a workspace matter beyond “where logs go”:

• Region determines residency. The Azure region you pick when creating the workspace fixes where the underlying log data is physically stored. If a client has a data-residency requirement — logs must stay within a specific country — that requirement is satisfied by choosing an in-country region at workspace creation, not by any setting elsewhere.
• Retention is configurable. You control how long ingested data stays interactively queryable before it ages out, and you can layer long-term archiving on top of a shorter interactive window. That combination — short interactive retention for routine troubleshooting, plus archived retention for compliance-driven multi-year requirements — satisfies a retention mandate without paying full interactive-query rates on data nobody is actively querying, and without anyone manually exporting files on a schedule.

Multiple subscriptions, one workspace: if a company wants VMs across several subscriptions to funnel diagnostic data into a single place one query can search, the answer is configuring all of them to send data into the same workspace — not a per-subscription workaround.

Once data is in a workspace, KQL is the language you use against it — purpose-built for filtering and summarizing large volumes of time-stamped, semi-structured data, unlike a relational language such as SQL or an automation shell like PowerShell.

Alert rules: signals, conditions, and action groups

An alert rule has two halves: a condition, evaluated against monitoring data, and one or more action groups, which define what happens when that condition is met. Azure Monitor supports several genuinely distinct signal types for the condition half:

• Metric alerts evaluate a numeric threshold over an evaluation window — the classic example is CPU percentage exceeding 90% for five consecutive minutes. They run on a near-real-time schedule, which is why they fit whenever a scenario emphasizes being notified quickly.
• Log search (scheduled query) alerts run a KQL query against a workspace on a recurring schedule and fire when the results meet a defined criterion — for example, more than five failed sign-ins in a 15-minute window, or checkout failures exceeding a threshold. Anything that requires counting or pattern-matching custom log data needs this signal type instead of a metric alert.
• Activity log alerts react to subscription-level management operations — a resource being created, modified, or deleted — rather than continuous telemetry. If a scenario asks for notification whenever anyone deletes a resource group, that’s an activity log alert watching the delete operation, not a metric or log query alert.

An action group is the reusable half of the equation: a named bundle of notification methods (email, SMS, voice call, webhook) and automated actions (invoking an Azure Function or Logic App) that any number of alert rules can reference, so a team defines its notification preferences once rather than reconfiguring them per rule.

Alert severity runs on a five-level numeric scale, Sev 0 (Critical) through Sev 4 (Verbose) — not a three-tier High/Medium/Low scheme and not a support-ticket P1–P5 scale, both of which are plausible-sounding distractors on this point.

Workbooks: combining everything into one report

Metrics charts, log query results, and narrative text can each be viewed separately — or combined into a single interactive, shareable canvas using Azure Monitor Workbooks. A Workbook doesn’t collect new data; it visualizes data that already exists into one report a non-technical stakeholder can open and understand at a glance. An alert rule reacts to data; a Workbook presents it.

How the AZ-900 exam tests this

• Metrics vs. logs discrimination. Expect a stem describing “lightweight numeric values at regular intervals” (metrics) paired against “structured records queried with KQL” (logs), sometimes with the roles deliberately swapped — read carefully before matching description to term.
• Choosing the right alert signal type. A numeric-threshold scenario (“CPU over 90% for five minutes”) wants a metric alert; counting custom events in application logs (“more than five failed sign-ins in 15 minutes”) wants a log search alert; an administrative action (“someone deletes a resource group”) wants an activity log alert. The exam tests whether you can match the scenario’s shape to the signal type.
• Tool-matching scenarios. Multi-part questions sometimes pair several unrelated needs — cost recommendations, application exceptions, planned maintenance, custom log queries — with the one tool purpose-built for each. Azure Monitor owns telemetry and alerting; it does not own cost recommendations (Advisor) or platform incident status (Service Health).
• Retention and compliance scenarios. A stem describing a multi-year retention requirement alongside a cost constraint tests whether you know archived retention on top of a shorter interactive window satisfies both — not that you should set interactive retention to the maximum everywhere, which is compliant but needlessly expensive.

Quick reference

• Metrics = lightweight numeric time-series data, no workspace required; Logs = structured records stored in and queried from a Log Analytics workspace.
• KQL (Kusto Query Language) is what you use to query logs — not metrics, and not SQL or PowerShell.
• A diagnostic setting is what routes a resource’s logs and metrics to a Log Analytics workspace, storage account, or event hub.
• A Log Analytics workspace’s region fixes data residency; its retention setting (interactive plus optional archive) controls how long data stays available.
• Alert rules pair a condition (metric, log search, or activity log signal) with an action group that defines the response.
• Action groups are reusable across many alert rules and support email, SMS, voice, webhook, and automated actions like Azure Functions.
• Alert severity is Sev 0 (Critical) through Sev 4 (Verbose) — a five-level scale, not three tiers.
• Workbooks combine metrics, log query results, and text into one interactive report; they don’t collect data themselves.

Once metrics, logs, and alert signal types stop blurring together, work through AZ-900 practice questions that mix all three inside the same scenario the way the real exam does.