云原生可觀測(cè)建設(shè)要點(diǎn)與案例分析

點(diǎn)擊上方“服務(wù)端思維”，選擇“設(shè)為星標(biāo)”

回復(fù)”669“獲取獨(dú)家整理的精選資料集

回復(fù)”加群“加入全國(guó)服務(wù)端高端社群「后端圈」

這幾年大家會(huì)發(fā)現(xiàn)業(yè)界內(nèi)頻繁地提到可觀測(cè)，也有很多人會(huì)問可觀測(cè)跟之前傳統(tǒng)的監(jiān)測(cè)到底有什么區(qū)別？可觀測(cè)并不是一個(gè)新的概念，它其實(shí)是傳統(tǒng)監(jiān)測(cè)的擴(kuò)展。傳統(tǒng)監(jiān)測(cè)領(lǐng)域更多是基于外部的視角去看一個(gè)系統(tǒng)，去看一些系統(tǒng)的行為，從而規(guī)劃整個(gè)系統(tǒng)的失敗模型，它更多的是從運(yùn)維的視角來看。今天，我們把這個(gè)概念從監(jiān)測(cè)擴(kuò)展到可觀測(cè)，其實(shí)更多是從系統(tǒng)內(nèi)部的白盒化思路去看系統(tǒng)內(nèi)部的運(yùn)行狀況，是由內(nèi)往外的，同時(shí)結(jié)合多種觀測(cè)手段，包括我們傳統(tǒng)說的 Metrics 指標(biāo)，從而做一個(gè)非常深入的分析，了解整個(gè)系統(tǒng)運(yùn)行狀態(tài)的根因。

另外從使用者角度來講，傳統(tǒng)監(jiān)測(cè)更多是從運(yùn)維角度，一些傳統(tǒng)的 Metric 維度指標(biāo)，從外部進(jìn)行觀測(cè)來得知里面發(fā)生了什么。云原生可觀測(cè)貫穿了整個(gè)應(yīng)用，甚至整個(gè)應(yīng)用開發(fā)的生命周期，包括開發(fā)、測(cè)試、上線、部署、發(fā)布。所有的生命周期不僅會(huì)通過 Metrics，還會(huì)有系統(tǒng)日志、業(yè)務(wù)日志、鏈路追蹤等方式來進(jìn)行整個(gè)全方位 360 度無死角的監(jiān)測(cè)。換句話說，更多是從內(nèi)往外來診斷出系統(tǒng)內(nèi)部產(chǎn)生問題的根因，究竟出現(xiàn)了什么樣的問題，發(fā)生的原因，以及一些對(duì)應(yīng)的恢復(fù)手段，這些是我們整個(gè)可觀測(cè)核心關(guān)注的點(diǎn)。

隨著容器、微服務(wù)逐漸流行起來，我們進(jìn)入到了云原生時(shí)代。傳統(tǒng)企業(yè)要做云原生轉(zhuǎn)型，對(duì)整個(gè)監(jiān)測(cè)以及穩(wěn)定性方面提出了更高的要求：

第一，支撐業(yè)務(wù)快速迭代。舉個(gè)例子，阿里巴巴內(nèi)部有將近 8000 到 9000 個(gè)應(yīng)用，每天會(huì)做將近 4000 次的應(yīng)用發(fā)布，這樣頻繁快速的迭代，對(duì)系統(tǒng)的穩(wěn)定性、可觀測(cè)、運(yùn)維等方面提出了極高的要求，要求通過各種手段完成穩(wěn)健的支撐。

第二，復(fù)雜的調(diào)用拓?fù)洹?/strong>隨著整個(gè)微服務(wù)化的興起，傳統(tǒng)的大型單體應(yīng)用在微服務(wù)化之后，帶來非常好的彈性、便捷的服務(wù)，但同時(shí)也導(dǎo)致整個(gè)應(yīng)用的鏈路會(huì)變得非常復(fù)雜。今天如果按照傳統(tǒng)的方式來做的話，我們可能只需要依賴于一些專家的經(jīng)驗(yàn)去看個(gè)別問題，這本質(zhì)上是一個(gè)瓶頸類型的問題。

