Monitor GCP Cloud Storage Bucket Metrics and Audit Logs

The Cloud Storage integration brings bucket metrics and logs into SigNoz, with a pre-built dashboard for the service.

Cloud Storage publishes its metrics to Cloud Monitoring and its audit 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 buckets belong to 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 Cloud Storage 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 logs in GCP

Logs for bucket changes, such as creating a bucket or changing its permissions, flow with no extra work. Logs for reading and writing objects are off by default. To collect them, turn on Data Access audit logs for Cloud Storage in your project.

Data Access audit logs create one log entry per request, so busy buckets can produce a lot of logs. This raises your Cloud Logging, Pub/Sub, and SigNoz ingestion costs. Turn on only the log types you need (ADMIN_READ, DATA_READ, or DATA_WRITE).

Skip this step if you only need metrics and bucket change logs.

Validate

Wait about 10 minutes for the first metrics to arrive.
In SigNoz, go to Dashboards and open GCP Cloud Storage Overview. The API, authentication, and network panels fill in first.
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 = 'gcs_bucket'
```
New log entries for your buckets appear within a few minutes of the next bucket change or, with Data Access audit logs on, the next object request.

Verify these values:
- <deployment-project-id>: the GCP project you connected with One-Click Integration.

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.

Manual Setup

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. 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 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-collector 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.
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 Cloud Storage 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.

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-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 Cloud Storage audit 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="gcs_bucket"

See Logs under What's collected for what this filter picks up and which logs need a setting in GCP first.

Add the same filter as an exclusion filter on the project's _Default sink, or you pay to store these logs in both Cloud Logging and SigNoz. See Avoid paying twice for logs.

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 logs, open Logs and filter on gcp.resource_type = 'gcs_bucket'.

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

Logs

With Log Collection turned on, SigNoz collects the Cloud Storage audit logs for buckets in your project:

Log	What it contains	GCP setup needed
Admin Activity audit logs	Changes to buckets and their settings, such as creating or deleting a bucket and changing its IAM policy	None. GCP always writes these.
Data Access audit logs	Reads of bucket settings (`ADMIN_READ`), object reads and listings (`DATA_READ`), and object creates, updates, and deletes (`DATA_WRITE`)	Turn on Data Access audit logs for Cloud Storage

Audit logs don't record access to public objects, or changes made by Object Lifecycle Management or Autoclass.

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="gcs_bucket"

Troubleshooting

No logs after turning on Log Collection. Admin Activity logs only appear when a bucket or its settings change, so a quiet project may show nothing at first. Open Logs Explorer in the GCP Console and filter on resource.type="gcs_bucket" to see what GCP has written. For object reads and writes, confirm Data Access audit logs are on for Cloud Storage.

No metrics at all (One-Click). Confirm the buckets belong to 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.

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 (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.

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.