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 是由兩個開源項目合并組成的：

• 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 的使用邏輯，分成兩部分：

1. 初始化并運行全局的 controller，用來在 APP 內部 receive / process / export 觀測數據，或將 APP 內的觀測數據推送到外部

2. APP 內按照業務需求生成 metrics 和 trace

pkg/ 目錄下分別封裝了 controller 和 signal (trace / metrics)，具體的實現不再贅述：

yaml/ 下提供了一個將觀測數據導出到 SLS 的示例，包括了用于接收觀測數據的 receiver (client 端可通過 grpc client 將數據推送到該 receiver)、用于觀測數據轉換處理的 processors、用于數據導出的 exporters、用于開啟組件的 services：

對于開發者，基于 OpenTelemetry 可通過一套標準的方案進行 trace / metrics / logs 的生成和導出，降低開發過程中對不同類型觀測數據的使用成本，也降低對接不同后端服務的成本，如開源項目 Prometheus 或第三方云廠商的服務。

對于 SRE，基于 OpenTelemetry 可為觀測數據提供一套標準的采集、處理、導出流程，并在處理環節根據團隊需求規范化觀測數據，便于后續采用標準化的方案使用觀測數據，如監控、告警服務。

同時，不論對于開發者還是 SRE，均可以通過社區的力量持續迭代對可觀測性問題域的理解，吸收社區的技術紅利，并將生產中產生的最佳實踐回饋社區，更好推動可觀測性領域的發展。

關于OpenTelemetry是什么意思就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。