OpenTelemetry的相關知識點有哪些

本篇內容主要講解“OpenTelemetry的相關知識點有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“OpenTelemetry的相關知識點有哪些”吧!

前世

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的相關知識點有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！