Documentation Grafana Cloud Monitor applications Database Observability Set up PostgreSQL Google CloudSQL

Set up Google CloudSQL PostgreSQL

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

What you’ll achieve

In this article, you:

• Configure CloudSQL PostgreSQL database flags for monitoring.
• Create monitoring users with required privileges.
• Configure Alloy with the Database Observability components.
• Forward telemetry to Grafana Cloud.

Before you begin

Review these requirements:

• CloudSQL PostgreSQL 14.0 or later.
• Access to modify CloudSQL instance database flags.
• Grafana Alloy deployed and accessible to your CloudSQL instance.
• Network connectivity between Alloy and your CloudSQL instance (via private IP, public IP with authorized networks, or Cloud SQL Auth Proxy).

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

Configure database flags

Enable pg_stat_statements and configure query tracking by adding database flags to your CloudSQL PostgreSQL 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 SQL.
2. Select your CloudSQL PostgreSQL instance.
3. Click Edit.
4. Expand Flags 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" "postgres" {
  name             = "<INSTANCE_NAME>"
  database_version = "POSTGRES_16"
  region           = "<REGION>"
  settings {
    database_flags {
      name  = "pg_stat_statements.track"
      value = "all"
    }
    database_flags {
      name  = "track_activity_query_size"
      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> \
  --pg_stat_statements.track=all,track_activity_query_size=4096

After the instance restarts, enable the pg_stat_statements extension in each database you want to monitor:

SQL Copy

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

Verify the extension is installed:

SQL Copy

SELECT * FROM pg_stat_statements LIMIT 1;

Create a monitoring user and grant required privileges

Connect to your Cloud SQL for PostgreSQL instance as an administrator and create the monitoring user:

Create the db-o11y user and grant base privileges:

SQL Copy

CREATE USER "db-o11y" WITH PASSWORD '<DB_O11Y_PASSWORD>';
GRANT pg_monitor TO "db-o11y";
GRANT pg_read_all_stats TO "db-o11y";

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

Verify that the user has the correct privileges to query pg_stat_statements:

SQL Copy

-- run with the `db-o11y` user
SELECT * FROM pg_stat_statements LIMIT 1;

Disable tracking of monitoring user queries

Prevent tracking of queries executed by the monitoring user itself:

SQL Copy

ALTER ROLE "db-o11y" SET pg_stat_statements.track = 'none';

Grant object privileges for detailed data

To allow collecting schema details and table information, connect to each logical database and grant access to each schema.

For example, for a payments database:

SQL Copy

-- switch to the 'payments' database
\c payments

-- grant permissions in the 'public' schema
GRANT USAGE ON SCHEMA public TO "db-o11y";
GRANT SELECT ON ALL TABLES IN SCHEMA public TO "db-o11y";

-- grant permissions in the 'tests' schema
GRANT USAGE ON SCHEMA tests TO "db-o11y";
GRANT SELECT ON ALL TABLES IN SCHEMA tests TO "db-o11y";

Alternatively, if you’re unsure which specific schemas need access, use the predefined role to grant USAGE and SELECT access to all objects:

SQL Copy

GRANT pg_read_all_data TO "db-o11y";

Verify database flag settings

Verify that the parameter settings were applied correctly after restarting:

SQL Copy

SHOW pg_stat_statements.track;

Expected result: Value is all.

SQL Copy

SHOW track_activity_query_size;

Expected result: Value is 4096.

Run and configure Alloy

Run Alloy and add the Database Observability configuration for your CloudSQL instance.

Run the latest Alloy version

Add the CloudSQL PostgreSQL configuration blocks

Add these blocks to Alloy for CloudSQL PostgreSQL. Replace <DB_NAME>. Create a local.file with the Data Source Name string, for example, "postgresql://<DB_USER>:<DB_PASSWORD>@<INSTANCE_IP>:<DB_PORT>/<DB_DATABASE>?sslmode=require":

Alloy Copy

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

prometheus.exporter.postgres "postgres_<DB_NAME>" {
  data_source_names  = [local.file.postgres_secret_<DB_NAME>.content]
  enabled_collectors = ["stat_statements"]

  stat_statements {
    exclude_users      = ["db-o11y", "cloudsqladmin"]
    exclude_databases  = ["cloudsqladmin"]
  }

  autodiscovery {
    enabled = true

    // Exclude the cloudsqladmin database
    database_denylist = ["cloudsqladmin"]
  }
}

database_observability.postgres "postgres_<DB_NAME>" {
  data_source_name  = local.file.postgres_secret_<DB_NAME>.content
  forward_to        = [loki.relabel.database_observability_postgres_<DB_NAME>.receiver]
  targets           = prometheus.exporter.postgres.postgres_<DB_NAME>.targets
  enable_collectors = ["query_details", "query_samples", "schema_details", "explain_plans"]
  exclude_users      = ["db-o11y", "cloudsqladmin"]
  exclude_databases  = ["cloudsqladmin"]
}

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

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

discovery.relabel "database_observability_postgres_<DB_NAME>" {
  targets = database_observability.postgres.postgres_<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_postgres_<DB_NAME>" {
  targets    = discovery.relabel.database_observability_postgres_<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).
• GCP_PROJECT_ID: Google Cloud project ID where your CloudSQL instance runs.
• CLOUDSQL_INSTANCE_NAME: CloudSQL instance name.
• GCP_REGION: GCP region where the instance is deployed.
• INSTANCE_LABEL: Value that sets the instance label on logs and metrics (optional).
• Secret file content example: "postgresql://DB_USER:DB_PASSWORD@INSTANCE_IP:DB_PORT/DB_DATABASE?sslmode=require".
  • 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: 5432).
  • DB_DATABASE: Logical database name in the DSN (recommend: use postgres).

Add processing of PostgreSQL logs (optional)

Add processing of PostgreSQL logs to gather detailed metrics about query and server errors.

The logs collector processes PostgreSQL logs received through the logs_receiver entry point and exports Prometheus metrics for query and server errors.

Configure log_line_prefix

Configure log_line_prefix via CloudSQL database flags:

1. Open the Cloud Console and navigate to SQL.
2. Select your CloudSQL PostgreSQL instance.
3. Click Edit.
4. Expand Flags section.
5. Click Add a database flag, set the name to log_line_prefix and the value to %m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a:.
6. Click Save to apply the changes.
7. The instance restarts automatically to apply the new flag.

Alternatively, use the gcloud CLI:

Bash Copy

gcloud sql instances patch <INSTANCE_NAME> \
  --database-flags log_line_prefix='%m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a:'

GCP Pub/Sub credentials

The loki.source.gcplog component requires a GCP project ID and a Pub/Sub subscription name. Configure credentials with:

• Workload Identity (recommended when running in GKE)
• Service account key file
• Application Default Credentials

The service account or workload identity must have the roles/pubsub.subscriber IAM role on the Pub/Sub subscription.

Add logs processing configuration

Add the logs processing configuration block with loki.source.gcplog. Replace <DB_NAME> (matching the database name used in the main configuration above), <GCP_PROJECT_ID>, <PUBSUB_SUBSCRIPTION>, and <INSTANCE_LABEL>:

Alloy Copy

// Pull PostgreSQL logs from GCP Pub/Sub
loki.source.gcplog "gcp_logs_<DB_NAME>" {
  pull {
    project_id   = "<GCP_PROJECT_ID>"
    subscription = "<PUBSUB_SUBSCRIPTION>"
    labels = {
      "job" = "integrations/db-o11y",
    }
  }

  relabel_rules = discovery.relabel.gcp_logs_<DB_NAME>.rules
  forward_to    = [database_observability.postgres.postgres_<DB_NAME>.logs_receiver]
}

// Relabel rules to map GCP log metadata to labels
discovery.relabel "gcp_logs_<DB_NAME>" {
  targets = []

  rule {
    source_labels = ["__gcp_logname"]
    target_label  = "logname"
  }
  rule {
    source_labels = ["__gcp_resource_type"]
    target_label  = "resource_type"
  }
  rule {
    source_labels = ["__gcp_resource_labels_database_id"]
    target_label  = "database_id"
  }
  rule {
    replacement  = "<INSTANCE_LABEL>"
    target_label = "instance"
  }
}

Replace the placeholders:

• DB_NAME: Database name Alloy uses in component identifiers (must match the <DB_NAME> used in the main configuration above).
• GCP_PROJECT_ID: Google Cloud project ID containing the Pub/Sub subscription.
• PUBSUB_SUBSCRIPTION: Pub/Sub subscription name that receives PostgreSQL logs from the log sink.
• INSTANCE_LABEL: Value that sets the instance label on logs (must match the <INSTANCE_LABEL> used in the main configuration above).

Historical Log Processing

The logs collector only processes logs with timestamps after the collector’s start time. This prevents re-counting historical logs when the source component replays old entries.

Behavior:

• On startup: Skips logs with timestamps before the collector started
• Relies on the source component features to prevent duplicate log ingestion across restarts

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.

Run and configure Alloy with the Grafana Kubernetes Monitoring Helm chart

Extend your values.yaml when you use the k8s-monitoring Helm chart and set databaseObservability.enabled to true within the PostgreSQL integration.

YAML Copy

integrations:
  collector: alloy-singleton
  postgresql:
    instances:
      - name: <INSTANCE_NAME>
        exporter:
          dataSource:
            host: <INSTANCE_IP>
            port: 5432
            database: postgres
            sslmode: require
            auth:
              usernameKey: username
              passwordKey: password
          collectors:
            statStatements: true
        databaseObservability:
          enabled: true
          extraConfig: |
            exclude_databases = ["cloudsqladmin"]
          collectors:
            queryDetails:
              enabled: true
            querySamples:
              enabled: true
            schemaDetails:
              enabled: true
            explainPlans:
              enabled: true
        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.
• GCP_PROJECT_ID: Google Cloud project ID where your CloudSQL instance runs.
• CLOUDSQL_INSTANCE_NAME: CloudSQL instance name.
• GCP_REGION: GCP region where the instance is deployed.
• SECRET_NAME: Name of the Kubernetes secret containing database credentials.
• NAMESPACE: Kubernetes namespace where the secret exists.

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

Optional: Configure GCP Secret Manager and Kubernetes

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

PostgreSQL secret format

Store the secret as JSON with the following format:

JSON Copy

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

Replace the placeholders:

• DB_O11Y_PASSWORD: Password for the db-o11y PostgreSQL user.
• INSTANCE_IP: CloudSQL instance IP address.

Create the secret via gcloud CLI

Bash Copy

echo '{"username":"db-o11y","password":"<DB_O11Y_PASSWORD>","host":"<INSTANCE_IP>","port":5432,"database":"postgres"}' | \
  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.

Next steps

For an overview of key concepts, refer to Introduction to Database Observability.

For troubleshooting during setup, refer to Troubleshoot.