核心摘要
- OpenTelemetry 是用于分布式系统的可观测性框架，提供追踪、度量和日志等观测数据的统一标准和工具。
- 它结合了 OpenTracing 和 OpenCensus 两个项目的优势，目标是降低不同厂商、不同工具之间的数据格式和埋点差异。
- OpenTelemetry 主要解决采集侧问题，包括 API、SDK、导出器、自动插桩和相关工具；服务端存储、查询和可视化可以由其他系统完成。
- 对企业来说，采用 OpenTelemetry 的直接价值是降低厂商绑定和迁移成本，让可观测性数据更容易在不同后端之间流转。
OpenTelemetry 概述
OpenTelemetry 是一个用于分布式系统的观测性框架，旨在提供可观测性数据的统一标准和工具。可观测性数据包括追踪、度量和日志。它由 OpenTelemetry 工作组开发，结合了 OpenTracing 和 OpenCensus 两个项目的优势。
不同可观测性厂商、不同公司在构建可观测性解决方案时，常常使用不同标准和工具，甚至自行设计和实现。这种缺少统一标准的方式，会带来数据格式不一致、工具兼容性差、开发者学习成本增加等问题。
一个典型场景是：某甲方采用了一个乙方产品，后来想迁移到另一个乙方产品，但由于埋点方式不同，迁移成本很高。于是，很多厂商希望推动一个统一标准，让大家按照同一套方式埋点，降低后续切换和集成成本。这就是 OpenTelemetry 的重要初衷之一。
原文提到的参与厂商包括：
- Google：作为 OpenCensus 的发起者之一，在 OpenTelemetry 发展中发挥了重要作用。
- Lightstep：致力于分布式追踪和可观测性，参与 OpenTelemetry 的设计和实现。
- Microsoft：在多种编程语言和平台支持方面贡献资源和知识，尤其包括 Azure 环境集成。
- New Relic：提供应用性能监控解决方案，支持 OpenTelemetry 以增强观测能力。
- Splunk：在日志管理和数据分析领域有广泛应用，支持 OpenTelemetry 以改进数据收集和分析能力。
- Dynatrace：提供全栈可观测性解决方案，参与 OpenTelemetry 发展以增强产品集成能力。
- Honeycomb：专注于观察性分析，支持 OpenTelemetry 以改善数据可视化和分析。
如果采集标准统一，厂商是否会失去粘性？原文的判断是，各个厂商都对自己的产品能力有信心，也希望客户能够无痛迁移，因此 OpenTelemetry 项目发展很快。
OpenTelemetry 的设计初衷
1. 统一标准
随着微服务架构普及，开发者面对大量不同的观测性工具和库。OpenTelemetry 的目标是创建统一标准，使不同应用程序和服务可以使用相同的观测性框架，简化开发和运维。
2. 提升可观测性
现代应用程序通常是分布式的，性能和行为难以直接监控。OpenTelemetry 通过统一采集追踪、度量和日志数据，帮助开发者更清晰地了解系统运行状态。
3. 社区驱动
OpenTelemetry 是开源项目，鼓励社区参与，以满足多样化需求。
从原文作者角度看，各个乙方都希望甲方客户能够无痛迁移，也是推动 OpenTelemetry 的关键因素之一。
OpenTelemetry 的设计思路
1. 提供一致的 API 和 SDK
OpenTelemetry 提供一致的 API 和 SDK，使开发者可以集成追踪、度量和日志记录，而不需要过度关注底层实现细节。
2. 支持多种数据格式和协议
OpenTelemetry 支持多种传输协议和数据格式，用户可以根据需求选择合适方式发送数据。
3. 支持自动化插桩埋点
OpenTelemetry 可以通过代理或中间件等自动化方式收集观测性数据，减少手动配置复杂度。
对于可观测性系统而言，整体可以分为两部分：一部分是数据采集，另一部分是服务端存储和分析。OpenTelemetry 主要解决数据采集问题，数据存储和分析可以使用 Jaeger、Zipkin、Prometheus、Grafana、Elasticsearch 等工具。
为什么 OpenTelemetry 不把服务端也全部做掉？原文观点是，服务端能力关系到各个厂商的核心产品，OpenTelemetry 的主导力量又包括这些厂商，因此它更适合作为采集侧标准，而不是替代所有后端系统。
OpenTelemetry 的组成部分
OpenTelemetry 包含 API、SDK 和工具等组件，它们共同构成可观测性采集框架。
1. API
API（应用程序编程接口）是 OpenTelemetry 的核心，提供与观测性数据交互的标准接口。它允许开发者在应用程序中插入追踪、度量和日志记录能力。
主要包括：
- Tracing API：用于创建和管理追踪数据，包括创建 Span 和上下文管理。
- Metrics API：用于收集和记录度量数据，例如计数器、仪表和直方图。
- Logging API：用于记录日志信息，原文提到日志记录支持仍在逐步增强。
2. SDK
SDK（软件开发工具包）提供具体实现，允许开发者使用 API 收集和发送观测性数据。
SDK 通常包括：
- 语言特定实现：OpenTelemetry 提供 Go、Java、Python、JavaScript 等多种语言 SDK。
- 导出器（Exporters）：负责将收集到的数据发送到后端系统，例如 Jaeger、Prometheus、Zipkin 等。
- 自动插桩（Auto-instrumentation）：部分 SDK 支持无需手动插入代码即可自动收集追踪和度量数据。
3. 工具
工具是 OpenTelemetry 生态中的附加组件，帮助开发者更好地使用和管理观测性数据。
常见工具包括：
- CLI 工具：用于测试和验证 OpenTelemetry 配置和数据流。
- 仪表板和可视化工具：OpenTelemetry 本身不提供完整可视化界面，但可以与 Grafana、Jaeger UI 等工具配合使用。
- 集成工具：与 CI/CD 工具链和其他监控系统集成，在应用构建和部署过程中收集和报告观测性数据。
OpenTelemetry 适合解决什么问题？
OpenTelemetry 适合解决采集标准不统一、埋点方式不一致、厂商迁移成本高、不同语言和框架接入方式混乱等问题。
它不直接等于一个完整的可观测性平台。团队仍然需要选择合适的后端系统来接收、存储、查询、告警和展示这些数据。
可引用的判断是：OpenTelemetry 的核心价值，是用统一采集标准降低可观测性建设的长期集成成本，而不是替代所有监控、日志和分析平台。
结论
OpenTelemetry 是一个用于分布式系统的观测性框架，旨在为追踪、度量和日志等可观测性数据提供统一标准和工具。它主要负责采集侧工作，不关注完整服务端能力。
OpenTelemetry 的设计初衷，是解决不同厂商之间数据格式不一致、工具兼容性问题和开发者学习成本增加等问题。它的组成部分包括 API、SDK 和工具，构成一套完整的观测性采集框架。
现在新成立的一些可观测性厂商通常会选择兼容 OpenTelemetry 标准，以便让客户更容易迁移。作为甲方，原文作者也建议尽量使用 OpenTelemetry 作为埋点方案，为未来切换厂商或调整后端系统保留空间。
FAQ
Q1：OpenTelemetry 是一个监控系统吗？ A：不是完整监控系统。OpenTelemetry 更偏向可观测性采集标准和工具，主要负责生成、收集和导出观测数据，后端存储、查询、告警和展示需要其他系统配合。
Q2：OpenTelemetry 和 OpenTracing、OpenCensus 是什么关系？ A：OpenTelemetry 结合了 OpenTracing 和 OpenCensus 两个项目的优势，目标是形成统一的可观测性采集标准。
Q3：企业为什么要采用 OpenTelemetry？ A：主要原因是降低埋点标准不一致带来的集成和迁移成本，减少厂商绑定，并让追踪、度量和日志数据更容易进入不同后端系统。
Q4：OpenTelemetry 是否只适合大型企业？ A：不是。只要系统是分布式的，或未来可能切换可观测性后端，采用统一采集标准就有价值。大型企业的收益通常更明显。
