科普：什么是 OpenTelemetry
OpenTelemetry 概述
OpenTelemetry 是一个用于分布式系统的观测性框架，旨在提供可观测性数据（如追踪、度量和日志）的统一标准和工具。它是由 OpenTelemetry 工作组开发的，结合了 OpenTracing 和 OpenCensus 两个项目的优势。
不同的可观测性厂商，以及不同的公司，在构建可观测性解决方案时，通常会使用不同的标准和工具，甚至会自行设计和实现。这样毫无标准、自由发挥的方式，会导致不同系统之间的数据格式不一致，不同工具之间的兼容性问题，以及开发者学习成本的增加。这会让众多乙方尤其感到不适。
比如某甲方采用了乙方的产品，后来想迁移到另一个乙方，因为埋点方式不同，迁移成本巨高。于是，众多大型乙方就想牵头制定一个标准，让所有的乙方都按照这个标准来埋点，这样就可以随意切换乙方了。这就是 OpenTelemetry 的初衷。主要参与的厂商：
- Google：作为 OpenCensus 的发起者之一，Google 在 OpenTelemetry 的发展中发挥了重要作用。
- Lightstep：致力于分布式追踪和可观测性的公司，积极参与 OpenTelemetry 的设计和实现。
- Microsoft：在支持多种编程语言和平台方面贡献了重要的资源和知识，特别是在 Azure 环境中的集成。
- New Relic：提供应用性能监控解决方案，支持 OpenTelemetry 以增强其观测性能力。
- Splunk：在日志管理和数据分析领域有广泛应用，支持 OpenTelemetry 以改进数据收集和分析能力。
- Dynatrace：提供全栈可观测性解决方案，积极参与 OpenTelemetry 的发展，以增强其产品的集成能力。
- Honeycomb：专注于观察性分析，支持 OpenTelemetry 以改善数据的可视化和分析。
如果大家采集标准统一了，那岂不是没有粘性了？各个厂商都很有自信，都觉得自己做的才是最好的，巴不得让客户无痛迁移，所以，OpenTelemetry 项目的发展非常迅速。
设计初衷
- 统一标准：随着微服务架构的普及，开发者面临大量不同的观测性工具和库。OpenTelemetry 的目标是创建一个统一的标准，使得不同的应用程序和服务可以使用相同的观测性框架，简化开发和运维。
- 提升可观测性：现代应用程序往往是分布式的，难以监控其性能和行为。OpenTelemetry 旨在提供全面的可观测性，使开发者能够更清晰地了解系统的运行状态。
- 社区驱动：OpenTelemetry 是一个开源项目，鼓励社区参与，确保它能够满足多样化的需求。
当然，从笔者角度来看，各个乙方都希望甲方客户能够无痛迁移，是其中一个极为关键的推动力。
OpenTelemetry 设计思路
- 提供一致的 API 和 SDK：OpenTelemetry 提供了一套一致的 API 和 SDK，使开发者可以轻松地集成追踪、度量和日志记录，而不需要关注底层实现细节。
- 支持多种数据格式和协议：OpenTelemetry 支持多种传输协议和数据格式，允许用户根据需求选择最适合的方式来发送数据。
- 自动化插桩埋点：通过自动化的方式（例如，使用代理或中间件）来收集观测性数据，减少手动配置的复杂性。
对于可观测性系统而言，整体分两部分，一个是数据的采集，一个是服务端的存储和分析。OpenTelemetry 主要是解决数据采集的问题，而数据的存储和分析，可以使用各种各样的工具，比如 Jaeger、Zipkin、Prometheus、Grafana、Elasticsearch 等等。
那能否让 OpenTelemetry 把服务端也做了？显然不合适，关键是抢了各个乙方的饭碗，而各个乙方是 OpenTelemetry 项目的主导力量，他们不可能让自己的饭碗被抢。
OpenTelemetry 的组成部分
OpenTelemetry 的设计包含多种组件，包括 API、SDK 和工具，这些组件共同构成了一个全面的可观测性采集框架。下面对这些组件进行详细解释：
1. API
API（应用程序编程接口） 是 OpenTelemetry 的核心，提供了与观测性数据交互的标准接口。它允许开发者在其应用程序中插入追踪、度量和日志记录功能。主要包括：
- Tracing API：用于创建和管理追踪数据。包括创建 Span（表示操作的时间段）和上下文管理（传递追踪信息）。
- Metrics API：用于收集和记录度量数据，如计数器、仪表和直方图。开发者可以定义和记录自定义指标。
- Logging API（在开发中）：用于记录日志信息，虽然 OpenTelemetry 目前主要专注于追踪和度量，但日志记录的支持也在逐步增强。
2. SDK
SDK（软件开发工具包） 提供了具体的实现，允许开发者使用 API 来收集和发送观测性数据。SDK 通常包括：
- 语言特定实现：OpenTelemetry 提供多种编程语言的 SDK，如 Go、Java、Python、JavaScript 等。每种语言的 SDK 都根据其特性进行了优化。
- 导出器（Exporters）：负责将收集到的观测性数据发送到后端系统（如 Jaeger、Prometheus、Zipkin 等）。SDK 包含多个现成的导出器，用户可以根据需求选择适合的。
- 自动插桩（Auto-instrumentation）：某些 SDK 允许开发者无需手动插入代码即可自动收集追踪和度量数据，支持流行框架和库的自动化集成。
3. 工具
工具 是 OpenTelemetry 生态系统中的附加组件，能够帮助开发者更好地使用和管理观测性数据。主要包括：
- CLI 工具：命令行工具用于测试和验证 OpenTelemetry 配置和数据流，帮助开发者快速排查问题。
- 仪表板和可视化工具：虽然 OpenTelemetry 本身不提供可视化界面，但它与许多可视化工具（如 Grafana、Jaeger UI）兼容，便于用户展示和分析观测性数据。
- 集成工具：与 CI/CD 工具链和其他监控系统的集成，帮助开发者在应用构建和部署过程中自动收集和报告观测性数据。
总结
本文对 OpenTelemetry 做了概要介绍。读者现在应该清楚了解 OpenTelemetry 是一个用于分布式系统的观测性框架，旨在提供可观测性数据（如追踪、度量和日志）的统一标准和工具。OpenTelemetry 只是负责采集侧的工作，不关注服务端的工作。
OpenTelemetry 的设计初衷是为了解决不同厂商之间的数据格式不一致、不同工具之间的兼容性问题，以及开发者学习成本的增加。OpenTelemetry 的组成部分包括 API、SDK 和工具，提供了一套完整的观测性采集框架。现在新成立的一些可观测性厂商，都会选择直接兼容 OpenTelemetry 标准，以便让客户无痛迁移。
作为甲方，笔者也建议尽量使用 OpenTelemetry 做为埋点方案，未来如果不满意现有的厂商，可以无痛迁移。
