智能運維 解放程序員，一個工具就能鎖定程序故障

原標(biāo)題：智能運維 解放程序員，一個工具就能鎖定程序故障

人生病了需要看醫(yī)生，醫(yī)生會給病人做很多檢查，然后拿著結(jié)果單子分析病因。而程序生病了就要找運維工程師。運維工程師分析系統(tǒng)故障也要查看采集的監(jiān)控指標(biāo)，然后判斷根因是什么。

查看指標(biāo)這事兒，說起來也不難。只要畫出指標(biāo)的趨勢圖（指標(biāo)值隨時間變化的曲線），有經(jīng)驗的工程師很容易就能看出有沒有毛病，進而推斷故障的原因。不過呢，都說脫離開劑量說食物的毒性是耍流氓，查看指標(biāo)這事也差不多。如果只有幾條指標(biāo)需要查看，做個儀表盤就能一目了然，可是如果有成千上萬的指標(biāo)呢？如果人工查看這么多指標(biāo)，腦子的下場估計也好不到哪兒去。所以說還是得靠“機器人”。

等等，“機器人”怎么能知道什么指標(biāo)有毛病，什么指標(biāo)沒毛病呢？就算能知道，把有毛病的指標(biāo)挑出來工程師憑啥就能知道根因呢？所以，我們的“機器人醫(yī)生”必須能夠識別出指標(biāo)的異常，然后還需要能把識別出的異常整理成工程師容易理解的報告才行。

傳統(tǒng)的辦法

圖1 模塊調(diào)用關(guān)系圖

人工診斷故障的時候，工程師往往是根據(jù)腦子里的模塊調(diào)用關(guān)系圖（圖1）來排查系統(tǒng)。很多時候，故障都是因為在最上游的前端模塊（圖1中的A）上看到了很多失敗的請求發(fā)現(xiàn)的。這時，工程師就會沿著A往下查。因為A調(diào)用了B模塊，所以需要查看B的指標(biāo)，如果有指標(biāo)異常那么就懷疑是B導(dǎo)致了故障。然后再檢查B的直接下游模塊C，以此類推。在這個過程中，懷疑通過模塊的調(diào)用關(guān)系不斷往下傳遞，直到傳不下去為止。在圖1的例子中懷疑最后就停在了倒霉蛋G的頭上，誰讓它沒有下游模塊呢。

總的來說，這就是模塊間把責(zé)任想辦法往下游推的過程。當(dāng)然，真實的場景要更加復(fù)雜一些。并不是只要下游有異常就可以推的，還需要考察異常的程度。比如，如果倒霉蛋G的異常程度比E的異常程度小很多，根因就更有可能在E里面。

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

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

• 做一個頁面展示模塊調(diào)用關(guān)系圖
• 工程師為每個指標(biāo)配置黃金指標(biāo)，以及黃金指標(biāo)的閾值
• 在模塊圖中標(biāo)出黃金指標(biāo)有異常的模塊以及它們到達前端模塊的可能路徑

這個工具通過配置黃金指標(biāo)及閾值的方式解決了指標(biāo)以及如何判斷異常的問題，然后再通過模塊調(diào)用關(guān)系圖的方式呈現(xiàn)異常判斷的結(jié)果，解決了異常判斷和結(jié)果整理這兩個核心問題。

不過，傳統(tǒng)的辦法在實際使用中還是會碰到很多問題：

• 活的系統(tǒng)一定是不斷演化的，模塊的調(diào)用關(guān)系也隨之發(fā)生改變。為了保證工具里面的關(guān)系圖不會過時，就需要不斷從真實系統(tǒng)同步。干過系統(tǒng)梳理這種活的工程師都知道，這可不容易。如果整個系統(tǒng)使用統(tǒng)一的RPC中間件在模塊中通訊，那就可以通過分析RPC trace log的方式挖掘出調(diào)用關(guān)系圖來，不過“歷史代碼”通常會趴在路中間攔著你
• 每個黃金指標(biāo)通常只能覆蓋一部分的故障類型，新的故障一出現(xiàn)，就需要增加黃金指標(biāo)。這樣一來配置工作——尤其是閾值的配置——就會不斷出現(xiàn)。另外，指標(biāo)多了，就很容易出現(xiàn)“全國山河一片紅”的情況。大多數(shù)的模塊都被標(biāo)出來的時候，工具也就沒啥用了。
• 大型的系統(tǒng)為了保證性能和可用性，常常需要在好幾個機房中部署鏡像系統(tǒng)。因為大多數(shù)的故障只發(fā)生在一個機房的系統(tǒng)中，所以工程師不但需要知道根因模塊是誰，還需要知道在哪個機房。這樣一來，每個機房都得有一個調(diào)用關(guān)系圖，工程師得一個一個地看。

