Lesson 19 — Azure Monitor: Metrics, Logs & Alerts

Why Monitoring Is Tested Differently from Other Domains

The monitoring domain in AZ-104 does not just test whether you know what Azure Monitor is — it tests whether you can configure monitoring correctly: which agent to use, what a diagnostic setting routes, where the Activity Log is stored, what an Action Group does, and the difference between a metric alert and a log search alert.

In production, monitoring failures are silent. A misconfigured diagnostic setting means audit logs are never collected. A missing agent means VM performance data is missing from dashboards. An alert without a correctly configured Action Group fires and notifies nobody. This lesson covers every component you need to configure monitoring correctly from first principles.

1. Azure Monitor — The Unified Platform

Azure Monitor is Microsoft's single unified monitoring platform for all Azure resources, hybrid VMs, and applications. It collects, analyses, and acts on telemetry from every layer of your Azure environment.

2. Metrics

Metrics are numeric time-series data points emitted by Azure resources at regular intervals (typically 1-minute granularity). They are designed for fast, real-time monitoring and alerting.

Platform metrics — automatic and free

Most Azure services emit platform metrics automatically. No agent, diagnostic setting, or configuration is required. They appear immediately in Metric Explorer as soon as a resource is created.

Metric dimensions

Many metrics support dimensions — additional properties that let you split a metric by a categorical attribute. For example, the Requests metric on an App Service can be split by the HttpStatusCode dimension to see how many requests returned 200, 404, or 500 separately.

Custom metrics

Applications can emit custom business metrics directly to Azure Monitor via the Azure Monitor REST API, Azure Monitor SDK, or OpenTelemetry. Custom metrics appear in Metric Explorer alongside platform metrics. They are billed based on the number of metric series ingested.

Metric Explorer

Metric Explorer is the portal tool for visualising and analysing metrics. Key capabilities:

• Plot multiple metrics from multiple resources on the same chart
• Apply aggregations: average, maximum, minimum, sum, count
• Split by dimension (e.g. CPU per VM in a VMSS)
• Add filters (e.g. show only East US resources)
• Pin charts to shared dashboards
• Set the time range from 30 minutes to 30 days (93 days of data available)

3. Logs and Log Analytics Workspaces

Logs are richer, structured records stored in a Log Analytics workspace — a dedicated storage and analytics engine built on Azure Data Explorer. Unlike metrics, logs require explicit configuration to collect, and they incur cost based on data ingestion volume and retention.

Log types

Log Analytics workspace

All Azure Monitor logs land in a Log Analytics workspace. Key facts:

• A workspace is a single Log Analytics resource deployed to a region — data is stored in that region.
• Multiple resources, subscriptions, and even tenants can send logs to the same workspace.
• Logs are stored in tables within the workspace (e.g. AzureActivity, SecurityEvent, Heartbeat, Perf).
• Queried with KQL (Kusto Query Language) — covered in Lesson 20.
• Default retention: 30 days free. Configurable up to 2 years (charges apply after 30 days).
• Data older than the interactive retention period can be archived to cheaper storage for up to 7 years.

4. Azure Monitor Agent (AMA) and Data Collection Rules

For VMs, platform metrics cover resource-level data (CPU%, disk IOPS from the hypervisor). But to collect OS-level data — Windows Event Logs, Syslog, IIS logs, custom performance counters — you must install an agent inside the VM. The Azure Monitor Agent (AMA) is the current, recommended agent.

Data Collection Rules (DCRs)

The AMA is configured via Data Collection Rules — Azure resources that define:

• What data to collect: which Windows Event Log channels (System, Security, Application), which Syslog facilities (kern, daemon, auth), which performance counter names and sample rates, IIS log paths
• Where to send it: one or more Log Analytics workspaces (or Azure Monitor workspace for metrics)
• Transformations: filter or reshape data before ingestion (e.g. drop verbose debug events)

5. Diagnostic Settings

For Azure PaaS resources (not VMs), you configure a diagnostic setting on the resource to route its platform logs and metrics to one or more destinations. This is separate from the Azure Monitor Agent (which is for VMs only).

What a diagnostic setting routes

• Resource logs (formerly "diagnostic logs"): operations that happened within the resource. Categories are service-specific (e.g. for Key Vault: AuditEvent; for SQL: SQLSecurityAuditEvents, QueryStoreRuntimeStatistics).
• Metrics: platform metrics sent to a Log Analytics workspace (where they can be queried with KQL) or to a storage account for archiving.

