Documentation Grafana Cloud Monitor applications Database Observability Set up MySQL Google Cloud SQL

Set up Google Cloud SQL for MySQL

Set up Database Observability with Grafana Cloud to collect telemetry from Google Cloud SQL for MySQL instances using Grafana Alloy. You configure your Cloud SQL instance and Alloy to forward telemetry to Grafana Cloud.

If you already use the MySQL integration, Database Observability extends it with query-level telemetry collected by the database_observability.mysql Alloy component.

What you’ll achieve

In this article, you:

• Configure Google Cloud SQL for MySQL database flags for monitoring.
• Create monitoring users with required privileges.
• Configure Grafana Alloy with the Database Observability components.
• Forward telemetry to Grafana Cloud.
• Verify that telemetry appears in Database Observability.

Setup steps

Setting up Database Observability for CloudSQL MySQL has three steps:

1. Set up your database: Prepare your CloudSQL instance so Alloy can collect from it.
2. Configure Grafana Alloy: Configure how Alloy collects telemetry and sends it to Grafana Cloud. CloudSQL supports a few methods to choose from.
3. Verify telemetry in Grafana Cloud: Check telemetry status and confirm that query metrics appear in Database Observability.

Before you begin

To complete this setup, you need:

• A Google Cloud SQL for MySQL 8.0 or later instance.
• Permission to modify Cloud SQL instance database flags.
• Permission to restart the Cloud SQL instance if flag changes require it.
• A MySQL admin user that can create users and grant privileges.
• A planned Grafana Alloy deployment location with network access to the Cloud SQL instance by using private IP, public IP with authorized networks, or Cloud SQL Auth Proxy.

Estimated setup time: 20-40 minutes, excluding any required maintenance window for restarting the instance.

For general MySQL setup concepts, refer to Set up MySQL.

Set up your database

In this step, you’ll prepare your CloudSQL MySQL instance for monitoring by setting up Performance Schema flags, creating a monitoring user, and granting the permissions Database Observability needs.

Complete this before configuring Alloy. Without it, Alloy can connect to your database, but it won’t be able to collect the telemetry required for Database Observability.

Configure database flags

Enable Performance Schema and related instrumentation by adding database flags to your CloudSQL MySQL instance. These flags require an instance restart to take effect.

Required database flags

Use the Google Cloud console

1. Open the Cloud Console and navigate to Instances
2. Select your CloudSQL MySQL instance.
3. Click Edit.
4. Expand Flags and parameters section.
5. Click Add a database flag for each flag listed above.
6. Set the flag name and value as specified in the table.
7. Click Save to apply the changes.
8. The instance restarts automatically to apply the new flags.

For detailed console instructions, refer to Configure database flags in the Google Cloud documentation.

Use Terraform

Using Terraform with google_sql_database_instance:

hcl Copy

resource "google_sql_database_instance" "instance" {
  database_version = "MYSQL_8_0"
  name             = "<INSTANCE_NAME>"
  region           = "<REGION>"
  settings {
    database_flags {
      name  = "performance_schema"
      value = "on"
    }
    database_flags {
      name  = "performance_schema_max_digest_length"
      value = "4096"
    }
    database_flags {
      name  = "performance_schema_max_sql_text_length"
      value = "4096"
    }
    database_flags {
      name  = "max_digest_length"
      value = "4096"
    }
  }
}

Replace the placeholders:

• INSTANCE_NAME: Your CloudSQL instance name.
• REGION: GCP region where the instance is deployed.

Alternatively, configure flags using the gcloud CLI:

Bash Copy

gcloud sql instances patch <INSTANCE_NAME> \
  --database-flags=performance_schema=on,performance_schema_max_digest_length=4096,performance_schema_max_sql_text_length=4096,
  max_digest_length=4096

Create a monitoring user and grant required privileges

Connect to your CloudSQL MySQL instance and create the monitoring user:

Create the db-o11y user and grant base privileges:

