Google Cloud Adds Native OpenTelemetry Metrics and Managed Collectors for GKE as Observability Converges on Open Standards
Google Cloud now accepts OTLP-format metrics in Cloud Monitoring and offers a fully managed OpenTelemetry Collector pipeline for GKE, joining a broader industry shift toward vendor-neutral observability driven by open standards.
Google Cloud has unveiled native support for the OpenTelemetry Protocol in Cloud Monitoring, enabling teams to send metrics in OTLP format alongside traces and logs through a single, vendor-agnostic pipeline. The company also announced Managed OpenTelemetry for Google Kubernetes Engine, a fully managed ingestion service that handles the deployment, scaling, and operation of OpenTelemetry Collectors for Kubernetes workloads.
The two announcements arrive as the observability industry accelerates its migration away from proprietary telemetry formats and toward open standards anchored by the Cloud Native Computing Foundation’s OpenTelemetry project.
What Google Cloud Shipped
Cloud Monitoring’s new OTLP metrics support, currently in preview, introduces several technical capabilities that align Google’s platform with the broader OpenTelemetry specification. Delta-type metrics reduce client-side memory consumption by reporting only counter changes rather than cumulative values. Exponential histograms enable dynamic bucket sizing, and the naming conventions now accept dots and slashes, matching standard OpenTelemetry semantic conventions.
Ingested OTLP metrics are stored as Prometheus-formatted data and remain queryable through standard Cloud Monitoring tools. The feature requires OpenTelemetry versions 0.140.0 or later. Google also plans a unified ingestion endpoint at telemetry.googleapis.com that will consolidate all observability data flows into a single entrypoint.
Managed OpenTelemetry for GKE, also in preview, is the first fully managed trace solution for the platform. It targets teams that need OTLP-driven observability without the operational burden of running and maintaining collector infrastructure. The service is available for GKE cluster versions 1.34.1-gke.2178000 and later.
An Industry Moving in the Same Direction
Google’s embrace of OTLP as a first-class ingestion format mirrors a pattern playing out across the observability market. On March 9, Datadog announced general availability of its MCP Server, a purpose-built interface that gives AI coding agents secure, real-time access to live logs, metrics, and traces. The server integrates with Claude Code, Cursor, GitHub Copilot, Codex, Cognition, and Visual Studio Code, feeding production telemetry directly into developer workflows.
“By combining telemetry from Datadog’s unified observability platform into teams’ AI workflows, we are enabling the next stage of AI-native development,” said Yanbing Li, Datadog’s chief product officer.
Meanwhile, the infrastructure demands of AI workloads are pushing observability requirements to new limits. Enterprises building AI factories face complex monitoring challenges that extend well beyond GPU utilization, encompassing compute, storage, networking, and data pipelines operating as integrated systems.
KubeCon and the OpenTelemetry Ecosystem
The timing of Google’s announcement coincides with KubeCon + CloudNativeCon Europe 2026, which opens in Amsterdam on March 23. Observability Day, a full-day co-located event with two parallel tracks, will bring together maintainers and practitioners from OpenTelemetry, Prometheus, Fluentd, Fluent Bit, and Jaeger. This year’s program emphasizes the growing intersection between observability and AI, including sessions on instrumenting AI applications using OpenTelemetry’s Generative AI Semantic Conventions.
The OpenTelemetry specification itself continues to evolve. Recent updates have deprecated the Jaeger propagator in favor of W3C TraceContext, a move that consolidates the ecosystem around a single, interoperable context propagation standard.
Why It Matters
Google Cloud’s decision to treat OTLP as a native ingestion format, rather than requiring a translation layer, lowers the barrier for teams already invested in OpenTelemetry instrumentation. Combined with the managed collector offering for GKE, it reduces the operational tax that has historically made vendor-neutral observability more aspirational than practical.
The broader convergence is significant. When a hyperscaler, a leading SaaS observability vendor, and the CNCF ecosystem all move in the same direction within the same month, it signals that the long-debated shift from proprietary agents to open telemetry pipelines is reaching an inflection point. For engineering teams evaluating their observability strategy, the question is increasingly not whether to adopt OpenTelemetry, but how quickly they can migrate.