Episode 1 — Azure Monitor: the mental model
Series: AZ-104 · Monitor and Maintain Azure Resources — micro-learning. Where we are: This is the opening episode; it builds the skeleton that the rest of Part 1 hangs on before we drill into Episode 2.
Why it matters
Azure Monitor is Microsoft's unified observability service for collecting, analyzing, and acting on telemetry from cloud and hybrid environments. Almost every AZ-104 monitoring question — metrics, logs, alerts, insights, Network Watcher — is really a question about one part of this single service. Learn the mental model once and the whole domain becomes navigation instead of memorization.
Learning objectives
- By the end, you can describe Azure Monitor as one observability service and place any feature inside the collect → analyze → respond loop.
- By the end, you can distinguish the two data-platform workspace types and the query language each uses.
- By the end, you can contrast metrics vs logs — the anchor distinction for all of Part 1.
- By the end, you can name what Azure Monitor covers: cloud resources, infrastructure, applications, and AI agents.
- By the end, you can explain how hybrid resources are onboarded via Azure Arc and the Azure Monitor Agent (AMA).
The one idea: collect → analyze → respond
Everything in Azure Monitor is a stage in a single loop. When you meet a new feature later in this course, ask "which stage is this?" — that alone tells you what it does.
Mnemonic: "CAR" — Collect, Analyze, Respond. Azure Monitor drives every observability journey like a CAR.
Azure Monitor also underpins Defender for Cloud and Microsoft Sentinel: they reuse the same data platform, query languages, and analysis tools, so your investment in KQL and workspaces pays off beyond monitoring.
The data platform: two workspace types
The centralized data platform is where telemetry lands. It uses two workspace types, each optimized for different data. Despite the similar names, these are separate resource types with different data stores and query languages — a classic exam trap.
| Workspace type | What it stores | Query language | Analyze with |
|---|---|---|---|
| Log Analytics workspace | Log & trace data | KQL (Kusto Query Language) | Log Analytics |
| Azure Monitor workspace | Prometheus & OpenTelemetry metrics | PromQL (Prometheus Query Language) | Metrics explorer |
Mnemonic: Log Analytics → Language KQL; Azure Monitor workspace → Metrics + ProMQL.
We open up logs, KQL, and the Log Analytics workspace in Episode 3, and metrics in Episode 2.
The big anchor: metrics vs logs
If you remember one contrast from this course, make it this one. It reappears in every later episode.
| Metrics | Logs | |
|---|---|---|
| Shape of data | Numeric time-series | Rich records (structured events) |
| Freshness | Near-real-time | Queryable records, deeper detail |
| Query tool | Metrics explorer (PromQL) | Log Analytics (KQL) |
| Best for | Fast dashboards, autoscale, dynamic thresholds | Correlation, root-cause, troubleshooting |
Preview — control plane vs data plane: logs also split by who did what (the activity log, control plane) vs what happened inside a resource (resource logs, data plane). We wire up that data-collection pipeline in Episode 4.
What Azure Monitor covers (the four sources)
| Source | What it brings in | Notes |
|---|---|---|
| Cloud resources | Platform metrics & logs across Azure services, plus Microsoft Entra ID audit logs | Some services add curated Azure Monitor Insights (deep dashboards) — see Episode 6 |
| Infrastructure | VMs and Kubernetes health/performance; event logs + OpenTelemetry & Prometheus metrics | Network Watcher uses the Azure Monitor data platform — see Episode 7 |
| Applications | Application Insights, the OpenTelemetry (OTel) APM feature for live web apps | Vendor-neutral telemetry collection |
| AI agents | Application Insights across Microsoft Foundry, Copilot Studio, third-party frameworks | Surfaces token consumption, latency, error rates, quality scores |
Analyze and visualize
- Metrics explorer — ad-hoc analysis of metrics using PromQL.
- Log Analytics — ad-hoc analysis of log & trace data using KQL.
- Workbooks, Azure dashboards, and Grafana — prebuilt or custom visualizations in the portal.
These interactive tools are also your troubleshooting/diagnostics surface: investigate failures, correlate events, and find performance bottlenecks.
Respond
- Alerts proactively notify you before issues reach customers. AIOps capabilities use machine learning to reduce noise: dynamic thresholds (adapt to metric patterns) and smart detection (application anomalies). Full treatment in Episode 5.
- Action groups deliver the response — including no-code Logic Apps workflows and low-code Azure Automation runbooks.
- Autoscale automatically adds and removes resources based on load; rules can key off metrics, schedules, or both.
Hybrid & onboarding
Azure Monitor is not Azure-only — it can be a centralized monitor for hybrid environments.
- Azure Arc connects resources in other clouds and on-premises so you monitor them alongside Azure.
- The Azure Monitor pipeline extends data collection into your own datacenter/other clouds — built for large data volumes and intermittent connectivity.
- Onboarding methods: Azure portal, command line, or infrastructure as code (IaC) for scale.
- The Azure Monitor Agent (AMA) installed on VMs/servers collects logs and metrics according to your data collection rules — detailed in Episode 4.
Numbers & names to memorize
| Item | Value / Name |
|---|---|
| Core loop | Collect → Analyze → Respond |
| Workspace types | Log Analytics workspace (logs/traces) · Azure Monitor workspace (metrics) |
| Query languages | KQL (logs) · PromQL (metrics) |
| Anchor contrast | Metrics = numeric time-series, near-real-time · Logs = rich records |
| Four sources | Cloud resources, Infrastructure, Applications, AI agents |
| APM feature | Application Insights (OpenTelemetry / OTel) |
| AIOps alert features | Dynamic thresholds, smart detection |
| Hybrid connector | Azure Arc |
| Collection agent | Azure Monitor Agent (AMA) + data collection rules |
| Shared platform users | Defender for Cloud, Microsoft Sentinel |
Apply it
Scenario 1. Your team runs Azure VMs plus a fleet of on-premises Linux servers, and wants both monitored from one place in the Azure portal. What do you configure, and why?
Scenario 2. A dashboard must show CPU refreshing every minute for autoscale decisions, while a separate investigation needs to correlate detailed application events after an outage. Which part of the data platform and which query tool fits each need?
Q3 (single-answer). Which query language is used to analyze data in a Log Analytics workspace?
- A. PromQL
- B. KQL
- C. SQL
- D. OTel
Q4 (single-answer). Which statement about the Azure Monitor data platform is correct?
- A. Log Analytics and Azure Monitor workspaces are the same resource with two names.
- B. Azure Monitor workspaces store logs; Log Analytics workspaces store metrics.
- C. Azure Monitor workspaces store Prometheus/OpenTelemetry metrics; Log Analytics workspaces store logs & traces.
- D. Both workspace types are queried only with KQL.
Answers
- Scenario 1. Use Azure Arc to connect the on-premises servers, then deploy the Azure Monitor Agent (AMA) with data collection rules; Arc brings non-Azure machines under one Azure Monitor pane.
- Scenario 2. CPU-for-autoscale → metrics in an Azure Monitor workspace, viewed in metrics explorer (near-real-time, PromQL). Post-outage event correlation → logs in a Log Analytics workspace, queried with KQL.
- Q3 — B. Log Analytics workspaces are analyzed with KQL; PromQL is for metrics.
- Q4 — C. The two workspace types are separate resources: metrics (Prometheus/OTel) vs logs & traces.
Recap
- Azure Monitor = one unified observability service for cloud + hybrid telemetry.
- Organize everything as Collect → Analyze → Respond (the "CAR" loop).
- The data platform has two workspace types: Log Analytics (logs/traces, KQL) and Azure Monitor workspace (metrics, PromQL) — separate resources.
- The anchor contrast: Metrics = numeric, near-real-time; Logs = rich records.
- It monitors four source families: cloud resources, infrastructure, applications, AI agents.
- Respond with alerts (AIOps), action groups, and autoscale.
- Hybrid comes in via Azure Arc; agents onboard via AMA + data collection rules. The same platform also powers Defender for Cloud and Sentinel.
Next up
Episode 2 — Metrics & Metrics Explorer: zoom into the near-real-time, numeric half of the platform and learn to slice time-series like a pro.