創造程序的「白衣天使」（上）

本文做者：AIOps智能運維

乾貨概覽

 

人生病了要去看醫生，程序生病了看的就是運維工程師了。醫生給病人看病要作不少檢查，而後拿着結果單子分析病因。運維工程師分析系統故障也會查看採集的監控指標，而後判斷根因是什麼。

 

查看指標這事兒，提及來也不難。只要畫出指標的趨勢圖（指標值隨時間變化的曲線），有經驗的工程師很容易就能看出有沒有毛病，進而推斷故障的緣由。不過呢，都說脫離開劑量說食物的毒性是耍流氓，查看指標這事也差很少。若是隻有幾條指標須要查看，作個儀表盤就能一目瞭然，但是若是有成千上萬的指標呢？人家查抄大老虎的時候點鈔機都燒壞了好幾臺，若是人工查看這麼多指標，腦子的下場估計也好不到哪兒去。因此說仍是得靠「機器人」。

 

等等，「機器人」怎麼能知道什麼指標有毛病，什麼指標沒毛病呢？就算能知道，把有毛病的指標挑出來工程師憑啥就能知道根因呢？因此，咱們的「機器人醫生」必須可以識別出指標的異常，而後還須要能把識別出的異常整理成工程師容易理解的報告才行。

 

傳統的辦法

 

人工診斷故障的時候，工程師每每是根據腦子裏的模塊調用關係圖（圖 1）來排查系統。不少時候，故障都是由於在最上游的前端模塊（圖 1中的A）上看到了不少失敗的請求發現的。這時，工程師就會沿着A往下查。由於A調用了B模塊，因此須要查看B的指標，若是有指標異常那麼就懷疑是B致使了故障。而後再檢查B的直接下游模塊C，以此類推。在這個過程當中，懷疑經過模塊的調用關係不斷往下傳遞，直到傳不下去爲止。在圖 1的例子中懷疑最後就停在了倒黴蛋G的頭上，誰讓它沒有下游模塊呢。

 

總的來講，這就是模塊間把責任想辦法往下游推的過程。固然，真實的場景要更加複雜一些。並非只要下游有異常就能夠推的，還須要考察異常的程度。好比，若是倒黴蛋G的異常程度比E的異常程度小不少，根因就更有可能在E裏面。

 

找到了根因模塊再去分析根因就容易多了，因此尋找根因模塊是故障診斷中很重要的步驟。

 

上面的過程能夠很直接地變成一個工具：

 

作一個頁面展現模塊調用關係圖

 

工程師爲每一個指標配置黃金指標，以及黃金指標的閾值

 

在模塊圖中標出黃金指標有異常的模塊以及它們到達前端模塊的可能路徑

 

這個工具經過配置黃金指標及閾值的方式解決了指標以及如何判斷異常的問題，而後再經過模塊調用關係圖的方式呈現異常判斷的結果，解決了異常判斷和結果整理這兩個核心問題。

 

不過，傳統的辦法在實際使用中仍是會碰到不少問題：

 

1.活的系統必定是不斷演化的，模塊的調用關係也隨之發生改變。爲了保證工具裏面的關係圖不會過期，就須要不斷從真實系統同步。幹過系統梳理這種活的工程師都知道，這可不容易。若是整個系統使用統一的RPC中間件在模塊中通信，那就能夠經過分析RPC trace log的方式挖掘出調用關係圖來，不過「歷史代碼」一般會趴在路中間攔着你。

 

2.每一個黃金指標一般只能覆蓋一部分的故障類型，新的故障一出現，就須要增長黃金指標。這樣一來配置工做——尤爲是閾值的配置——就會不斷出現。另外，指標多了，就很容易出現「全國山河一片紅」的狀況。大多數的模塊都被標出來的時候，工具也就沒啥用了。

 

3.大型的系統爲了保證性能和可用性，經常須要在好幾個機房中部署鏡像系統。由於大多數的故障只發生在一個機房的系統中，因此工程師不但須要知道根因模塊是誰，還須要知道在哪一個機房。這樣一來，每一個機房都得有一個調用關係圖，工程師得一個一個地看。

 

理想的效果

 

傳統的方法做出來的診斷工具最多也就是半自動的，應用起來也受到不少的限制，因此咱們就想作一個真正全自動、智能化的工具。

 

首先，咱們但願新工具不要過於依賴於黃金指標，這樣指標的配置工做就能減小。可是，這反過來講明全自動的工具必須可以掃描全部模塊上的全部指標，這樣才能作到沒有遺漏。因此，異常判斷不能再經過人工設置閾值的方式來進行，而必須是基本上無監督的（Unsupervised）。另外，不一樣指標的語意有很大差別，異常判斷的算法也必須足夠靈活，以適應不一樣指標的特色。

 

其次，咱們但願工具不要太過依賴於調用關係圖，這意味着咱們須要尋找一種新的方式來整理和呈現結果。其實，調用關係圖並非必須的。在使用傳統診斷方法時，咱們就發現一部分工程師常常脫離調用關係圖，直接按照黃金指標的異常程度從大到小檢查模塊。這是由於這部分工程師負責的系統黃金指標表明性強、容易理解，更重要的是不一樣模塊黃金指標的異常程度能夠比較。

 

因此說，咱們徹底能夠作一個診斷工具來產出根因模塊的推薦報告，報告的內容必須易於理解，推薦的順序也必須足夠準確。

 

實例指標的自動排查分析

 

咱們以實例指標爲例，介紹如何實現一個指標排查工具，達成理想的效果。

 

在第一步，全部被收集來的指標都會經過異常檢測算法賦予它們一個異常分數。比較兩個指標的異常分數就可以知道它們的異常程度誰大誰小了。這一步的核心是要尋找一個方法可以量化地衡量每一個指標的異常，並且這個量化衡量出來的分數還能夠在不一樣實例的不一樣指標之間比較。

 

第二步，咱們把異常分數按照它們所屬的實例分組，每組造成一個向量（vector）。這時，每一個實例都會對應一個向量，向量中的每一個元素就是一個指標的異常分數。而後，模式（pattern）差很少的向量就能夠經過聚類（clustering）算法聚成若干個摘要（digest）。這樣一來，工程師們就容易理解分析的結果了。

 

第三步，咱們能夠根據摘要中包含的實例以及指標的異常分數排序（ranking），造成推薦報告。

 

總結

 

本文介紹了一種在服務發生故障時自動排查監控指標的工具，第一步利用了機率統計的方式估算每一個指標的異常分數，第二步用聚類的方式把異常模式相近的實例彙集在一塊兒造成摘要，第三步用ranking的方式向工程師推薦最有多是根因的摘要。

 

因爲運維場景的特色是數據量大，可是標定不多，生成標定的代價高昂並且容易出錯，接下來咱們會詳細介紹如何利用機率統計、非監督學習和監督學習的方法來解決這個問題，敬請期待吧~

 

原文連接地址：https://developer.baidu.com/topic/show/290066