SQL Copy

CREATE USER 'db-o11y'@'%' IDENTIFIED BY '<DB_O11Y_PASSWORD>';
GRANT PROCESS, REPLICATION CLIENT ON *.* TO 'db-o11y'@'%';
GRANT SELECT ON performance_schema.* TO 'db-o11y'@'%';

Replace <DB_O11Y_PASSWORD> with a secure password for the db-o11y MySQL user.

Disable tracking of monitoring user queries

Prevent tracking of queries executed by the monitoring user itself:

SQL Copy

UPDATE performance_schema.setup_actors SET ENABLED = 'NO', HISTORY = 'NO' WHERE USER = 'db-o11y';

Grant object privileges

Grant access to specific schemas when you want detailed information:

SQL Copy

GRANT SELECT, SHOW VIEW ON <SCHEMA_NAME>.* TO 'db-o11y'@'%';

Replace <SCHEMA_NAME> with the name of the schema you want to monitor.

Alternatively, if you’re unsure which specific schemas need access, grant broader read access to all schemas:

SQL Copy

GRANT SELECT, SHOW VIEW ON *.* TO 'db-o11y'@'%';

Enable Performance Schema consumers

Database Observability uses Performance Schema consumers to collect CPU time, query samples, and wait events. These consumers must be enabled before Alloy can collect complete query telemetry.

Choose one of the following:

Option 1: Enable consumers manually

Use this method if you don’t want Alloy to modify Performance Schema settings.

Check whether the required consumers are enabled:

SQL Copy

SELECT NAME, ENABLED
FROM performance_schema.setup_consumers
WHERE NAME IN (
  'events_statements_cpu',
  'events_waits_current',
  'events_waits_history'
);

Enable any disabled consumers:

SQL Copy

UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME IN (
  'events_statements_cpu',
  'events_waits_current',
  'events_waits_history'
);

These consumers disable when your database restarts. If you use this method, re-enable them after each restart.

Option 2: Let Alloy manage consumers automatically

Use this method if you want to prepare the database so Alloy can automatically re-enable the required Performance Schema consumers after your database restarts.

To prepare the database for this method, grant the monitoring user permission to update Performance Schema consumers:

SQL Copy

GRANT UPDATE ON performance_schema.setup_consumers TO 'db-o11y'@'%';

Later, when you configure Alloy, enable automatic Performance Schema consumer management in the Alloy configuration.

Verify user privileges

Verify that the user exists and has the expected privileges:

SQL Copy

SHOW GRANTS FOR 'db-o11y'@'%';

Expected output:

Copy

+------------------------------------------------------------------------------+
| Grants for db-o11y@%                                                         |
+------------------------------------------------------------------------------+
| GRANT PROCESS, REPLICATION CLIENT ON *.* TO `db-o11y`@`%`                    |
| GRANT SELECT, SHOW VIEW ON *.* TO `db-o11y`@`%`                              |
| GRANT SELECT ON `performance_schema`.* TO `db-o11y`@`%`                      |
| GRANT INSERT, UPDATE ON `performance_schema`.`setup_actors` TO `db-o11y`@`%` |
+------------------------------------------------------------------------------+

Verify database flag settings

Verify that the settings were applied correctly:

SQL Copy

SHOW VARIABLES LIKE 'performance_schema';

Expected result: Value is ON.

SQL Copy

SHOW VARIABLES LIKE 'performance_schema_max_digest_length';

Expected result: Value is 4096.

SQL Copy

SHOW VARIABLES LIKE 'performance_schema_max_sql_text_length';

Expected result: Value is 4096.

SQL Copy

SHOW VARIABLES LIKE 'max_digest_length';

Expected result: Value is 4096.

Database setup checkpoint

Continue to Alloy configuration only after these conditions are true:

