[業界方案] 智能運維AIOps-學習筆記

本文轉載自查看原文 2020-08-24 20:18 1926 010_AIOps/ 001_機器學習/ 009_業界方案

[業界方案] 智能運維-學習筆記

[業界方案] 智能運維-學習筆記

0x00 摘要

本文為本人的學習筆記，非商用。

目的是對於所學習的技術，大致知道其應用領域，技術特點和未來方向，看看目前工作中是否可以用到，或者以后選型時能夠做到心里有數，順便也可以梳理清楚自己的知識體系。

文章或涉及多方引用，如有紕漏忘記列舉，請多指正與包涵。

0x01 AIOps 背景

1.1 AIOps概述

智能運維的理想狀態就是把運維工作的三大部分：監控、管理和故障定位，利用一些機器學習算法的方法把它們有機結合起來。

AIOps 平台包括數據湖，即存儲采集數據，還有自動化系統、記錄系統、交互系統、監控生態圈。
AIOps平台主要通過整合分析IT基礎設施、APM、NPM、日志、數字化體驗監測數據，來提升IT運維流程的效率。
AIOps平台能力的ROI多是基於平均故障接手時間（MTTA）和平均故障修復（MTTR）時間這兩個指標的降低進行評估的。

1.2 AIOps場景

AIOPS場景很多，諸如異常檢測、根因分析、故障自愈、容量預測等方面。根據平台的實際場景和業界AIOPS的實踐經驗，360將AIOPS划分為三個場景：成本、效率和穩定性。針對成本來說，利用AI算法節省資源、智能調度，提高資源利用率的手段來節省資源；針對效率方面來說，利用AI算法主動發現問題、分析問題和解決問題，真正節省人力，提高效率。

1.3 AIOps能力

AIOps智能運維平台需要提供如下能力：

提供獨立、開放的歷史/實時數據采集、算法分析平台，整合IT數據和業務指標數據；
提供告警消噪（包括告警抑制、告警收斂等），消除誤報或冗余事件；
提供跨系統追蹤和關聯分析，有效進行故障的根因分析；
設定動態基線捕獲超出靜態閾值的異常，實現單/多指標異常檢測；
根據機器學習結果，預測未來事件，防止潛在的故障；
直接或通過集成啟動解決問題的動作；

1.4 AIOps的基礎

只有當工程（自動化、標准化）的水平達到一定高度后，才有望向智能化方向發展。以下給出的幾種簡單方法和技術，既能在異構系統中建立某種關聯，為智能化提供一定的支持，又不要求開發人員改變技術棧或開發框架。

日志標准化：日志包含所約定的內容、格式，能標識自己的業務線、服務層級等。
全鏈路追蹤：TraceID或者RequestID應該能從發起方透傳到后端，標識唯一請求。
SLA規范化：采用統一的SLA約定，比如都用“響應時間”來約定性能指標，用“慢速比”來衡量系統健康度。

0x02 一些值得借鑒的方案

2.1 容量預估

2.1.1 360

監控項的樣本就是時間序列，通過分析監控項的序列，得到未來一段時間的預測值。根據波動劇烈程度，監控項可以分為波動不太劇烈和劇烈的，根據周期性，可以分為具有周期性和不具有周期性等等，當然還有很多划分的標准。可見，不同時間的序列，360需要使用不同的模型去預測。

在對時間序列進行預測的過程中，360先后使用了下面幾種模型，總結出了一些經驗：

模型	時間開銷	准確率	開源包
LR(線性回歸)	少	低	sklearn
ARIMA	少	低	statsmodels
淺層神經網絡，回歸樹等	中等	中	pybrain, sklearn
LSTM	大，需要GPU	高	tensorflow

2.1.2 京東物流

預測大體上分為故障預測、容量預測和性能預測。我們之前嘗試了業界基於 RSTM 的一個算法，該算法是基於時序數據預測的一個經典算法。

2.2 主機分類

360會根據監控項的特征，來判斷該機器屬於的類型（cpu、磁盤、內存密集型）。機器學習中有很多分類算法，比如SVM、決策樹、分類樹等都可以完成分類任務。

2.3 負樣本不足

