簡介：非常有幸參加了云原生社區(qū)Meetup北京站，有機(jī)會和眾多業(yè)內(nèi)的大牛一起討論云原生相關(guān)的技術(shù)和應(yīng)用，本次Meetup上我和大家分享了關(guān)于云原生下的可觀察性相關(guān)的議題，本篇文章主要是視頻的文字性總結(jié)，歡迎大家留言討論。

前言

非常有幸參加了云原生社區(qū)Meetup北京站，有機(jī)會和眾多業(yè)內(nèi)的大牛一起討論云原生相關(guān)的技術(shù)和應(yīng)用，本次Meetup上我和大家分享了關(guān)于云原生下的可觀察性相關(guān)的議題，相關(guān)的視頻可以移步《B站視頻回放：云原生下的可觀察性》回看，本篇文章主要是視頻的文字性總結(jié)，歡迎大家留言討論。

可觀察性的由來

可觀察性最早來自于電氣工程領(lǐng)域，主要原因是隨著系統(tǒng)發(fā)展的逐步復(fù)雜，必須要有一套機(jī)制用來了解系統(tǒng)內(nèi)部的運(yùn)行狀態(tài)以便更好的監(jiān)控和問題修復(fù)，為此工程師們設(shè)計(jì)了很多傳感器、儀表盤用于表現(xiàn)系統(tǒng)內(nèi)部的狀態(tài)。

A system is said to be?observable?if, for any possible evolution of?state and control vectors, the current state can be estimated using only the information from outputs.

電氣工程發(fā)展了上百年，其中各個子領(lǐng)域的可觀察性都在進(jìn)行完善和升級，例如交通工具（汽車/飛機(jī)等）也算的是可觀察性上的集大成者。拋開飛機(jī)這種超級工程不談，一輛可正常上路的小型汽車內(nèi)部也有上百種的傳感器用來檢測汽車內(nèi)/外部的各種狀態(tài)，以便讓汽車可以穩(wěn)定、舒適、安全地的行駛。

可觀察性的未來

隨著上百年的發(fā)展，電氣工程下的可觀察性已經(jīng)不僅僅用來輔助人們進(jìn)行問題檢查和定位問題，我們以汽車工程來看，整個可觀察性的發(fā)展經(jīng)歷了幾個過程：

盲目：1886年1月29日德國人卡爾·本茨發(fā)明了人類史上第一輛汽車，那個時候的汽車僅僅具備行駛的最基礎(chǔ)能力，根本沒有任何和可觀察性相關(guān)的事情。

傳感器：隨著后來汽車開始正式進(jìn)入市場，人們需要更好的知道汽車是不是沒油了、沒水了，因此基礎(chǔ)的傳感器儀表盤被發(fā)明出來。

告警：為了更好的保證汽車的形式安全性，人們開始使用自檢和實(shí)時告警系統(tǒng)來主動向駕駛員通知一些異常信息，比如電瓶沒電、水溫過高、胎壓低、剎車片磨損等。

輔助：雖然告警能夠即時發(fā)出，但有時候人還是來不及處理或者不想處理，這時候輔助系統(tǒng)就派上了用場，例如定速巡航、主動安全、自主泊車等。這些輔助系統(tǒng)是把傳感器+自動控制進(jìn)行結(jié)合，能夠部分解決駕駛員可能做不到或者不想做的事情。

自動駕駛：上述這些功能最終還是要人去參與，而自動駕駛可以完全不需要人的參與，直接是可觀察性系統(tǒng)+控制系統(tǒng)就可以讓汽車自動運(yùn)行起來。

自動駕駛的核心要素

作為電氣工程上可觀察性的巔峰，自動駕駛將汽車獲取到的各類內(nèi)外部數(shù)據(jù)發(fā)揮到極致，總結(jié)起來主要有幾下幾個核心的要素：

