有幸在2019KubeCon上海站聽到Steve Flanders關于OpenTelemetry的演講，之前Ops領域兩個網紅項目OpenTracing和OpenCensus終于走到了一起，可觀察性統一的標準化已經揚帆起航。
這篇文章旨在拋磚引玉，希望能夠和更多的同學一起交流可觀察性相關的內容。

前世

OpenTracing

OpenTracing制定了一套平臺無關、廠商無關的Trace協議，使得開發人員能夠方便的添加或更換分布式追蹤系統的實現。在2016年11月的時候CNCF技術委員會投票接受OpenTracing作為Hosted項目，這是CNCF的第三個項目，第一個是Kubernetes，第二個是Prometheus，可見CNCF對OpenTracing背后可觀察性的重視。比如大名鼎鼎的Zipkin、Jaeger都遵循OpenTracing協議。

OpenCensus

大家可能會想，既然有了OpenTracing，OpenCensus又來湊什么熱鬧？對不起，你要知道OpenCensus的發起者可是谷歌，也就是最早提出Tracing概念的公司，而OpenCensus也就是Google Dapper的社區版。OpenCensus和OpenTracing最大的不同在于除了Tracing外，它還把Metrics也包括進來，這樣也可以在OpenCensus上做基礎的指標監控；還一點不同是OpenCensus并不是單純的規范制定，他還把包括數據采集的Agent、Collector一股腦都搞了。OpenCensus也有眾多的追隨者，最近最大的新聞就是微軟也宣布加入，OpenCensus可謂是如虎添翼。

OpenTracing vs OpenCensus

兩套Tracing框架，都有很多追隨者，都想統一對方，咋辦？首先來PK啊，這里偷個懶，直接上Steve的圖：

可以看到，OpenTracing和OpenCensus從功能和特性上來看，各有優缺點，半斤八兩。OpenTracing支持的語言更多、相對對其他系統的耦合性要更低；OpenCensus支持Metrics、從API到基礎框架都實現了個便。既然從功能和特性上分不出高下，那就從知名度和用戶數上來PK吧：

好吧，又是半斤八兩，OpenTracing有很多廠商追隨（比如ElasticSearch、Uber、DataDog、還有國產的SkyWalking），OpenCensus背后Google和微軟兩個大佬就夠撐起半邊天了。
最終一場PK下來，沒有勝負，怎么辦？

OpenTelemetry

橫空出世

所謂天下合久必分、分久必合，既然沒辦法分個高低，誰都有優劣勢，咱們就別干了，統一吧。于是OpenTelemetry橫空出世。

那么問題來了：統一可以，起一個新的項目從頭搞嗎？那之前追隨我的弟兄們怎么辦？不能丟了我的兄弟們啊。
放心，這種事情肯定不會發生的。要知道OpenTelemetry的發起者都是OpenTracing和OpenCensus的人，所以項目的第一宗旨就是：兼容OpenTracing和OpenCensus。對于使用OpenTracing或OpenCensus的應用不需要重新改動就可以接入OpenTelemetry。

核心工作

OpenTelemetry可謂是一出生就帶著無比炫目的光環：OpenTracing支持、OpenCensus支持、直接進入CNCF sanbox項目。但OpenTelemetry也不是為了解決可觀察性上的所有問題，他的核心工作主要集中在3個部分：

規范的制定，包括概念、協議、API，除了自身的協議外，還需要把這些規范和W3C、GRPC這些協議達成一致；

相關SDK、Tool的實現和集成，包括各類語言的SDK、代碼自動注入、其他三方庫（Log4j、LogBack等）的集成；

采集系統的實現，目前還是采用OpenCensus的采集架構，包括Agent和Collector。

可以看到OpenTelemetry只是做了數據規范、SDK、采集的事情，對于Backend、Visual、Alert等并不涉及，官方目前推薦的是用Prometheus去做Metrics的Backend、用Jaeger去做Tracing的Backend。

看了上面的圖大家可能會有疑問：Metrics、Tracing都有了，那Logging為什么也不加到里面呢？
其實Logging之所以沒有進去，主要有兩個原因：

工作組目前主要的工作是在把OpenTracing和OpenCensus的概念盡早統一并開發相應的SDK，Logging是P2的優先級。

