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 是由兩個開源專案合併組成的：

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、logsInstrument可認為是某種 Signal 的例項

OpenTelemetry 自身專案相關APIOpenTelemetry Spec 的形式化描述，如 opentelemetry-protoSDK面向不同開發語言的 API 實現Contrib Packages與具體的開源專案或 vendor 產品相關的實現

使用的元件相關ComponentsReceivers接收觀測資料的元件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，均可以透過社群的力量持續迭代對可觀測性問題域的理解，吸收社群的技術紅利，並將生產中產生的最佳實踐回饋社群，更好推動可觀測性領域的發展。

作者 | 悟鵬