还在为被某个监控平台绑定而发愁？换后端就得改代码，换格式就得重写采集逻辑？OpenTelemetry（简称OTel）来了，它就像一个统一的“翻译官”，让你能用一套代码，把日志、指标和跟踪数据发给任何你想要的平台，彻底告别供应商锁定。
三个数据支柱
可观测性的三大支柱是日志、指标和跟踪。日志记录具体事件，指标展示聚合数据，而跟踪则揭示请求在分布式系统中的完整路径。这三者结合，才能完整描绘出系统的真实状态。
过去，这些数据的格式各不相同，开发者需要在代码里为每个后端编写不同的采集逻辑。OTel的出现，正是为了将这三种数据统一成标准格式，让团队不必再为数据格式的兼容性而头疼。
从两个项目合并而来
OTel的故事始于两个开源项目的合并：OpenTracing和OpenCensus。这两个项目原本都在尝试解决分布式跟踪领域缺乏标准的问题，但各自为战，反而造成了新的分裂。
2019年，两个项目的维护者决定将优势结合起来，共同创建了OpenTelemetry，并将其捐赠给云原生计算基金会（CNCF）托管。这一合并，结束了可观测性领域的碎片化状态，为行业提供了一个统一的标准。
API SDK和Collector
OTel的架构主要由三部分构成：API、SDK和Collector。API定义了一套标准接口，告诉开发者如何生成遥测数据，而不关心数据最终去向。SDK则是这些接口的具体实现。
Collector是一个独立的代理服务，它负责接收、处理和导出数据。你可以把它部署在应用旁边，作为数据中转站，对数据进行过滤、增强或批处理，然后再发往指定的后端，比如Prometheus或Jaeger。
代码无需锁定供应商
OTel最大的价值在于“面向未来”。当你使用它的API进行代码埋点后，数据格式就与具体的后端解耦了。未来如果想从收费的SaaS平台切换到自建的开源系统，只需要修改Collector的导出配置。
这意味着团队可以将精力集中在业务开发上，不必在每次技术选型变更时，都重写一遍全链路的监控代码。你的投资不会因为换了一个监控工具而白费，检测代码可以持续复用。
生态的快速融合
作为CNCF的孵化项目，OTel已经获得了业界的广泛支持。几乎所有主流的可观测性后端，如Datadog、New Relic，都提供了原生的OTel数据接入方式。
2023年4月，Elastic将其Elastic通用模式贡献给OTel社区，推动语义约定的进一步统一。这标志着行业头部力量正在向标准靠拢，OTel作为通用数据层的地位愈发稳固，真正实现了跨平台兼容。
CI/CD流程的可观测
OTel的应用场景不限于生产环境的应用监控。它也开始被用于提升CI/CD管道的可见性。通过与Jenkins、GitHub Actions等平台集成，OTel可以采集构建任务的跟踪数据。
这让开发者和运维人员能清晰地看到流水线的每一个环节耗时多少，瓶颈在哪里。用统一的标准监控流水线，有助于提升发布效率，让DevOps流程变得更加透明和可靠。
与后端工具的关系
需要明确的是，OTel本身不是一个像Grafana或SkyWalking那样的可视化后端。它不存储数据，也不提供分析图表。它的角色是数据采集和格式化。
你可以把它理解为“物流系统”，负责把货物（遥测数据）完好无损地运送到仓库（后端平台）。选择了OTel，你依然需要搭配一个或多个后端工具来存储和展示数据，但选择权完全在你手中。
看完这篇文章，你所在的技术团队是否已经开始考虑采用OpenTelemetry来改造现有的监控体系？欢迎在评论区分享你的迁移经验或遇到的难题。
