Google Cloud Finally Gets Native OpenTelemetry Ingestion

I got an email from Google this morning about a new OTLP endpoint. Buried in the usual “no action required” corporate-speak was something I’ve been waiting for: telemetry.googleapis.com — a single endpoint that accepts native OpenTelemetry Protocol for logs, traces, and metrics.

It goes live March 23, 2026.

The old way was annoying

If you wanted to send OTel data to GCP before, you needed GCP-specific exporters. Your pipeline looked like this:

App → OTel Collector → googlecloud exporter → logging.googleapis.com
                    → googlecloud exporter → cloudtrace.googleapis.com  
                    → googlecloud exporter → monitoring.googleapis.com

Three separate APIs. Custom exporter configuration. And if you were using something like Grafana Alloy instead of the vanilla OTel Collector, you had to deal with compatibility quirks.

The new way

App → telemetry.googleapis.com (OTLP/gRPC or OTLP/HTTP)

That’s it. One endpoint. Standard OTLP. Works with any collector that speaks the protocol.

Setting it up with Grafana Alloy

Here’s a working config for Alloy. I tested this with the beta endpoint:

// Receive OTLP from your apps
otelcol.receiver.otlp "default" {
  grpc {
    endpoint = "0.0.0.0:4317"
  }
  http {
    endpoint = "0.0.0.0:4318"
  }
  output {
    logs    = [otelcol.exporter.otlp.gcp.input]
    traces  = [otelcol.exporter.otlp.gcp.input]
    metrics = [otelcol.exporter.otlp.gcp.input]
  }
}

// Send to GCP
otelcol.exporter.otlp "gcp" {
  client {
    endpoint = "telemetry.googleapis.com:443"
    
    tls {
      insecure = false
    }
    
    // GKE workload identity — no credentials needed
    // For VMs or external: use service account JSON
    auth = otelcol.auth.oauth2.gcp.handler
  }
}

// OAuth2 for GCP authentication
otelcol.auth.oauth2 "gcp" {
  // If using workload identity in GKE, this works automatically
  // For service accounts, set GOOGLE_APPLICATION_CREDENTIALS env var
}

Authentication options

In GKE with Workload Identity (easiest):

# On your ServiceAccount
iam.gke.io/gcp-service-account: [email protected]

The collector picks it up automatically. No secrets to manage.

On VMs or outside GCP:

export GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account.json

Or mount the JSON file and point to it in your config.

Required IAM roles

Your service account needs these:

• roles/monitoring.metricWriter — write metrics
• roles/logging.logWriter — write logs
• roles/cloudtrace.agent — write traces

Grant them like this:

gcloud projects add-iam-policy-binding YOUR_PROJECT \
  --member="serviceAccount:YOUR_SA@YOUR_PROJECT.iam.gserviceaccount.com" \
  --role="roles/monitoring.metricWriter"
  
# Repeat for the other two roles

With vanilla OTel Collector

If you’re using the standard OpenTelemetry Collector:

exporters:
  otlp/gcp:
    endpoint: telemetry.googleapis.com:443
    auth:
      authenticator: oauth2client

extensions:
  oauth2client:
    client_id: ""  # Not needed for GCP
    client_secret: ""  # Not needed for GCP
    token_url: https://oauth2.googleapis.com/token
    scopes:
      - https://www.googleapis.com/auth/cloud-platform
    # Uses ADC (Application Default Credentials)

service:
  extensions: [oauth2client]
  pipelines:
    traces:
      exporters: [otlp/gcp]
    metrics:
      exporters: [otlp/gcp]
    logs:
      exporters: [otlp/gcp]

What about existing setups?

Google says existing integrations keep working. The new endpoint is additive. Your logging.googleapis.com calls won’t break.

You can migrate gradually: point new services at the OTLP endpoint, leave legacy stuff alone.

Is it actually better?

For my use case, yes. We run Grafana Alloy as the collector (it handles Prometheus metrics alongside OTel). Having a standard OTLP exporter instead of GCP-specific config means:

• Same collector config works across GCP, AWS, and local dev
• Easier to switch backends if needed
• Less vendor lock-in in the telemetry layer

The tradeoff: you lose some GCP-specific features like automatic resource detection. The googlecloud exporter knew how to label things with GCE instance IDs, GKE pod names, etc. With raw OTLP, you need to set resource attributes yourself.

For most teams, that’s a reasonable tradeoff. Your OTel SDK should be setting those attributes anyway.

When to switch

March 23 is when it auto-enables. But there’s no rush to migrate existing pipelines. I’d wait a month after GA to let others find the edge cases.

For new projects starting now? Just use the OTLP endpoint from day one.