第三，極致的用戶體驗(yàn)。今天企業(yè)擁抱云原生時(shí)代，對(duì)數(shù)字化轉(zhuǎn)型有強(qiáng)烈的訴求，需要一個(gè)更極致的 IT 方面的體驗(yàn)。比如說故障響應(yīng)必須要更快，一個(gè)問題從發(fā)現(xiàn)到恢復(fù)也希望更快，處理的時(shí)間更要加快，這是一個(gè)挑戰(zhàn)。

最后，高效的運(yùn)維協(xié)同。通過傳統(tǒng)的工單方式有時(shí)候的效率會(huì)偏低，如何解決組織協(xié)同的問題，這也是我們關(guān)注的一個(gè)方向。

云原生可觀測(cè)重點(diǎn)包括以下幾個(gè)場(chǎng)景：

1、應(yīng)用發(fā)布部署。在特定的場(chǎng)景下我們需要能支撐非常場(chǎng)景化的監(jiān)測(cè)和觀測(cè)能力。

2、全景監(jiān)測(cè)。這個(gè)很好理解，因?yàn)榻裉鞜o論從應(yīng)用的前端，從用戶側(cè)到應(yīng)用側(cè)，再到中間件，還是再到底層的 IaaS、基礎(chǔ)設(shè)施層，從端到端，這其中所有的鏈路都需要納入到企業(yè)的監(jiān)測(cè)體系中做一個(gè)全景監(jiān)測(cè)，這是企業(yè)應(yīng)該致力于做的事。

3、智能告警。如今僅是把所有的觀測(cè)做好了是遠(yuǎn)遠(yuǎn)不夠的，我們需要引入一些更高級(jí)的玩法。阿里內(nèi)部這么多年將一些人工智能技術(shù)引入到我們的觀測(cè)領(lǐng)域來，是為了能夠幫助減輕整個(gè)運(yùn)維的負(fù)擔(dān)，這也是后面會(huì)詳細(xì)分享的部分。

4、性能診斷。在發(fā)現(xiàn)問題或者說在性能壓測(cè)的時(shí)候，如何快速地診斷到問題，可以依賴一些工具發(fā)現(xiàn)問題的調(diào)用鏈，以及一些專家經(jīng)驗(yàn)級(jí)的實(shí)踐，這是我們?cè)谛阅茉\斷方面需要加強(qiáng)的。所有的這些場(chǎng)景都包含了整個(gè)應(yīng)用的生命周期。同時(shí)我們也要支持各種各樣的云環(huán)境，包括公有云、專有云、混合云的體系，這些是云原生的核心場(chǎng)景。

接下來分享一下我們通過最佳實(shí)踐，總結(jié)云原生可觀測(cè)的幾個(gè)要點(diǎn)。核心要點(diǎn)有三個(gè)：1. 我們的數(shù)據(jù)從哪里來。2. 我們?nèi)绾谓⑦@方面的可觀測(cè)數(shù)據(jù)模型。3. 我們?nèi)绾斡煤眠@些數(shù)據(jù)模型、如何分析。

今天的整個(gè)可觀測(cè)體系已經(jīng)非常豐富了。我們要把所有的端到端，包括上層的業(yè)務(wù)到應(yīng)用程序，再到分布式系統(tǒng)、中間件、底層基礎(chǔ)設(shè)施，所有這些都納入到可觀測(cè)體系中，核心是阿里云的各種監(jiān)測(cè)產(chǎn)品，包括云監(jiān)測(cè) & Prometheus、ARMS、SLS 等。這些產(chǎn)品的組合能夠幫助用戶把所有的可觀測(cè)點(diǎn)都納入到整個(gè)體系中來，包括各種維度的 Metrics、各種維度的指標(biāo)、各種維度的 Trace，包括開源的兼容、自建的鏈路追蹤，以及業(yè)務(wù)日志、系統(tǒng)日志、組件日志，所有維度都可以納入到可觀測(cè)里來。這是第一步，主要解決可觀測(cè)的數(shù)據(jù)從哪里來、做得是否全面的問題。

