Azure Metrics
A DMC Azure VM scan collects weeks of real performance history from Azure Monitor, VM configuration from the ARM APIs, and, when guest access is configured, software inventory, network dependencies, and SQL Server instances from inside each VM. This page explains exactly what is captured and how to interpret it.
DMC collects only data needed for migration planning. No personally identifiable information, no application-level content. All collected data can be reviewed locally before uploading to Dr Migrate.
What you get¶
The data DMC collects depends on whether guest VM access is configured alongside the Service Principal.
| Data category | Without guest access | With guest access |
|---|---|---|
| VM configuration (size, location, OS, disks, NICs) | Yes: Azure Resource Manager APIs | Yes: Azure Resource Manager APIs |
| Azure Monitor performance metrics | Yes: configurable 1–90 day lookback (default: 7 days) | Yes: configurable 1–90 day lookback (default: 7 days) |
| Guest performance metrics (point-in-time from inside the VM) | No | Yes |
| Software inventory and installed applications | No | Yes |
| Active network connections and listening ports | No | Yes |
| SQL Server instance discovery | No | Yes |
| Azure Resource Inventory (networking, storage, databases, etc.) | Yes: Reader role, ARM APIs only | Yes: Reader role, ARM APIs only |
Metric-only scanning (no guest access) still provides comprehensive VM sizing data. CPU, memory, disk, and network performance over your chosen lookback period is sufficient for right-sizing decisions in many environments. Guest access adds application-layer context for deeper assessments.
Performance metrics¶
DMC pulls historical performance data from Azure Monitor for every VM, regardless of whether guest access is configured. The lookback period and granularity are configurable, so you can tune how much history is captured based on your assessment requirements.
| Setting | Options | Default |
|---|---|---|
| Lookback period | 1–90 days | 7 days |
| Granularity | 5 min, 15 min, 30 min, 1 hr, 6 hr, 12 hr, 1 day | 15 minutes |
| Aggregations fetched | Average and Maximum | Both |
| Computed statistics | Average, Peak (max), P95 (via linear interpolation) | All three |
For migration assessments, 30 days at 15-minute granularity captures typical weekly usage patterns, monthly batch jobs, and end-of-month peaks. The default of 7 days is a good starting point, but extend it if your workloads have monthly or seasonal patterns.
Batch optimisation: When collecting metrics for large environments, DMC prefetches Azure Monitor data for up to 50 VMs per API call, grouped by region. This significantly reduces API call volume and scan time for subscriptions with many VMs.
CPU¶
| Field | Azure Monitor source | Unit | Description |
|---|---|---|---|
cpu.metric_value | Percentage CPU | % | Average CPU utilisation over the lookback period |
cpu.metric_value_peak | Percentage CPU | % | Peak (maximum) CPU utilisation |
cpu.metric_value_p95 | Percentage CPU | % | 95th percentile CPU utilisation |
cpu.data_points | Percentage CPU | count | Number of non-null data points collected |
cpu.powered_on_hours | Derived from data points | hours | Hours the VM was running during the metric window |
cpu.powered_on_percent | Derived | % | Percentage of the metric window the VM was powered on |
Memory¶
| Field | Azure Monitor source | Unit | Description |
|---|---|---|---|
memory_pct.metric_value | Available Memory Bytes | % | Average memory utilisation (derived from available bytes and VM total memory) |
memory_pct.metric_value_p95 | Available Memory Bytes | % | 95th percentile memory utilisation |
memory_pct.data_points | Available Memory Bytes | count | Number of non-null data points collected |
Azure Monitor does not expose a direct memory utilisation percentage metric. DMC derives it from Available Memory Bytes and the total memory value from the VM size lookup. This means memory metrics are only available for VMs that were running during the lookback period.
Disk¶
Disk performance metrics are stored under disk_data.disk_metrics.aggregate and represent aggregate throughput and IOPS across all attached disks.
| Field | Azure Monitor source | Unit | Description |
|---|---|---|---|
read_avg_kbps | Disk Read Bytes | KB/s | Average disk read throughput |
read_p95_kbps | Disk Read Bytes | KB/s | 95th percentile disk read throughput |
write_avg_kbps | Disk Write Bytes | KB/s | Average disk write throughput |
write_p95_kbps | Disk Write Bytes | KB/s | 95th percentile disk write throughput |
read_iops | Disk Read Operations/Sec | IOPS | Average read operations per second |
read_iops_p95 | Disk Read Operations/Sec | IOPS | 95th percentile read IOPS |
write_iops | Disk Write Operations/Sec | IOPS | Average write operations per second |
write_iops_p95 | Disk Write Operations/Sec | IOPS | 95th percentile write IOPS |
Network¶
Network performance metrics are stored under network_data.metrics.aggregate.
| Field | Azure Monitor source | Unit | Description |
|---|---|---|---|
net.received.average | Network In Total | KB/s | Average inbound network throughput |
net.received.p95 | Network In Total | KB/s | 95th percentile inbound throughput |
net.received.total_gb | Network In Total | GB | Total inbound data over the lookback period |
net.transmitted.average | Network Out Total | KB/s | Average outbound network throughput |
net.transmitted.p95 | Network Out Total | KB/s | 95th percentile outbound throughput |
net.transmitted.total_gb | Network Out Total | GB | Total outbound data over the lookback period |
VM configuration¶
VM configuration is always collected via Azure Resource Manager APIs, regardless of guest access. This includes everything Azure knows about the VM: size, OS image, disk attachments, NIC configuration, and current power state.
| Field | Source | Description |
|---|---|---|
server_name | ARM Compute API | VM display name |
OSName | ARM Compute API | OS name: populated with the full name when guest access is available; Unknown otherwise |
vm_size | ARM Compute API | Azure VM size (e.g. Standard_B4ms) |
number_of_cores | ARM (VM size lookup) | Number of vCPUs |
memory | ARM (VM size lookup) | Total memory in MB |
number_of_disks | ARM Compute API | Number of attached disks (OS + data) |
number_of_nw_adapters | ARM Compute API | Number of attached NICs |
server_type | Static | Always Virtual for Azure VMs |
hypervisor | Static | Always Azure |
boot_type | ARM Compute API | Boot type: BIOS or UEFI |
bios_uuid | ARM Compute API | Azure VM unique identifier (GUID) |
power_state | ARM Instance View | Current power state: running, stopped, or deallocated |
azure_region | ARM Compute API | Azure region (e.g. eastus, australiasoutheast) |
azure_resource_group | ARM Compute API | Resource group name |
disk_data | ARM Compute API + guest | Disk configuration and performance: see below |
network_data | ARM Network API + Azure Monitor | NIC configuration and network performance |
Disk data structure¶
The disk_data object contains both configuration details (always available) and performance metrics and filesystem details (when guest access is configured).
| Field | Description |
|---|---|
disks | Map of attached disks, each with: disk_name, capacity_gb, disk_type (os or data), storage_type (e.g. Premium_LRS), and optional lun |
disk_metrics.aggregate | Aggregate disk performance: see Disk metrics above |
filesystems | Guest access only: array of filesystems with mount_point, size_gb, used_gb, fs_type, and physical_device |
collection_start_time | Start of the metric collection window |
collection_end_time | End of the metric collection window |
Network data structure¶
| Field | Description |
|---|---|
ip_addresses | Private IP addresses from all attached NICs |
adapters | Network adapter details |
metrics.aggregate | Network performance: see Network metrics above |
collection_start_time | Start of the metric collection window |
collection_end_time | End of the metric collection window |
Guest-level data¶
When guest access is available (via Managed Run Command, WinRM, or SSH), DMC executes collection scripts inside each VM to gather data that Azure Monitor cannot provide: installed software, active network connections, and SQL Server instances. The data collected varies by OS:
- Windows Metrics: software inventory, OS details, server roles, active processes, and network dependency map
- Linux Metrics: package inventory, system information, and network dependency map
- SQL Server Metrics: SQL Server instance discovery and database configuration details
If no guest access method is available, DMC marks the scan as partial. Azure Monitor performance data and VM configuration are still collected and exported.
Azure Resource Inventory¶
Resource Inventory uses the ARM API with Reader role only, with no guest access or VM credentials needed. It maps the broader Azure estate your VMs depend on, covering networking, databases, storage, messaging, and more. This is particularly valuable for understanding migration dependencies beyond just the VMs themselves.
Some resource types (Private Endpoints and VNet Gateways) require a resource group filter to be set during scan configuration because Azure has no subscription-wide list API for them. Without a filter, these types are automatically excluded from the scan.
Common fields (all resource types)¶
| Field | Description |
|---|---|
azure_resource_id | Full Azure resource ID path |
name | Resource name |
resource_group | Resource group the resource belongs to |
location | Azure region |
type | Azure resource type (e.g. Microsoft.Network/virtualNetworks) |
tags | Azure resource tags (key-value pairs) |
Supported resource types¶
| Category | Resource types | Key attributes collected |
|---|---|---|
| Networking | Network Interfaces | MAC address, IP configurations (private/public IPs, subnets), NSG association, VM association, accelerated networking, IP forwarding, DNS servers |
| Network Security Groups | Security rules (direction, priority, access, protocol, port ranges, source/destination), default rules, associated NICs and subnets | |
| Virtual Networks | Address prefixes, DNS servers, subnets (address range, NSG, route table), VNet peerings, DDoS protection | |
| Public IP Addresses | IP address, allocation method (static/dynamic), FQDN, SKU, idle timeout | |
| Private Endpoints | Subnet ID, private link service connections, NIC IDs | |
| Application Gateways | SKU (tier, capacity), frontend/backend configurations, HTTP listeners, request routing rules, WAF status | |
| Load Balancers | SKU, frontend IP configs, backend pools, load balancing rules, health probes | |
| VNet Gateways | Gateway type (VPN/ExpressRoute), VPN type, SKU, BGP settings, IP configurations | |
| NAT Gateways | SKU, idle timeout, public IP associations, subnet associations, zones | |
| Azure Firewalls | SKU (tier), threat intel mode, IP configurations, firewall policy ID | |
| Front Door Profiles | SKU, frontend endpoints, routing rules, health probe settings | |
| Compute | Virtual Machines | VM size, OS type, image reference (publisher/offer/SKU), disk mappings, NIC mappings, availability set/zone |
| Managed Disks | Size GB, SKU (tier), encryption type, IOPS/MBps capabilities, managed-by VM, creation time | |
| VM Scale Sets | SKU (name, tier, capacity), upgrade policy, OS profile, network profile, zones | |
| AKS Clusters | Kubernetes version, node pools (count, VM size, OS type), network profile (plugin, service CIDR, DNS), RBAC enabled | |
| Storage | Storage Accounts | Kind, SKU, access tier, HTTPS enforcement, network rules (default action, IP rules, VNet rules), blob/file/table/queue endpoints |
| Web | App Service Plans | SKU (name, tier, size), reserved (Linux), elastic scale max workers, per-site scaling, worker count |
| Web & Function Apps | Kind (web/function/linux), state, HTTPS-only, app service plan, VNet integration, default hostname | |
| Containers | Container Instances | Container specs (image, CPU, memory, ports), restart policy, OS type |
| Container Registries | SKU, login server, admin enabled, zone redundancy, creation date | |
| Security | Key Vaults | SKU, soft delete enabled/retention, purge protection, RBAC authorisation, network ACLs |
| Databases | SQL Servers & Databases | FQDN, version, state, admin login, public network access, min TLS; databases include SKU, collation, max size, elastic pool ID |
| Cosmos DB Accounts | Kind, consistency level, failover policies, multi-region write, virtual network rules, IP rules | |
| SQL Managed Instances | SKU (name, tier, family), vCores, storage size GB, licence type, public endpoint enabled | |
| PostgreSQL Flexible Servers | SKU (name, tier), version, storage size GB, backup retention, geo-redundant backup, high availability mode | |
| MySQL Flexible Servers | SKU (name, tier), version, storage size GB, backup retention, geo-redundant backup, high availability mode | |
| Recovery | Recovery Services Vaults | SKU (name, tier) |
| Messaging | Event Hub Namespaces | SKU (name, tier, capacity), auto-inflate enabled/max throughput, zone redundant, Kafka enabled |
| Service Bus Namespaces | SKU (name, tier), zone redundant, minimum TLS version | |
| Cache | Redis Caches | SKU (name, family, capacity), hostname, port, SSL port, TLS version, shard count, linked servers |
| DNS | DNS Zones | Zone type, nameservers, record set count |
| Private DNS Zones | Record set count, VNet links, auto-registration enabled | |
| Monitoring | Log Analytics Workspaces | SKU, retention days, daily cap GB, workspace ID, public network access |
| Application Insights | Application type, ingestion endpoint, instrumentation key, retention days, daily cap GB, workspace resource ID |
SQL parent-child relationships: SQL Servers and their databases are linked. When SQL Servers are inventoried, their databases are automatically enumerated. Each database record includes a server_id field linking to its parent server.