有幸在2019KubeCon上海站聽到Steve Flanders關(guān)于OpenTelemetry的演講，之前Ops領(lǐng)域兩個(gè)網(wǎng)紅項(xiàng)目OpenTracing和OpenCensus終于走到了一起，可觀察性統(tǒng)一的標(biāo)準(zhǔn)化已經(jīng)揚(yáng)帆起航。
這篇文章旨在拋磚引玉，希望能夠和更多的同學(xué)一起交流可觀察性相關(guān)的內(nèi)容。

前世

OpenTracing

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

OpenCensus

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

OpenTracing vs OpenCensus

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

可以看到，OpenTracing和OpenCensus從功能和特性上來看，各有優(yōu)缺點(diǎn)，半斤八兩。OpenTracing支持的語言更多、相對(duì)對(duì)其他系統(tǒng)的耦合性要更低；OpenCensus支持Metrics、從API到基礎(chǔ)框架都實(shí)現(xiàn)了個(gè)便。既然從功能和特性上分不出高下，那就從知名度和用戶數(shù)上來PK吧：

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

OpenTelemetry

橫空出世

所謂天下合久必分、分久必合，既然沒辦法分個(gè)高低，誰都有優(yōu)劣勢(shì)，咱們就別干了，統(tǒng)一吧。于是OpenTelemetry橫空出世。

那么問題來了：統(tǒng)一可以，起一個(gè)新的項(xiàng)目從頭搞嗎？那之前追隨我的弟兄們?cè)趺崔k？不能丟了我的兄弟們啊。
放心，這種事情肯定不會(huì)發(fā)生的。要知道OpenTelemetry的發(fā)起者都是OpenTracing和OpenCensus的人，所以項(xiàng)目的第一宗旨就是：兼容OpenTracing和OpenCensus。對(duì)于使用OpenTracing或OpenCensus的應(yīng)用不需要重新改動(dòng)就可以接入OpenTelemetry。

核心工作

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

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

相關(guān)SDK、Tool的實(shí)現(xiàn)和集成，包括各類語言的SDK、代碼自動(dòng)注入、其他三方庫（Log4j、LogBack等）的集成；

采集系統(tǒng)的實(shí)現(xiàn)，目前還是采用OpenCensus的采集架構(gòu)，包括Agent和Collector。

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

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

工作組目前主要的工作是在把OpenTracing和OpenCensus的概念盡早統(tǒng)一并開發(fā)相應(yīng)的SDK，Logging是P2的優(yōu)先級(jí)。

他們還沒有想好Logging該怎么集成到規(guī)范中，因?yàn)檫@里還需要和CNCF里面的Fluentd一起去做，大家都還沒有想好。

終極目標(biāo)

OpenTelemetry的終態(tài)就是實(shí)現(xiàn)Metrics、Tracing、Logging的融合，作為CNCF可觀察性的終極解決方案。

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

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

Metrics、Tracing、Logging融合的關(guān)鍵

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

如何把Metrics和其他兩者關(guān)聯(lián)起來

如何提供更多維度的關(guān)聯(lián)，例如請(qǐng)求的方法名、URL、用戶類型、設(shè)備類型、地理位置等

關(guān)聯(lián)關(guān)系如何一致，且能夠在分布式系統(tǒng)下傳播

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

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

下面是Yuri Shkuro畫的原型設(shè)計(jì)：

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

當(dāng)前狀態(tài)以及后續(xù)路線

目前OpenTelemetry還處于策劃和原型階段，很多細(xì)節(jié)的點(diǎn)還在討論當(dāng)中，目前官方給的時(shí)間節(jié)奏是：

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

總結(jié)

從Prometheus、OpenTracing、Fluentd到OpenTelemetry、Thanos這些項(xiàng)目的陸續(xù)進(jìn)入就可以看出CNCF對(duì)于Cloud Native下可觀察性的重視，而OpenTelemetry的出現(xiàn)標(biāo)志著Metrics、Tracing、Logging有望全部統(tǒng)一。

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

• 提供統(tǒng)一的后端存儲(chǔ)，目前三類數(shù)據(jù)都是存儲(chǔ)在不同系統(tǒng)中
• 提供計(jì)算、分析的方法和最佳實(shí)踐，例如動(dòng)態(tài)拓?fù)浞治?/li>
• 統(tǒng)一的可視化方案
• AIOps相關(guān)能力，例如Anomaly Detection、Root Cause Analysis等

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。