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

原標題：智能運維解放程序員，一個工具就能鎖定程序故障下

在上一篇《智能運維 | 解放程序員，一個工具就能鎖定程序故障》文章中我們主要介紹了一種在服務發(fā)生故障時自動排查監(jiān)控指標的算法。算法的第一步利用了概率統(tǒng)計的方式估算每個指標的異常分數(shù)，第二步用聚類的方式把異常模式相近的實例聚集在一起形成摘要，第三步用ranking的方式向工程師推薦最有可能是根因的摘要。

由于運維場景的特點是數(shù)據(jù)量大，但是標定很少，生成標定的代價高昂而且容易出錯，所以我們綜合利用了概率統(tǒng)計、非監(jiān)督學習和監(jiān)督學習的方法解決問題，在盡量減少訓練數(shù)據(jù)的前提下取得了良好的效果。

在離線實驗的70個故障案例中，我們的算法能夠把60個案例的根因摘要rank在第一位，顯示出了算法強大的生命力。

異常檢測算法

異常檢測算法是我們整個自動排查監(jiān)控指標工具的核心，它需要解決跨實例跨指標的異常程度比較問題。這涉及一個本源的問題：什么是異常？

請閉上眼睛想1分鐘，再接著往下看。

是不是覺得這個問題似乎不大好回答？作者也拿這個問題為難過不少人。有的人說異常就是不正常唄，但是正常是什么就說不清楚了。有的人說，你給我一些具體的數(shù)據(jù)我能告訴你哪些是異常，但是脫離具體數(shù)據(jù)抽象的說不出來。還有人一上來就說，這個問題還真是從來沒想過。

正所謂“少見多怪”，說的是因為很少見或者干脆沒見過，所以覺得奇怪。又有說“司空見慣”，說的是天天見，所以就習慣了。這兩個成語表達的就是不常見的事情容易被看成是怪的，常見的事情就不怪了。換成數(shù)學的語言就是：小概率事件是異常，大概率事件是正常。雖然這個說法不是百分之百準確，但是大部分時候還就是這樣。所以，衡量指標的異常程度可以用觀測到指標值的概率來描述，既然是概率，當然是可以比較的，而且可以跨實例、跨指標地比較。

指標值的觀測概率可以從多個不同的角度來建模計算，這里我們主要關注突增突降的情況。指標的突增突降是很容易被人所理解的。比如，工程師們很容易就同意圖1中的指標有異常。另一方面，許多故障都會體現(xiàn)在某些指標的突增突降上。最關鍵的是，計算指標的突增突降對應的觀測概率是比較容易的，很適合我們這種需要掃描大量指標的場景。

圖1 CPU_WAIT_IO的突增說明出現(xiàn)了磁盤競爭

上溢概率：

下溢概率：

上溢概率：

下溢概率：

為了方便計算和人的查看，通常會計算概率的對數(shù)。概率的對數(shù)都是負數(shù)，大家看正數(shù)比較自然，所以我們就把概率的對數(shù)的負數(shù)作為異常分數(shù)

上溢分數(shù)：

下溢分數(shù)：

對于像CPU_IDLE一樣的指標，我們可以用Beta分布作為核函數(shù)，這時

有了概率密度函數(shù)，單點的概率就可以利用積分計算了

聚類

在為每個指標計算異常分數(shù)之后，我們把屬于同一個實例的指標的異常分數(shù)合起來，形成一個異常分數(shù)的向量

這里的每一個下標對應一個指標。

為了便于工程師閱讀，我們需要把異常模式差不多的向量通過聚類的方法聚在一起。聚類是無監(jiān)督學習（Unsupervised Learning）的典型方法之一。與監(jiān)督式學習（SupervisedLearning）不同，聚類不能通過樣本的標記（Label）來控制輸出的結果，所以控制聚類方向的核心就落在了距離函數(shù)和聚類算法上。

在聚類算法上，由于我們事先無法知道有多少種不同的異常模式存在，K-means顯然就不是一個很好的選擇了。層次聚類和DBSCAN都不需要預先設定聚類的個數(shù)，能更好地適應我們的需求。在實驗中，我們采用了DBSCAN，確實得到了很好的效果。

聚類時，理論上我們可以把所有模塊的所有實例放在一起聚類。在實驗中我們發(fā)現(xiàn)這樣的聚類結果有時候也還可以，而且它可以發(fā)現(xiàn)跨模塊的問題，比如由于網(wǎng)絡故障導致多個模塊之間通信收到影響最終產(chǎn)生整個系統(tǒng)的故障。但是，這種方法也在不少情況下的輸出并不好。所以，我們采用了相對保守的方式，將聚類局限在屬于同一個模塊、同一個機房的實例中。

排序（Ranking）

聚類算法把異常模式相似的實例聚到了一起，形成摘要。每個摘要已經(jīng)具備一定的可讀性，我們只需要把屬于根因模塊的摘要排在前面推薦給工程師就大功告成了。

排序算法考慮的因素有以下三個：

1. 摘要中實例的個數(shù)，實例越多說明影響越大，就越有可能是根因。

2. 摘要中異常分數(shù)特別高的指標的個數(shù)，指標越多越可能是根因。

3. 摘要中各實例指標的平均異常分數(shù)，平均分數(shù)越高越可能是根因。

將以上三個因素的值計算出來，就形成了三個feature。我們只需要用通常的方法訓練一個ranker就可以了。

表格 1 中是錯誤!未找到引用源。 所示的那個故障案例的自動分析結果。

標中的第一列是摘要所屬的模塊與機房。

第二列是摘要中實例在同模塊同機房的實例中所占的比例。

第三列是摘要中的實例列表。

第四列是異常分數(shù)特別高的指標以及它們的異常分數(shù)。

我們的算法確實把根因模塊G中的一個摘要最為第一個推薦出來了。通過第四列的內(nèi)容，我們可以看出機房DC1中的G模塊因為某種原因超載了。G超載后，它對上游模塊的響應變慢，從而使得同機房中的E模塊不得不維護更多的RPC連接，所以同機房的E模塊被拍在了第二位，而且與網(wǎng)絡連接數(shù)相關的指標也確實出現(xiàn)了異常。

表1 故障的排查分析結果

總 結

故障診斷作為智能運維中的一個典型的復雜場景，一直是眾多運維工程師的努力方向。本文介紹的指標自動排查算法表明，除了機器學習之外，概率統(tǒng)計也將會在智能運維中占據(jù)重要的位置。

關于故障診斷的研究，如有任何想法和疑問，歡迎留言一起交流。

生成海報

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