他們還沒有想好Logging該怎么集成到規范中，因為這里還需要和CNCF里面的Fluentd一起去做，大家都還沒有想好。

終極目標

OpenTelemetry的終態就是實現Metrics、Tracing、Logging的融合，作為CNCF可觀察性的終極解決方案。

Tracing：提供了一個請求從接收到處理完畢整個生命周期的跟蹤路徑，通常請求都是在分布式的系統中處理，所以也叫做分布式鏈路追蹤。
Metrics：提供量化的系統內/外部各個維度的指標，一般包括Counter、Gauge、Histogram等。
Logging：提供系統/進程最精細化的信息，例如某個關鍵變量、事件、訪問記錄等。

這三者在可觀察性上缺一不可：基于Metrics的告警發現異常，通過Tracing定位問題（可疑）模塊，根據模塊具體的日志詳情定位到錯誤根源，最后再基于這次問題調查經驗調整Metrics（增加或者調整報警閾值等）以便下次可以更早發現/預防此類問題。

Metrics、Tracing、Logging融合的關鍵

實現Metrics、Tracing、Logging融合的關鍵是能夠拿到這三者之間的關聯關系.其中我們可以根據最基礎的信息來聚焦，例如：時間、Hostname(IP)、APPName。這些最基礎的信息只能定位到一個具體的時間和模塊，但很難繼續Digin，于是我們就把TraceID把打印到Log中，這樣可以做到Tracing和Logging的關聯。但這還是解決不了很多問題：

如何把Metrics和其他兩者關聯起來

如何提供更多維度的關聯，例如請求的方法名、URL、用戶類型、設備類型、地理位置等

關聯關系如何一致，且能夠在分布式系統下傳播

在OpenTelemetry中試圖使用Context為Metrics、Logging、Tracing提供統一的上下文，三者均可以訪問到這些信息，由OpenTelemetry本身負責提供Context的存儲和傳播：

• Context數據在Task/Request的執行周期中都可以被訪問到
• 提供統一的存儲層，用于保存Context信息，并保證在各種語言和處理模型下都可以工作（例如單線程模型、線程池模型、CallBack模型、Go Routine模型等）
• 多種維度的關聯基于Tag（或者叫meta）信息實現，Tag內容由業務確定，例如：通過TrafficType來區別是生產流量還是壓測流量、通過DeviceType來分析各個設備類型的數據...
• 提供分布式的Context傳播方式，例如通過W3C的traceparent/tracestate頭、GRPC協議等

下面是Yuri Shkuro畫的原型設計：

+----------------------------------------------------+| |+------------+ custom application logic or specialized frameworks || | || +-------------------------------------+--------------+| || +---------+ +------+ +--------+ || | | | | | | || | metrics | | logs | | traces +---+ || | | | | | | | || +----+----+ +---+--+ +---+----+ | || ^ ^ ^ | || +-----+----------+--------+-----+ | || | | | |+---> baggage | | || | | |+---------------+---------------+ | || | | +---------------------+------------------+-----------+-------------------+Universal context propagation layer <-----> marshalingplugins

當前狀態以及后續路線

目前OpenTelemetry還處于策劃和原型階段，很多細節的點還在討論當中，目前官方給的時間節奏是：

• 2019年9月，發布主要語言版本的SDK（Pre Release版）
• 2019年11月，OpenTracing和OpenCensus正式sunsetted（ReadOnly）
• 未來兩年內，保證可以兼容OpenTracing和OpenCensus的SDK

總結

從Prometheus、OpenTracing、Fluentd到OpenTelemetry、Thanos這些項目的陸續進入就可以看出CNCF對于Cloud Native下可觀察性的重視，而OpenTelemetry的出現標志著Metrics、Tracing、Logging有望全部統一。

但OpenTelemetry并不是為了解決客觀性上的所有問題，后續還有很多工作需要進行，例如：

• 提供統一的后端存儲，目前三類數據都是存儲在不同系統中
• 提供計算、分析的方法和最佳實踐，例如動態拓撲分析
• 統一的可視化方案
• AIOps相關能力，例如Anomaly Detection、Root Cause Analysis等

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

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

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