云原生的基建：我理解的可观测性和 OpenTelemetry

在 Gartner 的 2022 技术成熟度曲线上，OpenTelemetry 被列到了 Innovation Trigger 的位置。那么，OpenTelemetry 是什么，为什么我们需要对他引起足够的关注呢？

OpenTelemetry 是 CNCF 的一个可观测性项目。要理解 OpenTelemetry，首先需要理解可观测性。

可观测性的提出是基于这样一个逻辑：不管是 IT 系统还是业务，要保证其正常运行，首先需要满足可视化的要求。如果一个系统完全是一个魔术师的黑盒，内部运行的各种指标数据不能被看见，我们是无法确定系统的运行状况，从而更无法对系统做有效的运维和处置的。

系统的可视化信息，可以分为Metrics、Logging和Tracing三类：

• 指标（Metrics）：记录一段时间内各个维度的量化信息，用来观察系统的某些状态和趋势。

• 日志（Logging）：记录程序运行过程中产生的一些离散事件。

• 链路追踪（Tracing）：记录一次请求从接收到处理完成整个生命周期内的调用链路。

从指标可以看系统运行的整体情况，从日志可以定位一些异常或值得关注的事件，最后用 Tracing 可以精准的分析和定位特定业务链路的情况和问题。

OpenTelemetry 可以认为是可观测性的一个具体的实现。首先，OpenTelemetry 是一个可观测领域的标准化方案，包括数据模型的定义、采集、处理、导出等。其次，OpenTelemetry 提供与 vendor 无关的实现，根据用户的需要将观测类数据导出到不同的后端，如开源的 Prometheus、Jaeger 或云厂商的服务中。OpenTelemetry 不提供与可观测性相关的后端服务，这类后端服务通常提供的是存储、查询、可视化等服务。

在早期的信息化阶段，只有服务器、网络、存储和操作系统是外采的，其他的应用都是自建的。而服务器等硬件设备和操作系统基本上也会集中在一两个厂商。只需要根据厂商相关接口，将可观测性指标采集上来，加上应用的日志和指标监控，就可以基本上完成信息系统的可观测性目标。

进入云原生和微服务时代后，首先更多的基础设施会采用采购或者租赁的方式，比如各类的 Paas 服务、容器等。其次，微服务会引入更多的技术栈，甚至部分 Saas 服务也会采用外采的方式，例如 Salesforce、财务服务、HR 服务等。这种异构的生态环境，就对信息系统的可观测性目标提出了巨大的挑战。

如果遵循 OpenTelemetry 的标准和实现，首先可以通过它提供的各类语言的 Instrumenting SDK，生成和发送统一格式的可观测性数据。Instrumenting 又可以分成 auto 和 manual 两类，分别意味着要不要修改应用代码。其次，通过标准的 Collector 接收这些指标数据，并支持把数据传输到各种类型的后端存储系统。最后，根据组织的关注点不同，定制客观性数据的存储和展示部分，就完成了可观测性的闭环。

所以，OpenTelemetry 目标是助力云原生和微服务下可观测性目标的实现，是完成这两大架构转型的基础。

同时，我们可以畅想一下，在业务连续性领域，也可以 follow OpentTelemetry 的思路，用标准的方案完成业务可视化目标的实现。

例如，最近在外汇风险领上，我们就是用如下的思路完成风险可视化和处置能力建设的：

• 通过交易链路预埋、定时任务处理和数据平台处理三类方式，输出业务异常事件、用户/交易员维度指标。预埋和两类后处理分别对应 manual 和 auto 的可观测指标生成方式。

• 通过统一的风险事件库存储事件，同时提供标准的事件生命周期管理服务，可以将自动化产生的风险、人工定位的风险、兄弟域产生的风险、市场监测到的风险，统一存储到一个风险事件库中。

• 最后用统一的风险事件库，完成风险事件的预警、处置、展示和分析能力。

• 后续，会补充建设 trancing 这自动化探测部分。