阿里巴巴智能監控新場景的探索

摘要: 智能監控是智能運維的子領域,詳細分析。算法

做者簡介數據庫

王肇剛
阿里巴巴全球運行指揮中心高級技術專家服務器

智能監控是智能運維的子領域,咱們說的監控,探討的更可能是在監控策略,由於可能從數據採集、日誌收集、包括計算等等產生數據,再設定一些判斷的規則和策略,發送報警,這些都屬於監控。網絡

我和個人團隊在阿里內部的分工是橫向去看阿里巴巴業務指標的監控,咱們就以這個話題展開。架構

分享分爲五個環節,從阿里巴巴不一樣的業態,特別是新的業態帶來的挑戰講起。對於咱們以前已有的基於機器學習算法這樣一個算法工程架構,咱們作了哪些加強應對這些挑戰。框架

咱們的監控也從單一指標監控延展到多個指標一塊兒監控。監控完了以後,咱們可能要分析定位,這時系統又能幫運維工程師作什麼,這是第四方面的話題。最後是對智能運維整個領域作一些展望。運維

1、新業態給業務監控帶來的挑戰機器學習

上圖是阿里巴巴不一樣的業態,有比較傳統的電商業態,右上角是國際電商,螞蟻金服還有阿里雲。最近這段時間阿里在收購各類各樣的公司,也是商業的佈局,咱們會看到優酷、釘釘等等。佈局

咱們團隊在阿里巴巴內部是負責橫向的業務指標監控,這個有什麼差別?學習

技術層面也是經過日誌的採集流程計算看一個指標下跌仍是上漲,區別在於只要業務發生了不可用或者發生問題,咱們但願都可以發現,而不是說阿里巴巴自己的系統出問題了。

舉個例子,若是阿里巴巴一點異常都沒有,可是電信可能有問題,這個時候咱們但願知道。

它是從對於業務數據量實時的監控。由於阿里巴巴自己的業態是很豐富的,有這麼多的業態,咱們看到的數據也很豐富。

上邊這個圖,你們可能看到的這些 Logo,看到購物或雲計算的一些業務,可是團隊作智能運維算法的同窗,看到的就是右邊這種奇形怪狀的曲線。

咱們團隊在阿里內部是橫向團隊,第一環節就是須要可以精確、及時的發現業務是否有異常。

爲了達到這個目標,咱們引入了稱之爲智能基線的系統,這個系統能夠在網上搜索到。

這個系統效果仍是不錯的,可以在沒有任何閾值或者規則輸入的狀況下,自覺作預測。同時有些業務發展比較迅速,咱們能夠比較好地在歷史的長期趨勢和短時間的業務溝通之間,作出一個相對較優的折中。

業務變化以後,假設你之前配了閾值還要改,智能基線不須要改。阿里巴巴幾千項業務指標,經過人工的檢查驗收以後的準確率是在80%以上,這個數字每週都不同。

而對比傳統的工程師經過傳統的靜態分段閾值或者環比的方式,準確率可能只有 40% 左右。

你們可能也會看到特別對於業務量監控,可能 10 條報警裏面,4 條真的以爲有問題已經不容易了。

阿里有不少不一樣的業態,因此一套系統解決全部問題仍是挺難的,由於不一樣業態之間的差別仍是很是大,數量級、波動、週期均有差別,包括如今有新零售業務,它是把線上線下的業務結合起來,並且很是強調線下。

好比盒馬鮮生有幾百家門店,這是個商業的嘗試,對於作運維監控的同窗也帶來不少挑戰。

好比淘寶和天貓的某些交易量在分鐘級別是萬或十萬或更高的數量級,這個可能就是百或幾百,波動的量級和原始量級在一個量級上,這個就比較難處理。

包括週期性,對於通常的在線服務,是7X24小時提供服務,天天什麼時間流量最低?國內業務凌晨四點鐘最低,這個會受門店的開關門影響,由於零售是有時間的。