Destination options

Common exam scenario: configuring resource logs

Resource: Key Vault "prod-kv-eastus"
Diagnostic setting: "send-to-law-and-archive"
  ├─ Log categories: AuditEvent (who accessed which secret/key/cert)
  ├─ Destination 1: Log Analytics Workspace "law-central-eastus" (retention: 90 days)
  └─ Destination 2: Storage Account "starchiveprod001" (archiving: 2 years)

6. Activity Log

The Activity Log records all control-plane operations on Azure resources within a subscription. Every time anyone — a user, a managed identity, a service principal, or Azure itself — creates, modifies, or deletes an Azure resource, an Activity Log entry is created.

What the Activity Log captures

• Who performed the operation (identity: user UPN, service principal, managed identity)
• What operation was performed (resource type + operation name, e.g. Microsoft.Compute/virtualMachines/write)
• When it happened (timestamp)
• What the result was (Succeeded, Failed, Accepted)
• Which resource was affected (resource ID)
• The source IP of the operation

Retention and forwarding

7. Alerts

Azure Monitor alerts evaluate a signal (metric, log query result, activity log event) on a schedule and fire an alert when the signal meets a defined condition. Alerts are composed of three parts: the alert rule, the action group, and the alert state.

Alert rule types

Static vs. dynamic thresholds for metric alerts

Metric alerts support two threshold types:

• Static threshold: a fixed numeric value (e.g. CPU > 85%). Simple, predictable, but can produce false positives for workloads with expected patterns (e.g. Monday morning CPU spikes).
• Dynamic threshold: uses machine learning to learn the metric's normal pattern over time (including daily/weekly seasonality) and alerts when the metric deviates abnormally from the learned baseline. Reduces alert fatigue for variable workloads.

Alert states

Once fired, alerts go through a lifecycle:

• Fired: condition met, action group executed, notifications sent
• Acknowledged: engineer has seen and is investigating the alert (suppresses re-notifications)
• Resolved: condition no longer met (metric-based alerts auto-resolve; log alerts require manual resolution)

8. Action Groups

An Action Group is a reusable collection of notification and remediation actions that are executed when an alert fires. Action groups decouple the what happened (the alert rule) from what to do about it (the action group), enabling the same response process to be triggered by multiple different alerts.

Action types

9. Smart Groups and Workbooks

Smart Groups

When a widespread issue occurs (e.g. a networking outage affecting 50 VMs), Azure Monitor can fire 50 separate CPU alerts and 50 separate disk alerts — creating 100 notifications for what is essentially one problem. Smart Groups use ML to automatically correlate related alerts into a single Smart Group, reducing alert noise and enabling engineers to triage the root cause rather than processing individual alert instances.

Azure Monitor Workbooks

Workbooks are interactive, parameterised reports in the Azure portal that combine metrics, logs (KQL queries), rich text, and interactive controls (dropdowns, time range pickers) into a single reusable document. They are ideal for:

• Executive-level dashboards showing SLA compliance, availability, and cost trends
• Operational runbooks — a Workbook can both show diagnostic data and link to remediation steps
• Cross-resource analysis — combine metrics from VMs, databases, and load balancers on one canvas
• Shared team views — Workbooks can be saved to a Resource Group and shared via RBAC

10. Application Insights (Overview)

Application Insights is the application performance monitoring (APM) component of Azure Monitor. It provides code-level telemetry: request rates, response times, exception rates, dependency tracking (calls to databases, external APIs), distributed tracing, and user behaviour analytics.

For the AZ-104 exam, Application Insights is in scope at a high level. You need to understand what it does without deep configuration knowledge (which is more relevant to AZ-204 Developer exam):

• Application Insights requires an SDK or auto-instrumentation to be added to the application code (or App Service can enable auto-instrumentation without code changes).
• Data is stored in a Log Analytics workspace (workspace-based Application Insights) or in a classic Application Insights resource.
• Use Application Insights for application-level metrics (failed requests, exceptions, custom events) — use platform metrics for infrastructure-level data (CPU, disk).
• Smart Detection: automatic anomaly detection for application metrics (e.g. sudden spike in failure rate).