VMs whose disk throughput signals an I/O bottleneck
What does ZopNight detect here?
Azure VMs averaging over 100 MB/s of combined disk read and write throughput across 30 days get a Premium SSD upgrade prompt from RC-264. Memory-optimized M-series and E-series machines are skipped, and when neither Azure Monitor byte series is available the rule abstains rather than guessing at a bottleneck.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-264 |
| Category | performance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | vm_disk_perf.go |
Where it applies
The one rule in this family that suggests spending more
Most disk-tier findings in ZopNight point downward; RC-264 points up. A VM sustaining an average of 100 MB/s or more of combined disk read and write traffic over 30 days is likely queuing I/O behind a disk tier that cannot keep pace: the workload’s latency problem is the disk, not the code. The recommendation is to move the data disks to Premium SSD. No dollar figure is attached, because a performance upgrade costs money rather than saving it; the value is the bottleneck it removes.
How the threshold is measured
The rule reads two Azure Monitor series per VM (VMDiskReadBytes and VMDiskWriteBytes, available under Monitoring Reader), windows both to the 30-day lookback, converts each average to bytes per second, and sums them. Only when the combined rate clears 100 MB/s does a finding appear, carrying both series as evidence. The VM must also be in a Succeeded provisioning state; a machine mid-deployment proves nothing about steady-state I/O.
A 60x unit bug lived here
Worth knowing when comparing this rule’s output to your own dashboards: the underlying Azure Monitor metrics are per-minute byte totals, not rates. An earlier version divided the hourly average by 3,600, the storage-slot width, instead of the 60-second native grain, undercounting throughput by roughly 60x and silently abstaining on genuinely bottlenecked VMs. The conversion now divides by the correct 60-second bucket, so machines that always deserved the finding actually get it.
Machines the rule leaves alone
M-series and E-series VMs are skipped by instance-type prefix. Those memory-optimized families already ship with premium storage support, so the upgrade advice would be noise. And when neither byte series is present, the rule abstains entirely: an old fallback that fired off a customer tag was removed because no producer ever wrote that tag, meaning it either never fired or would have fired on unverifiable evidence.
Pull the same series yourself
az monitor metrics list \ --resource <vm-resource-id> \ --metric "Disk Read Bytes" "Disk Write Bytes" \ --interval PT1H --aggregation Average --offset 30dDivide each hourly average by 60 to get bytes per second before comparing against the 100 MB/s bar. If the numbers hold, check which of the VM’s disks run Standard HDD or Standard SSD, upgrade those to Premium SSD in the disk’s configuration blade, and confirm the queue depth drops afterward.