How it works

Note: Unlike AWS and Azure, GCP requires deploying Grafana Alloy. There is no serverless “scrape job” option.

Complexity: Moderate | Infrastructure: GCE or GKE | Latency: Configurable

Alloy collects from Cloud Monitoring using its embedded Stackdriver exporter, then sends the metrics to Grafana Cloud. Its processing pipeline lets you filter, relabel, and aggregate metrics before they’re stored.

Authentication options

Authentication	Description
Service account (JSON key)	Simple setup; requires rotating the key
Workload identity	Uses the identity of the pod or VM; no keys to manage

Considerations

Multiple projects from one Alloy deployment
Workload identity support, so no keys to manage
Full processing pipeline for filtering, relabeling, and aggregation
Metrics in Prometheus format for PromQL
Alloy infrastructure to deploy, maintain, and update

Documentation

View the GCP metrics documentation.

0:00

Read transcript

Audio transcript

Now for GCP, and here’s an important difference. Unlike AWS and Azure, GCP doesn’t have a serverless scrape option. You need to deploy Grafana Alloy to collect metrics from Cloud Monitoring.

Alloy uses an embedded Stackdriver exporter to pull metrics and send them to Grafana Cloud.

You have two authentication options. The simpler approach is a service account with a JSON key file. Download it from GCP, configure it in Alloy, and you’re collecting metrics.

But if you’re security-conscious, and you should be, there’s a better way: workload identity. Deploy Alloy in GKE or on a GCE instance, and it authenticates using the identity of the pod or VM. No JSON keys to leak, no rotation schedules. It just works.

Alloy also gives you a full processing pipeline. Filter out metrics you don’t need, relabel for consistency, aggregate high-cardinality data.

Yes, you’re running infrastructure. But for GCP, that’s the only path to getting metrics into Grafana Cloud.

How it works

Authentication options

Considerations

Documentation

Still have questions?

Get every update