拿到數(shù)據(jù)之后怎么建模？考慮到傳統(tǒng)企業(yè)的運(yùn)維，可能更需要統(tǒng)一的監(jiān)測(cè)視圖，比如更需要做 2D 或者 3D 的展示，我今天給大家做了一個(gè)展示。

首先最底層就是 IaaS，包括一些容器、虛機(jī)。另外一層就是上面的應(yīng)用，這里面也包括微服務(wù)應(yīng)用和組件，分布式數(shù)據(jù)庫(kù)、分布式消息，以及緩存等。再往上一層就是整個(gè)的應(yīng)用服務(wù)，每一步其實(shí)都是可以做下鉆的，看某一個(gè)問題節(jié)點(diǎn)時(shí)，可以算到非常詳細(xì)的地方。

另外，在容器場(chǎng)景下，因?yàn)榻裉斓娜萜魇亲鳛檎麄€(gè)基礎(chǔ)設(shè)施的標(biāo)準(zhǔn)，大家可以依托于整個(gè)監(jiān)測(cè)體系快速搭建針對(duì)滿足自己需求的平臺(tái)。我們監(jiān)測(cè)關(guān)鍵的核心數(shù)據(jù)組件，包括應(yīng)用狀態(tài)、RT、CPU 響應(yīng)、消息等。另外就是緩存的狀態(tài)，也可以做一個(gè)展示，包括 RDS 分布式數(shù)據(jù)庫(kù)、管理型數(shù)據(jù)庫(kù)、MQ、核心數(shù)據(jù)庫(kù)等。我們也有非常多的數(shù)據(jù)庫(kù)診斷手段，包括ES檢索數(shù)據(jù)庫(kù)、MQ 消息，整個(gè)都是構(gòu)成針對(duì)運(yùn)維人員的統(tǒng)一監(jiān)測(cè)大盤，可以方便快速的自定義搭建。

最后，白屏化的集成定位。我們監(jiān)測(cè)到數(shù)據(jù)之后，接下來就是問題定位。今天不僅是在阿里內(nèi)部，我們對(duì)外提供的一些產(chǎn)品，其實(shí)已經(jīng)能夠?qū)崿F(xiàn)快速白屏化的定位，就是說今天你不需要再翻你的代碼、再去登錄機(jī)器看日志了，所有的問題都可以通過全鏈路展示的方式，定位到整個(gè)鏈路的根節(jié)點(diǎn)。包括我們關(guān)心的一些內(nèi)存、CPU、JVM 參數(shù)、線程參數(shù)，都可以通過白屏化的方式展現(xiàn)給大家，這是我們對(duì)可觀測(cè)系統(tǒng)做了非常高度的集成。

介紹了數(shù)據(jù)模型怎么建、怎么收集之后，還是遠(yuǎn)遠(yuǎn)不夠的。今天我們是需要對(duì)可觀測(cè)數(shù)據(jù)做一個(gè)深度挖掘，主要分為兩個(gè)方面：

一是采用人工智能技術(shù)。但我們發(fā)現(xiàn)單純采用人工智能技術(shù)來做，有時(shí)候是不起作用的，同時(shí)也需要一些專家經(jīng)驗(yàn)指導(dǎo)，我們需要把整個(gè)專家經(jīng)驗(yàn)沉淀下來。目前業(yè)界做故障診斷主流的方法是從算法的角度給出一些基線發(fā)現(xiàn)問題，但是針對(duì)問題根因的診斷還是源于排查人員的技能。今天我們要找到的不僅僅是異常結(jié)果，還需要把整個(gè)端到端到問題的根因分析，以及相應(yīng)的關(guān)鍵信息都展現(xiàn)出來。這里面依賴兩點(diǎn)：一是人的技能問題，二是機(jī)器的算法問題。

