OpenTelemetry 專案解讀

騰訊雲加社群發表於2021-12-25
點選一鍵訂閱《雲薦大咖》專欄,獲取官方推薦精品內容,學技術不迷路!

image.png

隨著分散式應用越來越普遍,分散式應用需要依賴強大的可觀測性設施來提供監控保障,強大的可觀測性設施需要依賴高質量的遙測資料。雖然已經有許多開源或者商業供應商提供了遙測資料監測採集方案。但是在沒有統一標準的情況下,採集的遙測資料相容性差,維護監測客戶端也給使用者帶來沉重的負擔。

Opentelemetry 可以為開發者們提供統一的,與第三方無關的遙測資料採集方案,以解決上述的各種問題。

源起

Opentelemetry 源於 OpenTracing 與 OpenCensus 兩大開源社群的合併而來。OpenTracing 在 2016 年由 Ben Sigelman 發起,旨在解決開源 Tracing 實現重複開發監測客戶端, 資料模型不統一, Tracing 後端相容成本高的問題。OpenCensus 則是由 Google 內部實踐而來,結合了 Tracing 和 Metrics 的監測客戶端開源工具包。

由於兩大開源社群各自的影響力都不小,而存在兩個或多個 Tracing 的標準這個事情本身跟社群組建的主旨相違背。於是兩大開源社群一拍即合,成立了 OpenTelemetry。

為什麼需要

從使用者角度來看,接入 Tracing 監測客戶端,對業務程式碼有一定入侵性。一旦接入了一個供應商的監測客戶端,就很難切換到其他供應商提供的監測客戶端。而從 Tracing 服務端供應商的角度來說,服務端除了要能夠處理自己 Tracing 客戶端的資料外,還需要相容其他供應商 Tracing 客戶端產生的資料,維護成本越來越高。尤其是在分散式應用逐漸普及的情況下,如文章開頭所說, Opentelemetry 的價值更加明顯。

Opentelemetry 專案組成

Opentelemetry 的專案主要分為四個部分內容

跨語言規範說明
收集、轉換、轉發遙測資料的工具 Collector
各語言監測客戶端 API & SDK
自動監測客戶端與第三方庫 Instrumentation & Contrib

跨語言規範說明

規範說明包含話題內容比較廣泛。其中有包含遙測客戶端內部實現所需要的規範,也有包含遙測客戶端與外部通訊所需要實現的協議規範。

程式碼倉庫:opentelemetry-specification

遙測客戶端內部實現所需要的規範,如監測客戶端基本架構、設計原則,遙測訊號(Traces/ Metrics/ Logs)與輔助物件(Baggage/ Context/ Propagator)的概念與模型定義,實現遙測客戶端需要實現的類與功能的設計等。這部分內容本文就不做詳細介紹,可以在 specification/overview.md 以及相應物件資料夾下面的 datamodel.md/ api.md/ sdk.md 可以進行查閱。

遙測客戶端與外部通訊所需要實現的協議規範主要是指 OpenTelemetry Protocol (簡稱 OTLP)。OTLP 是 Opentelemetry 原生的遙測訊號傳遞協議,雖然在 Opentelemetry 的專案中元件支援了 Zipkin v2 或 Jaeger Thrift 的協議格式的實現,但是都是以第三方貢獻庫的形式提供的。只有 OTLP 是 Opentelemetry 官方原生支援的格式。

OTLP 的資料模型定義是基於 ProtoBuf 完成的,如果你需要實現一套可以收集 OTLP 遙測資料的後端服務,那就需要了解裡面的內容,對應可以參考程式碼倉庫:

程式碼倉庫:opentelemetry-proto

收集、轉換、轉發遙測資料的工具 Collector

在 Tracing 實踐中有一個原則,遙測資料收集過程需要與業務邏輯處理正交。意思就是遙測資料收集並傳遞到遙測後端服務的過程不佔用業務邏輯的通道/執行緒,儘量較少監測客戶端對原有業務邏輯的影響。Collector 是基於這個原則實踐的產物。

程式碼倉庫:opentelemetry-collector

從架構層面來說,Collector 有兩種模式。一種是把 Collector 部署在應用相同的主機內(如 K8S 的 DaemonSet),或者部署在應用相同的 Pod 裡面 (如 K8S 中的 Sidecar),應用採集到的遙測資料,直接通過迴環網路傳遞給 Collector。這種模式統稱為 Agent 模式。

另一種模式是把 Collector 當作一個獨立的中介軟體,應用把採集到的遙測資料往這個中介軟體裡面傳遞。這種模式稱之為 Gateway 模式。

兩種模式既可以單獨使用,也可以組合使用,只需要資料出口的資料協議格式跟資料入口的資料協議格式保持一致。
image.png

Opentelemetry Architecture

