Skip to content

Add Google Cloud OpenTelemetry plugin#2955

Draft
eamsden wants to merge 3 commits into
mainfrom
gcp-opentelemetry-plugin
Draft

Add Google Cloud OpenTelemetry plugin#2955
eamsden wants to merge 3 commits into
mainfrom
gcp-opentelemetry-plugin

Conversation

@eamsden

@eamsden eamsden commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

What was changed

  • Added the temporal-gcp module and GcpOpenTelemetryPlugin as a thin Google Cloud Run configuration layer over temporal-opentelemetry.
  • Added Cloud Run worker-pool and service naming defaults while retaining standard OTLP endpoint overrides.
  • Deferred shutdown flushing by default until after asynchronous worker termination, with an explicit opt-in for immediate best-effort flushing.
  • Set the GCP metrics reporting/export interval to sixty seconds by default, coordinated with the other Temporal SDK GCP plugins and above Google Cloud's five-second minimum export interval.
  • Added focused tests, Gradle module wiring, and a Temporal BOM constraint.
  • Added module documentation that recommends worker pools, states the Cloud Run service requirements, makes the collector sidecar mandatory by default, and documents worker-pool resource-detection limitations.
  • Documented that cumulative metrics must pass directly to googlemanagedprometheus without a batch processor, while traces retain a dedicated five-second batch processor, so periodic exports and forced shutdown flushes cannot be combined into a duplicate-series request.

Why?

Temporal Java workers running on Google Cloud Run need an SDK-supported path for exporting Temporal metrics and traces through the standard local OTLP collector sidecar. Keeping Google resource detection and exporters in the collector avoids Google Cloud client dependencies and direct-export configuration in the worker process. Worker pools are the preferred Cloud Run deployment for continuously polling Temporal workers.

A one-second metric interval can interact poorly with a collector batch processor because the batch may combine multiple cumulative snapshots of each Temporal metric into one Google Monitoring request. The coordinated GCP-specific sixty-second default prevents ordinary periodic exports from colliding while remaining configurable. Passing cumulative metrics directly to Managed Prometheus without a collector batch makes a forced shutdown flush safe regardless of its timing relative to the last periodic export.

Checklist

  1. Closes: N/A.

  2. How was this tested:

    • ./gradlew --offline spotlessApply :temporal-gcp:test :temporal-gcp:javadoc :temporal-gcp:generatePomFileForMavenJavaPublication
    • ./gradlew --offline spotlessApply :temporal-opentelemetry:test :temporal-gcp:build :temporal-bom:generatePomFileForMavenJavaPublication
    • Seven focused unit tests cover configuration precedence, the sixty-second GCP metrics default, plugin installation, deferred shutdown flushing, and the immediate-flush override.
    • Verified the generated temporal-gcp POM only publishes temporal-opentelemetry as a dependency.
    • Cloud Run worker-pool and Temporal Cloud E2E verified workflow execution, the resolved service name and OTLP endpoint, metrics and trace export, periodic and shutdown flushing, GCP resource attribution, and clean collector shutdown without duplicate-series or exporter errors.
    • The complete refreshed GitHub Actions suite passed.
  3. Any docs updates needed?

    • Added contrib/temporal-gcp/README.md with setup, deployment requirements, lifecycle, collector-sidecar requirements, metrics interval and batching guidance, and resource-detection caveats.

Breaking changes?

No.

Server PR

None.

Use the coordinated 60-second metrics interval for the GCP plugin while preserving explicit overrides. Document an unbatched Managed Prometheus metrics pipeline so periodic exports and forced shutdown flushes cannot be combined into a duplicate-series request.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant