Monitor and maintain Azure resources

Azure Monitor overview

Azure Monitor collects metrics (numeric time series) and logs (records you query). Data comes from the platform, your resources, guest operating systems and apps.

Metrics

• Metrics Explorer charts platform metrics. Pick scope, metric namespace, metric, aggregation (Average, Min, Max, Sum, Count), and a time grain. Split by dimension (for example per API name or per instance) and filter by dimension values. Pin to dashboards or workbooks.
• Guest-OS metrics (memory, disk) aren’t platform metrics. Collect them with the Azure Monitor Agent (AMA) and a data collection rule.
• Interpreting: Percentage CPU is averaged across the VM. Use Max to spot spikes and Average for trends. Used capacity on storage updates slowly (hourly). Metric alerts can use dynamic thresholds (learned from history).

Logs and Log Analytics

Diagnostic settings

• A diagnostic setting routes a resource’s resource logs, platform metrics and the activity log to one or more destinations (up to five settings per resource):
  • Log Analytics workspace (query with KQL)
  • Storage account (cheap long-term archive; choose retention)
  • Event Hubs (stream to SIEM or other tools)
  • Partner solutions
• Create per resource, or in bulk with Azure Policy (DeployIfNotExists). Subscription-level activity log export is also a diagnostic setting. Destination must be in the same Region for storage accounts and for some services; workspaces can be in any Region.

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

Log Analytics workspace and agents

• A Log Analytics workspace stores logs in tables. You choose the Region, pricing (pay-as-you-go or commitment tiers), retention, a daily cap, and access mode (resource-context or workspace-context RBAC). Roles: Log Analytics Reader/Contributor, Monitoring Reader.
• To collect from VMs install the Azure Monitor Agent (AMA) (the Log Analytics agent (MMA) was retired in August 2024). AMA is configured with data collection rules (DCRs) specifying data sources (Windows event logs, Syslog, performance counters, text logs) and destinations. Arc-enabled servers use AMA too.
• Tables of interest: AzureActivity, Heartbeat, Perf, Event, Syslog, InsightsMetrics, AzureDiagnostics / resource-specific tables, StorageBlobLogs.

Query with KQL

Heartbeat
| where TimeGenerated > ago(1h)
| summarize LastBeat = max(TimeGenerated) by Computer
| where LastBeat < ago(10m)

Perf
| where ObjectName == "Processor" and CounterName == "% Processor Time"
| summarize avg(CounterValue) by Computer, bin(TimeGenerated, 5m)
| render timechart

AzureActivity
| where OperationNameValue endswith "DELETE" and ActivityStatusValue == "Success"
| project TimeGenerated, Caller, ResourceGroup, OperationNameValue

• Operators: where, project, summarize ... by, extend, count, top, order by, join, bin(), ago(), render. Queries flow through the pipe (|).
• Save queries, build workbooks and dashboards, and export to alerts. Use Log Analytics from a resource (scoped to that resource) or the workspace.

Alerts

An alert rule = scope + condition + action group (plus severity and name). Alerts have severity 0 (Critical) to 4 (Verbose) and a state (New, Acknowledged, Closed) plus a monitor condition (Fired, Resolved).

Action groups

• A reusable set of notifications and actions: Email, SMS, voice call, Azure mobile app push (notifications), and Automation Runbook, Azure Function, Logic App, Webhook, ITSM, Event Hub, Secure Webhook (actions). Created once, used by many rules. Notification rate limits apply (for example SMS and voice limited to one per five minutes per number).
• Roles: Monitoring Contributor to create rules.
• Action groups have a Region setting (global by default).

Alert processing rules

• Formerly action rules. They modify fired alerts without editing each rule:
  • Suppress notifications for a maintenance window (one-off or recurring) at a subscription, resource group or resource scope.
  • Add or replace action groups (for example route all Sev0 alerts for a resource group to the on-call group).
  • Can filter by severity, resource type, monitor service, alert rule name or description. Suppression doesn’t stop the alert from being created and visible; it stops the action group from running.

az monitor action-group create -g rg-mon -n ag-ops --short-name ops --action email admin admin@contoso.com
az monitor metrics alert create -g rg-mon -n cpu-high --scopes <vm-id> --condition "avg Percentage CPU > 80" \
  --window-size 5m --evaluation-frequency 1m --severity 2 --action ag-ops
az monitor activity-log alert create -g rg-mon -n vm-deleted --condition category=Administrative and operationName=Microsoft.Compute/virtualMachines/delete --action-group ag-ops

Insights

Azure Monitor Insights are curated experiences built on metrics and logs.

• Enabling VM insights from the portal installs AMA and creates the DCR and workspace link. Performance and Map are separate tabs. If the Map tab is empty, the Dependency agent isn’t installed.

Network Watcher and Connection Monitor

• Network Watcher is enabled per Region and is the toolbox for IaaS network diagnostics (one instance in NetworkWatcherRG is created automatically).