豐富的數(shù)據(jù)源：汽車外圍遍布多個激光/圖像雷達(dá)，能夠?qū)崿F(xiàn)高幀率、360°實(shí)時觀測周圍的物體及其狀態(tài)；內(nèi)部則能夠?qū)崟r知道當(dāng)前的車速、車輪角度、胎壓等信息，做到知彼知己。

數(shù)據(jù)集中化：相對輔助駕駛能力，自動駕駛的一個核心突破是能夠?qū)④噧?nèi)外的所有數(shù)據(jù)集中到一起去處理，真正發(fā)揮出數(shù)據(jù)的價值，而不是每個模塊的數(shù)據(jù)作為孤島進(jìn)行獨(dú)立運(yùn)作。

強(qiáng)大算力：集中化的數(shù)據(jù)也意味著數(shù)據(jù)量的急劇膨脹，無論哪家自動駕駛背后都有強(qiáng)大的芯片支撐，只有足夠的算力才能保證在最短的時間內(nèi)可以進(jìn)行足夠的計(jì)算。

軟件迭代：算力+算法構(gòu)成了智能化的最終目標(biāo)，然而算法不可能完美無瑕，我們會根據(jù)逐漸積累的自動駕駛數(shù)據(jù)不斷進(jìn)行算法的升級，使軟件系統(tǒng)能夠不斷的升級以獲得更佳的自動駕駛效果。

IT系統(tǒng)的可觀察性

伴隨著幾十年的發(fā)展，IT系統(tǒng)中的監(jiān)控、問題排查也逐漸抽象為可觀察性工程。在當(dāng)時，最主流的方式還是使用Metrics、Logging、Tracing的組合。

上面這幅圖詳細(xì)大家非常熟悉，這是Peter Bourgon在參加完2017 Distributed Tracing Summit后發(fā)表的一篇博文，簡潔扼要地介紹了Metrics、Tracing、Logging三者的定義和關(guān)系。這三種數(shù)據(jù)在可觀察性中都有各自的發(fā)揮空間，每種數(shù)據(jù)都沒辦法完全被其他數(shù)據(jù)代替。

以Grafana Loki中介紹中的一個典型問題排查過程來看：

1. 最開始我們通過各式各樣的預(yù)設(shè)報(bào)警發(fā)現(xiàn)異常（通常是Metrics/Logging） 2. 發(fā)現(xiàn)異常后，打開監(jiān)控大盤查找異常的曲線，并通過各種查詢/統(tǒng)計(jì)找到異常的模塊（Metrics） 3. 對這個模塊以及關(guān)聯(lián)的日志進(jìn)行查詢/統(tǒng)計(jì)分析，找到核心的報(bào)錯信息（Logging） 4. 最后通過詳細(xì)的調(diào)用鏈數(shù)據(jù)定位到引起問題的代碼（Tracing）

上述例子介紹了如何使用Metric、Tracing、Logging去聯(lián)合排查問題，當(dāng)然根據(jù)不同的場景可以有不同的結(jié)合方案，例如簡單的系統(tǒng)可以直接通過日志的錯誤信息去告警并直接定位問題，也可以根據(jù)調(diào)用鏈提取的基礎(chǔ)指標(biāo)（Latency、ErrorCode）觸發(fā)告警。但整體而言，一個具有良好可觀察性的系統(tǒng)必須具備上述三種數(shù)據(jù)。

云原生下的可觀察性

云原生帶來的不僅僅是應(yīng)用部署能夠部署云上而已，其整個的定義是一套新的IT系統(tǒng)架構(gòu)升級，包括開發(fā)模式、系統(tǒng)架構(gòu)、部署模式、基礎(chǔ)設(shè)施全套的演進(jìn)和迭代。

效率要求更高：隨著DevOps模式的普及，規(guī)劃、開發(fā)、測試、交付..的效率要求越來越高，而與之帶來的問題是需要更加實(shí)時的知道此次的發(fā)布是否成功，出現(xiàn)了什么問題，問題在哪里，如何快速去解決。

