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

總結

以上是生活随笔為你收集整理的OpenTelemetry - 云原生下可观测性的新标准的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。