首先是人的技能問題。我們的專家經(jīng)驗(yàn)是能夠在一定程度上幫助大家去解決問題的，但是怎么把這個(gè)東西給沉淀下來，這是一個(gè)問題。另外在機(jī)器方面，我們采用確定性的人工智能算法，能夠通過對(duì)指標(biāo)的檢測(cè)從而解決問題。

今天我們的思路是把這兩項(xiàng)相結(jié)合，在人工智能這種算法應(yīng)用的基礎(chǔ)上，再通過專家經(jīng)驗(yàn)的沉淀來做指導(dǎo)。因?yàn)槲覀冊(cè)趯?shí)戰(zhàn)過程中發(fā)現(xiàn)，如果僅僅依賴于人工智能的話，其實(shí)人工智能在有些場(chǎng)景下就變成了人工智障，所以必須依靠專家經(jīng)驗(yàn)的沉淀來指導(dǎo)這個(gè)算法。

所以為了達(dá)到兩者的結(jié)合，在專家經(jīng)驗(yàn)方面，阿里云將其沉淀在產(chǎn)品中。阿里云可觀測(cè)產(chǎn)品 ARMS 覆蓋了 50 多個(gè)故障場(chǎng)景，包括應(yīng)用的變更、RT的突增、突發(fā)的大請(qǐng)求、單機(jī)的問題、MySQL 等，都會(huì)把相應(yīng)的經(jīng)驗(yàn)固定下來幫助大家快速自動(dòng)診斷這部分問題場(chǎng)景，這是我們通過大量的實(shí)踐，把專家經(jīng)驗(yàn)通過白屏化的方式沉淀下來，自動(dòng)化的展示給大家。

這里面必不可少的是我們要做可觀測(cè)的日常預(yù)測(cè)監(jiān)測(cè)，這也是集團(tuán)內(nèi)用的非常多的。阿里內(nèi)部做異常檢測(cè)主要是三個(gè)方面，一個(gè)是服務(wù)器層面，將服務(wù)器故障的特征訓(xùn)練出來。另外是集群層面的一些異常指標(biāo)、特征給訓(xùn)練出來。最后是應(yīng)用層面，面向應(yīng)用和日志的，我們通過一些 API 出口的異常模型把它訓(xùn)練出來。

首先是監(jiān)測(cè)數(shù)據(jù)，包括多指標(biāo)的監(jiān)測(cè)數(shù)據(jù)收集上來之后，通過做一方面的預(yù)處理，把一些無關(guān)的指標(biāo)去除，或者說一些相關(guān)的指標(biāo)去重。這里面我們也用到了創(chuàng)新的方法，采用了標(biāo)準(zhǔn)化的模型方式，把正常跟異常的差異納入到某一個(gè)區(qū)間內(nèi)進(jìn)行分析。做完這些預(yù)處理之后，就要建立特征工程，今天我們也是把單指標(biāo)異常的分?jǐn)?shù)作為異常特征方式，這塊我們做得比較多，核心是把整個(gè)異常特征以及時(shí)序特征的準(zhǔn)確率提得更高。特征做完之后就是多指標(biāo)方式，阿里采用時(shí)序預(yù)測(cè)的方式，多指標(biāo)模型建立的更準(zhǔn)確。同時(shí)，模型建立完之后，上線運(yùn)行的過程中，我們會(huì)不斷反饋，對(duì)整個(gè)訓(xùn)練出來的模型進(jìn)行不斷地修正，形成一個(gè)閉環(huán)的正反饋。這就是可觀測(cè)產(chǎn)品基于日常檢測(cè)的基本的框架。近期阿里云會(huì)慢慢將這部分開放出來給大家用，大家可以關(guān)注一下。