咱們若是線上刷淘寶下單點一下就行,線下不同,一對一排隊結帳。並且在量小的狀況下,不少時候不能看單一指標,許多指標要一塊兒看,因此就給咱們以前的算法提出很是大的挑戰,咱們須要作新的算法演進。

你們可能會問爲何整這麼複雜的算法。配監控,配規則不就能夠了嗎?

實際上是能夠的,但業務太複雜。做爲一個橫向團隊,算法工程師可能只有三四人,七八我的要面對阿里巴巴集團成千上萬的業務監控指標,不可能瞭解每一個指標的全部細節,這個時候是沒有辦法用人,咱們要用機器學習的方法去作。

2、加強版的時間序列異常檢測實戰

接下來說講怎麼用機器算法解決問題,這是一年半之前咱們採起的架構,咱們能從業界不少文章上看到相似的架構。

咱們但願作一個基線擬合,這個曲線應該是什麼樣,咱們說異常這兩個字就是異於日常。

咱們第一步想知道正常的曲線是什麼樣子,因此咱們作基線擬合,咱們用STL作這樣的方法,咱們用比較傳統的 N-sigma 作調整。這種架構其實能解決 60% 左右的問題,可是有些極端的狀況解決不了,因此咱們就把架構作了演進。

咱們第二代的架構作數據預處理,而後又作了比較簡單的滑動平均,數據有時候會缺點,無論是採集側的一些不穩定因素,仍是計算一側出現了問題,致使你但願一分鐘出一個數據點,可是最後尚未算出來。

這種狀況應該從工程上解決,因此咱們會在算法層面作一些腦部的算法策略,就是即便缺了能補回來,可是不能長時間缺數據。

下面的邏輯就走了機器學習的思路,咱們對曲線作特徵工程。咱們以前的基線擬合的這種預測只是咱們特徵工程中一部分,對於重要的部分,咱們也會把一些統計特徵編碼進去,固然也會把一些時間特徵編碼進去。

由於咱們知道不少電商的業務是有按期促銷的習慣,好比淘寶的交易量天天早晨十點必定會有階峯,你們不知道在搶什麼東西。

算法層面怎麼解決?咱們把天天的這個時刻第幾小時第幾分鐘,經過熱度編碼的方式作到裏面去,就可讓算法學到這個時間點這樣一下多是正常的。

咱們後面採起了不一樣類型的統計學的判斷和作法,最後作成集成策略,你們能夠理解爲簡單的投票策略。

它其實給咱們帶來了比較好的一些算法的效果,好比說基線擬合會更準,對於不一樣類型的異常進行斷定。不少時候曲線有不同的異常,若是用 N-sigma 的方式,你的刻畫表現能力是不夠的。

即便是這樣,對於遇到的新零售業態,咱們以爲仍是不夠。由於你看剛纔的算法能解決通常性的問題,可是對於曲線問題差別很大的時候,以前的預處理就須要加強,量級從十萬左右到幾百萬,你的預處理策略須要變化。不少曲線不具有周期性,或者週期性很是零亂。

好比咱們有一個業務比較奇怪,你們在淘寶上有沒有充話費?這個是天、周、月三重週期,天的話基本沒有問題,周的話工做日和週末是有差別的,月這個週期,由於大部分人是在月末報警了或者月初充。

最後一個線下的業務對這種異常很敏感,在這種狀況下咱們用一套算法策略是解決不了不一樣問題的,因此咱們作了第三次優化。咱們先引入了一層算法路由,但願可以經過機器學習的方式,把不一樣的曲線歸到不一樣的算法路由裏面去,這樣的話不一樣的曲線走不一樣的處理路徑,那麼效果會很好。

我舉三個例子,比較週期性、非週期性、百分比的指標等等,這些不一樣類型的指標方法都不同。在這些不一樣的方法以後,咱們仍是以爲算法也許解決不了全部的問題,由於算法對於大多數運維工程師來說,不見得那麼方便去調參數,因此咱們也開放了三個參數,咱們會看它不一樣的抑制時間、發佈策略和敏感度。

