谷歌云可观测性采用 OpenTelemetry 协议进行原生追踪数据摄取

谷歌云宣布在其Cloud Trace服务中原生支持OpenTelemetry协议（OTLP），这标志着向供应商中立的可观测性基础设施迈出了重要发热一步。新功能允许开发人员通过 telemetry.googleapis.com 端点直接使用 OTLP 发送追踪数据，从而消除了对供应商特定导出器和自定义数据转换的需求。

OpenTelemetry 协议作为一种与供应商无关的数据交换标准，旨在将遥测数据从源头传输到目的地，而无需锁定到特定的可观测性平台。这一发展满足了行业对标准化遥测管道日益增长的需求，这些管道可以跨多个云提供商和可观测性工具工作。

谷歌云的实现超越了简单的协议支持，通过重构其内部存储系统以原生方式使用 OpenTelemetry 数据模型。这一架构变化为通过新 OTLP 端点发送数据的用户带来了存储限制的显著改进。与之前的 128 字节限制相比，属性键现在可以扩展到 512 字节，而属性值支持高达 64 KiB，而不是之前的 256 字节。

增强后的存储系统还显著增加了跨度（Span）容量。跨度名称现在可以包含高达 1,024 字节，而不是之前 128 字节，单个跨度可以容纳高达 1,024 个属性，而不是之前的 32 个。此外，系统现在支持每个跨度 256 个事件和每个跨度 128 个链接，为开发人员在他们的追踪实现中提供了更大的灵活性。

产品经理 Sujay Solomon 和 Keith Chen 强调，追踪支持代表了谷歌云可观测性更广泛 OpenTelemetry 采用策略的初始阶段：

我们知道，在当今复杂的云环境中，管理不同系统、不一致的数据格式和大量信息的遥测数据可能会导致可观测性的差距和操作开销的增加。我们致力于简化你的遥测管道，从专注于所有遥测类型的原生 OTLP 摄取开始，以便你可以无缝地将数据发送到 Google Cloud Observability。

战略愿景包括管理服务器端处理能力、灵活路由到多个目的地和跨不同环境的统一遥测管理。这种方法解决了组织在管理不同系统、不一致格式和处理要求的可观测性数据时面临的常见挑战。

原生 OTLP 支持消除了历史上阻碍可观测性实施的几个操作复杂性。组织现在可以直接使用标准的 OpenTelemetry 导出器，而不需要额外的特定于供应商的代理或复杂的数据转换过程。这种变化通过将遥测处理逻辑转移到后端基础设施，减少了客户端资源使用。

谷歌云追踪中的 Trace Explorer 接口广泛利用 OpenTelemetry 语义约定，使用标准化字段如 service.name 进行服务识别和 OpenTelemetry 跨度状态指示器进行追踪分析。这种与社区标准的对齐提高了已经熟悉 OpenTelemetry 约定的开发人员的用户体验。

谷歌云建议新用户和现有用户迁移到 OTLP 端点，特别是那些处理大量追踪数据的用户。公司提供了全面的迁移文档，以帮助组织从现有的追踪摄取方法过渡到新的协议原生方法。

随着主要云提供商越来越多地采用 OpenTelemetry 协议来支持多云和混合可观测性架构，该增强反映了 OpenTelemetry 标准化的广泛行业势头。这一发展使谷歌云在可观测性领域具有竞争力，同时推进了供应商中立遥测基础设施的更广泛目标。目前使用谷歌云追踪的组织可以立即开始利用新的 OTLP 端点，利用改进的存储限制和增强的处理能力。预计原生协议支持将成为谷歌云可观测性服务中追踪数据摄取的推荐最佳实践。

AWS、Azure 和谷歌云对 OpenTelemetry 支持的不同方法揭示了对可观测性基础设施的不同战略哲学。谷歌云优先考虑与内部存储系统重构的原生 OTLP 端点集成以最大化协议利益，而 AWS 通过其ADOT发行版结合X-Ray和CloudWatch的原生端点支持采取了混合方法。Azure 采取了更以应用为中心的路径，专注于全面的 SDK 集成和发行版，然后才承诺全面基于代理的 OTLP 支持。

原文链接：

https://www.infoq.com/news/2025/09/gcp-opentelemetry-adoption/