在AIOPS中，經常用遇到負樣本不足的問題，一個原因是異常的場景比較少，一個原因是用戶標注的成本比較高。在主機分類的過程中，360使用了兩種手段來生成樣本，一種是人工標注，一種是用戶標注，解決了負樣本不足的問題。

比如為了將不同類型的機器和不同類型的實例進行合理搭配，需要將實例和機器進行分類。在該項目中，實例分類采用了BP神經網絡，其中輸入是7個重要的實例指標，輸出是4個類別（低消耗、計算型、存儲型、綜合型）。機器分類采用決策樹模型，輸入是5個機器指標，輸出和實例的輸出類型一樣。樣本全部采用人工標注的方式，生成了1000左右的樣本。

2.4 異常檢測

2.4.1 360公司

異常檢測是AIOPS最常見的場景，算法也有很多，業界比較流行的比如普通的統計學習方法--3σ原則，它利用檢測點偏移量來檢測出異常。比如普通的回歸方法，用曲線擬合方法來檢測新的節點和擬合曲線的偏離程度，甚至有人將CNN和RNN模型應用到異常點的檢測。

360使用lvs比較多，為了應對流量突增和突減的情況，需要一個異常檢測算法。通過對lvs流量的時間序列圖的分析，發現有的曲線有周期性，有的沒有，有的毛刺比較多，有的比較平穩，所以需要有一個普適檢測算法，能夠處理各種復雜的場景。

現實場景中，負樣本比較少，360采用了無監督模型，除此之外，還借鑒投票機制來解決單純的方法有時候具有偏差這樣的問題。在該項目中，360采用了五種以上的檢測算法，有統計學中同比環比的情況、曲線擬合算法以及周志華老師的隔離森林模型。通過這些模型來一起對一個時間序列進行檢測。如果這些算法中有超過一半的算法認為該檢測點為異常點，360就認為這個點為異常點。

2.4.2 美團外賣訂單量預測異常報警模型

同比環比預測器

同比環比是比較常用的異常檢測方式，它是將當前時刻數據和前一時刻數據（環比）或者前一天同一時刻數據（同比）比較，超過一定閾值即認為該點異常。

基線預測器

同比環比使用歷史上的單點數據來預測當前數據，誤差比較大。t時刻的監控數據，與 t-1,t-2,…時刻的監控數據存在相關性。同時，與t-k,t-2k,…時刻的數據也存在相關性（k為周期），如果能利用上這些相關數據對t時刻進行預測，預測結果的誤差將會更小。

比較常用的方式是對歷史數據求平均，然后過濾噪聲，可以得到一個平滑的曲線（基線），使用基線數據來預測當前時刻的數據。

Holt-Winters預測器

同比環比預測到基線數據預測，使用的相關數據變多，預測的效果也較好。但是基線數據預測器只使用了周期相關的歷史數據，沒有使用上同周期相鄰時刻的歷史數據，相鄰時刻的歷史數據對於當前時刻的預測影響是比較大的。

美團使用了Holt-Winters來實現這一目標。Holt-Winters是三次指數滑動平均算法，它將時間序列數據分為三部分：殘差數據a(t)，趨勢性數據b(t)，季節性數據s(t)。使用Holt-Winters預測t時刻數據，需要t時刻前包含多個周期的歷史數據。相關鏈接：Exponential smoothing、Holt-Winters seasonal method。

外賣報警模型中的預測器

在外賣訂單量異常檢測中，使用Holt-Winters預測器實時預測下一分鍾訂單量，每次需要至少5天以上的訂單量數據才能有較好的預測效果，數據量要求比較大。在實際的異常檢測模型中，我們對Holt-Winters預測器進行了簡化。預測器的趨勢數據表示的是時間序列的總體變化趨勢，如果以天為周期看待外賣的訂單量時間序列，是沒有明顯的趨勢性的，因此，我們可以去掉其中的趨勢數據部分。

計算序列的周期性數據