分開來看,算法路由,這個工做的目的就是說讓算法自動把數據分類,這一塊也不必定非得用算法,用人就能夠,可是由於量太大,因此人工的成本很高。

這裏咱們用了深度學習的算法,上面那個圖是網絡的圖,咱們使用了孿生網絡,兩邊都是LSTM,因此咱們用了雙向的網絡結構去把咱們標記爲同樣和不同的,最終可以區分開。

在這個基礎上,咱們作了一個分類模型。這塊從技術層面來說,不用特別複雜的算法,咱們用這個算法就是想探索一下,實際你們真正作的好的話,好比你用通常的分類方法,用咱們最直接方法也能夠達到相似的效果,可是咱們這裏嘗試了一下。

分好以後有個工程架構,之前是說不一樣的算法場景走的處理邏輯都是同樣的,裏面的參數能夠不同,後面不一樣的處理邏輯像插件同樣能夠去作組合,這個組合的變化頻度不會太快,可是通常變化成本都很低。

這樣之前是三條通路,我把插件的參數和順序和有沒有插件作一個變化。有了這個以後,對於阿里巴巴成千上萬條,但都是到萬這個級別,不會再多。

你們會想這個東西多是從業務角度監控的,從慣性思惟來看,咱們可能會是想監控 CPU 或者某個接口調用的超時,這些也是能夠的。

咱們也探索了在系統級指標或者非應用級指標作這個嘗試。它的週期性不太明顯,第二個這個指標的變化跟業務行爲關係不那麼大,運維的決策對它的曲線影響大於業務的影響。最後一個就是標準不統一,你以爲這個可能須要報警,別人可能以爲不須要報警。

咱們採起了一種輕量級的方式去作檢測,能夠作到自動學習。

它跟上面那套算法相比在於它比較輕,能夠作成一個包的形式,嵌到監控系統中去作監測。它的效果如上圖右邊顯示,咱們內存中有奇形怪狀的異常,這個算法邏輯仍是比較簡單的,不用太在乎算法自己的框架,由於這些算法你能夠替換成其餘的算法,但可能須要考慮在數據進來以前作比較好的預處理。

第二個可能你須要基於統計特徵和那些曲線自己的特徵,影響你的特徵工程。最後孤立森林不是說基於用戶的標註去作的,由於實際場景中咱們不可能像作人臉識別這樣給咱們標註。

什麼參數微調?第一個是說抑制報警的時間,這個很容易理解。第二個防抖動策略,這個也很容易理解,就跟過去 N 分鐘有 N 條報警是同樣的,因此咱們歸納成N/M。

最後一個是報警靈敏度。這個在咱們市場環境中測試的效果大於70%,如今這個數字可能稍微好一些。

最終怎麼評價算法?仍是要看人標的。好比說咱們有十幾位同窗評判,他們的標準也不統一。甚至一我的今天說這個點標的對,次日忘了再看一遍就說標的不對。

因此說以上是咱們介紹的關於單個指標,無論是系統級的仍是業務級的指標,怎麼經過機器學習的方法,作不用任何監控閾值配置和維護成本的智能監控。

3、多指標關聯分析的探索

剛纔也提到了在新業態下,不少時候咱們只看一個指標是沒有辦法斷定業務有沒有異常,或者咱們發現指標和指標之間是有關聯的,這個在實踐當中也會遇到。有時候兩個指標都出了問題,這時這個信息能不能被利用,咱們也作了探索。

這個東西有一個業務背景,就是咱們剛纔提到的看一個指標不夠,咱們常常在一些業態裏看到會監控某一個業務的成功量、成功率、失敗的錯誤請求數幾個指標相關變化。

有時候會發現指標有異常傳播,這個傳播有幾種方向傳播。好比說在不一樣的業務之間傳播,好比由於兩個程序之間有關聯關係,A壞了B也影響了。

還有就是混合部署的狀況,同一個集羣布兩個業務,A被打爆,B也被壓死了,也有這樣的狀況。

咱們怎麼作這個事情?分爲兩步。第一步咱們但願發現和維護相關的指標,就是哪些指標應該有關聯的,發現以後要維護。一旦咱們掌握這個信息以後就能夠作兩個事情。