• performance_schema is ON.
• performance_schema_max_digest_length, performance_schema_max_sql_text_length, and max_digest_length are set to 4096.
• SHOW GRANTS FOR 'db-o11y'@'%'; includes all required monitoring and object privileges.
• The required Performance Schema consumers are enabled manually, or the monitoring user has permission for Alloy-managed consumer updates.
• The db-o11y monitoring user can connect from the network where Alloy will run.
• Any flag changes that required a restart have been applied and the instance restart is complete.

After these checks pass, your CloudSQL instance is ready for Database Observability. Next, configure Alloy so it can collect telemetry from the instance and send it to Grafana Cloud.

Configure Grafana Alloy

After you set up your database, choose how to configure Alloy.

Pick one:

1. Configuration page (recommended): Database Observability generates the Alloy configuration for you. Then let Fleet Management apply it to an enrolled collector, or choose Manual Configuration to download the generated file and deploy it yourself. Best for most teams.
2. Kubernetes Monitoring Helm chart: Set databaseObservability.enabled in your values.yaml. Best for teams already running Alloy through the k8s-monitoring Helm chart.
3. Custom configuration file (advanced): Write the Alloy configuration yourself. Best for full control, custom components or relabeling, or environments the other paths don’t cover.

Make sure you’re on a supported Alloy version

Option 1: Configure Alloy from the Database Observability Configuration page (recommended)

Start here for most deployments. The Configuration page (Configuration > Setup) generates the Alloy configuration for you, then lets you choose how to deploy it:

• Fleet Management: Grafana Cloud deploys the configuration to an enrolled Alloy collector and manages it for you, so you don’t edit or ship config files by hand. Best if you want to manage collectors centrally and monitor their health from Grafana Cloud. Refer to Introduction to Fleet Management.
• Manual Configuration: Download the generated configuration and deploy it with your own tooling. Best if you can’t use Fleet Management or you already manage Alloy deployment yourself.

To start the guided setup flow:

1. Open Database Observability in Grafana Cloud.
2. Go to Configuration.
3. Open Setup.
4. Click Add database.
5. Select your database engine.
6. Follow the setup flow and choose Fleet Management or Manual Configuration when prompted.

For an overview of setup methods and what appears in the Setup tab, refer to Configure Alloy from the Configuration page.

Option 2: Configure Alloy with the Grafana Kubernetes Monitoring Helm chart

Use this method if you already manage Alloy with the k8s-monitoring Helm chart. This path configures Alloy outside the Database Observability setup flow in Grafana Cloud.

Extend your values.yaml and set databaseObservability.enabled to true within the MySQL integration.

YAML Copy

integrations:
  collector: alloy-singleton
  mysql:
    instances:
      - name: <INSTANCE_NAME>
        jobLabel: integrations/db-o11y
        exporter:
          enabled: true
          collectors:
            perfSchemaEventsStatements:
              enabled: true
          dataSource:
            host: <INSTANCE_IP>
            auth:
              usernameKey: username
              passwordKey: password
        databaseObservability:
          enabled: true
          allowUpdatePerformanceSchemaSettings: true
          extraConfig: |
            exclude_schemas = ["cloudsqladmin"]
            cloud_provider {
              gcp {
                connection_name = "<CLOUDSQL_CONNECTION_NAME>"
              }
            }
        secret:
          create: false
          name: <SECRET_NAME>
          namespace: <NAMESPACE>
        logs:
          enabled: true
          labelSelectors:
            app.kubernetes.io/instance: <INSTANCE_NAME>

Replace the placeholders:

• INSTANCE_NAME: Name for this database instance in Kubernetes.
• INSTANCE_IP: CloudSQL instance IP address.
• CLOUDSQL_CONNECTION_NAME: Cloud SQL instance connection name in project:region:instance format (for example, my-project:us-central1:my-db).
• SECRET_NAME: Name of the Kubernetes secret containing database credentials.
• NAMESPACE: Kubernetes namespace where the secret exists.

To see the full set of values, refer to the k8s-monitoring Helm chart documentation or the example configuration.

