Monitoring Google Cloud with OpenTelemetry means collecting Cloud Monitoring metrics and application telemetry through the OpenTelemetry Collector and OTLP, so GCP services sit in one open pipeline..
Monitoring Google Cloud with OpenTelemetry means collecting Cloud Monitoring metrics and application telemetry through the OpenTelemetry Collector and OTLP, so GCP services sit in one open pipeline.
A GCP estate spans compute (GCE, GKE, Cloud Run, Cloud Functions), managed data (Cloud SQL, BigQuery, Spanner), networking, and applications. The goal is one correlated view: application error rate and latency, the saturation and quota usage of managed services, GKE node and pod health, and cost. Quota exhaustion and throttling are GCP-specific signals worth watching, because they cause failures that look exactly like application bugs.
As with any cloud, the fastest path to a fix is correlating an application symptom with the managed-service cause, so a Cloud Run latency spike lines up with the Cloud SQL instance or the quota behind it.
The Collector's googlecloudmonitoring receiver pulls Cloud Monitoring metrics for your resources, application traces and metrics arrive over OTLP, and GKE is covered by the standard Kubernetes receivers. If you keep Cloud Observability as a backend, the Google Cloud exporter can also send OpenTelemetry data into it.
Two notes: give the Collector a service account with the monitoring viewer role, and pull the metrics you need rather than the whole project, since Cloud Monitoring reads have both cost and latency.
Key Cloud Monitoring signals by service, the ones behind most incidents:
| Signal | Source | What it tells you / watch for |
|---|---|---|
cloudsql.googleapis.com/database/cpu/utilization | googlecloudmonitoring | Cloud SQL CPU saturation; the usual cause of an app that slows under load. |
cloudsql.googleapis.com/database/network/connections | googlecloudmonitoring | Cloud SQL connection count against the limit. |
run.googleapis.com/request_latencies | googlecloudmonitoring | Cloud Run request latency; watch p95/p99 per service. |
run.googleapis.com/request_count (by response code) | googlecloudmonitoring | Cloud Run request rate and error rate by status. |
Cloud Run container startup latency | googlecloudmonitoring | Cold-start latency; frequent cold starts degrade tail latency. |
serviceruntime quota exceeded | googlecloudmonitoring | API quota exhaustion, a GCP-specific failure that mimics application errors. |
A GCP dashboard should lead from application symptom to managed-service or quota cause. Row one is the application: error rate and p95 latency by service, from OTLP traces and Cloud Run request metrics. Row two is data and compute: Cloud SQL CPU and connections, Cloud Run latency and cold starts. Row three is quota and cost: quota usage against limits, and daily spend by service.
# Cloud SQL CPU saturation
cloudsql.googleapis.com/database/cpu/utilization by (database_id)
# Cloud Run 5xx rate
sum(rate(run.googleapis.com/request_count{response_code_class="5xx"}[5m])) by (service_name)
/ sum(rate(run.googleapis.com/request_count[5m])) by (service_name)
# Cloud Run p99 latency
histogram_quantile(0.99, run.googleapis.com/request_latencies) by (service_name)An application slows and Cloud SQL CPU utilization is pinned, because the database is the bottleneck. Optimise the heavy queries or scale the instance; the CPU-utilization metric confirms where the time goes.
Tail latency is high because new container instances start frequently, each paying a cold-start cost, especially on spiky or low-traffic services. Startup-latency and request-latency percentiles together reveal it. Set a minimum-instances floor or reduce container startup time.
Requests fail with quota-exceeded errors that look like application bugs, because a project or API quota was hit. The quota metric against its limit is the tell. Request a quota increase or spread load; this is a class of failure that has no application-side fix.
Starting thresholds to tune:
| Condition | Signal | Meaning |
|---|---|---|
| Cloud SQL CPU > 85% for 5m | database | Database saturating. |
| Cloud Run 5xx rate > 2% for 5m | app | Service failing. |
| quota usage > 90% of limit | quota | Approaching a hard failure. |
| cold-start rate rising | latency | Tail latency degrading. |
Ops Singularity's TelemetryOps ingests GCP telemetry over OpenTelemetry and its FinOps pillar tracks GCP cost, while Sentinel AI resolves incidents through governed Action Tickets. Explore TelemetryOps.
Use the OpenTelemetry Collector's googlecloudmonitoring receiver to pull Cloud Monitoring metrics, and collect application traces and metrics over OTLP, with Kubernetes receivers for GKE.
Application error rates and latency, resource saturation, quota usage and throttling, GKE node and pod health, and cost.
Bring a real incident. We will show you Sentinel investigate, act and verify end to end, with every action reversible and audited.