時間序列的周期性數據不需要實時計算，按周期性更新即可，如外賣訂單大盤監控，s(t)只需要每天更新一次即可。對於s(t)的計算，可以有多種方法，可以使用上面提到的Holt-Winters按公式計算出時間序列的周期性數據，或直接使用前一天的監控數據作為當天的周期數據（這兩種方式都需要對輸入序列進行預處理，保證算法的輸入序列不含有異常數據）。也可以將歷史數據做平均求出基線作為序列的周期性數據。

目前外賣訂單中心報警模型采用的是Holt-Winters計算周期數據的方式。在將該模型推廣到外賣其他業務線監控時，使用了計算基線數據作為周期數據的方式。

殘差數據實時預測

計算出周期數據后，下一個目標就是對殘差數據的預測。實際監控數據與周期數據相減得到殘差數據，對殘差數據做一次滑動平均，預測出下一刻的殘差，將該時刻的殘差、周期數據相加即可得到該時刻的預測數據。殘差序列的長度設為60，即可以得到比較准確的預測效果。

預測器預測出當前時刻訂單量的預測值后，還需要與真實值比較來判斷當前時刻訂單量是否異常。一般的比較器都是通過閾值法，比如實際值超過預測值的一定比例就認為該點出現異常，進行報警。這種方式錯誤率比較大。在訂單模型的報警檢測中沒有使用這種方式，而是使用了兩個串聯的Filter，只有當兩個Fliter都認為該點異常時，才進行報警，下面簡單介紹一下兩個Filter的實現。

離散度Filter：根據預測誤差曲線離散程度過濾出可能的異常點。一個序列的方差表示該序列離散的程度，方差越大，表明該序列波動越大。如果一個預測誤差序列方差比較大，那么我們認為預測誤差的報警閾值相對大一些才比較合理。
閾值Filter：根據誤差絕對值是否超過某個閾值過濾出可能的異常點。閾值Filter設計了一個分段閾值函數y=f(x)，對於實際值x和預測值p，只有當|x-p|>f(x)時報警。實際使用中，可以尋找一個對數函數替換分段閾值函數，更易於參數調優。

2.4.3 微眾銀行

微眾銀行目標是使用機器學習算法實現無閾值KPI曲線異常識別。

“微眾銀行智能監控系統識圖模塊”是針對業務四大黃金指標而設計的智能曲線異常檢測系統。四大黃金指標包括交易量(業務實時產生的交易量)、業務成功率(業務成功量/交易量)、系統成功率(系統成功量/交易量, 業務成功量和系統成功量的區別在於是否明確捕捉到系統異常)、平均時延(交易的平均耗時)。這四大黃金指標都是分鍾級數據，這四個指標統計維度不同，波動規律也有所差別，因此需要用不同的算法檢測。

檢測方法主要有三種：

基於LSTM與高斯分布的檢測，這個算法主要用於交易量和時延的檢測。大部分的曲線突變都能准確檢測到，但算法的死角在於小幅度長時間的緩慢變化容易被漏掉。
基於k-means算法的特征檢測，主要用於填補第一種算法的盲區,在交易量緩慢變化的案例效果較好。
基於概率密度的檢測，主要用於業務成功率和系統成功率的曲線，因為成功率曲線的背后隱藏着無數的可能，需要用一個更接近本質的量來衡量異常的程度。

而以上三種方法都有一個共同的判斷原則——少見即異常。在我們確立了無監督為主的大前提下，異常檢測的問題轉換成了如何衡量當前的情況是否“少見”的問題。

2.4.3 華為

首先是數據源的異常檢測。

Z-score算法

Z-score算法，就是每個點減去均價再除方差，衡量計算這個點與整體情況的偏離度，達到一定程度就標記為極度異常數據（不納入指標統計）。

用最簡單的方法先過濾掉，在正常情況下，z-score能夠幫助我們過濾掉更多的異常，而在真正出現故障時，可以減少對合理異常數據的過濾。

但是這個z-score算法，優點的計算簡單，計算成本低，但是缺點是后期人工成本高；比如對於數據滑窗參數要手工調整，同時閾值也需要手工判斷，成本較高。同時，算法本身對於異常點突出效果不明顯的話，閾值難以取舍。接下來就是來了基於Boxplot箱線圖的改良算法。

Boxplot算法

