作者 | 悟鵬
來源 |
阿裡巴巴雲原生公衆号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 版本，根據官方的成熟度模型 (
)，目前 trace 的 spec 已經達到 stable 級别，metrics 達到了 beta 級别，logs 目前還處在 alpha 級别：
OpenTelemetry 的前景如何？
自 OpenTelemetry 推出以來，有越來越多的廠商開始關注和貢獻。
可看出來，廠商的關注重點在于 exporter 部分，将觀測資料便利導入到自身的服務中，其中已經包含阿裡雲自身的
SLS 産品：
對于 receiver 和 processor 環節，相信廠商也會逐漸投入更多的精力，如：
- 通過 receiver 和 exporter 的配合，形成觀測資料的處理 workflow
- 通過 processor，在觀測資料存儲前進行規範化處理
對于多雲場景，OpenTelemetry 定義的觀測資料模型、采集/處理/導出 标準，将有利于使用者通過一套可觀測性标準對接多種雲廠商，避免 vendor 鎖定。
即使是面向單一的雲 (如雲廠商内部的服務)，也不可避免會考慮未來進行開源、與外部共建等，使用社群的可觀測性标準可以降低開源成本。同時，可觀測性的理念、标準、技術在不斷疊代，通過跟進社群，可以更好使用到社群帶來的技術紅利和影響力。
是以，無論是面對多雲場景還是單一的雲廠商，采用業界的可觀測性标準都是很有必要。
OpenTelemetry 如何使用？
核心概念
OpenTelemetry 中的概念比較多，這裡列舉些常見的概念，友善進行了解：
- 觀測資料相關
- Signal
- 觀測資料類型，如 trace、metrics、logs
- Instrument
- 可認為是某種 Signal 的執行個體
- Signal
- OpenTelemetry 自身項目相關
- 使用的元件相關
- Components
- Receivers
- 接收觀測資料的元件
- Processors
- 處理接收到的觀測資料的元件
- Exporters
- 将觀測資料導出的元件，如導出到開源項目 Prometheus 或雲廠商服務中
- Extensions
- 不參與觀測資料的處理，輔助相關處理元件的運作，如健康檢測、服務發現等
- Services
- 表征配置的哪些元件需要運作，如 receivers / processors / exporters / extentions
- Collector
- 可認為是 receivers / processors / exporters / extentions / services 組成的整體
- Controller
- 用于開發者開發的應用中，作用可等同于 receivers / processors / exporters 組成的整體
- Receivers
- Components
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 官網
歡迎大家留言交流使用 Kubernetes 過程中的穩定性保障問題，以及對穩定性保障的期待工具或服務。大家也可通過郵箱聯系作者，進一步深入交流：[email protected]。