第一種咱們可以把這些相關指標放在一塊兒斷定業務是否是異常,而不是隻看一個指標。

第二種咱們單指標能看的很準,但這時候我想知道爲何會下跌,雖然給不出因果,可是能夠給出相關。

業務指標之間的相關性其實有不一樣的類型,好比上下游之間有監控項,好比咱們在阿里作過一個實際狀況,你們看淘寶搜商品,若是出現異常你們就搜不了東西,咱們的淘寶詳情頁的瀏覽量和下單量都會降低。不是說搜索的程序或者應用服務掉了那個服務,它們之間沒有關聯,可是不少用戶習慣了搜而買。一但搜掛了,不少用戶不知道怎麼買了。

因此這樣的關聯靠系統內部是拿不到的。包括業務不一樣份量的監控,好比河南省播放成功率和河北省播放成功率之間的關聯。

這種關聯咱們怎麼發現?必定是靠人工梳理,可是對於阿里的體量,一個是梳理不過來,第二個梳理之後過兩天又變了。阿里集團可能天天的業務發佈的頻次是千級別的,那怎麼辦?還有第三種方式。

第一種利用 CMDB,咱們經過CMDB看到哪些應用之間可能相關。

第二個經過 時間序列相關性 發現了方法,這個跟剛纔提到的卵生網絡的方法是相似的。但從實際來看,通常是在第一個檢測的基礎上,再在局部作第二個,而不是全局的檢測。

第三個咱們利用關聯規則挖掘看哪些項常常關聯報警。

咱們能夠經過算法發現這些關係,這三個方案實際上是互補的方案。因此有了這三個方案後,就能夠把不少相關的指標放在一塊兒監控,方案取得了較好的效果。

在盒馬鮮生,基於咱們上面作的新的算法,單指標架構和多指標關聯架構,可以把監控發現率和誤報量作很是好的提高,這就是咱們在新業態下經過單個指標的算法和多個指標的算法取得關聯效果。

4、故障影響面和根因分析的探索

以前都是關於監控的部分,監控是爲了發現問題,可是發現完了問題,不少時候是須要想怎麼可以解決問題的。咱們在故障根因的推薦層面作過一些探索,但這個也只能是探索,供你們參考借鑑。

首先咱們看一下故障緣由分析問題的範圍和邊界,我也跟不少工程師交流過,凡是作運維繫統的工程師都有一個夢想,就是我想作一套系統,一旦個人業務出問題,告訴我問題緣由在哪,這個很是理想化。

但在實際過程當中,這個事情是很是難解決的,探索來講在阿里內部也解決地很差。雖然解決的很差,咱們也作了一些探索。

爲了不咱們作的事情不符合咱們老闆或者客戶的預期,咱們須要先把能作什麼說清楚。咱們很難作到淘寶交易量下跌了,我告訴你哪一個代碼有bug,這個作不到,可是咱們能作到縮小影響範圍。

這個爲何有價值?由於阿里巴巴有兩到三萬名工程師,半夜兩點出了問題,我打電話叫起來就是一個很是複雜的技術問題。

首先要從阿里巴巴幾萬個應用程序裏,先要看這個業務故障到底跟哪幾個應用相關,這個都是很是典型的問題。

咱們的目標是可以從站點、產品線和業務功能指標出現問題的時候,可以定位到應用服務層,包括數據庫這層。這個架構就是可以鎖定這個範圍,而後以後的事情可能須要更細緻的方式解決。

另一個好處,咱們能夠對故障作一個結構化的快照,除了阿里巴巴,我看到不少公司也會對故障作覆盤作改進措施,可是沒有造成很好的流程。

可是在阿里我看到過去大大小小很是嚴謹的覆盤和故障記錄,包括很是多的細分的環節和字段,這個很是好,由於之後的故障能夠從中學些東西。可是有個遺憾,這些東西全是用漢語寫成的,長篇大論幾千字。