• Connection Monitor continuously tests connectivity between sources (Azure VMs, scale sets, on-premises machines with the agent) and destinations (VMs, URLs, IPs) using TCP, ICMP or HTTP, and records latency, packet loss and reachability, with alerts on thresholds. It supersedes the older Network Performance Monitor and Connection Monitor (classic). Data goes to a Log Analytics workspace.
• Use Connection troubleshoot for a quick one-time check; Connection Monitor for ongoing monitoring.

Azure Backup

Vaults

• A vault must be in the same Region as the resource it protects (for VMs). Create the vault, set storage redundancy, then set backup policy.
• Storage redundancy for the vault: LRS, ZRS, GRS (default GRS). Change it only before you protect any items. Cross Region Restore (CRR) needs GRS, and lets you restore to the paired Region.
• Soft delete retains deleted backup data for 14 days by default (always-on, can be extended, enhanced soft delete up to 200 days). Immutable vault and multi-user authorisation (Resource Guard) protect from malicious deletion. Deleting a vault requires stopping protection and removing all items.

az backup vault create -g rg-bk -n rsv1 -l westeurope
az backup vault backup-properties set -g rg-bk -n rsv1 --backup-storage-redundancy GeoRedundant --cross-region-restore-flag true

Backup policy and operations

• A policy defines schedule (daily or weekly, or hourly for Enhanced policy), time and retention (daily, weekly, monthly, yearly). Standard VM policy allows one backup a day; the Enhanced policy allows multiple backups per day and supports Trusted Launch and ZRS disks.
• Instant restore snapshots are kept locally for 1-5 days (default 2) for fast restore, with the rest in the vault.
• Backup of a VM needs the VM extension (installed automatically, requires the VM agent and outbound access to Azure Backup), and it takes a crash-consistent or application-consistent (VSS for Windows, scripts for Linux) snapshot. First backup is full, later ones incremental.
• Enable backup on a VM (az backup protection enable-for-vm), run Backup now (retention defaults to 30 days if not specified), stop protection and either retain or delete data.

Restore options for VMs:

az backup protection enable-for-vm -g rg-bk -v rsv1 --vm vm1 --policy-name DefaultPolicy
az backup protection backup-now -g rg-bk -v rsv1 -c vm1 -i vm1 --retain-until 30-12-2026 --backup-management-type AzureIaasVM
az backup restore restore-disks -g rg-bk -v rsv1 -c vm1 -i vm1 -r <recovery-point> --storage-account stcontoso001

• Azure Files backup uses share snapshots through the vault. SQL in VM needs the workload backup extension and discovery. MARS agent protects Windows files, folders and system state (encrypted with a passphrase you must keep).
• Reports and alerts: Backup Reports need a diagnostic setting sending backup data to a Log Analytics workspace; they show jobs, usage, policy adherence and trends. Backup alerts: built-in alerts (job failures, soft delete) are on by default and surface in the Business Continuity Center / Backup center and via Azure Monitor alerts; configure notifications through an action group. Check the Backup jobs blade for failures and the Backup items blade for last backup status.

Azure Site Recovery (ASR)

• Disaster recovery for Azure VMs between Regions, plus VMware, Hyper-V and physical servers to Azure. It replicates continuously, then fails over when needed. It lives in a Recovery Services vault in the target Region (the vault can’t be in the source Region for VM region-to-region DR).
• Enabling replication for an Azure VM:
  1. Choose source VMs, target Region, target resource group, VNet, subnet and availability options.
  2. Pick a replication policy: recovery point retention (default 24 hours) and app-consistent snapshot frequency (default 4 hours).
  3. ASR installs the Mobility service extension and uses a cache storage account in the source Region.
• Recovery plan: an ordered group of VMs (with groups, delays and manual or script actions) so multi-tier apps fail over in order; also for test failover.
• Test failover: creates VMs in an isolated test VNet with no impact on production or replication. Clean up test failover afterward. Do a test before relying on DR.
• Failover sequence: choose a recovery point (latest, latest processed, latest app-consistent, or custom) -> VMs start in the target Region -> Commit (discard other points) -> Re-protect (reverse replication back to the original Region) -> Failback (a planned failover back) -> re-protect again. Primary-region outages are unplanned failovers.
• Network considerations: on failover ASR assigns target IPs from the target subnet; map networks and (via recovery plan or scripts) public IP, load balancer, NSG settings. Site Recovery doesn’t replicate NSG rules or most networking by itself.
• ASR vs Backup: Backup = point-in-time recovery from corruption, ransomware and deletion (RPO hours to a day, restore takes time). ASR = business continuity during a regional outage (RPO seconds to minutes, RTO minutes).

# Vault context, then reverse replication / failover are done through the portal or Az.RecoveryServices cmdlets
Set-AzRecoveryServicesAsrVaultContext -Vault $vault
Start-AzRecoveryServicesAsrUnplannedFailoverJob -ReplicationProtectedItem $item -Direction PrimaryToRecovery