場(chǎng)景一，容器場(chǎng)景下的全景可觀測(cè)能力。今天容器已經(jīng)成為 IaaS 層的標(biāo)準(zhǔn)，整個(gè)容器場(chǎng)景下的可觀測(cè)能力，包括全鏈路端到端多樣的數(shù)據(jù)接入能力，包括 APM 廠商、Prometheus、主動(dòng)撥測(cè)、流量監(jiān)測(cè)、網(wǎng)絡(luò)監(jiān)測(cè)等，全部納入到容器場(chǎng)景下的可觀測(cè)能力。另外就是全方位數(shù)據(jù)可視，我們會(huì)把數(shù)據(jù)的可觀測(cè)建模呈現(xiàn)得非常通俗易懂，對(duì)于運(yùn)維人員和客戶以非常友好的方式展現(xiàn)出來，而且每一層都可以 2D、3D 拓?fù)淙罢故?，每一層都可以層層下鉆，幫助分析根因。還有一個(gè)特點(diǎn)是快速發(fā)現(xiàn)問題，通過專家和白屏化的診斷手段，所有的問題都可以層層下鉆，直到找到最底層的相關(guān)信息，幫助大家解決問題。

場(chǎng)景二：復(fù)雜鏈路的智能診斷。主要依托于兩點(diǎn)。第一是專家經(jīng)驗(yàn)，我們沉淀下來將近 50 多個(gè)場(chǎng)景的專家經(jīng)驗(yàn)做白屏化的根因分析。第二是確定化的人工智能技術(shù)進(jìn)行一些問題的異常預(yù)測(cè)和檢測(cè)等等，包括整個(gè)阿里云可觀測(cè)的體系，把整個(gè)阿里云的核心云產(chǎn)品，包括 ECS、EDAS、AHAS、MSE，能夠跟所有產(chǎn)品之間做一個(gè)深度對(duì)接，之后再注入一些組建的自恢復(fù)能力，這樣能生成一個(gè)自動(dòng)化的問題發(fā)現(xiàn)、自動(dòng)化診斷、自動(dòng)化恢復(fù)。

場(chǎng)景三：對(duì)人工智能技術(shù)在異常檢測(cè)場(chǎng)景下的最佳實(shí)踐。主要是兩個(gè)場(chǎng)景：

一個(gè)是比較常見的運(yùn)行時(shí)的異常檢測(cè)。阿里巴巴內(nèi)部有將近 8000 到 1萬 個(gè)應(yīng)用，我們的監(jiān)測(cè)頻度比較高，都是分鐘以內(nèi)，這樣的話幾乎每時(shí)每刻都有上百萬個(gè)指標(biāo)要進(jìn)行監(jiān)測(cè)，這個(gè)量非常大。如果依賴于運(yùn)維人員做這個(gè)事顯然是不現(xiàn)實(shí)的，所以說我們采用異常檢測(cè)算法平臺(tái)，主要思路是基于 STL 時(shí)序分解的基線預(yù)測(cè)，再加上基于上下邊界的預(yù)估。

基線方法我們內(nèi)部有幾個(gè)最佳實(shí)踐第一個(gè)是我們采用的 STL 的時(shí)序數(shù)據(jù)的預(yù)測(cè)分解，另外一個(gè)是基于 ARIMA 框架的拓展 ARIMA-PRO，對(duì)周期性的序列做到更好的預(yù)測(cè)，并且能夠自動(dòng)的去更新我們的 ARIMA 框架參數(shù)，包括 DBQ 參數(shù)，就是差分、AR 參數(shù)，這些核心的人工智能參數(shù)我們是能夠做到自閉環(huán)。

另外一個(gè)是基于 Holt-winters 時(shí)續(xù)預(yù)測(cè)的模型，進(jìn)行殘差值的預(yù)測(cè)。另外上下文預(yù)估方案，我們是采用 IQR+歷史同筆的先驗(yàn)方案的做的，這是我們內(nèi)部比較好的實(shí)踐。這是剛才說的簡(jiǎn)單的運(yùn)行時(shí)的檢測(cè)算法框架，核心是幾個(gè)創(chuàng)新點(diǎn)，一個(gè)是 ARIMA-PRO，可以做到關(guān)鍵參數(shù)自動(dòng)更新的框架的增強(qiáng)。

