The Compute Engine integration brings VM instance metrics and logs into SigNoz, with a pre-built dashboard for the service.
Compute Engine publishes its metrics to Cloud Monitoring and its logs to Cloud Logging. SigNoz reads them through the OpenTelemetry Collector running in your GCP project.
Choose a setup method
One-Click Integration
SigNoz deploys and manages the Collector for you. You turn the service on in SigNoz, and the SigNoz agent sets up metrics and logs collection in the background. Collects metrics and logs.
Prerequisites
- Your GCP project is connected with One-Click Integration.
- Your VM instances run in that same project. The agent monitors only the project it's deployed in.
Step 1: Turn on the service in SigNoz
- In SigNoz, go to Integrations > Google Cloud Platform.
- Select GCP Compute Engine from the service list.
- Turn on Metric Collection, Log Collection, or both.
- Click Save.
The agent picks up the change within about 30 seconds and updates the Collector and the log sink for you. There's no Collector config to edit.
Step 2: Turn on the optional data in GCP
Most data starts flowing with no extra work. Two kinds of data need a setting on the GCP side first:
- Memory panels. GCP can't see inside a VM on its own, so memory metrics need help from the VM:
- % Memory Utilization via Ops Agent needs the Ops Agent installed on the VM.
- % Memory Utilization and Memory Used in Bytes are only reported by GKE nodes and by VMs running Container-Optimized OS. GKE nodes report them by default. Standalone Container-Optimized OS VMs need health monitoring turned on first: set the
google-monitoring-enabledmetadata key totrueon the VM or project. It's off by default.
- Logs from inside the VM, such as syslog and application logs, also need the Ops Agent. Without it, SigNoz still collects the Compute Engine audit logs.
Skip this step if you only need CPU, disk, and network metrics and audit logs.
Validate
-
Wait about 10 minutes for the first metrics to arrive.
-
In SigNoz, go to Dashboards and open GCP Compute Engine Overview. Panels should start filling in.
-
If you turned on Log Collection, open Logs in SigNoz and start with this filter to find your project's logs:
gcp.project = '<deployment-project-id>' AND gcp.resource_type = 'gce_instance'Log entries appear within a few minutes of the next VM change or, with the Ops Agent installed, the next log line from the VM. Audit logs for disks, firewall rules, and other Compute Engine resources use other resource types, so drop the
gcp.resource_typepart to see them too.Verify these values:
<deployment-project-id>: the GCP project you connected with One-Click Integration.
Manual Setup
You run the OpenTelemetry Collector in your own GCP project and add Compute Engine metrics to its configuration. You control which metrics are pulled and how often. Collects metrics, and logs if you set up the log pipeline.
Complete the GCP integration setup once, then follow the steps below for each project that hosts the VMs you want to monitor.
Prerequisites
Before configuring this service, complete the shared GCP integration setup:
- Your GCP account is connected in SigNoz, and the project running your VMs is in Projects to Monitor.
- The OpenTelemetry Collector is deployed and running.
- The
signoz-integration-collectorservice account hasroles/monitoring.vieweron the project that hosts the VMs. See Create a service account. - The Cloud Monitoring API is enabled in that project.
- For logs only: the Cloud Logging API is enabled in that project, and you have finished steps 1 to 5 of Collect logs.
Step 1: Enable the service in SigNoz
- In SigNoz, go to Integrations > Google Cloud Platform.
- Select GCP Compute Engine from the service list.
- Toggle Metric Collection on to activate the pre-built dashboard. Toggle Log Collection if you also want to send logs.
- Open the Data Collected tab and note the metrics listed there. These are the metrics the dashboard's panels query.
Step 2: Add the metrics to your Collector config
Open the otel-collector-config.yaml you created in Deploy the Collector and add the Compute Engine metric names to the metrics_list of the googlecloudmonitoring receiver for the project your VMs run in. Only the metrics_list shown below changes; leave the rest of the file as is:
receivers:
googlecloudmonitoring:
project_id: "<monitored-project-id>"
collection_interval: 300s # 5 minutes; minimum is 60s
metrics_list:
# Uptime
- metric_name: "compute.googleapis.com/instance/uptime_total"
# CPU and memory
- metric_name: "compute.googleapis.com/instance/cpu/utilization"
- metric_name: "compute.googleapis.com/guest/memory/bytes_used"
- metric_name: "compute.googleapis.com/guest/memory/percent_used"
- metric_name: "agent.googleapis.com/memory/percent_used"
# Disk
- metric_name: "compute.googleapis.com/instance/disk/average_io_latency"
- metric_name: "compute.googleapis.com/instance/disk/read_bytes_count"
- metric_name: "compute.googleapis.com/instance/disk/write_bytes_count"
- metric_name: "compute.googleapis.com/instance/disk/read_ops_count"
- metric_name: "compute.googleapis.com/instance/disk/write_ops_count"
- metric_name: "compute.googleapis.com/instance/disk/performance_status"
# Network
- metric_name: "compute.googleapis.com/instance/network/received_bytes_count"
- metric_name: "compute.googleapis.com/instance/network/sent_bytes_count"
- metric_name: "compute.googleapis.com/instance/network/received_packets_count"
- metric_name: "compute.googleapis.com/instance/network/sent_packets_count"
- metric_name: "compute.googleapis.com/firewall/dropped_packets_count"Verify these values:
<monitored-project-id>: The GCP project that hosts your VMs. It must be one of the entries in your Projects to Monitor list.
The memory metrics need help from the VM: agent.googleapis.com/memory/percent_used needs the Ops Agent, and the two guest/memory/ metrics are only reported by GKE nodes and by Container-Optimized OS VMs with health monitoring turned on (google-monitoring-enabled=true). Drop the ones your VMs don't report.
The receiver polls every metric in the list once per collection_interval, and the Monitoring API bills per read call, so keep the list to the metrics your dashboards and alerts actually use. See Cost and tuning.
Step 3: Apply the configuration
The Collector loads its config from the signoz-integration-collector-config secret, so a config change needs a new secret version and a redeploy:
- Save your updated
otel-collector-config.yaml. - Add a new secret version (step 2 of Deploy the Collector).
- Redeploy the Cloud Run service (step 3).
Step 4: Send logs (optional)
To also send Compute Engine logs to SigNoz, follow Collect logs to set up the Pub/Sub topic, the push subscription, and the logs receiver. In step 6, Create a log sink, use this filter:
resource.type="gce_instance" OR protoPayload.serviceName="compute.googleapis.com"See Logs under What's collected for what this filter picks up and which logs need a setting in GCP first.
Validate
- Wait one or two collection intervals (up to about 5 minutes with the default
300s). - In SigNoz, go to Dashboards and open the GCP Compute Engine Overview dashboard. Panels should start filling in.
- To check a single metric, open Metrics Explorer and query
compute.googleapis.com/instance/cpu/utilization. - For logs, open Logs and filter on
gcp.resource_type = 'gce_instance'.
What's collected
The GCP Compute Engine Overview dashboard has 16 panels. An Uptime total table sits at the top, followed by three sections:
- CPU & Memory: % CPU Utilization, % Memory Utilization, % Memory Utilization via Ops Agent, Memory Used in Bytes.
- Disk: Disk average latency, Disk performance status, Disk Read Throughput, Disk Write Throughput, Disk Read IOPS, Disk Write IOPS.
- Network: Received traffic, Sent traffic, Received packets, Sent packets, Dropped packets.
Two variables scope the panels: project_id and instance_id.
Metrics
See the Data Collected tab in the SigNoz integration for the definitive list the dashboard uses, and the GCP metrics list for full definitions.
| Metric name | Unit | Type |
|---|---|---|
compute.googleapis.com/instance/uptime_total | Seconds | Gauge |
compute.googleapis.com/instance/cpu/utilization | Percent | Gauge |
compute.googleapis.com/guest/memory/bytes_used | Bytes | Gauge |
compute.googleapis.com/guest/memory/percent_used | Percent | Gauge |
agent.googleapis.com/memory/percent_used | Percent | Gauge |
compute.googleapis.com/instance/disk/average_io_latency | Microseconds | Gauge |
compute.googleapis.com/instance/disk/read_bytes_count | Bytes | Sum |
compute.googleapis.com/instance/disk/write_bytes_count | Bytes | Sum |
compute.googleapis.com/instance/disk/read_ops_count | Count | Sum |
compute.googleapis.com/instance/disk/write_ops_count | Count | Sum |
compute.googleapis.com/instance/disk/performance_status | Bool | Gauge |
compute.googleapis.com/instance/network/received_bytes_count | Bytes | Sum |
compute.googleapis.com/instance/network/sent_bytes_count | Bytes | Sum |
compute.googleapis.com/instance/network/received_packets_count | Count | Sum |
compute.googleapis.com/instance/network/sent_packets_count | Count | Sum |
compute.googleapis.com/firewall/dropped_packets_count | Count | Sum |
Logs
With Log Collection turned on, SigNoz collects these logs for your VMs:
| Log | What it contains | GCP setup needed |
|---|---|---|
| Admin Activity audit logs | Changes to Compute Engine resources, such as creating, starting, stopping, or deleting a VM, and changes to disks and firewall rules | None. GCP always writes these. |
| System Event audit logs | Actions Google takes on your VMs, such as live migration, host maintenance, and preemption | None. GCP always writes these. |
| Data Access audit logs | Reads of Compute Engine resources, such as getting or listing VMs | Turn on Data Access audit logs for Compute Engine |
| VM logs | Logs written inside the VM, such as syslog and application logs | Install the Ops Agent on the VM |
With One-Click Integration, SigNoz applies this log sink filter for you. With Manual Setup, use it when you create your log sink:
resource.type="gce_instance" OR protoPayload.serviceName="compute.googleapis.com"Troubleshooting
Memory panels are empty. These panels need help from inside the VM. % Memory Utilization via Ops Agent needs the Ops Agent installed. % Memory Utilization and Memory Used in Bytes only report for GKE nodes and for Container-Optimized OS VMs. On a standalone Container-Optimized OS VM, confirm health monitoring is on by checking that the google-monitoring-enabled metadata key is true. CPU, disk, and network panels work without either.
No logs after turning on Log Collection. Audit logs only appear when a VM or other Compute Engine resource changes, so a quiet project may show nothing at first. For logs from inside the VM, confirm the Ops Agent is installed and running. Open Logs Explorer in the GCP Console and filter on resource.type="gce_instance" to see what GCP has written.
No metrics at all (One-Click). Confirm the VMs run in the project the agent is deployed in, and that Metric Collection is on and saved. See the One-Click troubleshooting for agent and Collector checks.
Logs don't arrive (Manual). If Logs Explorer in GCP shows the logs but SigNoz doesn't, work back through the log pipeline: the push subscription must reach the Collector, and the sink's writer identity needs roles/pubsub.publisher on the topic. See Collect logs troubleshooting.
A dashboard panel is empty (Manual). The metric backing that panel is missing from your metrics_list. Compare the Data Collected tab against your otel-collector-config.yaml, add what's missing, and repeat step 3.
No Compute Engine metrics at all (Manual). Confirm the signoz-integration-collector service account holds roles/monitoring.viewer on the project in project_id, and that the Cloud Monitoring API is enabled there. Then check the Cloud Run logs for googlecloudmonitoring receiver errors.
Dropped packets stays at zero. That's the healthy state. The panel only shows incoming packets that a firewall rule dropped.
Next steps
- Create alerts on high CPU utilization, rising disk latency, a disk performance status other than Healthy, or a spike in dropped packets.
- Build custom dashboards to correlate VM load with traces from the services running on it.
- Monitor Kubernetes Engine (GKE) if you also run workloads on GKE.
Get Help
If you need help with the steps in this topic, please reach out to us on SigNoz Community Slack. If you are a SigNoz Cloud user, please use in product chat support located at the bottom right corner of your SigNoz instance or contact us at cloud-support@signoz.io.