作者 | 悟鹏
来源 | 阿里巴巴云原生公众号
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 的工作范围：
从 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 的组件和工作流：
从 A brief history of OpenTelemetry (So Far) 可简单了解到，OpenTelemetry 是由两个开源项目合并组成的：
面向 trace 和 metrics 进行数据模型标准化，并提供采集、处理、导出的工具面向 trace 进行数据模型标准化，并提供采集、处理、导出的工具2019 年 5 月，两个开源项目合并，官方宣布开源 OpenTelemetry 项目。
2021.02，trace spec 达到 1.0 版本，根据官方的成熟度模型 (link)，目前 trace 的 spec 已经达到 stable 级别，metrics 达到了 beta 级别，logs 当前还处在 alpha 级别：
自 OpenTelemetry 推出以来，有越来越多的厂商开始关注和贡献。
从 opentelemetry-collector-contrib 可看出来，厂商的关注重点在于 exporter 部分，将观测数据便利导入到自身的服务中，其中已经包含阿里云自身的 SLS 产品：
对于 receiver 和 processor 环节，相信厂商也会逐步投入更多的精力，如：
通过 receiver 和 exporter 的配合，形成观测数据的处理 workflow通过 processor，在观测数据存储前进行规范化处理对于多云场景，OpenTelemetry 定义的观测数据模型、采集/处理/导出 标准，将有利于用户通过一套可观测性标准对接多种云厂商，避免 vendor 锁定。
即使是面向单一的云 (如云厂商内部的服务)，也不可避免会考虑未来进行开源、与外部共建等，使用社区的可观测性标准可以降低开源成本。同时，可观测性的理念、标准、技术在不断迭代，通过跟进社区，可以更好使用到社区带来的技术红利和影响力。
因此，无论是面对多云场景还是单一的云厂商，采用业界的可观测性标准都是很有必要。
OpenTelemetry 如何使用？核心概念OpenTelemetry 中的概念比较多，这里列举些常见的概念，方便进行理解：
观测数据相关
Signal
观测数据类型，如 trace、metrics、logsInstrument
可认为是某种 Signal 的实例OpenTelemetry 自身项目相关
API
OpenTelemetry Spec 的形式化描述，如 opentelemetry-protoSDK
面向不同开发语言的 API 实现Contrib Packages
与具体的开源项目或 vendor 产品相关的实现使用的组件相关
Components
Receivers
接收观测数据的组件Processors
处理接收到的观测数据的组件Exporters
将观测数据导出的组件，如导出到开源项目 Prometheus 或云厂商服务中Extensions
不参与观测数据的处理，辅助相关处理组件的运行，如健康检测、服务发现等Services
表征配置的哪些组件需要运行，如 receivers / processors / exporters / extentionsCollector
可认为是 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，均可以通过社区的力量持续迭代对可观测性问题域的理解，吸收社区的技术红利，并将生产中产生的最佳实践回馈社区，更好推动可观测性领域的发展。
ReferencesMetrics, tracing, and loggingMerging OpenTracing and OpenCensus: A Roadmap to ConvergenceIntroduction to OpenTelemetry (Overview Part 1/2)OpenTelemetry Best Practices (Overview Part 2/2)OpenTelemetry: Future-Proofing Your InstrumentationGetting started with OpenTelemetry on KubernetesOpenTelemetry 官网wikipedia: Observability欢迎大家留言交流使用 Kubernetes 过程中的稳定性保障问题，以及对稳定性保障的期待工具或服务。大家也可通过邮箱联系作者，进一步深入交流：flyer.zyf@alibaba-inc.com。
本文转自网络，原文链接：https://developer.aliyun.com/article/783298
相关文章
精彩导读
热门资讯