人能夠去讀,可是好比阿里有另一個工做叫全鏈度壓測,咱們要對去年的業務優先進行測試,這個時候咱們要挖掘到底哪些有問題。挖不出來,爲何?都是漢字寫的。

漢字寫的話,它的表述、格式,都是很難被機器理解的。若是作的這件事情之後出故障,咱們儘量地把故障作一個結構,這個不只對此次故障的自己,對之後故障的防範都有很是大的價值。

怎麼作?如上圖所示,咱們會有一個主的抽象流程,當咱們的前面算法發現問題以後,咱們會嘗試找到跟這個業務指標相關的應用和它的中間件以及數據庫,以及相關的網絡服務器IDC。

咱們創建了一個囊括阿里主流的全部運維相關事件的這樣一個數據倉庫,阿里內部可能有本身的這種事件存儲的機制。

這個數據倉庫可以告訴咱們在哪些運維的對象上發生了什麼事情,最後咱們對這個事情作一個排序和篩選,把可疑的挑出來。邏輯仍是比較清晰的,可是真正作的時候發現有不少具體的環節須要考慮。

好比你怎麼找到監控項關聯應用,淘寶交易下跌了,你怎麼知道是阿里的幾萬個應用中哪一個應用形成的問題?這個其實也是比較難的問題,咱們也沒有解決太好,可是能夠看到思路。

最直接來說,咱們經過監控系統自己的配置來獲得。咱們的業務指標能畫成一張趨勢圖,能作監控,由於背後有邏輯計算,有日誌的採集等等。這些系統的工做,是由於加監控的同窗已經把監控怎麼採集配置進去了。可是它有失效的時候,好比說兩種狀況。

一種發現業務環境很是強,ABC三個程序不斷作處理,最後把結果打到第四個程序上去了。因此你經過這個,能獲得第四個應用的名字,前三個應用其實跟這個業務很是相關,可是你從這裏讀不到,因此這是咱們要解決的。

第二個有一些應用自己是用來監控的,好比阿里的客戶端,它會上報到某一些監控系統,這時候監控系統畫出來的曲線,其實跟監控系統自己相關的,而不是跟產生監控數據的應用相關的。

這種狀況下,這個方案就失效了。這個時候就須要經過人工配置的方式解決,目前是這兩種方式結合在用。

剛纔說的第一個問題,咱們也能夠經過阿里巴巴的中間作的系統去解決這個問題,包括咱們也能夠經過算法,對於報警作平臺挖掘,能夠挖掘出來像剛纔搜索框下跌,致使交易量下跌的關係等等均可以挖掘出來,這個東西也是補充的方式。可是最核心的不是算法,最核心的是CMDB若是維護得好,比什麼都好。

經過剛纔那個思路,可以把咱們的業務指標跟應用結合起來,可是不少時候應用常常是無狀態的,狀態存儲在數據庫集羣裏面,這個時候仍是常常經過CMDB解決這個問題。

還有比較難的問題,就是網絡跟應用程序的關係,有一個機房出問題了,常常咱們是混合部署的,因此這個時候問題實際上是一個很是散的關聯,這個問題上咱們解決的也很差,因此咱們只能把這個信息當成一個缺乏的信息推薦出來,供你們去決策。

好比說無論阿里什麼業務出了問題,咱們都會把網絡最近出的一些異常點或者事情推送出來,提醒你們是否是這個問題,可是這塊很難作到精細的管理。

咱們知道了哪些運維實體跟業務有關聯以後,還要知道這些運維實體上、程序上、集羣上、網絡上發生了什麼事情?那這個事情咱們怎麼知道?咱們會創建一個在線的數據倉庫,它可以不斷地抓取來自於各個運維平臺和系統中的不一樣格式的事件。

這個抓取以後不是簡單放一塊存,還要創建關聯索引。阿里有不少不一樣的橫向縱向的系統,他們的數據格式的字段都不同。

咱們嘗試作一個翻譯,在當中找到了兩三個你們都能看懂的詞。好比釘釘應用,這在阿里內部很是穩定的。第二個IP地址,這個也是很穩定的。

