智能運(yùn)維 解放程序員，一個(gè)工具就能鎖定程序故障下

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

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

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

在離線實(shí)驗(yàn)的70個(gè)故障案例中，我們的算法能夠把60個(gè)案例的根因摘要rank在第一位，顯示出了算法強(qiáng)大的生命力。

異常檢測算法

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

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

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

正所謂“少見多怪”，說的是因?yàn)楹苌僖娀蛘吒纱鄾]見過，所以覺得奇怪。又有說“司空見慣”，說的是天天見，所以就習(xí)慣了。這兩個(gè)成語表達(dá)的就是不常見的事情容易被看成是怪的，常見的事情就不怪了。換成數(shù)學(xué)的語言就是：小概率事件是異常，大概率事件是正常。雖然這個(gè)說法不是百分之百準(zhǔn)確，但是大部分時(shí)候還就是這樣。所以，衡量指標(biāo)的異常程度可以用觀測到指標(biāo)值的概率來描述，既然是概率，當(dāng)然是可以比較的，而且可以跨實(shí)例、跨指標(biāo)地比較。

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

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

上溢概率：

下溢概率：

上溢概率：

下溢概率：

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

上溢分?jǐn)?shù)：

下溢分?jǐn)?shù)：

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

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

聚類

在為每個(gè)指標(biāo)計(jì)算異常分?jǐn)?shù)之后，我們把屬于同一個(gè)實(shí)例的指標(biāo)的異常分?jǐn)?shù)合起來，形成一個(gè)異常分?jǐn)?shù)的向量

這里的每一個(gè)下標(biāo)對應(yīng)一個(gè)指標(biāo)。

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

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

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

排序（Ranking）

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

排序算法考慮的因素有以下三個(gè)：

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

2. 摘要中異常分?jǐn)?shù)特別高的指標(biāo)的個(gè)數(shù)，指標(biāo)越多越可能是根因。

3. 摘要中各實(shí)例指標(biāo)的平均異常分?jǐn)?shù)，平均分?jǐn)?shù)越高越可能是根因。

將以上三個(gè)因素的值計(jì)算出來，就形成了三個(gè)feature。我們只需要用通常的方法訓(xùn)練一個(gè)ranker就可以了。

表格 1 中是錯(cuò)誤!未找到引用源。 所示的那個(gè)故障案例的自動(dòng)分析結(jié)果。

標(biāo)中的第一列是摘要所屬的模塊與機(jī)房。

第二列是摘要中實(shí)例在同模塊同機(jī)房的實(shí)例中所占的比例。

第三列是摘要中的實(shí)例列表。

第四列是異常分?jǐn)?shù)特別高的指標(biāo)以及它們的異常分?jǐn)?shù)。

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

表1 故障的排查分析結(jié)果

總 結(jié)

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

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

生成海報(bào)

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