Skip to main content
compliance · azure

Running VMs not onboarded to Azure Monitor

resource types
1
rule IDs covered
1
severity
medium

What does ZopNight detect here?

RC-268 records a finding when the Azure discoverer's monitoring lookup set was fetched and a running VM was not a member, with monitoring_enabled stamped as an authoritative false. An un-monitored VM fails silently: no guest metrics, no log collection, no alerts. Absent lookup data makes the rule abstain rather than guess.

Signal and threshold

How ZopNight evaluates Running VMs not onboarded to Azure Monitor.
Field Value
Rule IDsRC-268
Categorycompliance
Severitymedium
Metricnone — pure configuration read
Sourcevm_monitoring.go

Membership, not extension archaeology

Rather than inspecting each VM’s extension list, the discoverer builds a monitoring lookup set (which VMs are onboarded to Azure Monitor) and stamps every VM’s monitoring_enabled metadata from membership in it. The boolean is written in both polarities, so a "false" is the product of a completed enumeration that did not contain this VM, and the rule fires on that value alone. Where the key is absent (the lookup never ran, or credentials fell short), the rule abstains: missing evidence yields missing findings, not invented ones.

This rewiring is why the rule works at all. Its first incarnation read resource.Tags["monitoring_enabled"], the wrong container, since Tags holds the customer’s real cloud tags rather than derived state, and a key no producer ever emitted. The rec was structurally dead until the read moved to metadata.

The cost of a silent machine

Platform metrics such as host-visible CPU, disk, and network exist for every VM regardless. What an un-onboarded VM lacks is everything inside the guest: memory pressure, per-process behaviour, syslog and application logs, and any alert wired to them. Disk-full incidents, memory leaks, and crashed services on such machines are discovered by users, not dashboards. For an auditor, a production VM outside the monitoring estate is a finding in itself under most operational frameworks.

Where the agents stand in 2026

Onboarding today means the Azure Monitor Agent plus a Data Collection Rule. The legacy Log Analytics agent (MMA) was retired on 2024-08-31, and the portal’s old “guest-level monitoring” wizard installed it, so a fleet last touched years ago can be simultaneously “onboarded” and collecting nothing. Treat this rule’s finding as a prompt to check which agent generation the estate is actually running.

Verify a single VM’s onboarding

Terminal window
az monitor data-collection rule association list \
--resource $(az vm show -g <rg> -n <vm> --query id -o tsv) -o table

No associations means no AMA data flows, matching the finding.

Sensible first collection set

Start with CPU, available memory, and disk-space counters plus the OS error log channel, alert on those, and expand from telemetry you actually consult. Detection requires only the Reader role; the metric reads elsewhere in ZopNight use Monitoring Reader.

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·