Monitor GCP Cloud SQL for MySQL Instance Metrics and Logs

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

Cloud SQL 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 Cloud SQL for MySQL 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 Cloud SQL for MySQL 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

The MySQL error log flows with no extra work. Other MySQL logs are off by default and need a setting on the GCP side first:

Slow query and general query logs need the slow_query_log or general_log database flag turned on, with log_output set to FILE.
Audit logs, which record who ran which SQL statements, need the Cloud SQL audit plugin set up on the instance and Data Access audit logs turned on for the project. See MySQL database auditing.

Skip this step if you only need metrics and error logs.

Validate

Wait about 10 minutes for the first metrics to arrive.
In SigNoz, go to Dashboards and open GCP Cloud SQL for MySQL 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 = 'cloudsql_database'
```
New MySQL log lines from your instances appear within a few minutes.

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 Cloud SQL 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 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-collector 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.
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 SQL for MySQL 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 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:
      # Health
      - metric_name: "cloudsql.googleapis.com/database/up"
      - metric_name: "cloudsql.googleapis.com/database/instance_state"
      - metric_name: "cloudsql.googleapis.com/database/replication/replica_lag"
      # CPU, memory & disk
      - metric_name: "cloudsql.googleapis.com/database/cpu/utilization"
      - metric_name: "cloudsql.googleapis.com/database/memory/utilization"
      - metric_name: "cloudsql.googleapis.com/database/disk/utilization"
      - metric_name: "cloudsql.googleapis.com/database/network/connections"
      # Throughput
      - metric_name: "cloudsql.googleapis.com/database/mysql/queries"
      - metric_name: "cloudsql.googleapis.com/database/mysql/dml_operations_count"
      - metric_name: "cloudsql.googleapis.com/database/mysql/threads"
      - metric_name: "cloudsql.googleapis.com/database/mysql/innodb/buffer_pool_reads_count"
      - metric_name: "cloudsql.googleapis.com/database/mysql/innodb/buffer_pool_read_requests_count"
      # Errors & contention
      - metric_name: "cloudsql.googleapis.com/database/mysql/slow_queries_count"
      - metric_name: "cloudsql.googleapis.com/database/mysql/aborted_connects_count"
      - metric_name: "cloudsql.googleapis.com/database/mysql/innodb/deadlocks_count"
      - metric_name: "cloudsql.googleapis.com/database/mysql/innodb/row_lock_waits_count"
      - metric_name: "cloudsql.googleapis.com/database/disk/read_ops_count"
      - metric_name: "cloudsql.googleapis.com/database/disk/write_ops_count"

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.

Also monitoring Cloud SQL for PostgreSQL in the same project? Add its metrics from the PostgreSQL section to the same googlecloudmonitoring receiver. Three metrics are in both lists: database/up, database/cpu/utilization, and database/memory/utilization. Listing them twice is harmless, but you only need them once. Don't add a second receiver for the same project instead: the shared metrics would then be collected twice.

The InnoDB buffer pool miss ratio panel derives its value from two metrics, buffer_pool_reads_count and buffer_pool_read_requests_count. Keep both in the list or the panel stays empty.

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 MySQL 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="cloudsql_database" AND (
  logName:"/logs/cloudsql.googleapis.com%2Fmysql"
  OR (log_id("cloudaudit.googleapis.com/data_access")
    AND protoPayload.request.@type="type.googleapis.com/google.cloud.sql.audit.v1.MysqlAuditEntry")
)

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 5 minutes with the default 300s).
In SigNoz, go to Dashboards and open the GCP Cloud SQL for MySQL Overview dashboard. Panels should start filling in.
To check a single metric, open Metrics Explorer and query cloudsql.googleapis.com/database/cpu/utilization.
For logs, open Logs and filter on gcp.resource_type = 'cloudsql_database'.

What's collected

The GCP Cloud SQL for MySQL Overview dashboard groups its 17 panels into four sections:

Health: Server up, Instance state, Replication lag.
CPU, Memory & Disk: CPU utilization, Memory utilization, Disk utilization, Connections.
Throughput: Queries, DML operations, Threads, InnoDB buffer pool miss ratio.
Errors & Contention: Slow queries, Aborted connects, InnoDB deadlocks, InnoDB row lock waits, Disk Read IOPS, Disk Write IOPS.

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/instance_state`	Count	Gauge
`cloudsql.googleapis.com/database/replication/replica_lag`	Seconds	Gauge
`cloudsql.googleapis.com/database/cpu/utilization`	Percent	Gauge
`cloudsql.googleapis.com/database/memory/utilization`	Percent	Gauge
`cloudsql.googleapis.com/database/disk/utilization`	Percent	Gauge
`cloudsql.googleapis.com/database/network/connections`	Count	Gauge
`cloudsql.googleapis.com/database/mysql/queries`	Count	Sum
`cloudsql.googleapis.com/database/mysql/dml_operations_count`	Count	Sum
`cloudsql.googleapis.com/database/mysql/threads`	Count	Gauge
`cloudsql.googleapis.com/database/mysql/innodb/buffer_pool_reads_count`	Count	Sum
`cloudsql.googleapis.com/database/mysql/innodb/buffer_pool_read_requests_count`	Count	Sum
`cloudsql.googleapis.com/database/mysql/slow_queries_count`	Count	Sum
`cloudsql.googleapis.com/database/mysql/aborted_connects_count`	Count	Sum
`cloudsql.googleapis.com/database/mysql/innodb/deadlocks_count`	Count	Sum
`cloudsql.googleapis.com/database/mysql/innodb/row_lock_waits_count`	Count	Sum
`cloudsql.googleapis.com/database/disk/read_ops_count`	Count	Sum
`cloudsql.googleapis.com/database/disk/write_ops_count`	Count	Sum

