> ## Documentation Index > Fetch the complete documentation index at: https://docs.honeycomb.io/llms.txt > Use this file to discover all available pages before exploring further. # Collect Telemetry from Google Cloud Platform > Send Google Cloud Platform telemetry to Honeycomb using an OpenTelemetry Collector. Deploy an OpenTelemetry (OTel) Collector to ingest telemetry from Google Cloud Platform (GCP) services and send it to Honeycomb. Analyzing your GCP telemetry with Honeycomb lets you answer questions like: * How did response time change after scaling up my Cloud Run services? * What is the error rate for my Pub/Sub topics? * How does application performance vary across GCP regions? * Are application errors happening in specific services, or across the entire environment? * Are there any performance bottlenecks in my Cloud SQL or Firestore operations? ## Before you begin Before you begin, make sure you have: * A [Google Cloud account](https://docs.cloud.google.com/docs/get-started) with appropriate admin privileges * Access to a GCP project you want to monitor * A [Honeycomb Ingest API Key](/configure/environments/manage-api-keys/#create-api-key) ## Choosing a collector distribution Your first decision is which collector distribution to use: * **[OpenTelemetry Collector Contrib](https://github.com/open-telemetry/opentelemetry-collector-releases/releases):** The community-maintained distribution that includes GCP receivers. This is the recommended starting point if you are already using OpenTelemetry across your stack or want a single collector for multiple environments. * **[Google's collector distribution](https://github.com/GoogleCloudPlatform/opentelemetry-operations-collector/tree/v0.144.0/google-built-opentelemetry-collector):** Google's own build, optimized for GCP environments. Consider this if you are running entirely on GCP and want tighter integration with Google's deployment tooling. * **[Custom collector](https://opentelemetry.io/docs/collector/extend/ocb/):** Build your own binary with only the components you need. Include only the components that match the GCP services you want to monitor: * [Google Cloud Monitoring Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/googlecloudmonitoringreceiver) * [Google Pub/Sub Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/googlecloudpubsubreceiver) * [Google Cloud Spanner Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/googlecloudspannerreceiver) * [Google Cloud LogEntry Encoding Extension](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/encoding/googlecloudlogentryencodingextension) * [Google Client Auth Extension](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/googleclientauthextension) * [Google Secrets Provider](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/confmap/provider/googlesecretmanagerprovider) Use the following `builder-config.yaml` to build a custom collector with the GCP components you need: ```yaml theme={} extensions: - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/encoding/googlecloudlogentryencodingextension v0.149.0 - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/googleclientauthextension v0.149.0 receivers: - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/googlecloudmonitoringreceiver v0.149.0 - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/googlecloudpubsubreceiver v0.149.0 - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/googlecloudspannerreceiver v0.149.0 providers: - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/confmap/provider/googlesecretmanagerprovider v0.149.0 ``` ## Deploying an OpenTelemetry Collector Deploy your collector in the same GCP environment as the services you want to monitor. This minimizes network latency and simplifies authentication using GCP's built-in identity mechanisms. Google Cloud offers deployment guides for several environments. These guides focus on the Google-built OpenTelemetry Collector, but you can adapt them for other distributions. Follow the guide for your environment: * [Deploy on Google Kubernetes Engine](https://docs.cloud.google.com/stackdriver/docs/instrumentation/opentelemetry-collector-gke) * [Deploy on Container-Optimized OS](https://docs.cloud.google.com/stackdriver/docs/instrumentation/opentelemetry-collector-cos) * [Deploy on Cloud Run](https://docs.cloud.google.com/stackdriver/docs/instrumentation/opentelemetry-collector-cloud-run) * [Deploy on Compute Engine](https://docs.cloud.google.com/stackdriver/docs/instrumentation/opentelemetry-collector-gce) ## Collecting Google Cloud Run function metrics The [Google Cloud Monitoring Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.147.0/receiver/googlecloudmonitoringreceiver) pulls metrics from the Cloud Monitoring API on a schedule, making it useful for infrastructure-level data like instance counts, execution times, and memory usage. The receiver accepts a list of metric names; to explore available metrics, visit [Google's Cloud Monitoring documentation](https://docs.cloud.google.com/monitoring/api/metrics). This example configuration collects [Google Cloud Run function metrics](https://docs.cloud.google.com/monitoring/api/metrics_gcp_c#gcp-cloudfunctions): ```yaml theme={} receivers: googlecloudmonitoring: collection_interval: 2m project_id: your-gcp-project-id metrics_list: - metric_name: "cloudfunctions.googleapis.com/function/active_instances" - metric_name: "cloudfunctions.googleapis.com/function/execution_count" - metric_name: "cloudfunctions.googleapis.com/function/execution_times" - metric_name: "cloudfunctions.googleapis.com/function/instance_count" - metric_name: "cloudfunctions.googleapis.com/function/network_egress" - metric_name: "cloudfunctions.googleapis.com/function/user_memory_bytes" - metric_name: "cloudfunctions.googleapis.com/pending_queue/pending_requests" processors: batch: {} exporters: otlp/honeycomb_metrics: endpoint: "api.honeycomb.io:443" # US instance #endpoint: "api.eu1.honeycomb.io:443" # EU instance headers: "x-honeycomb-team": "YOUR_API_KEY" # your Honeycomb Ingest API key # "x-honeycomb-dataset": "YOUR_DATASET_NAME" # optional service: pipelines: metrics: receivers: [googlecloudmonitoring] processors: [batch] exporters: [otlp/honeycomb_metrics] ``` ## Collecting traces, logs, and metrics from Google Pub/Sub Pub/Sub is a natural integration point for telemetry in GCP because many services can publish to a topic, and the receiver handles consuming and forwarding that data without additional configuration overhead. Use the [Google Pub/Sub Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/googlecloudpubsubreceiver) to collect telemetry from a Google Pub/Sub subscription. The following example configuration collects telemetry from a Pub/Sub subscription: ```yaml theme={} receivers: googlecloudpubsub: project: your-project subscription: projects/your-project/subscriptions/otlp-logs ``` ## Collecting database metrics from Google Cloud Spanner The Spanner Receiver collects query and transaction metrics directly from Spanner's built-in statistics tables, giving you visibility into slow queries, lock contention, and data volume without requiring application-level instrumentation. Use the [Google Cloud Spanner Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/googlecloudspannerreceiver) to collect query, transaction, and other metrics from your databases. The following example configuration collects metrics from two Spanner instances across a single project: ```yaml theme={} receivers: googlecloudspanner: collection_interval: 60s initial_delay: 1s top_metrics_query_max_rows: 100 backfill_enabled: true cardinality_total_limit: 200000 hide_topn_lockstats_rowrangestartkey: false truncate_text: false projects: - project_id: "spanner project 1" service_account_key: "path to spanner project 1 service account json key" instances: - instance_id: "id1" databases: - "db11" - "db12" - instance_id: "id2" databases: - "db21" - "db22" ``` ## Exporting telemetry to Honeycomb Once your receivers are configured, add an OTLP exporter to send your GCP telemetry to Honeycomb. Use the endpoint that matches the region where your Honeycomb data is stored. Configure an OTLP exporter with your [Honeycomb Ingest API Key](/configure/environments/manage-api-keys/#create-api-key) as a header: ```yaml theme={} exporters: otlp/honeycomb: endpoint: "api.honeycomb.io:443" # US instance #endpoint: "api.eu1.honeycomb.io:443" # EU instance headers: "x-honeycomb-team": "YOUR_API_KEY" ``` By default, Honeycomb routes telemetry to datasets based on the service name in your data. If you want to send specific signal types, such as metrics, to a dedicated dataset, add a second exporter with the `x-honeycomb-dataset` header: ```yaml theme={} exporters: otlp/honeycomb: endpoint: "api.honeycomb.io:443" # US instance #endpoint: "api.eu1.honeycomb.io:443" # EU instance headers: "x-honeycomb-team": "YOUR_API_KEY" otlp/honeycomb_metrics: endpoint: "api.honeycomb.io:443" # US instance #endpoint: "api.eu1.honeycomb.io:443" # EU instance headers: "x-honeycomb-team": "YOUR_API_KEY" "x-honeycomb-dataset": "YOUR_METRICS_DATASET" ``` ## Getting help To ask questions and learn more, join our [Pollinators Community Slack](/troubleshoot/community/#join-pollinators-community-slack).