Google Cloud has announced native support for the OpenTelemetry Protocol (OTLP) in its Cloud Trace service, marking a significant step toward vendor-neutral observability infrastructure. The new capability allows developers to send trace data directly using OTLP through the telemetry.googleapis.com endpoint, eliminating the need for vendor-specific exporters and custom data transformations.
The OpenTelemetry Protocol serves as a vendor-agnostic data exchange standard designed to transport telemetry data from source to destination without lock-in to specific observability platforms. This development addresses a growing industry demand for standardized telemetry pipelines that can work across multiple cloud providers and observability tools.
Google Cloud’s implementation goes beyond simple protocol support by restructuring its internal storage system to use the OpenTelemetry data model natively. This architectural change brings substantial improvements to storage limits for users sending data through the new OTLP endpoint. Attribute keys can now extend up to 512 bytes compared to the previous 128-byte limit, while attribute values support up to 64 KiB versus the former 256-byte restriction.
The enhanced storage system also increases span capacity significantly. Span names can now contain up to 1,024 bytes rather than 128 bytes, and individual spans can accommodate up to 1,024 attributes instead of the previous limit of 32. Additionally, the system now supports 256 events per span and 128 links per span, providing developers with much greater flexibility in their tracing implementations.
Product managers Sujay Solomon and Keith Chen emphasized that trace support represents the initial phase of a broader OpenTelemetry adoption strategy across Google Cloud Observability:
We understand that in today’s complex cloud environments, managing telemetry data across disparate systems, inconsistent data formats, and vast volumes of information can lead to observability gaps and increased operational overhead. We are dedicated to streamlining your telemetry pipeline, starting with focusing on native OTLP ingestion for all telemetry types so you can seamlessly send your data to Google Cloud Observability.
The strategic vision includes managed server-side processing capabilities, flexible routing to multiple destinations, and unified telemetry management across different environments. This approach addresses common challenges organizations face when managing observability data across disparate systems with inconsistent formats and processing requirements.
The native OTLP support eliminates several operational complexities that have historically hindered observability implementations. Organizations can now use standard OpenTelemetry exporters directly without additional vendor-specific agents or complex data conversion processes. This change reduces client-side resource usage by moving telemetry processing logic to the backend infrastructure.
The Trace Explorer interface in Google Cloud Trace leverages OpenTelemetry semantic conventions extensively, using standardized fields like service.name for service identification and OpenTelemetry span status indicators for trace analysis. This alignment with community standards improves the user experience for developers already familiar with OpenTelemetry conventions.
Google Cloud recommends that both new and existing users migrate to the OTLP endpoint, particularly those handling high-volume trace data. The company has provided comprehensive migration documentation to help organizations transition from existing trace ingestion methods to the new protocol-native approach.
The enhancement reflects broader industry momentum toward OpenTelemetry standardization, with major cloud providers increasingly adopting the protocol to support multi-cloud and hybrid observability architectures. This development positions Google Cloud competitively in the observability space while advancing the broader goal of vendor-neutral telemetry infrastructure. Organizations currently using Google Cloud Trace can begin leveraging the new OTLP endpoint immediately, taking advantage of the improved storage limits and enhanced processing capabilities. The native protocol support is expected to become the recommended best practice for trace data ingestion across Google Cloud Observability services.
The contrasting approaches of AWS, Azure, and Google Cloud to OpenTelemetry support reveal different strategic philosophies toward observability infrastructure. While Google Cloud has prioritized native OTLP endpoint integration with internal storage system restructuring to maximize protocol benefits, AWS has pursued a hybrid approach through its ADOT distribution combined with native endpoint support across X-Ray and CloudWatch. Azure has taken a more application-centric path, focusing on comprehensive SDK integration and distros before committing to full agent-based OTLP support.