Logs

With Log Collection turned on, SigNoz collects these logs from your Cloud SQL for MySQL instances:

Log	What it contains	GCP setup needed
Error log (`cloudsql.googleapis.com/mysql.err`)	Startup, shutdown, and error messages from the MySQL server	None
Slow query log (`cloudsql.googleapis.com/mysql-slow.log`)	Queries that take longer than `long_query_time`	Turn on the `slow_query_log` flag and set `log_output` to `FILE`
General query log (`cloudsql.googleapis.com/mysql-general.log`)	Every statement the server receives	Turn on the `general_log` flag and set `log_output` to `FILE`
Audit logs (`cloudaudit.googleapis.com/data_access`)	Who ran which SQL statements, for auditing	Set up MySQL database auditing and turn on Data Access audit logs

The general query log records every statement, so it can grow large quickly and raise your Cloud Logging, Pub/Sub, and SigNoz ingestion costs. Turn it on only while you need it.

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="cloudsql_database" AND (
  logName:"/logs/cloudsql.googleapis.com%2Fmysql"
  OR (log_id("cloudaudit.googleapis.com/data_access")
    AND protoPayload.request.@type="type.googleapis.com/google.cloud.sql.audit.v1.MysqlAuditEntry")
)

Troubleshooting

No logs after turning on Log Collection. SigNoz can only forward logs that Cloud SQL writes to Cloud Logging. Open Logs Explorer in the GCP Console and filter on resource.type="cloudsql_database". If the slow or general query log is missing there, check its database flag and that log_output is FILE. For audit logs, confirm the audit plugin is set up and Data Access audit logs are on for the project.

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

The InnoDB buffer pool miss ratio panel is empty (Manual). This panel needs both buffer_pool_reads_count and buffer_pool_read_requests_count. Add whichever is missing and repeat step 3.

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

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, slow queries, aborted connects, InnoDB deadlocks, or replication lag.
Build custom dashboards to correlate database metrics with traces from the applications querying them.
Monitor Cloud SQL for PostgreSQL or Memorystore for Redis if your stack also uses them.

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.