Google Cloud Run

Overview

Google Cloud Run is a fully managed compute platform that automatically scales your stateless containers. Cloud Run emits several service-level metrics directly to Google Cloud Monitoring, including request counts, response latencies, container resource usage, and concurrency.

This integration helps you collect Cloud Run platform metrics using the OpenTelemetry Collector's receiver.

Use Cases

• Track request count and latency for each Cloud Run service.
• Monitor container concurrency and resource utilization.
• Capture error responses across Cloud Run revisions.

Metrics Summary

Metric Name	Description
	Number of requests received
	Latency of responses
	CPU usage by container
	Memory usage by container
	Number of container instances
	Time the container was active (billable)
	Max concurrency of requests handled
	Received bytes
	Sent bytes

See Cloud Run metrics in GCP Monitoring for the full list and definitions.

Setup

Cloud Run metrics are available in Google Cloud Monitoring. To collect these metrics and send them to Dash0, use the OpenTelemetry Collector with the receiver.

1. Where to Run the Collector

You can run the OpenTelemetry Collector in a few different environments:

• If you're already using Kubernetes, consider deploying the Collector in your cluster.
• Alternatively, you can run the Collector on a standalone VM or Compute Engine instance.

2. Permissions

To collect metrics from Google Cloud Monitoring, the OpenTelemetry Collector must authenticate with the correct permissions and run in a properly configured GCP project.

Required Permissions

The Collector must use a Google Cloud service account with the following role:

• — grants read access to Cloud Monitoring metrics.

You can assign this role directly to a service account or via Workload Identity if running on GKE.

Authentication

The receiver uses Application Default Credentials (ADC) to authenticate. The behavior depends on where you run the Collector:

• On GCP (GKE, Compute Engine): Credentials are picked up automatically from the attached service account — no need to set environment variables.
• Outside GCP (e.g., on a VM or local environment): You must set the environment variable to point to a service account key file.

Wherever possible, prefer using GCP-native authentication mechanisms like Workload Identity over key files.

Running on GKE? Use Workload Identity

To bind a Kubernetes service account (KSA) to a GCP service account:

• Enable Workload Identity on your GKE cluster (enabled by default on Autopilot).
• Annotate your KSA with the email of the GCP service account.
• Ensure the GCP service account trusts the KSA via the binding.

See Workload Identity docs for full setup details.

GCP Project Requirements

Make sure the project you're collecting metrics from meets the following:

• Billing is enabled — required for Cloud Monitoring to function beyond the free tier.
• Cloud Monitoring API is enabled — the collector depends on this to fetch metrics.
• Relevant metrics exist — the metrics you request must be emitted by services running in that project.

If you're not seeing expected data, check that the service is deployed and actively generating telemetry in the target project.

3. Collector Configuration

Replace the with your GCP project id. Dash0 GRPC endpoint and token can be obtained in the organization settings for your account under "Auth Tokens" and "Endpoints".

4. Further Reading

• Cloud Run metrics list
• googlecloudmonitoringreceiver docs