Monitor GCP Cloud Storage Metrics with OpenTelemetry

The Cloud Storage integration brings bucket metrics (stored bytes and object counts, deleted bytes, API request activity, signed-request authentication, and network throughput) into SigNoz, with a pre-built dashboard for the service.

Cloud Storage publishes its metrics to Cloud Monitoring. SigNoz reads them through the OpenTelemetry Collector running in your GCP project.

Choose a setup method

Available now. You run the OpenTelemetry Collector in your own GCP project and add Cloud Storage metrics to its configuration. You control which metrics are pulled and how often.

Complete the GCP integration setup once, then follow the steps on this page for each project that hosts the buckets 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 that owns your buckets is in Projects to Monitor.
The OpenTelemetry Collector is deployed and running.
The signoz-integration service account has roles/monitoring.viewer on the project that owns the buckets. See Create a service account.
The Cloud Monitoring API is enabled in that project.

Step 1: Enable the service in SigNoz

In SigNoz, go to Integrations > Google Cloud Platform.
Select GCP Cloud Storage from the service list.
Toggle Metric Collection on to activate the pre-built dashboard.
Open the Data Collected tab and note the metrics listed there. These are the metrics the dashboard's panels query.

Enabling the toggle does not start collection on its own. The metrics that reach SigNoz are exactly the ones in your Collector's metrics_list. If you skip a metric in step 2, its dashboard panel stays empty.

Step 2: Add the metrics to your Collector config

Open the otel-collector-config.yaml you created in Deploy the Collector and add the Cloud Storage metric names to the metrics_list of the googlecloudmonitoring receiver for the project that owns your buckets. 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:
      # Stored data
      - metric_name: "storage.googleapis.com/storage/v2/total_bytes"
      - metric_name: "storage.googleapis.com/storage/v2/total_count"
      - metric_name: "storage.googleapis.com/storage/v2/deleted_bytes"
      # API activity
      - metric_name: "storage.googleapis.com/api/request_count"
      - metric_name: "storage.googleapis.com/authn/authentication_count"
      # Network
      - metric_name: "storage.googleapis.com/network/received_bytes_count"
      - metric_name: "storage.googleapis.com/network/sent_bytes_count"

Verify these values:

<monitored-project-id>: The GCP project that owns your buckets. It must be one of the entries in your Projects to Monitor list.

If your buckets span several projects, add one named receiver per project (googlecloudmonitoring/<name>) and list them all in the metrics pipeline. See Configure multiple projects.

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.

Cloud Storage measures storage/v2/total_bytes and storage/v2/total_count once per day. After the measurement becomes available, Cloud Monitoring repeats it every 300 seconds until the next daily measurement. Empty buckets are not tracked by these metrics. storage/v2/deleted_bytes is also reported once per day and can take up to 24 hours to become available. The API, authentication, and network metrics are sampled every 60 seconds and update more frequently.

Step 3: Apply the configuration

The Collector loads its config from the signoz-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).

Validate

Wait one or two collection intervals (up to about 10 minutes with the default 300s).
In SigNoz, go to Dashboards and open the Cloud Storage dashboard. The API, authentication, and network panels should start filling in first.
To check a single metric, open Metrics Explorer and query storage.googleapis.com/api/request_count.

For buckets that contain objects, give the bucket size and object count panels up to 24 hours before treating them as empty. Cloud Storage measures these values daily and does not track empty buckets.

What's collected

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
`storage.googleapis.com/storage/v2/total_bytes`	Bytes	Gauge
`storage.googleapis.com/storage/v2/total_count`	Count	Gauge
`storage.googleapis.com/storage/v2/deleted_bytes`	Bytes	Sum
`storage.googleapis.com/api/request_count`	Count	Sum
`storage.googleapis.com/authn/authentication_count`	Count	Sum
`storage.googleapis.com/network/received_bytes_count`	Bytes	Sum
`storage.googleapis.com/network/sent_bytes_count`	Bytes	Sum

Troubleshooting

A dashboard panel is empty. 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.

Bucket size and object count stay empty while other panels work. These come from storage/v2/total_bytes and storage/v2/total_count, which Cloud Storage measures once per day. Confirm that the selected buckets contain objects, then wait up to 24 hours for the next measurement before investigating further.

No Cloud Storage metrics at all. Confirm the signoz-integration 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.

The bucket_name variable lists far more buckets than expected. It lists every bucket reporting metrics in the selected project. On projects with many buckets, keep the selection narrow instead of using All, so panels stay responsive.

Deleted bytes looks high after a lifecycle change. deleted_bytes reports bytes deleted during the daily reporting interval, including deletions made by lifecycle rules. It does not report only client-initiated deletes.

Next steps

Create alerts on unexpected growth in stored bytes, a spike in error response codes on request_count, or a drop in request volume that suggests a broken client.
Build custom dashboards to correlate storage traffic with traces from the applications reading and writing the buckets.
Monitor Cloud SQL for PostgreSQL or Memorystore for Redis if your stack also uses a managed database or cache.

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.