Compute Engine instances not reporting to Cloud Monitoring
What does ZopNight detect here?
ZopNight rule RC-1201 fires when the GCP discoverer stamps monitoring_enabled=false on a Compute Engine instance, meaning no agent is shipping guest metrics to Cloud Monitoring. Absent or unparseable metadata abstains, so only confirmed gaps surface. Fixing it means installing the Ops Agent. The legacy Monitoring and Logging agents are deprecated.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1201 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | vm_monitoring.go |
Where it applies
The single flag this rule trusts
Rule RC-1201 makes exactly one read: the monitoring_enabled state the GCP discoverer stamps into the instance’s metadata sink. Only a confirmed false fires; if the key is absent, empty, or unparseable, the rule abstains. There is no fallback to customer labels and no guessing from partial data. A VM whose monitoring state was never observed generates no finding. Notably, the rule never queries Cloud Monitoring itself: it judges the configuration flag, not whether time series actually arrive, so it detects the unmonitored state rather than a broken pipeline on a nominally monitored VM.
What an unmonitored VM costs you
Without an agent, Cloud Monitoring only sees what the hypervisor sees: CPU, network bytes, disk I/O. Memory pressure, disk-space exhaustion, and per-process behaviour are invisible, and those three are the usual suspects when a VM degrades slowly instead of failing loudly. The practical consequence is that the first alert for a full disk is often the application falling over. For a fleet, unmonitored instances also poison capacity planning, because rightsizing decisions get made on hypervisor metrics alone.
Fix with the Ops Agent, not the legacy agents
The remediation named by the rule is installing the Ops Agent, either directly on the VM or fleet-wide through an agent policy in VM Manager. The older Cloud Monitoring agent and Logging agent are deprecated; new installs should not use them. After installation, verify metrics are flowing and add alerting policies for CPU, memory, and disk. Once the discoverer next observes the agent, the recommendation clears automatically.
Audit your project’s agent coverage
gcloud compute instances ops-agents policies list --project my-projectAn empty list means no agent policy is managing installs in that project; individual VMs may still have hand-installed agents, which the per-instance finding will confirm or deny.
Where the finding stops
A $0 saving is expected here: the rule is compliance, and the Ops Agent itself is free, though the metrics and logs it ingests are billable in Cloud Monitoring and Cloud Logging. Weigh that ingestion cost per VM class: the answer for a production database and a batch worker is rarely the same.