Configure GCP Secret Manager and Kubernetes (optional)

If you use GCP Secret Manager with External Secrets Operator to manage database credentials, configure them as follows.

Secret path convention

Store monitoring credentials in GCP Secret Manager with a name following this convention:

Copy

cloudsql-<INSTANCE_NAME>-monitoring

MySQL secret format

Store the secret as JSON with the following format:

JSON Copy

{
  "username": "db-o11y",
  "password": "<DB_O11Y_PASSWORD>",
  "host": "<INSTANCE_IP>",
  "port": 3306
}

Replace the placeholders:

• DB_O11Y_PASSWORD: Password for the db-o11y MySQL user.
• INSTANCE_IP: CloudSQL instance IP address.
• INSTANCE_NAME: Your CloudSQL instance name.

Create the secret with the gcloud CLI

Bash Copy

echo '{"username":"db-o11y","password":"<DB_O11Y_PASSWORD>","host":"<INSTANCE_IP>","port":3306}' | \
  gcloud secrets create cloudsql-<INSTANCE_NAME>-monitoring --data-file=-

Kubernetes External Secrets configuration

Use the External Secrets Operator to sync the GCP secret into Kubernetes:

YAML Copy

---
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: <INSTANCE_NAME>-db-monitoring-secretstore
spec:
  provider:
    gcpsm:
      projectID: <GCP_PROJECT_ID>
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: <INSTANCE_NAME>-db-monitoring-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: <INSTANCE_NAME>-db-monitoring-secretstore
  dataFrom:
    - extract:
        key: cloudsql-<INSTANCE_NAME>-monitoring

Replace the placeholders:

• INSTANCE_NAME: CloudSQL instance name.
• GCP_PROJECT_ID: Google Cloud project ID.

Option 3: Configure Alloy with a custom configuration file (advanced)

Use this method if you manage Alloy configuration outside Grafana Cloud or need custom relabeling. This path configures Alloy outside the Database Observability setup flow in Grafana Cloud.

Add the CloudSQL MySQL configuration blocks

Add these blocks to Alloy for CloudSQL MySQL. Replace <DB_NAME>. Create a local.file with the Data Source Name string, for example, <DB_USER>:<DB_PASSWORD>@tcp(<INSTANCE_IP>:<DB_PORT>)/:

Alloy Copy

local.file "mysql_secret_<DB_NAME>" {
  filename  = "/var/lib/alloy/mysql_secret_<DB_NAME>"
  is_secret = true
}

prometheus.exporter.mysql "mysql_<DB_NAME>" {
  data_source_name  = local.file.mysql_secret_<DB_NAME>.content
  enable_collectors = ["perf_schema.eventsstatements"]
  perf_schema.eventsstatements {
    exclude_schemas = ["cloudsqladmin"]
    text_limit      = 0
    limit           = 100
  }
}

database_observability.mysql "mysql_<DB_NAME>" {
  data_source_name  = local.file.mysql_secret_<DB_NAME>.content
  forward_to        = [loki.relabel.database_observability_mysql_<DB_NAME>.receiver]
  targets           = prometheus.exporter.mysql.mysql_<DB_NAME>.targets
  exclude_schemas   = ["cloudsqladmin"]

  // OPTIONAL: enable these settings if you chose Alloy-managed Performance
  // Schema consumers during database setup. The auto_enable_setup_consumers
  // setting enables the required performance_schema.setup_consumers options.
  // It requires allow_update_performance_schema_settings and UPDATE on
  // performance_schema.setup_consumers.
  allow_update_performance_schema_settings = true

  query_samples {
    auto_enable_setup_consumers = true
  }

  cloud_provider {
    gcp {
      connection_name = "<CLOUDSQL_CONNECTION_NAME>"
    }
  }
}

loki.relabel "database_observability_mysql_<DB_NAME>" {
  forward_to = [loki.write.logs_service.receiver]

  rule {
    target_label = "instance"
    replacement  = "<INSTANCE_LABEL>"
  }
}

