AZ-104: Monitor & Backup
Azure Monitor
What it is
Azure Monitor is the unified monitoring platform for all Azure (and some on-premises/other-cloud) resources. It collects, analyzes, and acts on telemetry — the data a resource emits — and turns it into insights, dashboards, alerts, and automation. It is the single pane of glass for “what is happening in my environment.”
Why it exists
Every resource generates telemetry, but raw data is useless. You need a central place to (1) collect telemetry, (2) store it durably, (3) query/visualize it, and (4) react when something is wrong. Without Azure Monitor you’d have hundreds of disconnected portals per resource.
Key ideas
- Two telemetry “pipelines”: time-series metrics and Log Analytics logs (KQL-queryable via KQL).
- Sources: platform telemetry generated by Azure, guest OS/VM diagnostics, application telemetry (via Application Insights), and custom metrics/logs.
- Data stores: Metrics store (retention ~93 days / 30 days default) + Log Analytics workspace (configurable retention).
- Act & react: alerts fire on signals and trigger action groups; data can feed workbooks/dashboards.
- Activity log (control-plane audit) is a separate log stream of management events.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-monitor/overview
Exam notes
- Know the three telemetry sinks: Metrics, Activity Log, Log Analytics — and what each holds.
- Metrics = numeric, time-series, granular performance. Activity log = control-plane/audit events (
who did what). Logs = diagnostic text/data queried with KQL. - Azure Monitor is the umbrella under which metrics, logs, alerts, and Application Insights live — many exam questions test “which tool for which job.”
Related
azure-monitor-metrics · azure-monitor-activity-log · log-analytics · kql · metric-alert · action-group · workbooks · application-insights · Home
📘 Source: Microsoft Learn — Azure Monitor
Azure Monitor Metrics
What it is
Azure Monitor metrics are lightweight, numeric, time-series values that describe how a resource is performing — e.g. CPU percentage, disk I/O, network bytes in/out. They are stored in a time-series database optimized for fast, sub-minute polling and near-real-time alerting.
Why it exists
Some signals are quantitative and time-based: you want to know the value at this exact moment and how it trends over 5 minutes/hours/days. Metrics give fast, low-cost, always-on monitoring with tight alert latency — unlike heavy log queries.
Key ideas
- Platform metrics are emitted by Azure services for free with no configuration (e.g. VM host CPU, storage account requests).
- Guest OS metrics (inside a VM: processes, guest CPU/memory) require the Azure Monitor Agent (Azure Monitor agent).
- Custom metrics can be pushed/injected by your apps or via the metrics API.
- Retained by default in a rollup (e.g. ~93 days as of 2024 depending on aggregation); high-res (1-min) retained less than coarse (hourly).
- Viewed as charts in metrics explorer, pinned to dashboards, or queried for metric alerts.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-monitor/essentials/data-platform-metrics
Exam notes
- No cost / no setup for platform metrics; a VM’s host metrics (CPU, network, disk) show immediately.
- To see in-VM (guest) performance metrics you must install the Azure Monitor Agent + enable diagnostics.
- Metric alerts are the fastest reacting alert type — good for “CPU > 90% for 10 min.”
- Don’t confuse metric alerts (metric signal) with log/log-analytics alerts (KQL query signal) or activity-log alerts.
Related
azure-monitor · metric-alert · log-analytics · workbooks · Home
📘 Source: Microsoft Learn — Azure Monitor Metrics
Azure Monitor Activity Log
What it is
The activity log (formerly audit log) is a subscription-level, control-plane log that records management events — everything that created, modified, or deleted a resource and who did it. It answers “who changed this VM and when?” It covers the management/control plane, not the data inside a VM.
Why it exists
You need auditability and accountability: to know who created a resource, who resized it, who deleted a storage account, and who assigned an RBAC role. The activity log gives a tamper-resistant record of management operations.
Key ideas
- Per-operation entries include: caller identity, which operation ran (e.g.
Microsoft.Compute/virtualMachines/write), resource, timestamp, correlation ID, and the result/status. - Categories/levels: Administrative (write/delete/action), Service Health, Alert, Autoscale, Security (Defender), Resource Health, Policy, Recommendation.
- Retained 90 days by default; for longer, route to a Log Analytics workspace (or storage/event hub).
- Can trigger activity-log alerts and feed action groups (e.g. alert when a VM is deleted).
- View in Azure portal → Monitor → Activity log; query with the activity-log or via KQL once exported.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-monitor/essentials/activity-log-insights
Exam notes
- Activity log = control plane / management events only — NOT guest OS or app data.
- It is subscription-scoped: one activity log per subscription, all resources.
- 90-day default retention; export to Log Analytics/logging for compliance beyond that.
- Activity-log alerts are a distinct alert type from metric and log alerts.
Related
azure-monitor · log-analytics · metric-alert · action-group · rbac · Home
Log Analytics Workspace
What it is
A Log Analytics workspace (LAW) is a dedicated container that stores logs (diagnostic data, activity log exports, Application Insights, custom telemetry) in a structured, queryable format. It is the log store of Azure Monitor, queried with the KQL language.
Why it exists
Metrics are great for numeric trends, but many signals are relational/text/event data — error messages, audit trails, slow queries — that you need to combine and search across. A workspace gives a central place to ingest, retain, and richly query log data.
Key ideas
- Tables hold typed data (e.g.
VMComputer,Heartbeat,AzureActivity,Perf); data lands with defined schemas. - Ingestion via diagnostics settings: send VM guest logs, activity log export, app logs to the workspace.
- Query with KQL (
| where,| summarize,| join,| render). - Retention (default 30-31 days for Pay-as-you-go; can extend to years) and interactive vs long-term retention buckets.
- Supports log-based alerts (schedule a KQL rule), workbooks, and dashboards.
- Each workspace is tied to a region and can collect from many subscriptions/resources.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-monitor/logs/log-analytics-overview
Exam notes
- Diagnostics settings define which logs/metrics stream where (LAW, storage, event hub).
- Know common tables for the exam:
AzureActivity(activity log),Perf/VMComputer(VM performance/logs via agent),Heartbeat. - Log alert = scheduled KQL query that triggers when results match; distinct from metric alerts.
- Workspace needs an agent/DIAG setting configured to actually receive data — data isn’t collected by default.
Related
kql · azure-monitor · azure-monitor-activity-log · workbooks · metric-alert · Home
📘 Source: Microsoft Learn — Log Analytics
Kusto Query Language (KQL)
What it is
KQL (Kusto Query Language) is the query language used to retrieve and analyze data from Log Analytics workspaces (and other Azure Monitor/Application Insights log stores). It’s how you turn raw log rows into meaningful analysis.
Why it exists
Log tables can hold millions of rows. KQL gives a fast, expressive, pipe-based way to filter, aggregate, join, sort, and visualize that data without writing heavy code.
Key ideas
- Pipe operator
|chains steps: each operator takes the record set and outputs a transformed one. - Core operators:
where(filter),project(pick columns),summarize(aggregate, e.g.count(),sum(),avg()by a group),sort/order,take/limit,join,extend. - Time filtering:
| where TimeGenerated > ago(1d); grouping:| summarize count() by Computer. render timechart / table / barchart / piechartto visualize.- Great for log-alert rules: the query’s result set triggers an alert when it returns rows/matches a threshold.
Example (memorize the shape)
AzureActivity
| where OperationNameValue contains "virtualMachines"
| where ActivityStatus == "Succeeded"
| summarize ActivityCount = count() by Resource, bin(TimeGenerated, 1h)
| order by ActivityCount desc
How it fits (diagram)
Exam notes
- Learn the pipe
|and the core operators — exam lab questions often ask to “filter X with KQL.” where= filter rows;project= select columns;summarize ... by ...= group + aggregate;bin()for time buckets.- Understand the difference between the three alert signals: KQL/log alert (query), metric alert (numeric), activity-log alert (event).
Related
log-analytics · azure-monitor · metric-alert · azure-monitor-activity-log · Home
📘 Source: Microsoft Learn — Kql
Metric Alerts
What it is
A metric alert is an Azure Monitor alert rule that watches a metric (a numeric signal) and fires when a condition is met — e.g. “CPU % > 90% for 10 consecutive minutes.” When triggered it activates an action group (email, SMS, webhook) and enters a fired state.
Why it exists
You can’t watch dashboards 24/7. Alerts automatically detect that a numeric signal crossed a threshold and notify/automate a response, giving sub-minute reaction times where metrics are available.
Key ideas
- Components: resource(s) to monitor + signal (metric) + condition & threshold + frequency of evaluation + action group + severity.
- Dynamic thresholds (algorithmic) can adapt to baseline instead of fixed numbers.
- States: fired / resolved; configured in Monitor → Alerts → Create alert rule.
- Alert processing rules can suppress/deselect notifications (e.g. during maintenance).
- Metric alerts give the fastest, lowest-cost detection vs log alerts.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-monitor/alerts/alerts-overview
Exam notes
- Know the four alert signals in Azure Monitor: metric, log (KQL), activity log, resource/availability.
- Threshold + frequency + condition are the configurable core; action group is the notification target.
- Severity (0-4) and alert state (new/acknowledged/closed in Alert Management) are distinct concepts.
- For VMs, host CPU metric alerts work out-of-the-box; guest metrics need the agent.
Related
azure-monitor-metrics · action-group · log-analytics · azure-monitor-activity-log · Home
📘 Source: Microsoft Learn — Metric Alert
Action Group
What it is
An action group is a named collection of notification/automation actions that an alert invokes when it fires. Common actions: email, SMS, voice call, Azure app (push) notification, webhook, ITSM, Automation runbook, Azure Function, or Logic App. Many alert rules share one action group.
Why it exists
An alert without a receiver does nothing. Action groups decouple “detect the problem” (alert rule) from “who gets told / what runs” (action group), so you configure the notification once and reuse it across many alerts. This avoids duplicating email addresses and webhooks on every rule.
Key ideas
- One alert rule → may reference one or more action groups.
- Actions run in parallel; each has its own configuration (recipients, webhook URL, custom JSON payload).
- Alert processing rules can suppress notifications (e.g. dynamic scale-out ignored) or deselect specific actions.
- Reusable across metric, log, and activity-log alerts — a key exam point.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-monitor/alerts/action-groups
Exam notes
- Action group = the notification target; alert rule = the detection. Both are needed to actually notify.
- Actions include: email, SMS, push, voice, webhook, ITSM (ServiceNow), runbook, Function, Logic App.
- You can create an action group with no actions and add actions later.
- Same action group reused across multiple alert rules is the “one-to-many” relationship to remember.
Related
metric-alert · azure-monitor · azure-monitor-activity-log · log-analytics · Home
📘 Source: Microsoft Learn — Action Group
Azure Workbooks
What it is
Azure Workbooks are interactive, customizable reports/canvases in Azure Monitor that combine multiple data sources (metrics, Log Analytics KQL queries, activity log, Application Insights) into a single rich document with text, charts, grids, and parameters.
Why it exists
Dashboards show tiles, but incident response needs contextual, parameterized, multi-source views — e.g. “pick an environment then see its VMs, their health, logs, and open alerts together.” Workbooks make that repeatable and shareable, with templates for common scenarios.
Key ideas
- Building blocks: steps combine text, parameters/drop-downs (e.g. select subscription), queries (KQL/metrics), and visualizations (time charts, grids, maps).
- Templates ship for many Azure services (VM, networking, storage) — customize or create from blank.
- Pin workbook parts to dashboards; share across a team/subscription.
- Uses live KQL and metric queries — reusable analysis, not static images.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-monitor/visualize/workbooks-overview
Exam notes
- Workbooks = interactive multi-source reports; dashboards = pinned tiles. Don’t confuse the two.
- Strongly tied to KQL and Log Analytics for rich queries.
- Templates and parameters are exam-relevant (“create an interactive monitoring report”).
Related
azure-monitor · log-analytics · kql · azure-monitor-metrics · Home
📘 Source: Microsoft Learn — Workbooks
Application Insights
What it is
Application Insights is an Application Performance Monitoring (APM) feature of Azure Monitor that collects application-level telemetry — requests, dependencies, exceptions, page views, traces — from live apps (web apps, functions, APIs, mobile). It’s the application observability layer, complementing platform infrastructure metrics.
Why it exists
Infrastructure monitoring (CPU, disk) tells you the host is fine but not why users are frustrated. Application Insights instruments the app itself to reveal request latency, error rates, failed dependencies (DBs, external APIs), and end-to-end distributed traces — the insight you need for debugging performance.
Key ideas
- Instrument apps with the SDK (or agentless for certain PaaS) sending telemetry to an Application Insights workspace (backed by Log Analytics).
- Signals: requests, dependencies, exceptions, traces, metrics, availability tests (URL ping from global locations).
- Rich views: Application Map (visual service dependencies), Live Metrics, Profiler/Snapshot Debugger (paid).
- Data stored in a Log Analytics workspace — query with KQL, feed workbooks and alerts.
- Availability / URL ping tests are a key monitoring feature.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-monitor/app/app-insights-overview
Exam notes
- App Insights = application (code) telemetry; Azure Monitor metrics/logs = infrastructure/platform telemetry.
- Data lives in a Log Analytics workspace and is KQL-queryable.
- Availability tests (ping from global locations) check a URL’s reachability — often a question topic.
- Instrument the app, not just the host.
Related
azure-monitor · log-analytics · kql · metric-alert · workbooks · Home
📘 Source: Microsoft Learn — Application Insights
Azure Backup
What it is
Azure Backup is Azure’s backup (data-protection) service. It takes secure, policy-driven backups (snapshots) of workloads — Azure VMs, on-premises servers (via MARS/MABS agents), SQL Server, Azure Files shares, and more — and stores them in a Recovery Services vault, from which you can restore.
Why it exists
Data loss protection for accidental deletion, corruption, or ransomware: you need reliable, retention-controlled, point-in-time copies you can restore on demand. Azure Backup provides managed, encrypted, off-server copies with a simple policy model — instead of scripting your own snapshot jobs.
Key ideas
- Workloads: Azure VMs (VM backup), on-prem → Azure (MARS agent or MABS), Azure Files shares, SQL Server / SAP HANA in VMs, blobs, and (managed) disks.
- Backup policy (Backup policy) defines what, when (schedule), and how long (retention) to back up — policy is applied via the vault.
- VM backup flow: uses snapshots (instant restores) stored in the vault + transfers data; backed up to the vault with vault-encrypted storage.
- Restore options: restore as a new VM, restore a disk, or restore to original/alternate location, from restore points.
- Security: vault-level encryption, soft delete, and checks against accidental deletion.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: backup/backup-overview
Exam notes
- Azure Backup = back up / restore (data protection); Site Recovery = disaster recovery replication (know the distinction).
- Backups are governed by a policy and land in a Recovery Services vault.
- VM backup supports instant restore via app-consistent snapshots.
- Vault must exist and a policy must be assigned before VM backups run.
Related
recovery-services-vault · azure-backup-policy · azure-site-recovery · azure-vm · Home
📘 Source: Microsoft Learn — Azure Backup
Recovery Services Vault
What it is
A Recovery Services vault is an Azure storage container that holds Azure Backup restore points and Site Recovery replication data for the workloads you protect. It is the central “ark” for both backup and disaster-recovery data.
Why it exists
Backups and replicas must live separate from the production resource so that a failure/accident on the source (deletion, ransomware, region outage) can’t destroy the protection copies. The vault provides a managed, encrypted, access-controlled store with a defined billing model.
Key ideas
- Holds both: Backup (restore points, backup items) and Site Recovery (replicated VMs, replication policies).
- Encryption at rest (platform key or customer-managed keys), soft delete (forgot/recovered-deleted backups), and RBAC control over access.
- Policy (Backup policy) is created/applied from within the vault.
- Vaults are regional — choose the region that balances cost + residency; backup/replication data is stored there.
- View backup items, job state, and run restore/failover from the vault blade.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: backup/backup-azure-recovery-services-vault-overview
Exam notes
- Name the vault-does-both: backup restore points + Site Recovery replication.
- Vault encryption settings are set at creation and apply to stored data; plan CMK if required.
- Soft delete must be considered when removing backups.
- Vault is a resource (RG-scoped, RBAC-controlled) — needed before you can enable backup or replication.
Related
azure-backup · azure-backup-policy · azure-site-recovery · azure-vm · Home
Azure Backup Policy
What it is
A backup policy defines when backups are taken (the schedule) and how long they’re kept (the retention). In Azure Backup, every protected workload is governed by a policy, created and stored in a Recovery Services vault.
Why it exists
You want backups to happen automatically on a schedule (not ad-hoc) and old restore points to be purged automatically to control cost/compliance. A policy encodes “back up daily at 22:00, keep 30 daily, 12 weekly, 5 monthly” as a reusable, managed rule.
Key ideas
- Schedule: daily and/or frequency per control (e.g. nightly) plus optional multiple points per day.
- Retention: keep N daily / weekly / monthly / yearly points (older granularities retained longer).
- Applied to protected items; changing a policy re-scopes future backups of those items.
- Can set instant restore retention for the snapshot actually kept locally.
- New policies typically override/retain prior retention for already-created restore points until they expire.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: backup/backup-architecture
Exam notes
- Policy = schedule + retention; applied from the vault to backup items.
- Retention is tiered: daily/weekly/monthly/yearly counts, with longer tiers kept longest.
- Backups are only as good as the policy — a misconfigured policy means missed/no backups.
- Each protected resource needs a policy to run scheduled backups.
Related
azure-backup · recovery-services-vault · azure-vm · Home
📘 Source: Microsoft Learn — Azure Backup Policy
Azure Site Recovery
What it is
Azure Site Recovery (ASR) is Azure’s disaster-recovery (DR) service that replicates workloads (mainly VMs) to another region/site and orchestrates failover/failback so that if the primary region goes down, a replica can be brought online in the secondary region. It keeps a live copy running, not just historical snapshots.
Why it exists
Backup (the distinction) protects against data loss but doesn’t keep your app running. Site Recovery protects against region/site downtime — when the primary location is unavailable, you fail over to the replica and keep serving users with minimal downtime (RTO) and data loss (RPO).
Key ideas
- Replicates Azure VMs (Azure→Azure) or on-prem VMware/Hyper-V/Physical (on-prem→Azure) to a secondary region.
- Continuous replication into a Recovery Services vault; controlled by replication policy (RPO, snapshot frequency, recovery points).
- Test failover validates DR without disrupting production; failover switches traffic to the replica; failback returns to primary.
- RTO/RPO: Recovery Time Objective vs Recovery Point Objective — tuned via policy.
- Requires cache storage (staging) in source region, target resources in destination, and the vault.
How it fits (diagram)
Exam notes
- Site Recovery = DR replication (keep it running); Azure Backup = backups (recover deleted/corrupt data). This is a top distinction question.
- Enabled from the Recovery Services vault; uses a replication policy (RPO/retention).
- Test failover is how you validate DR safely; real failover + failback complete the cycle.
- Understand RTO (time to recover) vs RPO (max data loss between recovery points).
Related
azure-backup · recovery-services-vault · azure-vm · azure-backup-policy · Home
📘 Source: Microsoft Learn — Azure Site Recovery