在 Collector 內部設計中,一套資料的流入、處理、流出的過程稱為 pipeline。一個 pipeline 有三部分元件組合而成,它們分別是 receiver/ processor/ exporter。

receiver
負責按照對應的協議格式監聽接收遙測資料,並把資料轉給一個或者多個 processor
processor
負責做遙測資料加工處理,如丟棄資料,增加資訊,轉批處理等,並把資料傳遞給下一個 processor 或者傳遞給一個或多個 exporter
exporter
負責把資料往下一個接收端傳送(一般是遙測後端),exporter 可以定義同時從多個不同的 processor 中獲取遙測資料

image.png

Collector Pipeline

從上面的設計可以看出,Collector 除了提供讓遙測資料收集與業務邏輯處理正交的能力,還充當了遙測資料對接遙測後端的介面卡。Collector 可以接收 otlp, zipkin, jaeger 等任意格式的資料,然後以 otlp, zipkin, jaeger 等任意格式的資料轉發出去。這一切只取決於你需要輸入或輸出的格式是否有對應的 receiver 和 exporter 實現。 otlp 相關的實現都是在 opentelemetry-collector 倉庫中。而 otlp 以外的協議實現,則是可以參考下面程式碼倉庫。

程式碼倉庫:opentelemetry-collector-contrib

各語言監測客戶端 API & SDK

Opentelemetry 為每種語言提供了基礎的監測客戶端 API & SDK 包。這些包一般都是根據 opentelemetry-specification 裡面的建議與定義,以及結合語言自身的特點,實現了在客戶端採集遙測資料的基本能力。如後設資料在服務間、程式間的傳遞,Trace 新增監測與資料匯出,Metrics 指標的建立、使用及資料匯出等。以下為各語言監測客戶端 API & SDK 包對應的程式碼倉庫表。

企業微信截圖_16402428742604.png

按照 Opentelemetry 專案的規劃,2021 年上半年大部分元件完成 Tracing 的支援。以目前的時間點(2021年12月)來看,C++/.NET/Golang/Java/Javascript/Python/Ruby 監測客戶端對 Tracing 支援已經進入 Stable 狀態。 Erlang/Rust/Swift 監測客戶端對 Tracing 支援則是進入了 Beta 測試階段。

而 Opentelemetry 專案規劃對於 Mertics 的支援則晚一些。希望在 2021 年下半年大部分元件能夠完成 Metrics 的支援。以目前情況來看,各語言客戶端包對於 Metrics 支援還處在 Alpha 測試階段。 而對於 Logs 的支援,則是計劃在 2022 年開始。

Instrumentation & Contrib

如果單純使用監測客戶端 API & SDK 包,許多的操作是需要修改應用程式碼的。如新增 Tracing 監測點,記錄欄位資訊,後設資料在程式/服務間傳遞的裝箱拆箱等。這種方式具有程式碼侵入性,不易解耦,而且操作成本高,增加使用者使用門檻。這個時候就可以利用公共元件的設計模式或語言特性等來降低使用者使用門檻。

利用公共元件的設計模式,例如在 Golang 的 Gin 元件,實現了 Middleware 責任鏈設計模式。我們可以引用 github.com/gin-gonic/gin 庫,建立一個 otelgin.Middleware,手動新增到 Middleware 鏈中,實現 Gin 的快速監測。

利用語言特性的,例如 Java 使用 Java Agent 的能力與 bytebuddy 位元組碼織入技術,在 Java 應用啟動之前找到對應類和方法,修改位元組碼注入監測,實現對指定類的自動監測。

理論上來說,快速監測依賴於客戶端 API & SDK,自動監測則依賴於快速監測。但是實際操作卻並沒有按理論的來。如 Java 語言利用 Java Agent 與 bytebuddy 技術可以實現對指定開源元件實現全自動監測的,所以就沒有單獨提供快速監測(在 OpenTracing 裡面是有分開的)。
企業微信截圖_16402429284872.png

總結

Opentelemetry 的使命是實現收集高質量、大範圍、便攜的遙測資料,讓有效的可觀測性設施成為可能。它本身並不提供完整的可觀測性解決方案,而是提供了統一的遙測資料採集方案。而如果是需要搭建一套完整的可觀測性設施,還需要搭配相應的監測後端做資料持久化與資料查詢,如 Tracing 後端 zipkin/jaeger/tempo/,metrics 後端 prometheus,logs 後端 loki 等。

5周東科.jpg

周東科往期精彩文章推薦:鏈路追蹤(Tracing)的前世今生(上)

《雲薦大咖》是騰訊雲加社群精品內容專欄。雲薦官特邀行業佼者,聚焦於前沿技術的落地及理論實踐之上,持續為您解讀雲時代熱點技術、探索行業發展新機。點選一鍵訂閱,我們將為你定期推送精品內容。

相關文章