Monitor and maintain Azure resources
Azure Monitor Signals, Logs, Insights, and Alerts
CoreRoute telemetry, query logs, interpret metrics and Insights, and connect alert logic to response and processing controls.
Aligned to the current AZ-104 study guide, verified August 21, 2026.
Why this matters
Operations depend on collecting the right signal at the right scope, retaining it in the right destination, and connecting detection logic to a useful response.
Must Know
- Metrics are numerical time-series signals suited to fast aggregation; logs are records queried for detailed context and relationships.
- Diagnostic settings route supported platform logs and metrics from a resource to destinations such as a Log Analytics workspace, storage account, or event stream.
- Log Analytics provides a workspace and KQL query experience for collected log data.
- An alert rule defines signal, condition, scope, and evaluation; an action group defines reusable notifications or actions.
- An alert processing rule changes action behavior for fired alerts, such as suppression during maintenance, without replacing detection logic.
- Azure Monitor Insights offers curated monitoring experiences for resources such as VMs, storage accounts, and networks.
Compare and Distinguish
- Metrics vs logs: numeric time series with dimensions and aggregation vs structured event or state records queried for detail.
- Alert rule vs action group: decide when an alert fires vs decide who or what is notified or invoked.
- Alert processing rule vs alert rule: alter actions after alerts fire vs evaluate the monitored condition.
- Insights vs raw metrics and logs: curated workbook and domain experience vs direct signal exploration and custom queries.
Scenario examples
- Scenario: Resource logs never appear in the workspace after deployment. Think: Verify diagnostic setting categories, destination, permissions, and ingestion time.
- Scenario: CPU must be evaluated every five minutes and page the on-call team. Think: Create a metric alert rule and connect it to an action group.
- Scenario: Alerts should still evaluate during maintenance but notifications should be suppressed. Think: Apply an alert processing rule for the maintenance scope and schedule.
Exam traps
- An action group by itself never detects a condition.
- Creating a workspace does not automatically route every resource log into it.
- An Insights page is not proof that all diagnostic categories are retained for arbitrary KQL analysis.
Key takeaways
- Choose the signal, collection path, analysis surface, detection rule, and response as separate steps.
- Use Insights for a curated starting point and metrics or logs when custom evidence is needed.
How it works
- Azure resources emit platform metrics and selected logs; diagnostic settings route supported data while workspaces index logs into tables.
- Alert rules evaluate their signal on a schedule or event basis, create alert instances, and invoke action groups subject to processing rules.
Objects and administrative surfaces
- Resource or subscription scope — metrics, activity log, diagnostic settings, and supported resource log categories.
- Log Analytics workspace — tables, retention, access, query scope, and KQL results.
- Azure Monitor — alert rules, action groups, alert processing rules, workbooks, and Insights experiences.
When to use it
- Use metrics for near-real-time numeric health and logs for detailed cross-resource investigation.
- Use Insights when a supported resource needs a ready-made operational view before deeper analysis.
Security and governance implications
- Control workspace query access and avoid exposing sensitive log fields through broad permissions.
- Route operational notifications to maintained groups or automation endpoints and govern changes to suppression rules.
How to reason about this
- For missing telemetry, trace resource emission, diagnostic category, destination configuration, ingestion delay, table, time range, and query filter.
- For a missing notification, verify the alert condition and state first, then action-group enablement and delivery, then processing-rule suppression.
More detail
- Interpret metric charts and dimensions, configure diagnostic destinations, run useful KQL filters and summaries, and connect alert conditions to actions.
- Configure or interpret VM, storage, and network Insights while recognizing the underlying signals and dependencies.
Ready for the quiz?
- Which signal type fits a CPU threshold and which fits detailed failure events?
- What configuration sends resource logs to a workspace?
- How do alert rules, action groups, and alert processing rules divide responsibility?
- When would Insights be faster than writing a custom query?
Related objectives
- D5.1.S1 — Interpret metrics in Azure Monitor
- D5.1.S2 — Configure log settings in Azure Monitor
- D5.1.S3 — Query and analyze logs in Azure Monitor
- D5.1.S4 — Set up alert rules, action groups, and alert processing rules in Azure Monitor
- D5.1.S5 — Configure and interpret monitoring of virtual machines, storage accounts, and networks by using Azure Monitor Insights