9.1 Azure Monitor Metrics, Logs, and Diagnostic Settings

Signal types and collection boundaries

Azure Monitor is the central monitoring platform for Azure resources, but the exam expects more than knowing the product name. You need to decide whether a problem should be solved with platform metrics, activity log events, resource logs, guest logs, diagnostic settings, or a Log Analytics query. The right answer usually depends on the source of the event and the operation the administrator must perform.

Metrics are numeric measurements collected at regular intervals. CPU percentage on a VM, storage account availability, disk read operations, HTTP server errors, and gateway throughput are metric-style signals. Metrics are useful when the requirement says near-real-time chart, threshold alert, autoscale, or quick capacity view. They are not the best fit when the requirement asks to search individual records, parse message text, join tables, or find the caller who changed a setting.

Logs are structured records stored in tables. Azure Monitor Logs, usually queried through a Log Analytics workspace, supports Kusto Query Language, or KQL. Logs are stronger for investigation because each record contains columns, timestamps, resource identifiers, status values, caller details, and message fields. Logs are also better for cross-resource questions, such as finding which VMs failed updates, which storage operations were denied, or which resources generated errors during a deployment window.

The activity log is a subscription-level control plane log. It records create, update, delete, policy, service health, security, recommendation, and administrative events. If a question asks who deleted a network security group rule, which policy denied a deployment, or when a VM size was changed, start with the activity log. If a question asks what an application wrote to stdout, what a firewall allowed, or which storage request returned 403, start with resource or guest logs.

Diagnostic settings

Diagnostic settings are the common routing mechanism for many Azure resource logs and selected metrics. They do not magically enable every data source in Azure. They are configured on resources, subscriptions, and some tenant-level services, and they choose categories plus destinations.

Portal path: Azure portal > Resource > Monitoring > Diagnostic settings > Add diagnostic setting. Select log categories, optionally metrics, then choose one or more destinations.

A common mistake is creating a Log Analytics workspace and assuming all resources automatically send diagnostic logs to it. Many platform metrics are available automatically, but resource logs usually require diagnostic settings. For VMs, guest OS performance counters and event logs require an agent and data collection configuration, not just a diagnostic setting on the VM resource.

Metrics and dimensions

Metrics live in a metrics database optimized for time-series operations. In Metrics Explorer, choose the scope, metric namespace, metric, aggregation, time range, and dimensions. Dimensions split a metric by properties such as status code, API name, disk, or instance. If a storage account has high total transactions, dimensioning by response type can quickly show whether the problem is throttling, authentication failures, or normal load.

CLI example:

az monitor metrics list \
  --resource <resource-id> \
  --metric "Percentage CPU" \
  --interval PT5M \
  --aggregation Average \
  --output table

Metric alerts evaluate metric values against thresholds. They are often faster and cheaper than log alerts for simple numeric conditions. Use a log query alert when the condition depends on filtering records, joining tables, or counting events that only exist in Log Analytics.

Workspace design and retention

A Log Analytics workspace is a regional data store and administrative boundary. Workspaces have retention settings and access controls. A centralized workspace can simplify cross-resource queries and alert management. Separate workspaces can support data residency, billing separation, environment isolation, or team boundaries. For AZ-104, do not assume one workspace is always correct. Match the design to region, operations ownership, and query needs.

Workspace access can be workspace-context or resource-context. With resource-context access, a user who can read a resource can view that resource's logs without gaining broad access to every table in the workspace. This matters when a central operations team owns the workspace but application teams should only see their own resources.

Implementation workflow

A practical monitoring setup for a production resource group follows a repeatable order:

1. Identify required signals: platform metrics, activity log, resource logs, guest logs, or application logs.
2. Create or select the Log Analytics workspace in the correct region and subscription.
3. Enable diagnostic settings on resources and subscription activity logs.
4. Configure VM data collection with Azure Monitor Agent when guest data is needed.
5. Verify ingestion by querying expected tables and checking timestamps.
6. Create workbooks, alerts, and action groups only after confirming data exists.

Example diagnostic setting command:

az monitor diagnostic-settings create \
  --name send-to-law \
  --resource <resource-id> \
  --workspace <workspace-resource-id> \
  --logs '[{"category":"AuditEvent","enabled":true}]' \
  --metrics '[{"category":"AllMetrics","enabled":true}]'

Categories differ by resource provider. On the exam, a command with a plausible category for one service might be wrong for another. In real administration, inspect supported categories first:

az monitor diagnostic-settings categories list --resource <resource-id> --output table

Troubleshooting collection gaps

If a workbook or alert shows no data, start with scope and ingestion. Confirm the resource has a diagnostic setting and that the selected category is enabled. Confirm the destination workspace is the workspace you are querying. Check the time range. Many investigations fail because the query is correct but the time picker excludes the event.

If activity log events appear but resource details do not, remember that activity log and resource logs are different sources. If VM CPU appears but Windows event logs do not, platform metrics are present but guest collection is missing. If data exists in a storage account but not Log Analytics, the diagnostic setting destination is archival rather than queryable.

Exam traps are usually wording traps. "Monitor administrative changes" points to activity log. "Query failed sign-ins" points outside ordinary resource metrics and into identity logs if configured. "Alert when CPU is above 90 percent" points to metric alerts. "Alert when more than five 403 storage requests occur in ten minutes" points to diagnostic logs plus a KQL query. "Keep raw logs for seven years" points to storage export or archive strategy, not a short interactive query.