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個部分：
- 規範的制定和協議的統一，規範包含資料傳輸、API的規範，協議的統一包含：HTTP W3C的標準支援及GRPC等框架的協議標準
- 多語言SDK的實現和整合，使用者可以使用SDK進行程式碼自動注入和手動埋點，同時對其他三方庫（Log4j、LogBack等）進行整合支援；
- 資料收集系統的實現，當前是基於OpenCensus Service的收集系統，包括Agent和Collector。
由此可見，OpenTelemetry的自身定位很明確：資料採集和標準規範的統一，對於資料如何去使用、儲存、展示、告警，官方是不涉及的，我們目前推薦使用Prometheus + Grafana做Metrics儲存、展示，使用Jaeger做分散式跟蹤的儲存和展示。
首先，再補充一下背景知識，之前提到了APM的兩種監控子類：分散式跟蹤和Metrics，其實還有第三種，就是Logging日誌，目前常見的日誌收集平臺有EFK、Fluentd.
上圖中可以看到，缺失了Logging，主要有以下原因：
- 優先順序是在上面提到的三個核心工作上，Logging目前優先順序相對較低(P2)
- Logging一般是通過三方平臺完成收集，目前如何與分散式跟蹤、Metrics的資料進行整合，官方還沒有給出設計方案
大一統
有了以上的背景知識，我們就可以頂一下OpenTelemetry的終極目標了：實現Metrics、Tracing、Logging的融合及大一統，作為APM的資料採集終極解決方案。
- Tracing：提供了一個請求從接收到處理完成整個生命週期的跟蹤路徑，一次請求通常過經過N個系統，因此也被稱為分散式鏈路追蹤
- Metrics：例如cpu、請求延遲、使用者訪問數等Counter、Gauge、Histogram指標
- Logging：傳統的日誌，提供精確的系統記錄
這三者的組合可以形成大一統的APM解決方案：
- 基於Metrics告警發現異常
- 通過Tracing定位到具體的系統和方法
- 根據模組的日誌最終定位到錯誤詳情和根源
- 調整Metrics等設定，更精確的告警/發現問題
該如何融合？
在以往對APM的理解中，這三者都是完全獨立的，但是隨著時間的推移，人們逐步發現了三者之間的關聯，例如我們可以把Tracing的TraceID打到Logging的日誌中，這樣可以把分散式鏈路跟蹤和日誌關聯到一起，彼此資料互通，但是還存在以下問題：
- 如何把Metrics和其他兩者關聯起來
- 如何提供更多維度的關聯，例如請求的方法名、URL、使用者型別、裝置型別、地理位置等
- 關聯關係如何一致，且能夠在分散式系統下傳播
在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