系統(tǒng)更加復(fù)雜：架構(gòu)從最開始的一體化發(fā)展到分層模式，到現(xiàn)在的微服務(wù)模式，架構(gòu)的升級帶來了開發(fā)效率、發(fā)布效率、系統(tǒng)靈活性、魯棒性等優(yōu)勢，但隨之而來系統(tǒng)的復(fù)雜度將更高，問題的定位將更加難。

環(huán)境動態(tài)性增強(qiáng)：無論是微服務(wù)的架構(gòu)還是容器化的部署模式，帶來的一個特性是環(huán)境的動態(tài)性會增強(qiáng)，每個實(shí)例的生命周期會更短，出現(xiàn)問題后往往現(xiàn)場已經(jīng)被破壞，登錄機(jī)器排查問題的方式已經(jīng)不復(fù)存在。

上下游依賴更多：問題的定位最終都會從上下游來排查，在微服務(wù)、云、K8s的環(huán)境中，上下游將更加多，包括各類其他業(yè)務(wù)應(yīng)用、云上使用的各類產(chǎn)品、各種中間件、K8s自身、容器運(yùn)行時、虛擬機(jī)等等。

拯救者：OpenTelemetry

上述的這些問題相信很多讀者都會深有體會，而業(yè)界也針對這種情況退出了各類可觀察性相關(guān)的產(chǎn)品，包括開源、商業(yè)化的眾多項(xiàng)目。例如：

Metrics：Zabbix、Nagios、Prometheus、InfluxDB、OpenFalcon、OpenCensus

Tracing：Jaeger、Zipkin、SkyWalking、OpenTracing、OpenCensus

Logging：ELK、Splunk、SumoLogic、Loki、Loggly

利用這些項(xiàng)目的組合或多或少可以解決針對性的一類或者幾類問題，但真正應(yīng)用起來你會發(fā)現(xiàn)各種問題：

多套方案交織：可能要使用至少M(fèi)etrics、Logging、Tracing3種方案，維護(hù)代價巨大

數(shù)據(jù)不互通：雖然是同一個業(yè)務(wù)組件，同一個系統(tǒng)，產(chǎn)生的數(shù)據(jù)由于在不同的方案中，數(shù)據(jù)難以互通，無法充分發(fā)揮數(shù)據(jù)價值

廠商綁定：無論從數(shù)據(jù)采集、傳輸、存儲、計(jì)算、可視化、告警等都可能會被廠商綁定，可觀察性系統(tǒng)一旦上線后替換的代價講巨大無比

云原生不友好：這些方案其中很多都是針對傳統(tǒng)系統(tǒng)的，對于云原生的支持相對較弱，而且方案本身部署和使用代價都很高，不符合“云原生”這種一鍵部署、開箱即用的使用方式。

在此背景下，云原生基金會CNCF下誕生了OpenTelemetry項(xiàng)目，旨在將Logging、Tracing、Metrics三者進(jìn)行統(tǒng)一，實(shí)現(xiàn)數(shù)據(jù)的互通互操作。

Create and collect telemetry data from your services and software, then forward them to a variety of analysis tools.

OpenTelemetry最核心的功能是產(chǎn)生、收集可觀察性數(shù)據(jù)，并支持傳輸?shù)礁鞣N的分析軟件中，整體的架構(gòu)如下圖所屬，其中Library用于產(chǎn)生統(tǒng)一格式的可觀察性數(shù)據(jù)；Collector用來接收這些數(shù)據(jù)，并支持把數(shù)據(jù)傳輸?shù)礁鞣N類型的后端系統(tǒng)。

OpenTelemetry給云原生下帶來的革命性的進(jìn)步，包括：

統(tǒng)一協(xié)議：OpenTelemetry為我們帶來了Metric、Tracing、Logging（正在制定中，LogModel已經(jīng)定義完畢）的統(tǒng)一標(biāo)準(zhǔn)，三者都有相同的元數(shù)據(jù)結(jié)構(gòu)，可以輕松實(shí)現(xiàn)互相關(guān)聯(lián)

