OpenTelemetry - 結束分佈式追蹤的江湖之亂

一、江湖亂象

分佈式追蹤，隨着分佈式系統的流行而興起。在分佈式系統中，往往存在一個單一的用戶請求中，可能會需要大量微服務的處理後，才能完成這個請求，在微服務中的任何一個服務的失敗或性能低下，都會對於用戶請求的響應造成極大影響。隨着業務的不斷擴張，這個調用鏈的也就會越來越複雜。爲了解決微服務架構中請求鏈路過長導致的問題定位和監控難問題，鏈路追蹤產品也就應運而生。

目前的主流開源產品有 Zipkin、Jaeger、PinPoint 等。市場上產品雖多，但是各方都具有自己的數據採集協議以及 SDK，雖然幾乎都是基於谷歌 Dapper 協議，但是彼此的實現是大相徑庭的。 爲了解決這個問題，國外的大神們在之前創建了 OpenTracing 和 OpenCensus，我們先來分別看看這兩個產品。

OpenTracing

OpenTracing 制定了一套平臺無關、廠商無關的協議標準，使得開發人員能夠方便的添加或更換底層 APM 的實現。

在 2016 年 11 月的時候發生了一件里程碑事件，CNCF.io 接受 OpenTracing，同時這也是 CNCF 的第三個項目，前兩個都已經鼎鼎大名了：Kubernetes，和 Prometheus，由此可見開源世界對 APM 的重視，對統一標準的重視和渴望。

遵循 OpenTracing 協議的產品有 Jaeger、Zipkin 等等。

OpenCensus

中國有句老話，既生瑜何生亮，OpenTracing 本身出現的更早且更流行，爲什麼要有 OpenCensus 這個項目？

這裏先補充一下背景知識，前面提到了分佈式追蹤，其實在 APM 領域，還有一個極其重要的監控子類：Metrics 指標監控，例如 cpu、內存、硬盤、網絡等機器指標，grpc 的請求延遲、錯誤率等網絡協議指標，用戶數、訪問數、訂單數等業務指標，都可以涵蓋在內。

該項目有個非常牛逼的背景：Google，要知道就連分佈式跟蹤的基礎論文就是谷歌提出的。

其次，OpenCensus 的最初目標並不是與 OpenTracing 競爭，而是爲了把 Go 語言的 Metrics 採集、鏈路跟蹤與 Go 語言自帶的 profile 工具打通，統一用戶的使用方式。但是隨着項目的進展，野心也膨脹了，這個時候開始幻想爲什麼不把其它各種語言的相關採集都統一呢？於是乎，OpenCensus 的場景進一步擴大了，不僅做了 Metrics 基礎指標監控，還做了 OpenTracing 的老本行：分佈式跟蹤。

有個谷歌做親爹已經夠牛了，那再加入一個微軟做乾爹呢？是不是要起飛了？所以，對於 OpenCensus 的發展而言，微軟的直接加入可以說是打破了之前的競爭平衡，間接導致了後面 OpenTelemetry 項目的誕生。

二、OpenTelemeTry 橫空出世

2019 年 4 月 24 日，新項目成立，項目成員提交審查

2019 年 5 月 8 日，各團隊成立，開始各種語言下的工作

2019 年 5 月 20 日，項目正式開始

2019 年 9 月 6 日， Golang，Java，NodeJS 和 Python 語言已經完成項目目標

2019 年 11 月 6 日，項目進入收尾階段

2019 年 11 月 20 日，項目完成

OpenTelemetry

2019 年，OpenTelemetry 項目組成立，在 2019 年年底項目初步完成，

• 規範的制定和協議的統一，規範包含數據傳輸、API 的規範，協議的統一包含：HTTP W3C 的標準支持及 GRPC 等框架的協議標準
• 多語言 SDK 的實現和集成，用戶可以使用 SDK 進行代碼自動注入和手動埋點，同時對其他三方庫（Log4j、LogBack 等）進行集成支持；
• 數據收集系統的實現，當前是基於 OpenCensus Service 的收集系統，包括 Agent 和 Collector。

由此可見，OpenTelemetry 的自身定位很明確：**數據採集和標準規範的統一。**對於數據如何去使用、存儲、展示、告警，官方是不涉及的，目前官方推薦的是使用 Prometheus + Grafana 做 Metrics 存儲、展示，使用 Jaeger 做分佈式追蹤的存儲和展示。

