Google Cloud SQL PostgreSQL Monitoring

Cloud SQL: Managed Simplicity, Monitoring Gaps

Google Cloud SQL for PostgreSQL handles provisioning, replication, backups, and patching automatically. It supports high availability with regional instances, read replicas for scaling reads, and automatic storage increases. For many teams, Cloud SQL is the most direct managed path to running PostgreSQL in production.

But simplicity in operations does not mean simplicity in monitoring. Cloud SQL restricts superuser access, limits available extensions, and does not expose log files on disk. Google Cloud Monitoring provides CPU, memory, disk, and connection metrics at the infrastructure level, but PostgreSQL-specific insights — query performance trends, index utilization, vacuum health, lock contention — require a tool that queries the database directly.

MonPG connects to your Cloud SQL instance using a standard PostgreSQL connection, collects catalog statistics at 30-second intervals, and gives you the same depth of query and table analysis that you would have on a self-managed PostgreSQL instance.

Setting Up MonPG on Google Cloud

The MonPG collector runs inside your Google Cloud project — on a Compute Engine instance, in a GKE pod, or in a Cloud Run job. It connects to your Cloud SQL instance over private IP (via VPC peering or the Cloud SQL Auth Proxy) or over public IP with SSL.

Private IP vs Cloud SQL Auth Proxy

For production deployments, Google recommends using private IP or the Cloud SQL Auth Proxy rather than exposing your database on a public IP. MonPG supports all connection methods:

• Private IP. If your Cloud SQL instance has a private IP in a VPC, the collector connects directly. No proxy needed. This is the lowest-latency option.
• Cloud SQL Auth Proxy. If you prefer IAM-based authentication without managing SSL certificates, run the Auth Proxy alongside the collector and connect to it on localhost.
• Public IP with SSL. If private networking is not available, the collector can connect over public IP using the server CA certificate and client certificates provided by Cloud SQL.

Enabling pg_stat_statements on Cloud SQL

Cloud SQL supports pg_stat_statements as a database flag. Set the cloudsql.enable_pg_stat_statements flag to on in the instance configuration. This requires a restart, which Cloud SQL handles automatically during a maintenance window or immediately if you request it.

Once enabled, MonPG collects the full set of pg_stat_statements fields: call counts, total and mean execution time, rows returned, shared block hits and reads, local block activity, WAL generation, and more.

Google Cloud Monitoring vs MonPG

Google Cloud Monitoring (formerly Stackdriver) collects infrastructure metrics for Cloud SQL instances automatically. These metrics are useful for capacity planning and threshold alerting, but they do not answer PostgreSQL-specific questions:

• Cloud Monitoring shows database CPU. MonPG shows you which queries consumed that CPU, their execution plans, and whether adding an index would reduce the load.
• Cloud Monitoring shows disk read operations. MonPG shows you which tables are being sequentially scanned, which indexes are unused, and which new indexes would eliminate those scans.
• Cloud Monitoring shows active connections. MonPG breaks connections down by state (active, idle, idle-in-transaction), by database, by user, and by application name — and alerts when idle-in-transaction connections hold locks for too long.
• Cloud Monitoring shows storage utilization. MonPG shows you table-level dead tuple counts, bloat estimates, and autovacuum effectiveness so you can address the root cause of storage growth.

Think of Cloud Monitoring as your infrastructure dashboard and MonPG as your PostgreSQL-specific dashboard. They serve different purposes and complement each other well.

Query Insights: How It Compares

Cloud SQL Query Insights is Google's built-in query analysis tool. It provides a view of top queries by execution time, CPU, and I/O wait, similar to AWS Performance Insights. Here is how Query Insights and MonPG compare:

• Collection granularity. Query Insights samples at configurable intervals (1-20 minutes). MonPG snapshots every 30 seconds for much higher resolution.
• Metric depth. Query Insights shows execution time and wait events. MonPG adds block I/O per query, WAL generation, rows per call, cache hit ratio, and mean time trend over configurable windows.
• Actionable recommendations. Query Insights identifies slow queries but does not recommend solutions. MonPG provides index recommendations with estimated impact, unused index detection, and duplicate index warnings.
• Vacuum and table health. Query Insights does not cover vacuum activity. MonPG tracks dead tuples, autovacuum timing, wraparound risk, and table bloat.
• Query regression detection. Query Insights does not alert when a query regresses. MonPG automatically compares current performance against historical baselines and alerts on significant degradation.

Query Insights is included at no extra cost with Cloud SQL and is useful for quick triage. MonPG provides the deeper analysis needed for ongoing optimization work.

Log Collection on Cloud SQL

Cloud SQL sends PostgreSQL logs to Google Cloud Logging (formerly Stackdriver Logging). You can view logs in the Cloud Console or export them to BigQuery, Cloud Storage, or Pub/Sub. This is useful for compliance and long-term archival, but navigating raw log entries in the Cloud Logging UI is cumbersome for operational troubleshooting.

MonPG's collector can collect PostgreSQL logs from your Cloud SQL instance and feed them into its log insights pipeline. Log entries are parsed, categorized, and surfaced in the MonPG dashboard with automatic grouping by category:

• Slow queries (above your configured log_min_duration_statement)
• Lock timeouts and deadlocks
• Connection limit reached errors
• Autovacuum and checkpoint activity
• Extension and permission errors

This structured log analysis saves significant time compared to searching through raw text logs in the Cloud Console.

High Availability and Read Replicas

Cloud SQL supports regional high availability (HA) and cross-region read replicas. In HA mode, Cloud SQL maintains a standby instance in a different zone that takes over if the primary fails. Read replicas use asynchronous streaming replication to serve read-only queries.

MonPG monitors the full Cloud SQL topology:

• Replication lag per replica. Byte-level and time-level lag tracked at 30-second intervals with alerting.
• Per-replica query analysis. Independent pg_stat_statements analysis for each replica, since read replicas often run different workloads than the primary.
• Failover events. When an HA failover occurs, MonPG records the event and its timing, letting you correlate failovers with application impact.
• Cross-region considerations. Cross-region replicas inherently have higher lag due to network latency. MonPG provides separate lag thresholds for same-region and cross-region replicas.

Maintenance Window Monitoring

Cloud SQL performs automatic maintenance for security patches and minor version upgrades during your configured maintenance window. These events can cause brief disruptions — restarts, brief unavailability, or temporary performance degradation during buffer warmup.

MonPG annotates metric timelines during maintenance periods so you can distinguish planned maintenance effects from genuine performance problems. A brief CPU spike during the Sunday 3 AM maintenance window is expected. The same spike at 2 PM on a Tuesday deserves investigation.

Multi-Cloud Monitoring

If your organization runs PostgreSQL on multiple cloud providers — Cloud SQL for some workloads, AWS RDS for others, and perhaps self-hosted instances on-premises — MonPG provides a unified view across all of them. The same dashboard, the same metrics, the same alerting rules, regardless of where the database runs.

This consistency is important for teams that need to compare performance across environments, enforce consistent monitoring standards, or simply avoid switching between three different cloud consoles to check on their databases.

Related Resources

• PostgreSQL Monitoring Guide — Core PostgreSQL metrics and monitoring best practices.
• AlloyDB Monitoring — Monitoring Google's high-performance PostgreSQL-compatible service.
• AWS RDS PostgreSQL Monitoring — Monitoring PostgreSQL on Amazon Web Services.
• Azure PostgreSQL Monitoring — Monitoring PostgreSQL on Microsoft Azure.
• How to Find and Fix Slow Queries — Query diagnostics that go beyond Google Cloud Query Insights.
• Replication Monitoring Guide — Monitor read replica lag and HA failover events.