該算法核心是基於箱線圖算法來改良的，在這個思想里，默認異常數據百分比是比較低且相對穩定的，不過，指標數據一般不是完美的正態分布，比如時延指標是有右偏（偏大）情況，會往高的時延方向偏移，因此，我們在原有的箱線圖算法中加了一個重心偏移。同時，我們還發現時延數據不僅有重心偏移，還存在長尾效應，因此我們還加入了長尾修正參數，即：99分位數據減去中間值除上75分位與中間值來衡量這個長尾效應，這樣，算法很好地解決了存在重心偏移以及長尾效應的異常數據過濾。

時間序列分解算法

數據源的異常檢測解決好后，指標的異常檢測就有了基礎。

大家經常用到異常檢測方法的時間序列分解法，周期項、趨勢項、殘差項的計算都在其中。從算法表現圖上來看，通過周期學習，趨勢計算后，原始數據減去周期再減去趨勢，就變成了白噪聲。通過置信空間的計算，疊加原來計算的周期與趨勢，就得到了指標的上下閾值。

因為用戶少，少量用戶的異常失敗就會導致整個指標下降30%甚至更多，而且每天發生這種下降的隨機性很強。

多工況檢測算法

上面時間序列分解算法所不能適應的場景，就是多工況檢測（MRCheck）算法的由來，這個算法外部用的很少，在此分享下，我們通過歷史數據的特征進行貢獻度識別，其實數據的波動和請求量還有時間是有關系的。因此，如圖所示流程，會根據特征（請求量和時間），建立不同的工況（本質是聚類算法），如3~20種工況，然后通過各個點與聚類中心點的距離進行工況划分的評估，確定工況划分的合理性。

可以這么理解，以前時間序列是只有一種工況的特例，而現在我們通過變成多種工況，重新評估置信空間，異常檢測閾值線根據工況變化隨之發生變化，很好的解決了原來時間序列分解算法的問題。

2.5 報警收斂

2.5.1 360

360對歷史報警進行分析，發現其中有很多規律。如果360利用算法分析出這些報警項之間的關系，再加上人工經驗，將很大程度減少報警的數目。

下面介紹一下如何通過算法去分析出報警項之間的潛在關系。360采用機器學習中關聯分析常用的算法Apriori來分析歷史報警，該模型利用頻繁項集分析出A—>B這種關系。將這種規則應用到報警中，如果A報警發出，則B報警就不需要發出，這樣就能夠成倍減少報警次數。下圖是360對過去30天的報警數據分析，得到20+的關聯規則。

360線上維護着一個規則庫，這個規則庫來源於兩部分：算法分析規則、人工總結規則。在利用這些規則同時，360還結合了業務的評級來對業務報警進行一定程度的合並處理。

2.5.2 美團

以下是美團的一種算法落地實施。

異常報警根因分析的設計大致分為四個部分：收集報警信息、提取報警信息的關鍵特征、聚類處理、展示報警摘要。

聚類算法采用論文“Clustering Intrusion Detection Alarms to Support Root Cause Analysis [KLAUS JULISCH, 2002]”中描述的根因分析算法。該算法基於一個假設：將報警日志集群經過泛化，得到的泛化報警能夠表示報警集群的主要特征。可以將報警抽象為各種層次，抽象層次越高，細節越少，但是它能包含的范圍就越大；反之，抽象層次越低，則可能無用信息越多，包含的范圍就越小。這種抽象的層次關系可以用一些有向無環圖（DAG）來表達。

算法描述

算法假設所有的泛化層次結構Gi都是樹，這樣每個報警集群都有一個唯一的、最頂層的泛化結果。
將L定義為一個原始的報警日志集合，算法選擇一個屬性Ai，將L中所有報警的Ai值替換為Gi中Ai的父值，通過這一操作不斷對報警進行泛化。
持續步驟2的操作，直到找到一個覆蓋報警數量大於min_size的泛化報警為止。
輸出步驟3中找到的報警。

2.6 根因分析

2.6.1 360 模型

360推出一種模型，能夠幫助運維人員縮小報警排查范圍，快速定位到問題。該項目中要分析兩個維度數據：