還有一個(gè)是基于 STL 以及 IQR 殘差值的檢測(cè)，并且基于 IQR 上下文邊界的劃分，是算法平臺(tái)里面比較核心的幾個(gè)技術(shù)點(diǎn)。比如說基于 RMSE 均衡分布差的統(tǒng)計(jì)方式，能夠從之前的 0.74 下降到 0.59，誤差下降了 20 個(gè)百分點(diǎn)。在 2019年這個(gè)算法框架成功預(yù)測(cè)了某一次因?yàn)橥丝钕碌l(fā)的故障，取得了不錯(cuò)的效果。

另一個(gè)是應(yīng)用發(fā)布時(shí)異常檢測(cè)。很多故障都是新版本上線的時(shí)候，所以我們針對(duì)應(yīng)用發(fā)布也做了非常多的算法，尤其在阿里，前面也說了我們 8000個(gè) 應(yīng)用，每天可能有 4000次 的應(yīng)用發(fā)布，內(nèi)部應(yīng)用迭代非?？臁Ｈ绻且揽總鹘y(tǒng)的設(shè)置固定的閾值監(jiān)測(cè)的話不夠靈活，拓展性比較差，而且需要人工去不斷地更新。效率是非常低下的。

今天我們?cè)诎l(fā)布時(shí)實(shí)現(xiàn)的框架，核心是實(shí)現(xiàn)了我們算法模型自適應(yīng)的閉環(huán)。我們整個(gè)線上的模型以及事例，通過篩選誤報(bào)和微檢測(cè)的異常來更新正負(fù)樣本，在我們的大數(shù)據(jù)平臺(tái)更新訓(xùn)練集、重新更新模型。同時(shí)基于 SBD，是能夠針對(duì)偏移后的序列相關(guān)性進(jìn)行很好的序列分析算法，把整個(gè)訓(xùn)練閉環(huán)做得非常好。這是當(dāng)時(shí)做發(fā)布時(shí)的異常檢測(cè)算法框架的比較核心的創(chuàng)新點(diǎn)。整個(gè)算法框架上線之后，內(nèi)部單個(gè)維度的監(jiān)測(cè)效果有了 3 到 5 倍的提升。另外從整體監(jiān)測(cè)維度，提升了大概將近 5 到 10個(gè) 百分點(diǎn)，整個(gè)效果還是比較明顯的。

本文主要介紹了運(yùn)行時(shí)和上線發(fā)布時(shí)的監(jiān)測(cè)案例，其實(shí)還有很多其他的，比如說日常出現(xiàn)異常情況的監(jiān)測(cè)，也是業(yè)內(nèi)比較典型的例子，其他還有一些包括業(yè)務(wù)指標(biāo)的異常檢測(cè)等。我們已經(jīng)把一些人工智能技術(shù)以及專家的經(jīng)驗(yàn)沉淀到云原生產(chǎn)品上，除了在我們內(nèi)部使用之外，正在慢慢地開放到外部的云產(chǎn)品上，歡迎大家去使用。

— 本文結(jié)束 —

● 漫談設(shè)計(jì)模式在 Spring 框架中的良好實(shí)踐

● 顛覆微服務(wù)認(rèn)知：深入思考微服務(wù)的七個(gè)主流觀點(diǎn)

● 人人都是 API 設(shè)計(jì)者

● 一文講透微服務(wù)下如何保證事務(wù)的一致性

● 要黑盒測(cè)試微服務(wù)內(nèi)部服務(wù)間調(diào)用，我該如何實(shí)現(xiàn)？

關(guān)注我，回復(fù) 「加群」 加入各種主題討論群。

對(duì)「服務(wù)端思維」有期待，請(qǐng)?jiān)谖哪c(diǎn)個(gè)在看

喜歡這篇文章，歡迎轉(zhuǎn)發(fā)、分享朋友圈

在看點(diǎn)這里