共计 5446 个字符，预计需要花费 14 分钟才能阅读完成。
作者 | 悟鹏
起源 | 阿里巴巴云原生公众号
OpenTelemetry 是 CNCF 的一个可观测性我的项目，旨在提供可观测性畛域的标准化计划，解决观测数据的数据模型、采集、解决、导出等的标准化问题，提供与三方 vendor 无关的服务。
2021.02.10，OpenTelemetry 的 tracing spec 达到 1.0 版本 (link)，基于这个里程碑，笔者对 OpenTelemetry 进行了摸索，判断在可观测性畛域带来的价值和发展前景。
上面给出笔者对 OpenTelemetry 的了解，抛砖引玉。因为笔者能力无限，了解不当的中央请大家斧正。
OpenTelemetry 是什么？
从官网 What is OpenTelemetry? 可理解到：
OpenTelemetry is a set of APIs, SDKs, tooling and integrations that are designed for the creation and management of telemetry data such as traces, metrics, and logs.
The project provides a vendor-agnostic implementation that can be configured to sent telemetry data to the backend(s) of your choice. It supports a variety of popular open-source projects including Jaeger and Prometheus.
OpenTelemetry 是一组规范和工具的汇合，旨在治理观测类数据，如 trace、metrics、logs 等 (将来可能有新的观测类数据类型呈现)。
OpenTelemetry 提供与 vendor 无关的实现，依据用户的须要将观测类数据导出到不同的后端，如开源的 Prometheus、Jaeger 或云厂商的服务中。
那么 OpenTelemetry 不是什么？从官网形容能够看出：
OpenTelemetry is not an observability back-end like Jaeger or Prometheus. Instead, it supports exporting data to a variety of open-source and commercial back-ends. It provides a pluggable architecture so additional technology protocols and formats can be easily added.
即 OpenTelemetry 不提供与可观测性相干的后端服务，这类后端服务通常提供的是存储、查问、可视化等服务。
通过下述形象图能够简略了解 OpenTelemetry 的工作范畴：
OpenTelemetry 面对的问题域是什么？
从 wikipedia: Observability 可了解到 可观测性 的定义：
In control theory, observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs.
Consider a physical system modeled in state-space representation. A system is said to be observable if, for any possible evolution of state and control vectors, the current state can be estimated using only the information from outputs (physically, this generally corresponds to information obtained by sensors). In other words, one can determine the behavior of the entire system from the system’s outputs. On the other hand, if the system is not observable, there are state trajectories that are not distinguishable by only measuring the outputs.
简略表述为，可观测性是一种办法，通过零碎的内部输入推导出零碎外部的状态。
下图简化了零碎的组成和零碎间的交互：
从上述交互图可理解到，零碎的交互行为有如下几种状态：
零碎外部
- 组件性能闭环，不与其余组件或零碎交互
- 组件之间交互
零碎之间
- 零碎和零碎之间进行交互
这样，若想通过零碎的内部输入理解零碎的状态，就须要两种状态的信息：
- 组件闭环的信息
- 组件间或零碎间流动的信息
第一种状态通常可通过 logs 或 metrics 表征，第二种状态就须要 trace 表征，在流动的信息中减少标记。
对于 logs 和 metrics 的区别，可通过它们的操作方法进行了解。
再进一步形象，可观测性波及到如下问题：
- 观测数据的数据模型
- 观测数据的采集
- 观测数据的解决
- 观测数据的导出
- 观测数据的应用
- etc.
上述即是 OpenTelemetry 面对的问题域及具体的问题，且将具体的问题限定在：
- 观测数据的数据模型
- 观测数据的采集
- 观测数据的解决
- 观测数据的导出
OpenTelemetry 的解决方案是什么？
OpenTelemetry 通过 Spec 标准了观测数据的数据模型以及采集、解决、导出办法，包含 trace、metrics、logs (将来不排除会有新的类型)，参见 opentelemetry-specification。
同时为了方便使用，通过 protobuf 来形容，参见 opentelemetry-proto。
基于 Spec，OpenTelemetry 面向观测数据的生成和解决，做了如下的致力：
- 为了不便开发者应用，提供了语言相干的 SDK，如 opentelemetry-go、opentelemetry-java、opentelemetry-js 等，所有反对的开发语言可参见 官网文档
- 为了不便可观测数据的采集、解决、导出，提供了通过配置管理的 Collector 服务，如对接开源我的项目的 opentelemetry-collector、对接第三方 vendor 的 opentelemetry-collector-contrib
通过下图可直观了解 OpenTelemetry 的组件和工作流：
OpenTelemetry 的历史是什么？
从 A brief history of OpenTelemetry (So Far) 可简略理解到，OpenTelemetry 是由两个开源我的项目合并组成的：
OpenCensus
- 面向 trace 和 metrics 进行数据模型标准化，并提供采集、解决、导出的工具
OpenTracing
- 面向 trace 进行数据模型标准化，并提供采集、解决、导出的工具
2019 年 5 月，两个开源我的项目合并，官网发表开源 OpenTelemetry 我的项目。
2021.02，trace spec 达到 1.0 版本，依据官网的成熟度模型 (link)，目前 trace 的 spec 曾经达到 stable 级别，metrics 达到了 beta 级别，logs 以后还处在 alpha 级别：
OpenTelemetry 的前景如何？
自 OpenTelemetry 推出以来，有越来越多的厂商开始关注和奉献。
从 opentelemetry-collector-contrib 可看进去，厂商的关注重点在于 exporter 局部，将观测数据便当导入到本身的服务中，其中曾经蕴含阿里云本身的 SLS 产品：
对于 receiver 和 processor 环节，置信厂商也会逐渐投入更多的精力，如：
- 通过 receiver 和 exporter 的配合，造成观测数据的解决 workflow
- 通过 processor，在观测数据存储前进行规范化解决
对于多云场景，OpenTelemetry 定义的观测数据模型、采集 / 解决 / 导出 规范，将有利于用户通过一套可观测性规范对接多种云厂商，防止 vendor 锁定。
即便是面向繁多的云 (如云厂商外部的服务)，也不可避免会思考将来进行开源、与内部共建等，应用社区的可观测性规范能够升高开源老本。同时，可观测性的理念、规范、技术在一直迭代，通过跟进社区，能够更好应用到社区带来的技术红利和影响力。
因而，无论是面对多云场景还是繁多的云厂商，采纳业界的可观测性规范都是很有必要。
OpenTelemetry 如何应用？
外围概念
OpenTelemetry 中的概念比拟多，这里列举些常见的概念，不便进行了解：
观测数据相干
Signal
- 观测数据类型，如 trace、metrics、logs
Instrument
- 可认为是某种 Signal 的实例
OpenTelemetry 本身我的项目相干
API
- OpenTelemetry Spec 的形式化形容，如 opentelemetry-proto
SDK
- 面向不同开发语言的 API 实现
Contrib Packages
- 与具体的开源我的项目或 vendor 产品相干的实现
应用的组件相干
Components
Receivers
- 接管观测数据的组件
Processors
- 解决接管到的观测数据的组件
Exporters
- 将观测数据导出的组件，如导出到开源我的项目 Prometheus 或云厂商服务中
Extensions
- 不参加观测数据的解决，辅助相干解决组件的运行，如衰弱检测、服务发现等
Services
- 表征配置的哪些组件须要运行，如 receivers / processors / exporters / extentions
Collector
- 可认为是 receivers / processors / exporters / extentions / services 组成的整体
Controller
- 用于开发者开发的利用中，作用可等同于 receivers / processors / exporters 组成的整体
golang demo
笔者写了一个 golang demo，用来演示：
- APP 中如何生成 trace / metrics 数据
- APP 中应用 stdout controller 来采集、解决、打印 trace / metrics 数据
- APP 中通过 otlp controller 采集 trace / metrics 数据，并导出到内部运行的 collector 中
- 本地独立运行一个 collector 服务，接管 otlp controller 推送的 trace / metrics 数据，并将其导出到本地文件和阿里云 SLS 中
demo 参见：https://github.com/flyer103/otel-demo
具体的应用办法参见 demo 的 README.md，下述简略形容下思路。
cmd/app/server.go 文件形容了 OpenTelemetry 的应用逻辑，分成两局部：
- 初始化并运行全局的 controller，用来在 APP 外部 receive / process / export 观测数据，或将 APP 内的观测数据推送到内部
- APP 内依照业务需要生成 metrics 和 trace
pkg/ 目录下别离封装了 controller 和 signal (trace / metrics)，具体的实现不再赘述：
yaml/ 下提供了一个将观测数据导出到 SLS 的示例，包含了用于接管观测数据的 receiver (client 端可通过 grpc client 将数据推送到该 receiver)、用于观测数据转换解决的 processors、用于数据导出的 exporters、用于开启组件的 services：
畅想
通过上述剖析，大家对 OpenTelemetry 的概念、问题域、解决方案和应用办法会有一个直观的领会，通过上述 golang demo 能够疾速上手。
对于开发者，基于 OpenTelemetry 可通过一套规范的计划进行 trace / metrics / logs 的生成和导出，升高开发过程中对不同类型观测数据的应用老本，也升高对接不同后端服务的老本，如开源我的项目 Prometheus 或第三方云厂商的服务。
对于 SRE，基于 OpenTelemetry 可为观测数据提供一套规范的采集、解决、导出流程，并在解决环节依据团队需要规范化观测数据，便于后续采纳标准化的计划应用观测数据，如监控、告警服务。
同时，不管对于开发者还是 SRE，均能够通过社区的力量继续迭代对可观测性问题域的了解，排汇社区的技术红利，并将生产中产生的最佳实际回馈社区，更好推动可观测性畛域的倒退。
References
- Metrics, tracing, and logging
- Merging OpenTracing and OpenCensus: A Roadmap to Convergence
- Introduction to OpenTelemetry (Overview Part 1/2)
- OpenTelemetry Best Practices (Overview Part 2/2)
- OpenTelemetry: Future-Proofing Your Instrumentation
- Getting started with OpenTelemetry on Kubernetes
- OpenTelemetry 官网
- wikipedia: Observability
欢送大家留言交换应用 Kubernetes 过程中的稳定性保障问题，以及对稳定性保障的期待工具或服务。大家也可通过邮箱分割作者，进一步深刻交换：flyer.zyf@alibaba-inc.com。