一個是事件維度，關注的是六大類報警事件；

一個是指標維度，關注機器維度的監控項（大約有200左右個監控項）。

那如何在事件發生后，找到跟它相關的指標呢？實現的方法如下：

針對每個事件，使用在2014年SIGKDD會議上發表的論文《Correlating Events with Time Series for Incident Diagnosis》中提到的方法，看哪些指標跟這個事件發生有關系。

這樣的目的能夠對指標進行初篩，達到降維的目的。

針對第一步選出來的指標，求出這些指標的信息增益比，選擇前k個（360取得值是5）特征作為最后的影響指標；
最后使用xgboost對影響指標進行分類，驗證效果。

2.6.2 微眾銀行專家系統

微眾銀行先采用專家系統的技術來實現，主要有以下原因：

首先，“業務異常”的數據是“小數據”。在“小數據”的基礎上，機器學習在根因分析方面的應用相對有限。
其次，“根因分析”是需要有較強的解釋性的，每次業務異常后，運維工程師都會有完整的異常事件分析報告，機器學習在可解釋性上相對較弱，而專家系統能更好的解釋根因是如何分析出來的，更符合人類的思考邏輯。
最后，利用人類專家“舉一反三”的能力，可以短期內構建出根因分析系統。

因此我們先選擇了專家系統的解決方案，將IT專家的經驗總結起來形成推導規則。

2.6.3 微眾銀行知識圖譜

傳統根因推導過程是運維工程師通過對軟件架構和調用關系的理解將異常發生時的告警、日志等信息聯系在一起，應用運維知識經驗來排查推導異常根因，相當於在大腦中存儲和訓練了一個知識圖譜。其中最大的挑戰在於，運維工程師的知識經驗存在差異而且往往僅精通本領域知識，同時人腦存儲的信息量也相對有限。

圖形數據庫（圖形數據庫是一種非關系型數據庫，應用圖形理論存儲實體之間的關系信息）可以針對每個異常事件創建一個覆蓋多應用域及基礎架構的全專業圖譜，沉淀運維知識進行因果推導。相比於專家規則引擎系統，基於圖數據庫的知識圖譜更利於開發維護，並且具備結合機器學習實現復雜推理和新知識發現的擴展性，可視化的推導鏈路也具有較好的可解釋性易於復盤和優化。

針對異常事件建立的知識圖譜包含每筆異常交易的路徑信息、CMDB 關聯的數據庫等基礎架構信息、相關性分析得出的告警 / 日志 / 變更信息，針對這些數據基於基礎組件影響上層應用等運維知識進行因果推導得出根因，如果存在多種結論則依據加權評分進行可能性排名。

異常事件的知識圖譜是結合“動”態和“靜”態數據來設計，“動”態數據包括業務流水相關的日志、證據數據，“靜”態數據則來自於CMDB等配置系統。兩類數據共同構建起一個完整的異常事件圖譜。一般來說，知識圖譜設計及根因分析一般包括信息收集、根因定位、根因補充三個階段。

2.6.4 京東物流

在做根因分析的時候，我們首先要做的就是要把指標和應用的一些關聯拓撲構建出來。指標和應用的拓撲依賴關系應該如何去構建呢？這主要依賴於分布式跟蹤系統進行自動探測應用拓撲。

但在實際應用中，通常我們探測的拓撲關系比較復雜需要結合人工標注的方式為拓撲增加相應的權重作為拓撲依賴關系的一個修正。有了應用拓撲之間的依賴關系之后，基於大量歷史告警數據進行自學習，分析每個故障時間點應用和指標之間的關聯關系匯總為知識庫數據，並存儲到知識庫系統。

這個不斷完善的知識庫系統可以作為研發定位問題的依據，也可以作為故障自動處理的依據，還可以作為運維機器人的知識來源。同時，知識庫也支持人工添加一些常見的故障以及故障原因並給予較高的分析權重。基於不斷修正的業務拓撲關系，系統就可以自動找出一個或幾個故障的根因。

2.7 平台

2.7.1 京東

京東物流的運維體系規划。最下層是資源層，包括物理資源、虛擬資源、應用、中間件以及數據庫。上層是平台層。

