Integration · Google Cloud

Google Cloud monitoring for GKE, Cloud Run, Cloud SQL and Pub/Sub

Collect Cloud Monitoring metrics from all your GCP projects without agents, add Kubernetes and host depth with the Obseria Agent, and follow requests across services with OpenTelemetry.
Try for freeRequest a demo
Obseria apps and capabilities: observability, APM, infrastructure and integrations
Obseria home dashboard with service health, open problems, SLO compliance and ingestion
Obseria trace explorer with span list and span attributes
Overview

Why monitor Google Cloud with Obseria

All projects, one place

Connect GCP projects with a read-only service account and see Compute Engine, GKE, Cloud Run, Cloud SQL and Pub/Sub together.

OpenTelemetry-native

Google Cloud services and client libraries speak OpenTelemetry well; Obseria ingests OTLP traces, metrics and logs as they are.

Backlog to root cause

Link a growing Pub/Sub backlog or slow Cloud SQL query to the service and deployment that caused it, using topology and traces.

Coverage

Google Cloud services Obseria monitors

  • Compute Engine. CPU, disk, network and uptime per instance and managed instance group, plus processes with the Obseria Agent.
  • Google Kubernetes Engine (GKE). Cluster, node, pod and container metrics for Standard and Autopilot clusters.
  • Cloud Run. Request count, latency, instance count and container CPU and memory per service and revision.
  • Cloud SQL. CPU, memory, disk, connections and replication lag for PostgreSQL, MySQL and SQL Server.
  • Pub/Sub. Publish rates, undelivered messages and oldest unacked message age per subscription.
  • Cloud Monitoring and Cloud Logging. Metrics from any Google Cloud metric type and logs routed from Cloud Logging.
At a glance

The Google Cloud signals that matter

Obseria collects these values automatically and shows them in ready-made dashboards and alerts.

Compute capacity

Shows how busy your virtual machines and containers are, so you can tell when you are close to running out.

  • compute.googleapis.com/instance/cpu/utilization
  • kubernetes.io/container/cpu/core_usage_time
  • kubernetes.io/container/memory/used_bytes

Service speed and demand

Tells you how many requests your services handle, how fast they answer and how far they scale up.

  • run.googleapis.com/request_count
  • run.googleapis.com/request_latencies
  • run.googleapis.com/container/instance_count

Database load

Indicates whether your managed databases are working comfortably or are approaching their limits during busy periods.

  • cloudsql.googleapis.com/database/cpu/utilization

Message backlog

Reveals whether background messages are piling up or waiting too long, which delays orders, notifications and downstream processes.

  • pubsub.googleapis.com/subscription/num_undelivered_messages
  • pubsub.googleapis.com/subscription/oldest_unacked_message_age
Show all 9 metrics in detail
MetricUnitWhat it tells you
compute.googleapis.com/instance/cpu/utilizationRatioFraction of allocated CPU in use on a VM instance.
kubernetes.io/container/cpu/core_usage_timesCumulative CPU time used by a container on GKE.
kubernetes.io/container/memory/used_bytesBytesMemory used by a container; compare with its limit to anticipate OOM kills.
run.googleapis.com/request_countCountRequests served by a Cloud Run revision, split by response code class.
run.googleapis.com/request_latenciesmsDistribution of request latency per Cloud Run revision.
run.googleapis.com/container/instance_countCountContainer instances running, useful to spot scaling limits and cold starts.
cloudsql.googleapis.com/database/cpu/utilizationRatioCPU utilization of the Cloud SQL instance.
pubsub.googleapis.com/subscription/num_undelivered_messagesCountBacklog of unacknowledged messages in a subscription.
pubsub.googleapis.com/subscription/oldest_unacked_message_agesAge of the oldest unacknowledged message, the clearest sign of a stuck consumer.
Setup

Set up Google Cloud monitoring in minutes

  1. Step 1

    Create a read-only service account

    Create a service account in each project or at folder level and grant Monitoring Viewer, Compute Viewer and Cloud Asset Viewer.

  2. Step 2

    Connect projects in Obseria

    Provide the service account credentials, select projects and services, and Cloud Monitoring metrics start flowing agentlessly.

  3. Step 3

    Add GKE and trace depth

    Install the Obseria Agent on GKE with the Helm chart, and point OpenTelemetry SDKs on Cloud Run or GKE at your OTLP endpoint.

Example configuration · BASH
# Service account for agentless collection
gcloud iam service-accounts create obseria-reader \
  --display-name="Obseria read-only"

SA="obseria-reader@${PROJECT_ID}.iam.gserviceaccount.com"

# Read metrics, instances and asset metadata
for ROLE in roles/monitoring.viewer roles/compute.viewer roles/cloudasset.viewer; do
  gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
    --member="serviceAccount:${SA}" \
    --role="${ROLE}"
done

Out of the box

Dashboards, alerts and SLOs that are ready the moment data arrives.

  • GCP project overview by service and region
  • GKE cluster and workload health
  • Cloud Run latency, errors and instance scaling
  • Cloud SQL performance and replication lag
  • Pub/Sub backlog and oldest message age alerts
Guide

Google Cloud monitoring: what matters

Why Google Cloud monitoring goes beyond single services

Google Cloud monitoring is built on Cloud Monitoring, which exposes thousands of metric types for Compute Engine, GKE, Cloud Run, Cloud SQL, Pub/Sub and the rest of the platform. Each metric is precise, but modern GCP architectures are event-driven and distributed: a Cloud Run service publishes to Pub/Sub, a GKE worker consumes the messages and writes to Cloud SQL. When latency rises, the cause can sit anywhere in that chain.

