有幸在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個部分：

1. 規範的制定，包括概念、協議、API，除了自身的協議外，還需要把這些規範和W3C、GRPC這些協議達成一致；
2. 相關SDK、Tool的實現和整合，包括各類語言的SDK、程式碼自動注入、其他三方庫（Log4j、LogBack等）的整合；
3. 採集系統的實現，目前還是採用OpenCensus的採集架構，包括Agent和Collector。

可以看到OpenTelemetry只是做了資料規範、SDK、採集的事情，對於Backend、Visual、Alert等並不涉及，官方目前推薦的是用Prometheus去做Metrics的Backend、用Jaeger去做Tracing的Backend。

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

1. 工作組目前主要的工作是在把OpenTracing和OpenCensus的概念儘早統一併開發相應的SDK，Logging是P2的優先順序。
2. 他們還沒有想好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的關聯。但這還是解決不了很多問題：

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

在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 <-----> marshaling
                                                          plugins

當前狀態以及後續路線

目前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等

參考

有興趣的同學可以看看下面的一些文章，歡迎各位指教和探討：
https://opentracing.io/
https://opencensus.io/
https://opentelemetry.io/
https://thenewstack.io/opentracing-opencensus-merge-into-a-single-new-project-opentelemetry/
https://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/
https://www.cncf.io/blog/2016/10/11/opentracing-joins-the-cloud-native-computing-foundation/
https://medium.com/jaegertracing/embracing-context-propagation-7100b9b6029a
https://github.com/open-telemetry/opentelemetry-specification/issues/9
https://docs.google.com/document/d/1UxrEYOaQlF_E4gtiPoFmcZ4YKKe1GxohvCvQDuwvD1I/edit?source=post_page---------------------------#heading=h.pcdszlrz3y2w
https://medium.com/jaegertracing/jaeger-and-opentelemetry-1846f701d9f2

本文作者：元乙

原文連結

本文為雲棲社群原創內容，未經