統(tǒng)一Agent：使用一個Agent即可完成所有可觀察性數(shù)據(jù)的采集和傳輸，不需要為每個系統(tǒng)都部署各種各樣的Agent，大大降低了系統(tǒng)的資源占用，使整體可觀察性系統(tǒng)的架構(gòu)也變的更加簡單

云原生友好：OpenTelemetry誕生在CNCF，對于各類的云原生下的系統(tǒng)支持更加友好，此外目前眾多云廠商已經(jīng)宣布支持OpenTelemetry，未來云上的使用會更加便捷

廠商無關(guān)：此項(xiàng)目完全中立，不傾向于任何一家廠商，讓大家可以有充分的自由來選擇/更換適合自己的服務(wù)提供商，而不需要收到某些廠商的壟斷或者綁定

兼容性：OpenTelemetry得到了CNCF下各種可觀察性方案的支持，未來對于OpenTracing類、OpenCensus、Prometheus、Fluntd等都會有非常好的兼容性，可以方便大家無縫遷移到OpenTelemetry方案上。

OpenTelemetry限制

從上面的分析來看，OpenTelemetry的定位是作為可觀察性的基礎(chǔ)設(shè)施，解決數(shù)據(jù)規(guī)范與獲取的問題，后續(xù)部分依賴各個Vendor來實(shí)現(xiàn)。當(dāng)然最佳的方式是能夠有一個統(tǒng)一的引擎去存儲所有的Metrics、Logging、Tracing，有一個統(tǒng)一的平臺去分析、展示、關(guān)聯(lián)這些數(shù)據(jù)。目前的話還沒有一個廠商能夠非常好的支持OpenTelemetry的統(tǒng)一后端，現(xiàn)在還是需要自己去使用各個廠商的產(chǎn)品來實(shí)現(xiàn)。而這個帶來的另一個問題是各個數(shù)據(jù)的關(guān)聯(lián)會更加復(fù)雜，還需要去解決每個廠商之間的數(shù)據(jù)關(guān)聯(lián)性問題。當(dāng)然這個問題相信在1-2年肯定會解決掉，現(xiàn)在有眾多廠商開始在努力實(shí)現(xiàn)OpenTelemetry所有類型數(shù)據(jù)的統(tǒng)一方案。

可觀察性的未來方向

我們團(tuán)隊(duì)從剛開始09年做飛天5K項(xiàng)目起，就一直在負(fù)責(zé)監(jiān)控、日志、分布式鏈路追蹤等可觀察性相關(guān)的工作，中間經(jīng)歷過小型機(jī)到分布式系統(tǒng)再到微服務(wù)、云化的一些架構(gòu)變更，相關(guān)的可觀察性方案也經(jīng)歷了很多演變。我們覺得整體上可觀察性相關(guān)的發(fā)展和自動駕駛等級的設(shè)定非常吻合。

自動駕駛一共分為6級，其中0-2級主要還是靠人來進(jìn)行決定，到了等級3之后就可以進(jìn)行無意識駕駛，也就是手眼可以暫時性不用關(guān)注駕駛，到了等級5的話人就可以完全脫離駕駛這個枯燥的工作，在車上可以自由活動。

在IT系統(tǒng)的可觀察性上，也可以類似劃分6級：

• 等級0：手工分析，依靠基礎(chǔ)的Dashboard、告警、日志查詢、分布式鏈路追蹤等方式進(jìn)行手動告警、分析，也是目前絕大部分公司使用的場景
• 等級1：智能告警，能夠自動去掃描所有的可觀察性數(shù)據(jù)，利用機(jī)器學(xué)習(xí)的方式去識別一些異常并進(jìn)行自動告警，免去人工設(shè)置/調(diào)整各種基線告警的工作
• 等級2：異常關(guān)聯(lián)+統(tǒng)一視圖，對于自動識別的異常，能夠進(jìn)行上下文的關(guān)聯(lián)，形成一個統(tǒng)一的業(yè)務(wù)視圖，便于快速的定位問題
• 等級3：根因分析+問題自愈，自動根據(jù)異常以及系統(tǒng)的CMDB信息直接定位問題的根因，根因定位準(zhǔn)確后那邊可以去做問題的自愈。這一階段相當(dāng)于是一次質(zhì)的飛躍，在某些場景下可以在人不用參與的情況下實(shí)現(xiàn)問題的自愈。
• 等級4：故障預(yù)測，故障發(fā)生總會有損失，所以最好的情況是避免故障的發(fā)生，因此故障預(yù)測技術(shù)可以更好的來保證系統(tǒng)的可靠性，利用之前積累的一些故障先兆信息做到“未卜先知”
• 等級5：變更影響預(yù)測，我們知道絕大部分的故障都是由變更引起的，因此如果能夠模擬出每個變更對系統(tǒng)帶來的影響以及可能產(chǎn)生的問題，我們就能夠提前評估出是否能夠允許此次變更。

