OpenTelemetry - 雲原生下可觀測性的新標準

CNCF 簡介

CNCF（Cloud Native Computing Foundation），中文爲「雲原生計算基金會」，CNCF是Linux基金會旗下的基金會，能夠理解爲一個非盈利組織。

當年谷歌內部一直用於編排容器的Borg項目開源了，爲了該項目更好的發展，谷歌與Linux基金會一塊兒創辦了CNCF。同時，谷歌把Borg用Go語言重寫，改名爲Kubernetes並捐贈到CNCF。

成立這個組織的初衷或者願景，簡單說：

• 推進雲原生計算可持續發展；
• 幫助雲原生技術開發人員快速地構建出色的產品；
• CNCF經過創建社區、管理衆多開源項目等手段來推廣技術和生態系統發展。

APM

你們應該都據說過APM(Application Performance Monitoring)，也應該據說過Distributed Tracing(分佈式跟蹤)，其中後者是前者的子集。分佈式跟蹤該名詞是隨着微服務的流行而興起的，主要是爲了解決微服務架構中請求鏈路過長致使的定位和監控難問題。 目前該領域有名的產品有：Jaeger、Pinpoint、Zipkin等等，能夠說是競爭異常激烈，可是由此帶來一個問題：每一家都有本身的一套數據採集標準和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工具打通，統一用戶的使用方式。隨着項目的進展，野心也膨脹了，這個時候開始幻想爲何不把其它各類語言的相關採集都統一呢？而後項目組發現了OpenTracing，忽然發現，我K，做爲谷歌，咱們都沒玩標準，大家居然敢玩標準敢想着統一全世界？(此處乃做者的瘋人瘋語) 因而乎，OpenCensus的場景進一步擴大了，不只作了Metrics基礎指標監控，還作了OpenTracing的老本行：分佈式跟蹤。

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

OpenTracing vs OpenCensus

這裏直接把 Steve Flanders的對比圖拿了過來

功能特性

能夠看到，OpenTracing和OpenCensus從功能和特性上來看，各有優缺點。OpenTracing支持的語言更多、相對對其餘系統的耦合性要更低；OpenCensus支持Metrics、分佈式跟蹤,同時從API層一直到基礎設施層都進行了支持。

開源社區

難分勝負？再來對比下社區活躍，我去，好像仍是半斤八兩，你有更廣的使用羣衆基礎，我有谷歌和微軟就足矣。

因此，從上面能夠看出，兩個產品真的是各紅遍半邊天，可是做爲開源項目，這種競爭未免太消耗資源了，對用戶也十分不友好，咋麼辦？

OpenTelemetry

正所謂是：天下合久必分、分久必合，在此之時，必有梟雄出現：OpenTelemetry橫空出世。

兩個產品合併，首先要考慮的是什麼？有過經驗的同窗都知道：如何讓兩邊的用戶可以繼續使用。所以新項目首要核心目標就是兼容OpenTracing和OpenCensus。

OpenTelemetry的核心工做目前主要集中在3個部分：

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

因而可知，OpenTelemetry的自身定位很明確：數據採集和標準規範的統一，對於數據如何去使用、存儲、展現、告警，官方是不涉及的，咱們目前推薦使用Prometheus + Grafana作Metrics存儲、展現，使用Jaeger作分佈式跟蹤的存儲和展現。

首先，再補充一下背景知識，以前提到了APM的兩種監控子類：分佈式跟蹤和Metrics，其實還有第三種，就是Logging日誌，目前常見的日誌收集平臺有EFK、Fluentd.

上圖中能夠看到，缺失了Logging，主要有如下緣由：

1. 優先級是在上面提到的三個核心工做上，Logging目前優先級相對較低(P2)
2. Logging通常是經過三方平臺完成收集，目前如何與分佈式跟蹤、Metrics的數據進行整合，官方尚未給出設計方案

大一統

有了以上的背景知識，咱們就能夠頂一下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，最終實現監控數據標準的大一統。

引用

https://github.com/SpringLeee/docs-cn/blob/master/OT.md

最後

歡迎掃碼關注咱們的公衆號 【全球技術精選】，專一國外優秀博客的翻譯和開源項目分享，也能夠添加QQ羣 897216102