做者丨吳樹生:騰訊高級工程師,負責SNG大數據監控平臺建設。近十年監控系統開發經驗,具備構建基於大數據平臺的海量高可用分佈式監控系統研發經驗。程序員
導語:監控數據多維化後,帶來新的應用場景。SNG的哈勃多維監控平臺在完成大數據架構改造後,嘗試引入AI能力,多維根因分析是其中一試點,用於摸索AI的應用經驗。本分分享探索過程和經驗,但願可給後續AI應用提供參考。算法
在2015年構建多維監控平臺時用kmeans作了異常點多維根因分析的嘗試,後因種種緣由而擱置了深刻研究。雖停止了兩年,但一直未忘當初的夢想。隨着掀起AI浪潮,平臺和技術也已成熟,監控團隊歷經兩個月的從新調研和預研後取得突破,另闢蹊徑地找到異常點的多維根因分析方法,咱們稱爲MDRCA(Multi-Dimensional Root Cause Analysis)算法。後端
這篇文章爲持續兩年多的夢畫上一個句號,它是監控團隊第一代成果總結:介紹監控多維數據特色、基於kmeans多維根因分析方法、第一代MDRCA算法和AI在監控領域應用經驗。筆者不敢貪功,僅將成果描述出來,若有誤差不全之處還望與讀者多交流修正。服務器
監控的核心是對監控對象的指標採集、處理、檢測和分析。傳統監控的對象是一個單一的實體,例如服務器、路由器、交換機等。這些單一對象經過指標反映運行狀態,例如服務器的狀態指標有CPU使用率、內存使用大小、磁盤IO和網卡流量等。架構
傳統監控系統經過定時任務採集這些監控對象的指標數據,通過校訂後存儲起來用於展現和異常檢測。異常檢測經過判斷指標是否偏離設置的閾值來標識異常事件。運維
在傳統監控以後,將監控對象擴展爲一個虛擬的業務功能或業務模塊,這時的對象還是單一的,可用一個惟一ID表達。對象的指標也相應的轉變爲反映業務功能狀態的指標,例如接口調用次數、http返回200次數、http返回500次數等。分佈式
這些指標數據一般須要在應用程序埋點上報。數據處理、存儲和異常檢測與傳統監控一致。性能
隨着業務擴展,業務模塊間的關係越發複雜。經過單一對象的指標反映的狀態已不能知足業務監控需求。業務異常每每體如今多個對象的指標異常,用戶收到告警後須要在大量指標數據中剝絲抽繭般地分析異常緣由。學習
這個情況伴生了運維痛點:一是告警量大;二是分析耗時長。大數據
解決這一問題的關鍵是創建對象和指標的關聯模型。經過相關性收斂對象和指標,減小告警量。並經過關聯模型中的調用關係模型和層次關係模型快速找到問題根因。對傳統監控中的對象翻譯爲多維度屬性後對指標數據進行處理、存儲和異常檢測,造成多維監控。對象的維度屬性將對象分類,構建了對象的關聯模型。
這樣對單一對象的異常檢測可提煉爲對某一維度屬性的異常檢測,從而減小檢測對象。在發生異常後根據維度下鑽分析,有規則地提供分析路徑,避免盲目分析,減小分析耗時。
用A、B和C這三個業務模塊來講明上面介紹的多維監控造成過程:
這三個模塊的調用關係爲A調用B,B調用C。C根據機房劃分爲C1和C2兩個子模塊。A模塊下有2臺機器(10.0.1.1和10.0.1.2),B下有3臺機器(10.0.2.一、10.0.2.2和10.0.2.3),C1下有1臺機器(10.0.3.11),C2下有2臺機器(10.0.3.21和10.0.3.22)。
假設C模塊下的機器負載已飽和,也就是說若是其中有一臺機器異常,則提供有損服務,影響B和A的成功率。若是C2模塊下的10.0.3.21機器異常,則會觸發10.0.3.21機器告警及A和B下的5臺機器告警,總共有6個對象產生告警。
在實際運營中,每每有多個指標反映一個功能狀態,進一步增長告警量。
爲解決例子描述的告警量大和分析耗時痛點,將監控對象的機器翻譯成業務模塊,從而造成一個業務模塊和機器的多維度數據。異常檢測也由機器維度更改成業務模塊維度,減小檢測對象的數量。在分析異常時,沿着業務模塊到機器的層級關係可查找出異常點。
還有一種多維數據的場景是面向APP應用。APP的請求自身帶有版本、機型、運營商和地域這些維度信息。發現指標異常後須要判斷是哪一個維度特性形成的異常或異常影響的維度範圍。
監控多維數據由三部分組成:
下表是一個SNG移動監控的多維數據樣例:
在建設多維監控平臺初期,爲解決人工逐個觀察各維度的異常數據帶來的效率問題,使用kmeans對成功率指標分類。推薦出分類後的異常維度後再作二次分析。
下圖是2014年12月手Q接入層SSO模塊的成功率分鐘曲線。當天中午13:00附近接入層成功率由接近99.9%降低爲99.5%。
發生異常後,經過人工分析的步驟爲分別查看某一維度的成功率,找出成功率低而且總量大的維度條件。選定最可疑的維度條件再重複剛剛介紹的分析過程。直到遍歷完全部維度,找出成功率降低的維度組合。
例如:模塊維度有A、B和C三個模塊,A模塊下有命令字(a1,a2和a3),B模塊下有命令字(b1,b2),C模塊下有命令字(c1,c2和c3)。
在異常點的指標統計以下表:
分析完成後肯定模塊B的命令字b1形成成功率降低。
使用kmeans對成功率分類模擬人工分類操做。對各維度的成功率進行分類後能夠獲得顯著差別的維度條件。
如對上面例子的各模塊成功率作kmeans分類,能夠得到成功率有顯著差別的模塊B和命令字b1。稱具備顯著差別的維度集合爲反向分析。反向分析結果在二次分析時須要特別關注。
下面兩張圖是對手 Q 接入層異常模塊分析的反向分析結果, 結合接入層的響應量判斷出異常模塊的RedTouchSvc,異常命令字爲RedTouchSvc.ClientReport。
基於Kmeans對成功率分析方法在必定程度上提高了問題分析效率,但存在兩個問題:
中斷近兩年,並在建設完成多維監控平後,監控團隊從新投入人力調研實現多維根因分析方法。在監控領域AI剛剛起步,可參考的論文和經驗較少。咱們在走了一段彎路後,借鑑和改進廣告推薦中的異常分析算法,實現MDRCA算法,解決Kmeans成功率分類方法的兩個問題。
對於指標咱們分兩類:單一變量指標和複合指標。
這裏咱們用單一變量指標請求量來講明MDRCA算法的原理。
假設一個業務的請求量X(m)的某一維度下有m個值,分解到各維度的請求量爲(x1,x2,…,xn,n=m)。X(m)可用公式表示:
在異常時刻t 觀察到異常的請求量爲A(m)。A(m) 由各維度在t 時刻的值組成。A(m) 可用公式表示:
也就是說觀察到的整體請求量異常由各維度的異常份量組成。
根據歷史觀察值得到時刻 t 的請求量預測值F(m)。F(m)由各維度的預測值組成。F(m) 可用公式表示:
生成預測值算法有多種,一種方法是取前一天對於時刻 t 的值。在本文的 MDRCA 算法中,預測值取離前7天的 t-20,t 時刻的平均值最近的一天的 t 時刻做爲參考點。
在MDRCA算法中定義一個值 Explanatory Power,簡稱EP來衡量觀察維度 i 下維度值 j 對異常的佔比,或稱貢獻度。EP的計算公式爲:
例如,異常時刻t的請求量爲1000,根據歷史數據預測時刻t的請求量爲1500。維度 i 下的維度值 j 在異常時刻 t 的請求量值爲200,根據j的歷史數據預測時刻 t 下 j 的請求量值應爲500。根據公式計算可知j的EP值爲(200-500)/(1000-1500)=0.6。
當維度下有值的變化方向與異常值變化方向相反時,EP取值爲負數。這時其餘維度值的EP取值也可能大於1。可是觀察維度下全部維度值的EP和爲1。
MDRCA算法中定義另外一個值Surprise來衡量觀察維度 i 下維度值 j 的變化差別。爲計算JSD,先計算兩個變量 p 和 q 。其中 p 爲維度值 j 在預測值中的佔比,q 爲維度值 j 在異常值中的佔比。p 和 q 的計算公式以下:
至此,咱們得到衡量維度值 j 的異常貢獻值 EP 和變化差別值 Surprise。對這兩個值用四象限方法解釋以下:
從四象限中可知,維度中 EP 和 Surprise 分類大的維度值可做爲候選維度。對 EP 和Surprise 分類可採用前面介紹的 kmeans 分類方法。
選出每一個維度下的候選維度集合後,計算各集合的 Surprise 和用於衡量各維度的異常變化差別。差別越大的維度越有可能成爲異常的主要影響因素。
在這還用了另外一個技巧: 異常的主要影響因素每每是少許維度值的集合。因此取後續集合的 Surprise均值大的維度做爲優先選擇的條件。選出維度後,在選擇維度中貢獻大的維度值做爲優先條件。
MDRCA算法的多維根因分析方法以下:
以上爲對單一變量的MDRCA算法介紹。對成功率這類複合指標EP計算爲求分子分母兩個變量的偏導,Surprise的計算方法爲求分子和分母變量的Surprise值之和。
爲藉助AI的東風解決監控領域的痛點,同時摸索AI在監控的實踐經驗。咱們拿智能多維分析探路。中間經歷曲折踩坑,反思當中的過程有幾點經驗值得在後續開發過程當中借鑑。
新近的互聯網浪潮AI,必然吸引很多新老程序員踏浪,如何才能在浪中不翻船呢?
通過摸索後,咱們認爲在AI應用開發中須要如下四類角色:
深刻了解業務的領域專家能把握住該業務的核心痛點,結合AI找出着力點和給AI專家提供業務領域信息;
這個角色知識淵博、深刻掌握算法和實踐。理解領域專家提供的痛點信息後,預研並提供算法指導和支撐。
這個角色拿到AI專家提供的算法後作工程化實現和優化提高算法性能。
這類角色是將AI成果上線應用,提高易用性和用戶體驗,同時在應用中預設收集用戶操做和反饋信息的渠道。
讀論文很重要。領域專家梳理出核心痛點,業界也存在相似痛點,而且有相關研究。不妨先參考業界作法,讀懂和理解相關論文和應用場景後再作改進。
在監控領域AI應用剛剛起步,你們還在摸着石頭過河,可參考的成功案例較少。所謂三個臭皮匠抵過一個諸葛亮,聚在一塊兒學習交流,有利於糾正錯誤認識,明晰算法應用場景和擴展思路。
最後,再次感謝SNG監控團隊小夥伴們的努力,摸索出了以上經驗。也歡迎你們多交流指正。團隊也在持續探索更優的多維監控異常分析算法,後續也將持續推出系列文章。你們敬請關注。
參考資料: 1 Adtributor: Revenue Debugging in Advertising Systems RanjitaBhagwan,Rahul Kumar,Ramachandran Ramjee, George Varghese,SurjyakantaMohapatra, Hemanth Manoharan, and Piyush Shah, Microsoft, 2014