# Azure VM Monitoring Not Enabled > 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. Source: https://zop.dev/integrations/azure/recommendations/azure-vm-monitoring-not-enabled Updated: 2026-08-19 --- ## 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 ```bash az monitor data-collection rule association list \ --resource $(az vm show -g -n --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.