理想的效果

傳統(tǒng)的方法作出來的診斷工具最多也就是半自動的，應(yīng)用起來也受到很多的限制，所以我們就想做一個真正全自動、智能化的工具。

• 首先，我們希望新工具不要過于依賴于黃金指標(biāo)，這樣指標(biāo)的配置工作就能減少。但是，這反過來說明全自動的工具必須能夠掃描所有模塊上的所有指標(biāo)，這樣才能做到?jīng)]有遺漏。所以，異常判斷不能再通過人工設(shè)置閾值的方式來進行，而必須是基本上無監(jiān)督的（Unsupervised）。另外，不同指標(biāo)的語意有很大差異，異常判斷的算法也必須足夠靈活，以適應(yīng)不同指標(biāo)的特點。

• 其次，我們希望工具不要太過依賴于調(diào)用關(guān)系圖，這意味著我們需要尋找一種新的方式來整理和呈現(xiàn)結(jié)果。其實，調(diào)用關(guān)系圖并不是必須的。在使用傳統(tǒng)診斷方法時，我們就發(fā)現(xiàn)一部分工程師經(jīng)常脫離調(diào)用關(guān)系圖，直接按照黃金指標(biāo)的異常程度從大到小檢查模塊。這是因為這部分工程師負(fù)責(zé)的系統(tǒng)黃金指標(biāo)代表性強、容易理解，更重要的是不同模塊黃金指標(biāo)的異常程度可以比較。

所以說，我們完全可以做一個診斷工具來產(chǎn)出根因模塊的推薦報告，報告的內(nèi)容必須易于理解，推薦的順序也必須足夠準(zhǔn)確。

實例指標(biāo)的自動排查分析

我們以實例指標(biāo)為例，介紹如何實現(xiàn)一個指標(biāo)排查工具，達成理想的效果。排查工具的總體流程如圖2所示。

圖2 實例指標(biāo)自動排查的總體流程

• 在第一步，所有被收集來的指標(biāo)都會通過異常檢測算法賦予它們一個異常分?jǐn)?shù)。比較兩個指標(biāo)的異常分?jǐn)?shù)就能夠知道它們的異常程度誰大誰小了。這一步的核心是要尋找一個方法能夠量化地衡量每個指標(biāo)的異常，而且這個量化衡量出來的分?jǐn)?shù)還可以在不同實例的不同指標(biāo)之間比較。

• 第二步，我們把異常分?jǐn)?shù)按照它們所屬的實例分組，每組形成一個向量（vector）。這時，每個實例都會對應(yīng)一個向量，向量中的每個元素就是一個指標(biāo)的異常分?jǐn)?shù)。然后，模式（pattern）差不多的向量就可以通過聚類（clustering）算法聚成若干個摘要（digest）。這樣一來，工程師們就容易理解分析的結(jié)果了。

• 第三步，我們可以根據(jù)摘要中包含的實例以及指標(biāo)的異常分?jǐn)?shù)排序（ranking），形成推薦報告。

總結(jié)

本文介紹了一種在服務(wù)發(fā)生故障時自動排查監(jiān)控指標(biāo)的工具。

第一步，利用了概率統(tǒng)計的方式估算每個指標(biāo)的異常分?jǐn)?shù)。

第二步，用聚類的方式把異常模式相近的實例聚集在一起形成摘要。

第三步，用ranking的方式向工程師推薦最有可能是根因的摘要。

由于運維場景的特點是數(shù)據(jù)量大，但是標(biāo)定很少，生成標(biāo)定的代價高昂而且容易出錯，接下來我們會詳細(xì)介紹如何利用概率統(tǒng)計、非監(jiān)督學(xué)習(xí)和監(jiān)督學(xué)習(xí)的方法來解決這個問題，敬請期待吧~

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。