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

本文為本人的學習筆記，非商用。目的是對于所學習的技術，大緻知道其應用領域，技術特點和未來方向，看看目前工作中是否可以用到，或者以後選型時能夠做到心裡有數，順便也可以梳理清楚自己的知識體系。

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

目錄

• • 2.1 容量預估
  • 2.2 主機分類
  • 2.3 負樣本不足
  • 2.4 異常檢測
  • 2.5 報警收斂
  • 2.6 根因分析
  • 2.7 平台
  • 2.8 APM
  • 2.1.1 360
  • 2.1.2 京東物流
  • Z-score算法
  • Boxplot算法
  • 時間序列分解算法
  • 多工況檢測算法
  • 2.4.1 360公司
  • 2.4.2 美團外賣訂單量預測異常報警模型
  • 2.4.3 微衆銀行
  • 2.4.3 華為
  • 2.5.1 360
  • 2.5.2 美團
  • 2.6.1 360 模型
  • 2.6.2 微衆銀行專家系統
  • 2.6.3 微衆銀行知識圖譜
  • 2.6.4 京東物流
  • 2.7.1 京東
  • 2.8.1 京東物流
  • 1.1 AIOps概述
  • 1.2 AIOps場景
  • 1.3 AIOps能力
  • 1.4 AIOps的基礎
  • 0x00 摘要
  • 0x01 AIOps 背景
  • 0x02 一些值得借鑒的方案
  • 0xFF 參考

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

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

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

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

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

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

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

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

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

• 日志标準化：日志包含所約定的内容、格式，能辨別自己的業務線、服務層級等。
• 全鍊路追蹤：TraceID或者RequestID應該能從發起方透傳到後端，辨別唯一請求。
• SLA規範化：采用統一的SLA約定，比如都用“響應時間”來約定性能名額，用“慢速比”來衡量系統健康度。

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

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

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

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

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

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

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

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

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

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

同比環比預測器

同比環比是比較常用的異常檢測方式，它是将目前時刻資料和前一時刻資料（環比）或者前一天同一時刻資料（同比）比較，超過一定門檻值即認為該點異常。

基線預測器

同比環比使用曆史上的單點資料來預測目前資料，誤差比較大。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)時報警。實際使用中，可以尋找一個對數函數替換分段門檻值函數，更易于參數調優。

微衆銀行目标是使用機器學習算法實作無門檻值KPI曲線異常識别。

“微衆銀行智能監控系統識圖子產品”是針對業務四大黃金名額而設計的智能曲線異常檢測系統。四大黃金名額包括交易量(業務實時産生的交易量)、業務成功率(業務成功量/交易量)、系統成功率(系統成功量/交易量, 業務成功量和系統成功量的差別在于是否明确捕捉到系統異常)、平均時延(交易的平均耗時)。這四大黃金名額都是分鐘級資料，這四個名額統計次元不同，波動規律也有所差别，是以需要用不同的算法檢測。

檢測方法主要有三種：

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

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

首先是資料源的異常檢測。

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

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

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

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

資料源的異常檢測解決好後，名額的異常檢測就有了基礎。

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

因為使用者少，少量使用者的異常失敗就會導緻整個名額下降30%甚至更多，而且每天發生這種下降的随機性很強。

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

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

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

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

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

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

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

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

算法描述

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

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

一個是事件次元，關注的是六大類報警事件；

一個是名額次元，關注機器次元的監控項（大約有200左右個監控項）。

那如何在事件發生後，找到跟它相關的名額呢？實作的方法如下：

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

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

1. 針對第一步選出來的名額，求出這些名額的資訊增益比，選擇前k個（360取得值是5）特征作為最後的影響名額；
2. 最後使用xgboost對影響名額進行分類，驗證效果。

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

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

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

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

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

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

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

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

但在實際應用中，通常我們探測的拓撲關系比較複雜需要結合人工标注的方式為拓撲增加相應的權重作為拓撲依賴關系的一個修正。有了應用拓撲之間的依賴關系之後，基于大量曆史告警資料進行自學習，分析每個故障時間點應用和名額之間的關聯關系彙總為知識庫資料，并存儲到知識庫系統。

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

京東物流的運維體系規劃。最下層是資源層，包括實體資源、虛拟資源、應用、中間件以及資料庫。上層是平台層。

• 在平台層，我們建立了維護基礎資料的 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，最後存儲和索引。

關于 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 大能力：

• 分布式事務跟蹤；
• 自動檢測應用拓撲；
• 水準擴充支援大規模服務叢集；
• 代碼級别的可見性，這是相對于其他産品最大的不同，它可以跟蹤方法堆棧，特别清晰；
• 使用位元組碼增強；
• 內建了 SQLAdvisor，在抓到 SQL 之後，我們會分析到哪些是比較慢的 SQL，慢的 SQL 到底慢在哪裡，我們可以通過這個給出一些優化建議；
• 智能化采樣率，基于業務通路量自動調整采樣率，大大降低了業務性能方面的開銷。

關于性能方面，我們從以下幾個方面進行了優化：

• 使用二進制格式（thrift 協定），高壓縮比，在網絡傳輸上可以減輕很多開銷；
• 使用變長編碼和格式優化資料記錄（thrift  CompactProtocol）；
• 用常量表替換重複的 API 資訊，SQL 語句和字元串；
• 智能采樣率；
• 使用異步資料傳輸來最小化應用線程中止；
• 使用 UDP 協定傳輸資料。

優化後性能損失與目前流行的 Zipkin 相近。相對于我們擷取的資料精度來說，這個是可以接受的結果。

時間序列異常檢測算法梳理

微衆銀行智能運維AIOps系列| 淺析智能異常檢測：“慧識圖”核心算法（三）

時間序列異常檢測（一）—— 算法綜述

https://tech.meituan.com/2017/04/21/order-holtwinter.html

https://github.com/Microsoft/TagAnomaly

https://github.com/baidu/Curve

https://github.com/Tencent/Metis

https://github.com/yahoo/egads

https://github.com/Netflix/Surus

https://github.com/rob-med/awesome-TS-anomaly-detection

https://github.com/yzhao062/anomaly-detection-resources

https://github.com/dsmi-lab-ntust/AnomalyDetectionToolbox

https://github.com/jeroenjanssens/phd-thesis

https://www.xenonstack.com/blog/time-series-analysis/

智能運維（AIOps）中幾處問題的解決方案與思路

AIOps智能運維之三：無監督異常檢測

技術幹貨 | 日志易産品總監饒琛琳：資料驅動的智能運維平台

從人肉到智能，阿裡運維體系經曆了哪些變遷？

AIOps探索：基于VAE模型的周期性KPI異常檢測方法

https://github.com/NetManAIOps/donut

一文講明白AIOps是什麼，有什麼用？看看你們公司能不能用到

AIOPS在360的實踐和探索

基于時間序列的異常檢測算法小結

億級使用者百TB級資料的 AIOps 技術實踐之路（增強版）

百度雲說 | 從0到1，AIOps領先業内的實踐之路