Skip to main content

Googlecloudstorage Exporter

Status Available in: contrib Maintainers: @constanca-m, @braydonk Source: opentelemetry-collector-contrib

Supported Telemetry

Logs Traces

Overview

This exporter writes received OpenTelemetry data to a cloud storage bucket.

Configuration

Partition Configuration

The bucket.partition configuration allows you to organize files into time-based folders.

resource_attrs_to_gcs

When resource_attrs_to_gcs.prefix is configured, a partition segment is derived from the specified resource attribute, allowing data to be routed into per-attribute folders (for example, one folder per host or service). The resulting layout is <partition.prefix>/<attribute value>/<partition.format>/..., so the existing bucket.partition.prefix is preserved and the attribute segment is appended after it. The attribute value is stringified, so non-string attributes are converted to their string form (for example, the int 42 becomes 42 and a bool becomes true); complex types such as maps or slices render as their textual representation and are not recommended. Because resource attribute values are arbitrary and may be untrusted, the value is normalized with the standard library path.Clean before being used as an object-name segment: duplicate slashes are collapsed and empty, . and .. segments are removed (so the value cannot traverse above its segment root). Leading and trailing / are trimmed, while internal / are preserved so a value can span multiple folder levels (e.g. service-a/logs). If the value normalizes to an empty string, no extra segment is added. Note that high-cardinality attribute values produce a correspondingly large number of object key prefixes.
Note: the attribute value is read from the first resource of each exported batch. If a batch can contain multiple distinct attribute values and you need strict per-value routing, separate the data upstream first using the routingconnector or groupbyattrsprocessor.

Example

Here is an example configuration for this exporter:

Routing by Resource Attribute

This configuration writes each service’s data into its own folder by deriving a partition segment from the service.name resource attribute, while keeping a static storage prefix:
Given a resource with service.name = serviceA, an object is written to:
If the service.name attribute is absent, the attribute segment is omitted and the object is written to storage/2026-06-17/14/logs_<uuid>.

Resiliency Settings

This exporter supports standard OpenTelemetry Collector resiliency settings. You can configure timeouts, retry behaviors, and a sending queue to ensure reliable data delivery to Google Cloud Storage.
For more details on how to configure these specific sections, refer to the exporterhelper configuration documentation.

Retry Behavior

This exporter utilizes two independent layers of retries: Google Cloud SDK Retries (always on): The underlying Google Cloud Go SDK automatically retries transient errors (like network blips) in the background. By default, the SDK handles its own exponential backoff and idempotency checks. Exporter Helper Retries (optional via retry_on_failure): This is the OpenTelemetry-level retry mechanism. It integrates with the sending queue to ensure data is not dropped during prolonged outages. Important Notes on Retries: If the Google Cloud SDK determines an error is permanent (e.g., unauthorized access) or not idempotent, the exporter will immediately wrap it as a permanent error. This halts the retry_on_failure loop and drops the payload to prevent infinite queue blocking. You can find more information on what the SDK considers retryable in the Google Cloud Storage Retry Strategy documentation. Because file names are generated dynamically using a UUID and timestamp, each retry attempt by the OpenTelemetry retry_on_failure mechanism generates a new filename. In rare cases (such as when GCS commits an object but returns a transient error before the client receives acknowledgment) this can result in duplicate blobs in GCS.

Compression Example

Using with Bucket-Level Permissions Only

When the service account lacks project-level bucket creation permissions but has bucket-level permissions:
With reuse_if_exists: true, the exporter checks if the bucket exists using storage.buckets.get permission on that specific bucket (not project-level). If the bucket doesn’t exist, the exporter will fail with an error. This allows service accounts with only bucket-level permissions to work without requiring project-level bucket creation permissions.

Configuration

Example Configuration


Last generated: 2026-08-24