GCP observability means connecting those metrics to traces and logs from your services, across projects, so you can follow a single request or message through the system. It also means looking at GCP side by side with workloads that run on AWS, Azure or on premises, because few organizations run on one cloud only.

The GCP metrics that matter

Use the golden signals per service and add saturation metrics where queues and pools are involved:

  • Compute Engine: instance/cpu/utilization, disk read and write operations, network bytes and uptime. Memory requires a guest agent, which the Obseria Agent provides.
  • GKE: container/cpu/core_usage_time, container/memory/used_bytes against limits, container restart counts and node allocatable resources.
  • Cloud Run: request_count by response code class, request_latencies percentiles, container/instance_count and container CPU and memory utilization.
  • Cloud SQL: database/cpu/utilization, memory and disk utilization, connection counts such as database/postgresql/num_backends, and replica lag.
  • Pub/Sub: subscription/num_undelivered_messages and subscription/oldest_unacked_message_age, plus publish and acknowledge rates.

Common Google Cloud problems and how to detect them

Stuck consumers. If oldest_unacked_message_age keeps climbing while the backlog grows, a subscriber is failing or too slow. Traces from the consumer show whether it is blocked on a downstream call or crashing.

Cloud Run scaling limits. When container/instance_count hits the configured maximum, latency and 429 or 503 responses rise. Cold starts appear as long first requests on new instances. Both are visible when request latency and instance count share one chart.

Cloud SQL saturation. High CPU or exhausted connections on Cloud SQL often trace back to one new query or a missing connection pool in a Cloud Run service that scaled out. Database spans name the query and the caller.

GKE resource pressure. Containers close to their memory limit get OOM killed and restart. Restart counts, memory usage against limits and Kubernetes events identify the workload and help you tune requests and limits, or the Autopilot resource settings.

Quota and configuration changes. Changed quotas, IAM bindings or new revisions often precede incidents. Showing deployments and revisions on the same timeline as metrics makes the connection obvious.

Google Cloud monitoring best practices

  1. Use consistent labels for team, service and environment and carry them into dashboards and alerts.
  2. Connect all projects through folder-level IAM grants so new projects are monitored automatically.
  3. Alert on latency, error rate and backlog age that users and downstream systems feel, not only on CPU.
  4. Instrument services with OpenTelemetry and propagate trace context through Pub/Sub message attributes.
  5. Track revisions and deployments as events to correlate regressions with releases.

How Obseria monitors Google Cloud

Obseria connects agentlessly with a read-only service account and collects Cloud Monitoring metrics and asset metadata for Compute Engine, GKE, Cloud Run, Cloud SQL, Pub/Sub and more, as part of 300+ cloud services across AWS, Azure and Google Cloud. The Obseria Agent runs as a DaemonSet on GKE and on Compute Engine VMs, and OpenTelemetry traces, metrics and logs arrive over OTLP. Obseria TopoGraph maps services, topics and databases automatically, and Obseria Intelligence uses that map to find root causes with a chain of evidence. Dashboards, alerts and SLOs are included at no extra cost.

Cloud Logging entries can be routed to Obseria through a log sink and processed by Obseria Pipeline, which drops noise, masks personal data and routes each stream to the right retention. Because Obseria speaks OTLP, PromQL and SQL, teams that already use Managed Service for Prometheus or OpenTelemetry on GKE can keep their instrumentation and queries.

Related integrations

Amazon Web ServicesAWS MonitoringMicrosoft AzureAzure MonitoringApache KafkaApache Kafka Monitoring
All integrations

Related capabilities

Cloud Monitoring

Monitor 300+ cloud services agentless and see how they affect your applications. One platform for multi-cloud metrics, logs, traces and topology.

Learn more

Kubernetes Monitoring

See every cluster, node, pod and workload in context. Obseria connects Kubernetes metrics, events, logs and traces so you find the cause of a failing rollout in minutes.

Learn more

Serverless Monitoring

Trace every invocation across functions, queues and APIs. Obseria shows cold starts, errors, duration and cost for serverless workloads in the context of your whole system.

Learn more
Part of Infrastructure Observability

Learn more

What is observability?

What is observability? Learn how metrics, logs, traces and profiles let you understand any system state, how it differs from monitoring, and how to start.

The four golden signals: latency, traffic, errors and saturation

The four golden signals explained: latency, traffic, errors and saturation, how they relate to the RED and USE methods, and how to measure them with OTel.

Google Cloud monitoring FAQ

No. Cloud Monitoring metrics are collected agentlessly with a read-only service account. The Obseria Agent is optional and adds host, Kubernetes and log detail on Compute Engine and GKE.

Monitoring Viewer for metrics, Compute Viewer for instance metadata and Cloud Asset Viewer for resource discovery. All are read-only roles.

Yes. Platform metrics for Autopilot clusters are collected agentlessly, and OpenTelemetry Collectors or SDKs running in the cluster can send additional telemetry over OTLP.

Add the OpenTelemetry SDK for your language and set OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT and OTEL_EXPORTER_OTLP_HEADERS as environment variables on the service. Traces then show up within minutes.

Yes. Grant the roles at folder or organization level and select the projects in Obseria. Data from all projects can be filtered by project, region and label.

Start monitoring Google Cloud today

Connect Google Cloud in minutes with OpenTelemetry or the Obseria Agent. Free for 14 days.

Try for freeContact Sales