OpenTelemetry标准：可观测性如何走向供应商无关

从指标到追踪到日志，OpenTelemetry正在统一云端和本地的应用可观测性

OpenTelemetry（OTel）已成为应用可观测性的事实标准，用统一、供应商中立的框架替代了专有检测，用于收集指标、追踪和日志。

碎片化问题

在OpenTelemetry之前，可观测性是一个碎片化的格局：

• 追踪：Jaeger、Zipkin、AWS X-Ray、Google Cloud Trace——各有不同的SDK
• 指标：Prometheus、StatsD、CloudWatch、Datadog——不兼容的格式
• 日志：ELK Stack、Splunk、CloudWatch Logs——没有标准导出格式
• 供应商锁定客户：自定义检测使切换成本高昂

OpenTelemetry架构

OTel提供全面的检测框架：

• API：用于创建遥测数据的语言特定API
• SDK：自动和手动检测，带上下文传播
• Collector：供应商中立的遥测处理和导出管道
• 语义约定：跨服务和语言的标准属性命名
• 自动检测：流行框架的零代码检测

行业采用

主要平台和供应商已标准化OTel：

• 云提供商：AWS、GCP和Azure都原生支持OTel
• 供应商：Datadog、New Relic、Grafana Cloud、Honeycomb构建了OTel优先集成
• 框架：Spring Boot、ASP.NET Core和Express.js添加了原生OTel支持
• CNCF毕业：OpenTelemetry于2024年从CNCF孵化毕业

Collector生态系统

OTel Collector已成为关键基础设施：

• 接收器：以任何格式接收数据（OTLP、Prometheus、Jaeger、StatsD）
• 处理器：转换、过滤、采样和丰富遥测数据
• 导出器：发送到任何后端（Datadog、Grafana、Elasticsearch、Kafka）
• 连接器模式：在遥测信号之间路由数据（从追踪生成指标）

意义

OpenTelemetry正在为可观测性做Kubernetes为容器编排所做的事情——创建供应商中立的标准，使组织能够自由选择最佳后端而无需重写检测。追踪和指标的标准基本完成，日志支持正在快速成熟。组织今天应该使用OTel进行检测，因为它是可观测性基础设施最安全的长期选择。

来源：基于2026年OpenTelemetry和可观测性趋势的分析