Add GCP OpenTelemetry plugin - #1658
Draft
eamsden wants to merge 2 commits into
Draft
Conversation
This was referenced Jul 17, 2026
seanbollin
added a commit
that referenced
this pull request
Sep 9, 2026
* Add GCP Cloud Run OpenTelemetry support Adds a Cloud Run serverless-worker OpenTelemetry integration, mirroring the approved .NET SDK common-core refactor (temporalio/sdk-dotnet#844) and building on #1658. - New package temporalio.contrib.gcp.cloud_run: an OpenTelemetryPlugin that exports Core metrics and tracing spans over OTLP/gRPC to a local OpenTelemetry Collector sidecar. Cloud Run specifics only (service name from CLOUD_RUN_WORKER_POOL/K_SERVICE, 60s metric periodicity); gated behind a new cloud-run-worker-otel extra, no google-cloud client libraries. - New private temporalio/contrib/opentelemetry/_serverless.py: shared, provider-neutral helpers (endpoint/service-name resolution, Core-metrics telemetry config, lazy OTLP span-processor factory). It is not re-exported, so importing temporalio.contrib.opentelemetry gains no exporter import. - Refactor the AWS Lambda lambda_worker/otel.py onto _serverless with no public API or behavior change (existing tests unmodified). Co-authored-by: Edward Amsden <edward.amsden@temporal.io> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Update uv.lock for the cloud-run-worker-otel extra Records the new optional-dependency extra in the lockfile. The extra reuses packages already locked via lambda-worker-otel, so there are no new package or version changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Suppress reportMissingTypeStubs on the OTLP exporter import The lazy OTLPSpanExporter import in _serverless.build_otlp_span_processor tripped basedpyright reportMissingTypeStubs under the test-latest-deps job (whose newer exporter build ships no type stubs). Matches the existing suppression pattern in contrib/aws/lambda_worker/otel.py. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Raise cloud-run-worker-otel OTLP exporter floor to >=1.26 The extra required opentelemetry-exporter-otlp-proto-grpc>=1.11.1 without a companion constraint pinning a modern OpenTelemetry stack (unlike lambda-worker-otel, whose opentelemetry-sdk-extension-aws>=2.0.0 transitively caps protobuf<7). That let uv lock --upgrade downgrade the exporter to 1.11.1 and pull the just-released protobuf 7.35.1, whose runtime is incompatible with the old generated protobuf code (test-latest-deps failures). Raising the floor to >=1.26 (matching the api/sdk floors in this extra) removes the ancient version from the resolution; uv lock --upgrade now holds at protobuf 6.33.6. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Cap protobuf<7 in cloud-run-worker-otel; restore exporter floor >=1.11.1 Raising the exporter floor to >=1.26 (previous commit) fixed test-latest-deps but broke check-protos: that job forces protobuf<4 and runs uv sync --all-extras, and a >=1.26 exporter requires protobuf>=4, so uv could not resolve. Restore the low >=1.11.1 floor (matching lambda-worker-otel) so the exporter can downgrade to a protobuf-3-compatible build under protobuf<4, and add an explicit protobuf<7 cap so uv lock --upgrade (test-latest-deps) cannot downgrade the exporter to pull the incompatible protobuf 7.x. Satisfies both jobs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Move Cloud Run OTel plugin into cloud_run/opentelemetry sub-package Mirror the worker-ID PR structure by relocating the OpenTelemetry plugin into temporalio/contrib/gcp/cloud_run/opentelemetry/. The rich package docstring and public exports now live in that sub-package's __init__.py, and the module/README/tests move alongside it. New public import: from temporalio.contrib.gcp.cloud_run.opentelemetry import OpenTelemetryPlugin Reduce temporalio/contrib/gcp/__init__.py and temporalio/contrib/gcp/cloud_run/__init__.py to generic namespace markers so this PR and the worker-ID PR add byte-identical files and merge cleanly. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Added unreleased changelog entry for OTel plugin --------- Co-authored-by: Edward Amsden <edward.amsden@temporal.io> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
temporalio.contrib.gcp.OpenTelemetryPlugin, a thin GCP-focused wrapper around the existing OpenTelemetry pluginmetric_periodicity=overridesgcp-opentelemetrydependency extra, usage documentation, and focused testsThe worker does not use Google Cloud clients, exporters, or resource detection directly. The collector is responsible for authenticating, enriching telemetry with GCP resource attributes, and exporting it to Google Cloud.
Google Managed Service for Prometheus must receive each cumulative OTLP metric export separately. A collector batch processor can combine a periodic export with a shutdown-time export and cause
Duplicate TimeSeriesrejection regardless of the configured periodicity. Trace batching remains safe and recommended.Related implementations
Validation
ruff checkandruff format --checkfor the GCP implementation/testspyright,mypy, andbasedpyrightfor the GCP implementation/testsuv lock --checkThe Python runtime currently has no public explicit Core-metrics force-flush API. The no-batch metrics guidance prevents a periodic and runtime-shutdown export from being combined if such an export occurs.