可是這兩個以外,格式語言是不同的。咱們把數據倉庫建好以後,輸入開始時間、結束時間和應用列表三個關鍵詞,就能夠查到這段時間內實體發生了什麼事情。我把事情都推薦出來是否是就解決了?還不夠。

我給你們分享一個數字,在阿里巴巴內部,像這樣的事情一分鐘發生四千到六千次,也就是說一個故障若是持續了十分鐘,就是幾萬個事件,因此咱們還要再作篩選。

這個時候就會經過一些方式作篩選,咱們會根據哪些運維實際上發生了報警,把這些實體的信息優先放在前面。怎麼知道有跳變?咱們會對懷疑的對象作系統級指標的掃描,掃描出來跳變就排到前面去,因此有了這個以後就能夠相對精確地縮小範圍,當阿里巴巴淘寶天貓有異常的時候,我就能夠知道。

咱們可以從上面看到,最上面這個環節是同一個時間內有多少業務的多少點在報警,紅顏色的時候,可能就是某些業務出現短暫的異常了。

咱們會感受 CMDB 加平臺化算法對報警壓縮合並,看到了集中在優酷、集團客戶體驗、菜鳥這三個業務功能上。

這個其實就是剛纔講的多指標關聯分析的做用,這時候我也不知道是否是由於它致使的,可是他們之間是相關的,這個能夠幫助咱們定位。

最後咱們可以根據剛纔說的邏輯,把跟這個事情相關的前五個或者前十個應用程序推薦給你。爲何推薦給你?要麼它發生了一些驟變,要麼發生了一些大的業務操做。

不少時候可能百分之五六十的業務故障,都是發佈新功能或者改配置改錯致使的。作的比較好的地方,可能可以作到70%以上的推薦準確率。可是也有作的很差的,百分之三四十的準確率。

由於阿里業務很複雜,每一個環節每一個業務都有不同的方式。可是這個方法,我認爲仍是一個值得推廣和借鑑的大邏輯上的思路,這個就是咱們介紹的監控發現問題以後,咱們在根因分析層面有哪些探索和思考。

5、智能運維在故障治理領域的將來規劃

最後但願可以和你們一塊兒探討一下在智能運維領域如今與將來能夠作什麼事情。

運維本質上是解決在線服務運行中的質量、成本和效率三方面,運維不是從上到下的思路,包括我也參與了白皮書的工做,咱們也跟其餘業界的同事探討這個問題,不是說有一個頂層規劃要怎麼作,實際是在這些點所處的具體環節上,不少工程師開始嘗試用算法的方式解決問題,逐步聚集成一個數。

咱們如今在上圖左邊那條路作了一些探索,已經在業務中用起來了。最先的探索,其實在阿里內部已經穩定運行了接近兩年時間,也是效果在不斷演化演進。

最近咱們也在探索右邊這條路,就是無人值守相關的東西。出問題的時候不少人問淘寶的故障恢復了沒有,支付寶有沒有受影響。靠天然語言提出的問題,是否是能夠經過機器人回答你,這個也是咱們探索的。

固然如今還不敢作全自動,仍是咱們列出來你再確認一下,但已經比你調出系統而後跟不少人溝通半天決策要方便一些。因此其實不只是在質量領域咱們作智能化的監控,智能化的根因分析,其實在節省人效率層面,也能夠作一些探索。

中間這塊跟成本相關,這塊在阿里巴巴有不少團隊作這樣的事情,也能夠經過智能化的調度可以作容量預測,優化包括硬件採購的週期,預測你服務器增加怎麼樣。或者在實施的時候,經過自動化的調度策略,節省服務器的資源。

因此其實智能運維這個概念,在今天已經不是個概念,它已經在咱們企業實際工做中,有很是多落地的點。但願今天個人分享,能給你們有一些借鑑和參考,咱們一塊兒建設智能運維美好的明天。

說明:以上內容爲阿里高級技術專家王肇剛在 GOPS 2018 · 上海站的分享。

原文連接

相關文章
相關標籤/搜索