阿里云SLS在可觀察性相關(guān)的工作

目前我們SLS正在開展云原生可觀察性的工作，基于OpenTelemetry這個未來云原生下可觀察性的標(biāo)準(zhǔn)，實(shí)現(xiàn)各類可觀察性數(shù)據(jù)的統(tǒng)一收集，覆蓋各個數(shù)據(jù)源和各類數(shù)據(jù)類型，做到多語言支持、多設(shè)備支持、類型統(tǒng)一；向上我們會提供能夠支持各類可觀察性數(shù)據(jù)的統(tǒng)一存儲和計(jì)算能力，支持PB級存儲、ETL、流計(jì)算、百億級數(shù)據(jù)秒級分析，為上層算法提供強(qiáng)大的算力支撐；IT系統(tǒng)的問題非常復(fù)雜，尤其涉及到不同的場景和架構(gòu)，因此我們把算法和經(jīng)驗(yàn)結(jié)合起來進(jìn)行異常的分析，算法包括基礎(chǔ)的統(tǒng)計(jì)學(xué)、邏輯性算法，也包括AIOp相關(guān)的算法，經(jīng)驗(yàn)中包括人工輸入的專家知識、網(wǎng)上上積累的各類問題解決方案以及外部產(chǎn)生的一些事件；最上層我們會提供一些輔助決策的功能，例如告警通知、數(shù)據(jù)可視化、Webhook等，此外會提供豐富的外部集成能力，例如對接三方的可視化/分析/告警系統(tǒng)，提供OpenAPI以便不同的應(yīng)用方集成。

總結(jié)

作為CNCF下除了Kubernetes外最活躍的項(xiàng)目，OpenTelemetry受到了各大云廠商以及相關(guān)解決方案公司的關(guān)注，相信未來一定會成為云原生下可觀察性的標(biāo)準(zhǔn)。雖然目前還沒有到生產(chǎn)可用的程度，但是目前各個語言的SDK和Collector也基本上穩(wěn)定，在2021年就能夠發(fā)布生產(chǎn)可用的版本，值得大家期待。

而OpenTelemetry只是定義了可觀察的前半部分，后面還有非常多的復(fù)雜工作需要我們?nèi)?shí)現(xiàn)，任重道遠(yuǎn)。

重點(diǎn)來了！！！！SLS團(tuán)隊(duì)長期招聘人才，歡迎對大數(shù)據(jù)、監(jiān)控、可觀察性、前端可視化、移動端開發(fā)、機(jī)器學(xué)習(xí)等有興趣的同學(xué)前來聯(lián)系我:

• 郵箱： davidzhang.zc@alibaba-inc.com
• 微信： davidzhang-zc。
• 職位： https://cloudnative.to/job/aliyun-sls-observability/
• https://mp.weixin.qq.com/s/pTeVHMeBThKO4C7wLt-oHQ

參考：

https://opentelemetry.io/

https://developer.aliyun.com/article/766070

https://aiopsworkshop.github.io/

https://landscape.cncf.io/

https://www.instana.com/blog/observability-vs-monitoring/

原文鏈接：https://developer.aliyun.com/article/780609?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。 與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的解读云原生下的可观察性发展方向的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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