在平台層，我們建立了維護基礎數據的 CMDB 系統，在 ITSM 管理方面，集成了事件管理、問題管理、值班管理等運維流程化管理模塊。在 CMDB 系統基礎上我們建設了大規模資源監控平台、網絡監控平台以及多個運維平台。
再往上，是數據化層。在這一層，我們期望通過對監控和運維平台產生的大量數據進行分析，做趨勢性的預測和智能分析，提供一些比較有價值的統計報表，來指導業務運營和決策。
最上層是 AIOps 層，我們是從三個方面去實現的：發現問題，解決問題，規避問題。基於 AIOps，我們可以在異常檢測、根因分析、故障預測、智能故障處理、智能運維機器人等方面繼續發力探索。在解決問題方面，可以借助 KPI 聚類分析進行告警知識庫自學習和故障自動處理等。

如何從架構方面落地實現的呢？我們將整體系統架構拆分為底層數據處理架構和業務架構，底層數據處理架構負責監控數據的采集、數據清洗、校驗、告警和通知操作。業務架構負責監控數據統計分析、展現。

首先我們采用被動監控的方式，通過部署監控 Agent，把監控數據收集到 Kafka 消息隊列里。消費模塊從 Kafka 拿到數據后轉存到 jimdb（京東內部的內存數據庫中間件）中，jimdb 實際是一個內存的分布式消息隊列。
這里加了一層 jimdb 的隊列。為什么要加這層呢？因為我們如果直接消費 Kafka，Kafka 有分區的概念，不同的分區之間可以並發生產消息，但是 Kafka 的分區是消耗磁盤 IO 的，如果我們建的分區太多，這個磁盤 IO 可能就會是一個瓶頸，而且意味着我們要需要更多的硬件資源。
考慮到這一點，我們增加了 jimdb 層，它是一個生產者消費者模型的分布式消息隊列，理論上可以有無數個 Consumer，這些 Consumer 之間並發消費數據，從而實現並發數據處理。

我們把所有的監控平台的監控數據整合在一起，接入了京東目前所有的監控系統，包括 log 監控、Docker 監控，MDC 的監控，DBS 的數據庫監控，還有調用鏈監控等，把數據收集起來做統一的報警和分析。在 2.0 版本，我們會把所有監控平台的指標收集上來之后，在應用維度做統一的整合。這樣在一個應用頁面，就可以看到這個應用相關的所有監控信息，比如操作系統維度的指標，數據庫相關指標、應用性能相關指標以及日志相關的指標等。

此外，我們還加入了日志分析的相關功能，使用的是業界比較成熟的方案：通過 agent 將日志發送到 Kafka，Kafka 里面做一些 Cluster，Filter，最后存儲和索引。

2.8 APM

2.8.1 京東物流

關於 APM，Google Dapper 可以說是所有 APM 產品的鼻祖。基於 Dapper，近年來也出現了非常多優秀的 APM 產品。除了商業化的 APM 廠商，還有一些比較優秀的開源項目：Pinpoint / Zipkin / Cat / EagleEye / OpenTracing / SkyWalking 等。各種 APM 產品各有優劣，結合自身業務需求並充分對比分析后我們選擇基於 Pinpoint 進行二次開發實現 APM。

它的缺點在於性能方面比 Zipkin、SkyWalking 要差一點，但是 Pinpoint 也有其他項目不具備的優勢，比如接入簡單無需修改代碼，再比如可以跟蹤到代碼級別等等。

目前有很多國內外的廠商都在做 APM 的產品，如果企業計划做 AIOps 的話我們不推薦直接使用廠商的產品，因為廠商的 APM 底層數據對客戶是不透明的。而自主研發 APM 平台最大的意義在於 APM 里面有大量的數據是我們可以使用的，通過對這些基礎數據進行大數據分析以及數據挖掘之后，可以為 AIOps 提供很多數據來源。如果使用廠商的產品，在很多方面底層數據的使用就不是那么自由了。

下面介紹一下我們在 APM 方面的進展，我們基於 Pinpoint 開發的 Jtrace 分布式跟蹤系統擁有 7 大能力：