毫无疑问，在过去几年里，你可能已经多次听到过可观测性这个词。对于很多人来说，很难理解这个词的真正含义。对许多人来说，他们错误地将其等同于"监控"。虽然可观测性的根本定义以及它所包含的一切都不在本系列博文的讨论范围之内，但我强烈建议您购买一本由 Charity Majors (twitter)、Liz Fong-Jones (twitter) 和 George Miranda (twitter) 合著的《可观测性工程》（Observability Engineering）一书。
不过，本系列博文将介绍使用 OpenTelemetry 实现可观测性的完整示例和说明，OpenTelemetry 是 CNCF 的一个项目，致力于让可观测性变得更简单。
本文是 OpenTelemetry 构建可观测性系列的第一篇，重点回答四个问题：
- OpenTelemetry 是什么，为什么它常被称为 OTel？
- OTel 中 API、SDK、Collector 分别负责什么？
- traces、metrics、logs 在可观测性体系里各自承担什么角色？
- 示例购物车应用如何用 OpenTelemetry 把链路追踪数据送到 Jaeger？
什么是 OpenTelemetry？
OpenTelemetry 是几年前 OpenCensus 和 OpenTracing 合并的产物。从那时起，OpenTelemetry（也简称为 “OTel”）就很好地将自己定位为在现代软件世界中获取遥测数据且厂商中立的方法。很多人会说 OpenTelemetry 是可观测性的未来，根据我的经验和接触，我倾向于同意这种说法。
更具体地说，OpenTelemetry 不是一个单独的大盘工具，也不是某个后端存储。它更像一套标准和组件集合，帮助应用程序生成、处理和导出遥测数据。这样做的好处是：应用代码里的埋点不必强绑定某一个厂商，后续可以把数据送到 Jaeger、Prometheus、日志系统或其他可观测性平台。
OTel 组件
在 OpenTelemetry 中，典型的 OTel 方案可以被细分为几个逻辑组件，它们包括 APIs、SDKs 和收集器。
APIs and SDKs
在开始使用 OpenTelemetry 时，首先要了解的重要事项之一是该项目如何区分 API 和 SDK。简而言之，API 负责收集遥测数据及其中的所有数据，而 SDK 则负责将这些数据从当前被观测的进程中提取出来，转给另一个实体进行分析。随着我们对这个示例的深入研究，这一点将变得更有意义，但值得理解的是 API 和 SDK 之间的职责分离。
由于它们是关注点分离的，通过什么是观测（API）与如何处理（SDK）来区分它们。它们支持多种编程语言，包括（但不限于）：Go、Python、Java、Ruby、JavaScript、.NET 等！有关语言支持的更多信息，请查看埋点文档。我们将在稍后的博文中介绍埋点知识。
Collector
SDK 的职责之一就是从正在被观测的进程中获取数据，但是需要一个地方来汇总接收这些数据。我们将这个独立的进程称为收集器。
收集器的整个工作可分为三个不同阶段：
- 接收遥测数据
- 处理遥测数据
- 导出遥测数据
收集器是一个处理遥测数据的 ETL（Extract, Transform, Load）管道。虽然不一定要使用 OTel 解决方案，不过想要找个一个常用且好用的收集器例子，推荐用 OpenTelemetry Collector，它将是本系列的重点，并将在后面的博文中详细介绍。
可以把这三个组件的职责简化为：
| 组件 | 核心职责 | 典型问题 |
|---|---|---|
| API | 在代码中描述要采集什么遥测数据 | 这个请求、操作或事件应该如何被记录？ |
| SDK | 决定采集到的数据如何处理和导出 | 数据要采样吗？要批量发送吗？要加哪些资源信息？ |
| Collector | 接收、处理并转发遥测数据 | 数据要送到 Jaeger、Prometheus、日志系统还是多个后端？ |
Traces, metrics, and logs
在链路追踪和可观测性中，有三方面信息：链路追踪，指标数据和服务日志。虽然我们长期以来一直使用服务日志和指标数据，但是许多人认为链路追踪才是真正解锁可观测性能力的关键。
通过收集具备高基数（基数是指某个属性或维度的唯一值的数量，高基数数据可以认为是提供更全面和详尽的上下文信息）特点的链路追踪数据，我们就具备了不用修改代码也能够快速解答部分问题的能力。分析数据是可以有多种手段，例如说我们可以对比异常数据和常规数据等。
本系列博文将会专注于讲解链路追踪，如果你想进一步了解可观测性，以及三种信息之间差异可以参阅前文提到的《可观测性工程》一书。
示例应用
本系列博文的主要任务是介绍如何使用 OpenTelemetry 来让软件系统具备可观测性。为此，我创建了一个示例应用程序，并在后续文章中说明在应用过程中的一些要点。该应用程序的设计可参见下图：
这是一个购物车应用程序示例，按功能模块分成了不同的web服务：
- 购物车 - 处理用户购物车数据请求的服务（用 Go 语言编写）
- 用户服务 - 处理来自购物车服务的用户验证和查询请求（用 Go 语言编写）
- 定价服务 - 为产品提供更新定价信息服务（用 Python 编写）
后端依赖MySQL对数据进行持久化存储。
使用 OpenTelemetry 的 API 和 SDK 进行埋点。遥测数据是通过 OpenTelemetry Collector 向 Jaeger 发送数据来实现的。
下面是使用 OpenTelemetry 采集并展示分布式链路跟踪数据在 Jaeger 中的示例：
所有代码和构建运行说明都可以在 GitHub 上找到：trstringer/otel-shopping-cart。
学习路径
如果你是第一次接触 OpenTelemetry，可以按这个顺序理解：
- 先理解 trace、span、metric、log 这些基础对象。
- 再理解 API 和 SDK 的分工：API 负责采集语义，SDK 负责处理和导出。
- 然后理解 Collector：它把应用和后端系统解耦，负责接收、处理、转发。
- 最后再看具体语言的埋点方式，以及如何在 Jaeger 等后端中查看数据。
总结
希望通过上面介绍让您现在对 OpenTelemetry 已经有所了解，知道它由哪些组件构成，以及我们将如何在本系列的其余部分深入实施。这仅仅是个开始！请继续关注本系列博文的其余部分，了解如何使用 OpenTelemetry 来让应用程序具备可观测性。
FAQ：OpenTelemetry 入门常见问题
Q1：OpenTelemetry 和监控系统是什么关系？
OpenTelemetry 负责生成、处理和导出遥测数据；监控系统或可观测性平台负责存储、查询、展示、告警和分析这些数据。二者是配合关系。
Q2：为什么要区分 API 和 SDK？
API 让代码表达“要采集什么”，SDK 决定“采集后怎么处理和发送”。这种分离可以减少业务代码对具体后端的绑定。
Q3：刚开始学习 OTel，应该先看 traces、metrics 还是 logs？
本文系列重点放在 traces，因为分布式链路追踪最能体现 OpenTelemetry 在跨服务上下文关联上的价值。metrics 和 logs 仍然重要，但可以在理解 trace/span 后继续学习。
本文翻译自：https://trstringer.com/otel-part1-intro/
扩展阅读：
