Compute Engine VMs running without the Ops Agent for guest monitoring
What does ZopNight detect here?
Compute Engine VMs are flagged when ZopNight reads the VM's OS inventory cleanly and finds no `google-cloud-ops-agent` package, meaning no Ops Agent reports from inside the guest. Without the agent, Cloud Monitoring sees only hypervisor metrics such as CPU and network, and memory and process utilisation never appear, so rightsizing works from half the picture.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1201 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | google-cloud-ops-agent package absent from OS inventory |
| Source | ZopNight |
| Permissions used | compute.instances.list · osconfig.inventories.get |
Where it applies
What Cloud Monitoring cannot see without an agent
Every Compute Engine VM reports some metrics on its own. Google’s VM observability page lists CPU utilisation and network traffic as available from creation, then states that memory and process utilisation are only available once the Ops Agent is installed. The agent collects those guest metrics plus system logs in one process, using Fluent Bit for logs and the OpenTelemetry Collector for metrics, per the Ops Agent overview.
That gap matters most for memory. A VM that is swapping or close to an out-of-memory kill looks perfectly healthy on CPU graphs, and a rightsizing decision made on CPU alone can shrink a machine that was memory-bound. The older Monitoring and Logging agents have reached end of support, so the Ops Agent is the one to install.
Checking a VM for the agent yourself
On Linux, the agent runs as a systemd service. From an SSH session:
sudo systemctl status google-cloud-ops-agent"*"From outside the VM, the quickest test is whether memory data exists. In Metrics Explorer, chart
agent.googleapis.com/memory/percent_used filtered to the instance; an empty chart means no
agent is reporting.
How ZopNight reaches a finding
ZopNight reads each Compute Engine instance’s OS inventory (VM Manager) and records whether the
google-cloud-ops-agent package is installed. The rule fires only when the inventory reads cleanly
and the package is absent. No utilisation threshold or lookback window
is involved; the finding is about missing telemetry, not about what the telemetry would show.
Instances the rule leaves alone
A VM whose OS inventory is not enabled or cannot be read produces nothing, rather than being assumed unmonitored. VMs whose inventory lists the package are silent, even if the agent is stopped. This rule does not judge alert policies or dashboards, only whether guest metrics can exist at all.
Visibility, not a line on the bill
There is no saving attached. The cost of the gap is indirect: incidents found by users instead of alerts, and other rightsizing findings that cannot weigh memory pressure for this VM.
Installing the Ops Agent
- On a single Linux VM, add the repository and install in one step:
Terminal window curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.shsudo bash add-google-cloud-ops-agent-repo.sh --also-install - For a fleet, use an agent policy so new VMs matching a label get the agent automatically, as described in managing agent policies.
- Confirm memory metrics for the instance now appear in Metrics Explorer.
- Add alerting policies for memory and disk usage now that the data exists.