Monitor GCP Cloud SQL for PostgreSQL Metrics

The Cloud SQL for PostgreSQL integration brings instance metrics (availability, CPU, memory, disk, connections, transactions, vacuum age, query execution time, and replication lag) into SigNoz, with a pre-built dashboard for the service.

Cloud SQL 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 SQL 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 Cloud SQL instance 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 Cloud SQL instances 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 hosts the instances. 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 SQL for PostgreSQL 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 SQL metric names to the metrics_list of the googlecloudmonitoring receiver for the project your instances 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:
      # Availability
      - metric_name: "cloudsql.googleapis.com/database/up"
      # Compute
      - metric_name: "cloudsql.googleapis.com/database/cpu/utilization"
      - metric_name: "cloudsql.googleapis.com/database/memory/utilization"
      - metric_name: "cloudsql.googleapis.com/database/memory/usage"
      # Storage
      - metric_name: "cloudsql.googleapis.com/database/disk/bytes_used"
      # PostgreSQL engine
      - metric_name: "cloudsql.googleapis.com/database/postgresql/num_backends"
      - metric_name: "cloudsql.googleapis.com/database/postgresql/num_backends_by_state"
      - metric_name: "cloudsql.googleapis.com/database/postgresql/transaction_count"
      - metric_name: "cloudsql.googleapis.com/database/postgresql/deadlock_count"
      - metric_name: "cloudsql.googleapis.com/database/postgresql/vacuum/oldest_transaction_age"
      # Query insights
      - metric_name: "cloudsql.googleapis.com/database/postgresql/insights/aggregate/execution_time"
      - metric_name: "cloudsql.googleapis.com/database/postgresql/insights/perquery/execution_time"
      # Replication
      - metric_name: "cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag"

Verify these values:

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

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

The two insights/ metrics need Query Insights enabled on the instance (off by default, no extra charge) or their panels stay empty; drop them from the list if you don't need per-query timing.

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-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 5 minutes with the default 300s).
In SigNoz, go to Dashboards and open the Cloud SQL for PostgreSQL dashboard. Panels should start filling in.
To check a single metric, open Metrics Explorer and query cloudsql.googleapis.com/database/cpu/utilization.

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
`cloudsql.googleapis.com/database/up`	Count	Gauge
`cloudsql.googleapis.com/database/cpu/utilization`	Percent	Gauge
`cloudsql.googleapis.com/database/memory/utilization`	Percent	Gauge
`cloudsql.googleapis.com/database/memory/usage`	Bytes	Gauge
`cloudsql.googleapis.com/database/disk/bytes_used`	Bytes	Gauge
`cloudsql.googleapis.com/database/postgresql/num_backends`	Count	Gauge
`cloudsql.googleapis.com/database/postgresql/num_backends_by_state`	Count	Gauge
`cloudsql.googleapis.com/database/postgresql/transaction_count`	Count	Gauge
`cloudsql.googleapis.com/database/postgresql/deadlock_count`	Count	Gauge
`cloudsql.googleapis.com/database/postgresql/vacuum/oldest_transaction_age`	Count	Gauge
`cloudsql.googleapis.com/database/postgresql/insights/aggregate/execution_time`	Microseconds	Gauge
`cloudsql.googleapis.com/database/postgresql/insights/perquery/execution_time`	Microseconds	Gauge
`cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag`	Bytes	Gauge

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.

Query execution time panels are empty. The insights/ metrics only report once Query Insights is enabled on the instance. Enabling it is a change on the Cloud SQL instance, not in the Collector. See step 2.

No Cloud SQL 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.

Metrics appear but are stale. The receiver polls on collection_interval (default 300s) and Cloud SQL itself samples most metrics no faster than every 60 seconds. Lower the interval only if you need the resolution, and expect a higher Monitoring API bill.

Next steps

Create alerts on instance availability, CPU or memory saturation, disk growth, connection exhaustion, transaction wraparound risk (rising vacuum age), or replication lag.
Build custom dashboards to correlate database metrics with traces from the applications querying them.
Monitor Memorystore for Redis if your stack also uses a Redis 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.