在上圖中描述了服務產生數據，經由 OpenTelemetry 處理後轉發至各數據展示及倉庫的過程。左側爲產生數據的 Service，在 Service 中通過 agent 或者 SDK 的形式來進行數據收集，再由 agent 或者 SDK 將數據上傳至 OpenTelemetry-Collector 中進行數據處理，再將數據傳輸至右側的數據存儲、分析、展示平臺，如 Prometheus、Jaeger 等（這裏可以是任意平臺，通過實現 Exporter 來完成）。

數據的採集端，官方給出的方案是使用 OpenTelemetry 的 SDK/Agent 進行採集，不過也可以使用其他的方式進行採集，比如企業自己開發的一個上報功能。在數據上傳時，如果規範與 OpenTelemetry 自身規範發生衝突，也可以通過實現新的 Collector 中的 Receiver 來處理。在後續的 OpenTelemetry-Collector 介紹文檔中會進行詳細說明。

在上圖中，並未添加日誌的數據數據輸出，日誌的採集上報，在 OpenTelemetry 的 SDK 及 Agent 中均有實現，但是截止至目前 <2021 年 1 月> 關於日誌的處理官方還沒有一個很好的方案，在 OpenTelemtry-Collector 中並沒有針對於輸出至 ES 或者其他日誌分析平臺的 Exporter 實現，這部分可能需要由開發者自己進行處理。

三、大一統

有了以上的背景知識，我們就可以頂一下 OpenTelemetry 的終極目標了：實現 Metrics、Tracing、Logging 的融合及大一統，作爲 APM 的數據採集終極解決方案。

• Tracing：提供了一個請求從接收到處理完成整個生命週期的跟蹤路徑，一次請求通常過經過 N 個系統，因此也被稱爲分佈式鏈路追蹤
• Metrics：例如 cpu、請求延遲、用戶訪問數等 Counter、Gauge、Histogram 指標
• Logging：傳統的日誌，提供精確的系統記錄

這三者的組合可以形成大一統的 APM 解決方案：

1. 基於 Metrics 告警發現異常
2. 通過 Tracing 定位到具體的系統和方法
3. 根據模塊的日誌最終定位到錯誤詳情和根源
4. 調整 Metrics 等設置，更精確的告警 / 發現問題

該如何融合？

在以往對 APM 的理解中，這三者都是完全獨立的，但是隨着時間的推移，人們逐步發現了三者之間的關聯，例如我們可以把 Tracing 的 TraceID 打到 Logging 的日誌中，這樣可以把分佈式鏈路跟蹤和日誌關聯到一起，彼此數據互通，但是還存在以下問題：

1. 如何把 Metrics 和其他兩者關聯起來
2. 如何提供更多維度的關聯，例如請求的方法名、URL、用戶類型、設備類型、地理位置等
3. 關聯關係如何一致，且能夠在分佈式系統下傳播

在 OpenTelemetry 中試圖使用 Context 爲 Metrics、Logging、Tracing 提供統一的上下文，三者均可以訪問到這些信息，同時 Context 可以隨着請求鏈路的深入，不斷往下傳播

• Context 數據在 Task/Request 的執行週期中都可以被訪問到
• 提供統一的存儲層，用於保存 Context 信息，並保證在各種語言和處理模型下都可以工作（例如單線程模型、線程池模型、CallBack 模型、Go Routine 模型等）
• 多種維度的關聯基於元信息 (標籤) 實現，元信息由業務確定，例如：通過 Env 來區別是測試還是生產環境等
• 提供分佈式的 Context 傳播方式，例如通過 W3C 的 traceparent/tracestate 頭、GRPC 協議等

四、總結

從谷歌 Dapper 協議提出到現在已經很多年了，江湖也已經亂戰了很多年，這次谷歌和微軟下定決心結束江湖之亂，對於未來分佈式系統的監控真的是非常巨大的利好消息，我們也有理由相信在這兩家巨頭的主導，該項目會越發展越好，未來會有越來越多的開源項目、框架、平臺，原生的使用 OpenTelemetry，最終實現監控數據標準的大一統。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://blog.csdn.net/qq_35427785/article/details/113736940