指標告警演算法
『壹』 ai智能演算法有哪些
智能運維現狀與問題分析
智能運維系統在現今社會中廣泛應用，盡管智能問答系統已經深入我們的生活，但在實際應用中，智能系統對問題的理解和回答往往與用戶期望存在差距，演算法與效果之間的差距明顯。
智能運維的發展歷程已有六七年，涉及對性能指標、日誌告警和CMDB等數據的分析。演算法類型和效果不斷進步，包括指標異常檢測、容量預測、日誌聚類、日誌日常檢測、告警場景挖掘和根因定位等。主要涉及指標異常檢測、日誌智能分析和告警數據分析三個領域。
在指標異常檢測領域，盡管數據准備和效果驗證相對容易，但實際應用中存在誤報過多、模型參數難以設置和缺乏有效反饋和修正機制等問題。日誌智能分析雖然解決了海量日誌的處理問題，但也存在模板質量評估困難和反饋修正機制缺失的問題。告警數據分析領域中，告警模板提取效果不佳和根因定位效果欠佳是主要問題。
智能運維演算法效果不佳的深層次原因主要包括演算法需要不斷迭代優化，當前演算法缺乏有效反饋修正能力，以及系統故障本身為低頻事件，演算法基於歷史數據優化難以適應這一特性。因此，將演算法作為輔助手段，提高運維效率、精度和輔助故障定位，構建知識圖譜等成為更為實際的目標。
為解決上述問題，探索高效反饋機制，如通過異常置信度、日誌模板置信度進行異常篩選和可視化探索，以及利用基於樣例的演算法和小樣本演算法快速實現數據轉化和目標達成。同時，開發基於自然語言的問答系統、基於時間關聯的復雜查詢技術和拖拽式分析流程等數據探索技術，將演算法作為一種高效輔助運維的工具。
總結而言，智能運維中的演算法應用日益廣泛，但實現自動化運維的目標還需時日。當前應將演算法作為提升運維效率、精度和輔助故障定位的輔助工具，通過不斷優化演算法和探索高效的數據探索技術，為運維工作提供有力支持。
『貳』 IT運維平台演算法背後的兩大「神助攻」
智能運維(AIops)是目前 IT 運維領域最火熱的詞彙，全稱是 Algorithmic IT operations platforms，正規翻譯是『基於演算法的 IT 運維平台』，直觀可見演算法是智能運維的核心要素之一。
本文主要談演算法對運維的作用，涉及異常檢測和歸因分析兩拆御隱方面，圍繞運維系統Kale 中 skyline、Oculus 模塊、Opprentice 系統、Granger causality（格蘭傑因果關系）、FastDTW 演算法等細節展開。
一、異常檢測
異常檢測，是運維工程師們最先可能接觸的地方了。畢竟監控告警是所有運維工作的基礎。設定告警閾值是一項耗時耗力的工作，需要運維人員在充分了解業務的前提下才能進行，還得考慮業務是不是平穩發展狀態，否則一兩周改動一次，運維工程師絕對是要發瘋的。
如果能將這部分工作交給演算法來解決，無疑是推翻一座大山。這件事情，機器學習當然可以做到。但是不用機器學習，基於數學統計的演算法，同樣可以，而且效果也不差。
異常檢測之Skyline異常檢測模塊
2013年，Etsy 開源了一個內部的運維系統，叫 Kale。其中的 skyline 部分，就是做異常檢測的模塊， 它提供了 9 種異常檢測演算法 ：
first_hour_average、
simple_stddev_from_moving_average、
stddev_from_moving_average、
mean_subtraction_cumulation、
least_squares
histogram_bins、
grubbs、
median_absolute_deviation、
Kolmogorov-Smirnov_test
簡要的概括來說，這9種演算法分為兩類：
從正態分布入手：假設數據服從高斯分布，可以通過標准差來確定絕大多數數據點的區間；或者根據分布的直方圖，落在過少直方里的數據就是異常；或者根據箱體圖分析來避免造成長尾影響。
從樣本校驗入手：採用 Kolmogorov-Smirnov、Shapiro-Wilk、Lilliefor 等非參數校驗方法。
這些都是統計學上的演算法，而不是機器學習的事情。當然，Etsy 這個 Skyline 項目並不是異常檢測的全部。
首先，這里只考慮了一個指標自己的狀態，從縱向的時序角度做旅廳異常檢測。而沒有考慮業務的復雜性導致的橫向異常。其次，提供了這么多種演算法，到底一個指標在哪種演算法下判斷的更准？這又是一個很難判斷的事情。
問題一： 實現上的抉擇。同樣的樣本校驗演算法，可以用來對比一個指標的當前和歷史情況，也可以用來對比多個指標里哪個跟別的指標不一樣。
問題二： Skyline 其實自己採用了一種特別朴實和簡單的辦法來做補充——9 個演算法每人一票，投票達到閾值就算數。至於這個閾值，一般算 6 或者 7 這樣，即佔到大多數即可。
異常檢測之Opprentice系統
作為對比，面對相同的問題，網路 SRE 的智能運維是怎麼處理的。在去年的 APMcon 上，網路工程師描述 Opprentice 系統的主要思想時，用了這么一張圖：
Opprentice 系統的主體流程為：
KPI 數據經過各式 detector 計算得到每個點的諸多 feature；
通過專門的交互工具，由運維人員標記 KPI 數據的異常時間段；
採用隨機森林演算法做異常分類。
其中 detector 有14種異常檢測演算法，如下圖：
我們可以看到其中很多演算法在 Etsy 的 Skyline 里同樣存在。不過，為避免給這么多演算法調配參數，直接採用的辦法是：每個參數的取值范圍均等分一下——反正隨機森林不要求什麼特徵工程。如，用 holt-winters 做為一類拆滾 detector。holt-winters 有α，β，γ 三個參數，取值范圍都是 [0, 1]。那麼它就采樣為 (0.2, 0.4, 0.6, 0.8)，也就是 4 ** 3 = 64 個可能。那麼每個點就此得到 64 個特徵值。
異常檢測之
Opprentice 系統與 Skyline 很相似
Opprentice 系統整個流程跟 skyline 的思想相似之處在於先通過不同的統計學上的演算法來嘗試發現異常，然後通過一個多數同意的方式/演算法來確定最終的判定結果。
只不過這里網路採用了一個隨機森林的演算法，來更靠譜一點的投票。而 Etsy 呢？在 skyline 開源幾個月後，他們內部又實現了新版本，叫 Thyme。利用了小波分解、傅里葉變換、Mann-whitney 檢測等等技術。
另外，社區在 Skyline 上同樣做了後續更新，Earthgecko 利用 Tsfresh 模塊來提取時序數據的特徵值，以此做多時序之間的異常檢測。我們可以看到，後續發展的兩種 Skyline，依然都沒有使用機器學習，而是進一步深度挖掘和調整時序相關的統計學演算法。
開源社區除了 Etsy，還有諸多巨頭也開源過各式其他的時序異常檢測演算法庫，大多是在 2015 年開始的。列舉如下：
Yahoo! 在去年開源的 egads 庫。(Java)
Twitter 在去年開源的 anomalydetection 庫。(R)
Netflix 在 2015 年開源的 Surus 庫。(Pig，基於PCA)
其中 Twitter 這個庫還被 port 到 Python 社區，有興趣的讀者也可以試試。
二、歸因分析
歸因分析是運維工作的下一大塊內容，就是收到報警以後的排障。對於簡單故障，應對方案一般也很簡單，採用 service restart engineering~ 但是在大規模 IT 環境下，通常一個故障會觸發或導致大面積的告警發生。如果能從大面積的告警中，找到最緊迫最要緊的那個，肯定能大大的縮短故障恢復時間(MTTR)。
這個故障定位的需求，通常被歸類為根因分析（RCA，Root Cause Analysis）。當然，RCA 可不止故障定位一個用途，性能優化的過程通常也是 RCA 的一種。
歸因分析之 Oculus 模塊
和異常檢測一樣，做 RCA 同樣是可以統計學和機器學習方法並行的~我們還是從統計學的角度開始。依然是 Etsy 的 kale 系統，其中除了做異常檢測的 skyline 以外，還有另外一部分，叫 Oculus。而且在 Etsy 重構 kale 2.0 的時候，Oculus 被認為是1.0 最成功的部分，完整保留下來了。
Oculus 的思路，用一句話描述，就是：如果一個監控指標的時間趨勢圖走勢，跟另一個監控指標的趨勢圖長得比較像，那它們很可能是被同一個根因影響的。那麼，如果整體 IT 環境內的時間同步是可靠的，且監控指標的顆粒度比較細的情況下，我們就可能近似的推斷：跟一個告警比較像的最早的那個監控指標，應該就是需要重點關注的根因了。
Oculus 截圖如下：
這部分使用的 計算方式有兩種：
歐式距離，就是不同時序數據，在相同時刻做對比。假如0分0秒，a和b相差1000，0分5秒，也相差1000，依次類推。
FastDTW，則加了一層偏移量，0分0秒的a和0分5秒的b相差1000，0分5秒的a和0分10秒的b也相差1000，依次類推。當然，演算法在這個簡單假設背後，是有很多降低計算復雜度的具體實現的，這里就不談了。
唯一可惜的是 Etsy 當初實現 Oculus 是基於 ES 的 0.20 版本，後來該版本一直沒有更新。現在停留在這么老版本的 ES 用戶應該很少了。除了 Oculus，還有很多其他產品，採用不同的統計學原理，達到類似的效果。
歸因分析之 Granger causality
Granger causality（格蘭傑因果關系）是一種演算法，簡單來說它通過比較「已知上一時刻所有信息，這一時刻 X 的概率分布情況」和「已知上一時刻除 Y 以外的所有信息，這一時刻 X 的概率分布情況」，來判斷 Y 對 X 是否存在因果關系。
可能有了解過一點機器學習信息的讀者會很詫異了：不是說機器只能反應相關性，不能反應因果性的么？需要說明一下，這里的因果，是統計學意義上的因果，不是我們通常哲學意義上的因果。
統計學上的因果定義是：『在宇宙中所有其他事件的發生情況固定不變的條件下，如果一個事件 A 的發生與不發生對於另一個事件 B 的發生的概率有影響，並且這兩個事件在時間上有先後順序（A 前 B 後），那麼我們便可以說 A 是 B 的原因。』
歸因分析之皮爾遜系數
另一個常用的演算法是皮爾遜系數。下圖是某 ITOM 軟體的實現：
我們可以看到，其主要元素和採用 FastDTW 演算法的 Oculus 類似：correlation 表示相關性的評分、lead/lag 表示不同時序數據在時間軸上的偏移量。
皮爾遜系數在 R 語言里可以特別簡單的做到。比如我們拿到同時間段的訪問量和伺服器 CPU 使用率：
然後運行如下命令：
acc_count<-scale(acc$acc_count,center=T,scale=T)
cpu<-scale(acc$cpuload5,center=T,scale=T)
cor.test(acc_count,cpu)
可以看到如下結果輸出：
對應的可視化圖形如下：
這就說明網站數據訪問量和 CPU 存在弱相關，同時從散點圖上看兩者為非線性關系。因此訪問量上升不一定會真正影響 CPU 消耗。
其實 R 語言不太適合嵌入到現有的運維系統中。那這時候使用 Elasticsearch 的工程師就有福了。ES 在大家常用的 metric aggregation、bucket aggregation、pipeline aggregation 之外，還提供了一種 matrix aggregation，目前唯一支持的 matrix_stats 就是採用了皮爾遜系數的計算，介面文檔見：
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-matrix-stats-aggregation.html
唯一需要注意的就是，要求計算相關性的兩個欄位必須同時存在於一個 event 里。所以沒法直接從現成的 ES 數據中請求不同的 date_histogram，然後計算，需要自己手動整理一遍，轉儲回 ES 再計算。
饒琛琳，目前就職日誌易，有十年運維工作經驗。在微博擔任系統架構師期間，負責帶領11人的SRE團隊。著有《網站運維技術與實踐》、《ELKstack權威指南》，合譯有《Puppet 3 Cookbook》、《Learning Puppet 4》。在眾多技術大會上分享過自動化運維與數據分析相關主題。
『叄』 IT異常監測告警的探索與研究——動態閾值
隨著信息技術的迅猛發展，現代企業對IT系統的穩定性要求日益提高。然而，各種異常行為，如硬體故障、軟體錯誤和網路攻擊，嚴重影響了企業的運營和安全。因此，IT異常監測成為了至關重要的任務。傳統的固定閾值告警方式依賴專家經驗進行規則配置，無法根據業務場景靈活調整閾值，無法提供及時有效的警告和響應。本文通過探索在IT異常監測中使用動態閾值的方法，以實現更加智能化的IT系統異常行為監測。
數據特徵分析是IT異常監測的基礎，基於監控歷史數據，如日誌、指標和應用信息，分析時序數據的變化規律，以選取合適的演算法。特徵分析揭示了數據分布的三種主要型態：平穩型、周期型和趨勢型。平穩型數據在極小范圍內波動，周期型數據受早晚高峰或定時任務影響，趨勢型數據隨著時間推移出現顯著變化或全局突變點。為准確捕捉數據的最新趨勢，需判斷歷史數據中是否存在均值漂移。
時序建模基於當前數據的統計特徵和歷史數據的分析。數據區間選擇需至少包含一個完整周期的數據，進行平滑處理以去除異常點干擾，數據預聚合則用於匯總和降維，優化數據處理效率和降低計算成本，同時保留重要特徵和統計信息。在此基礎上，移動平均演算法作為動態閾值計算方法被選擇。移動平均演算法平滑數據並識別趨勢，通過計算數據平均值去除隨機波動，突出長期變化。簡單移動平均適用於平穩性和周期性數據，而指數移動平均適用於存在遞增或遞減趨勢的數據。
實時監測是IT異常監測的關鍵環節。載入模型計算閾值後，結合流式數據處理和實時監控技術，對實時數據進行快速分析和計算，一旦監測到異常行為，自動觸發規則引擎並及時發送告警通知。
基於動態閾值的IT異常監測方法在提高企業運營效率和安全性方面展現出巨大潛力。通過數據建模、學習和實時處理，可以自動監測異常行為並提供即時警報和響應。然而，仍面臨數據量龐大、時序類別多樣性和實時處理挑戰。持續的研究和技術創新有助於解決這些問題，實現多種類型海量指標的自動異常監測。此外，告警收斂、降噪和抑制規則和演算法的探索與研究，旨在提供更加精簡有效的信息，減少告警風暴和干擾。