簡介： OpenTelemetry 是 CNCF 的一個可觀測性項目，旨在提供可觀測性領域的標准化方案，解決觀測數據的數據模型、采集、處理、導出等的標准化問題，提供與三方 vendor 無關的服務。 2021.02.10，OpenTelemetry 的 tracing spec 達到 1.0 版本 (link)，基於這個里程碑，筆者對 OpenTelemetry 進行了探索，判斷在可觀測性領域帶來的價值和發展前景。 下面給出筆者對 OpenTelemetry 的理解，拋磚引玉。由於筆者能力有限，理解不當的地方請大家指正。
作者 | 悟鵬
來源 | 阿里巴巴雲原生公眾號
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 是由兩個開源項目合並組成的：
-
- 面向 trace 和 metrics 進行數據模型標准化，並提供采集、處理、導出的工具
-
- 面向 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，均可以通過社區的力量持續迭代對可觀測性問題域的理解，吸收社區的技術紅利，並將生產中產生的最佳實踐回饋社區，更好推動可觀測性領域的發展。