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 通过 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 中的概念比较多，这里列举些常见的概念，方便进行理解：
观测数据相关
Signal
观测数据类型，如 trace、metrics、logs
Instrument
可认为是某种 Signal 的实例
OpenTelemetry 自身项目相关
API
OpenTelemetry Spec 的形式化描述，如 opentelemetry-proto
SDK
面向不同开发语言的 API 实现
Contrib Packages
与具体的开源项目或 vendor 产品相关的实现
使用的组件相关
Components
Receivers
接收观测数据的组件
Processors
处理接收到的观测数据的组件
Exporters
将观测数据导出的组件，如导出到开源项目 Prometheus 或云厂商服务中
Extensions
不参与观测数据的处理，辅助相关处理组件的运行，如健康检测、服务发现等
Services
还未添加个人签名 2021.11.08 加入
还未添加个人简介
评论