discovery.relabel "database_observability_mysql_<DB_NAME>" {
  targets = database_observability.mysql.mysql_<DB_NAME>.targets

  rule {
    target_label = "job"
    replacement  = "integrations/db-o11y"
  }

  // OPTIONAL: relabel `instance` to `dsn` before overwriting `instance`;
  // the `dsn` label is used in the integration with the knowledge graph
  rule {
    source_labels = ["instance"]
    target_label  = "dsn"
  }
  rule {
    target_label = "instance"
    replacement  = "<INSTANCE_LABEL>"
  }
}

prometheus.scrape "database_observability_mysql_<DB_NAME>" {
  targets    = discovery.relabel.database_observability_mysql_<DB_NAME>.output
  forward_to = [prometheus.remote_write.metrics_service.receiver]
}

Replace the placeholders:

• DB_NAME: Database name Alloy uses in component identifiers (appears in component names and secret filenames).
• CLOUDSQL_CONNECTION_NAME: Cloud SQL instance connection name in project:region:instance format (for example, my-project:us-central1:my-db).
• INSTANCE_LABEL: Value that sets the instance label on logs and metrics (optional).
• Secret file content DSN example: DB_USER:DB_PASSWORD@tcp(INSTANCE_IP:DB_PORT)/.
  • DB_USER: Database user Alloy uses to connect (for example, db-o11y).
  • DB_PASSWORD: Password for the database user.
  • INSTANCE_IP: CloudSQL instance IP address (private or public).
  • DB_PORT: Database port number (default: 3306).

Find more about the options supported by the database_observability.mysql component in the reference documentation.

The cloud_provider block integrates Database Observability with Cloud Provider Observability. To navigate between query performance and Google Cloud infrastructure metrics, refer to Google Cloud Platform observability.

Add Prometheus and Loki write configuration

Add Prometheus and Loki write configuration

Add the Prometheus remote write and Loki write configuration. From Grafana Cloud, open your stack to get the URLs and generate API tokens:

Alloy Copy

prometheus.remote_write "metrics_service" {
  endpoint {
    url = sys.env("GCLOUD_HOSTED_METRICS_URL")

    basic_auth {
      password = sys.env("GCLOUD_RW_API_KEY")
      username = sys.env("GCLOUD_HOSTED_METRICS_ID")
    }
  }
}

loki.write "logs_service" {
  endpoint {
    url = sys.env("GCLOUD_HOSTED_LOGS_URL")

    basic_auth {
      password = sys.env("GCLOUD_RW_API_KEY")
      username = sys.env("GCLOUD_HOSTED_LOGS_ID")
    }
  }
}

Replace the placeholders:

• GCLOUD_HOSTED_METRICS_URL: Your Grafana Cloud Prometheus remote write URL.
• GCLOUD_HOSTED_METRICS_ID: Your Grafana Cloud Prometheus instance ID (username).
• GCLOUD_HOSTED_LOGS_URL: Your Grafana Cloud Loki write URL.
• GCLOUD_HOSTED_LOGS_ID: Your Grafana Cloud Loki instance ID (username).
• GCLOUD_RW_API_KEY: Grafana Cloud API token with write permissions.

Troubleshoot first-run issues

If data doesn’t appear after setup:

• If the database instance doesn’t appear in Database Observability, check Alloy connectivity and labels.
• If telemetry status checks fail, use the Configuration page to identify the failed requirement.
• If query metrics appear but samples, wait events, or explain plans are missing, check database privileges and Performance Schema settings.
• If Alloy can’t connect to the database, check authorized networks, private IP or Cloud SQL Auth Proxy settings, DNS, and the monitoring user’s host restrictions.

For detailed guidance, refer to Troubleshoot Alloy or Troubleshoot MySQL.

Next steps

• View query performance
• Find your application’s queries
• Analyze explain plans