複雜異常檢測如何快速落地？看看百度怎麼作

本文做者：AIOps智能運維

做者簡介

周偉    百度雲高級研發工程師

 

負責百度雲智能運維（Noah）告警通告系統的設計和研發，在大規模分佈式系統、運維監控、精準報警等方面具備普遍的實踐經驗。

 

乾貨概覽

本文提到的異常檢測（Anomaly Detection）特指在運維領域中對時序數據的異常檢測，目的是爲了發現時序數據中狀態的變化。

在咱們看來，異常檢測通常可分爲兩類：簡單異常檢測和複雜異常檢測

• 簡單異常檢測：通常指恆定閾值檢測，好比判斷可用性指標是否小於99.99%，若是小於則檢測結果爲異常，不然檢測結果爲正常。簡單恆定閾值檢測通常適用於可用性、資源利用率等監控指標。

• 複雜異常檢測：對於收入、錯誤率、流量等業務監控指標，須要檢測天/周/月/年等環比變化或者突增突降等狀態變化，這類業務監控指標的維度特徵較多（好比地域、運營商等），特徵變化也比較快（例如電商按期搞活動，流量瞬間漲起來，干擾正常的異常檢測）。恆定閾值檢測每每沒法檢測到這類業務監控指標的狀態變動，因此還須要複雜異常檢測算法來檢測業務監控指標的異常。爲了發現監控指標的狀態變化，複雜異常檢測每每會採用機器學習、深度學習等比較複雜的技術。

和簡單異常檢測相比，複雜異常檢測對落地流程和異常檢測的運行平臺提出了更高的要求。

落地複雜異常檢測的阻塞點

爲了支持簡單異常檢測，異常檢測的運行平臺只須要可以支持用戶添加自定義報警判斷規則便可。好比，對於上面提到的可用性指標，用戶能夠在系統中將報警判斷規則配置爲表達式「SLI < 99.99％」，而後等着接收報警就能夠了。

然而對高級異常檢測算法，算法從研發到上線，通常須要包括如下三步：

1. 線下編寫算法腳本（通常是Matlab或Python腳本），並根據歷史數據，離線訓練算法所依賴的參數，經過用歷史Case進行回溯驗證效果。在這個過程當中，算法工程師須要反覆調整算法參數，直到準確率和召回率都達到目標爲止。

2. 將算法腳本改寫成線上代碼（通常是C++、JAVA語言等編譯型語言）。這是由於線下編寫的算法代碼通常和線上運行代碼使用不一樣語言開發，線下實驗算法代碼更側重研發效率，須要快速迭代和測試，而線上運行代碼更側重運行效率，高效穩定運行。

3. 最後將改寫後的算法代碼生效到線上，並觀察其運行穩定性和資源消耗狀況，及時調整線上資源分配狀況。

以上流程在實踐的過程當中存在若干阻塞點，致使複雜算法落地時間長，算法迭代效率低：

1. 線下實驗的過程當中，歷史數據、歷史Case、不一樣實驗所使用的算法、參數和效果全靠人工管理，經常出現指標數據不全，歷史Case不全，實驗過程兜圈子的狀況。

2. 線下代碼和線上代碼開發語言不同，代碼移植須要消耗比較多的時間，經常不能保證線上代碼和線下代碼的效果徹底一致。

3. 一些複雜算法對資源的消耗很大，貿然上線會影響監控系統部分或總體的穩定性。

落地複雜異常檢測的需求

上述阻塞點很容易致使算法迭代速度跟不上指標變化速度的狀況，最終限制了檢測效果的提高。因此，爲了保證算法的順利落地，咱們須要提供一個新的異常檢測支持方案，知足如下的需求：

1. 須要一個方便算法快速迭代和算法驗證的環境，用於在線下調試算法腳本，並對歷史Case回溯，保證算法的普適性。

2. 須要能彌合線下腳本和線上代碼鴻溝的機制，儘快將算法生效到線上，能快速驗證算法代碼的真實效果，不然線下實驗腳本和線上生效代碼遷移成本過高，費事費力費程序員。

3. 須要評估線上代碼的資源消耗和穩定性狀況。由於複雜異常判斷算法，其資源需求差別性特別大，好比有的會採用深度學習等很是耗CPU/GPU的算法，而有的僅僅是簡單公式計算。另外，這類算法開發迭代特別快，算法代碼很容易引入Bug，因此須要在不影響其餘線上算法運行的同時，採用線上真實流量驗證算法穩定性。

4. 須要分離算法代碼和算法參數，並支持算法參數的獨立更新。由於算法通過快速迭代後，會逐漸穩定下來，可是算法的參數是對歷史數據的特徵表達，因此算法所依賴的參數須要週期性更新，保障算法達到最優效果。

落地方案

爲了解決上述問題和需求，咱們推出了異常檢測運行平臺。基於運行平臺，算法工程師能夠用腳本語言（當前支持Python腳本語言）線下編寫異常檢測算法，並在線下回溯歷史Case，當策略調試完畢後，能夠直接將Python算法腳本生效到到線上。同時，還支持算法參數的獨立更新，大大加快算法的生效速度。

異常檢測運行平臺包括三個環境：離線環境、在線環境、近線環境，下面詳細介紹。

1 離線環境

離線環境會提供如圖1所示的策略開發框架，異常開發框架提供了Python運行環境和經常使用的Python庫，基於開發框架，算法工程師採用一致的抽象接口編寫算法代碼，這樣能夠保證在線下開發的算法代碼能夠直接放到線上環境運行，從而彌合線下腳本和線上代碼鴻溝。爲了回溯Case，開發框架還提供了歷史時序數據組件、異常判斷評價組件（支持準確率、召回率、F1 Score等評價指標）。因爲複雜異常檢測算法不像恆定閾值算法能夠根據數據直觀看出判斷結果，複雜異常檢測算法每每須要運行並輸出異常判斷結果（能圖形化展現更好），才能評估算法效果，因此開發框架提供了圖形組件，能夠圖形化展現異常檢測結果。

圖1  策略開發框架

圖2展現了算法開發接口，其中包括四個標準接口：

• load_model函數負責加載算法參數；

• get_data函數負責加載指定時間段的歷史時序數據；

• initialize函數負責在算法正式運行前進行初始化，好比加載算法參數、申請內存等等；

• detect函數負責對時序數據點進行異常檢測，並返回異常檢測結果（正常或異常）。

圖2  用於高級異常檢測的抽象接口

2 在線環境

算法工程師在線下環境基於開發框架開發完策略算法後，能夠將算法發佈到在線環境。在線環境提供了跟策略開發框架一致接口的策略運行時環境。策略運行時環境會接收上游發送的時序數據，並驅動Python算法腳本週期性運行，同時將產生的異常判斷結果發送到下游，用於報警通告。

圖3  在線環境架構

在線環境的架構圖如圖3所示，在線環境主要包括如下三個模塊：

• 任務分發模塊：負責管理運維人員提交的高級異常檢測算法配置，並將每一個算法配置組裝成任務，分配給任務運行模塊。

• 數據調度模塊：數據調度模塊週期性從任務管理模塊同步任務的分配信息，根據任務分配信息，將每一個任務所需的數據調度給相應的任務運行模塊，同時將數據也Copy一份，寫入到時序數據緩存中。

• 任務運行模塊：任務運行模塊週期性從任務分發模塊拉取分配到的任務，併爲每一個任務啓動一個策略運行時環境。策略運行時環境支持跟開發框架相同的接口，因此能夠直接驅動基於開發框架開發的算法代碼的運行。策略運行環境剛啓動的時候，會調用intialize函數，進行初始化操做，而後策略運行環境不斷接收數據調度模塊調度過來的數據，並驅動調用detect函數，detect函數會對接收到的數據進行判斷，並返回判斷結果（正常或異常），運行時環境收到判斷結果後，將其發送到下游，用於報警發送。有時算法在剛啓動或運行的時候，須要拉取近期的時序數據，這時經過get_data函數從時序數據緩存中獲取便可。另外，任務運行時環境還會週期性檢測算法依賴的參數是否有變動，若是算法參數被更新了，則會調用load_model函數從新加載配置。

3 近線環境

在線下環境編寫算法代碼，若是直接貿然上線到在線環境，每每會存在不少問題，因此策略算法在離線環境驗證可用後，首先會放到近線環境運行起來，近線環境和線上環境的架構和功能其實沒有本質差異，只是用途不一樣而已。近線環境的目的，一方面是爲了用線上真實流量數據來驗證算法的資源消耗，以發現算法運行的真實資源需求，只是不真正發送告警而已；另外一方面，是爲了驗證算法的穩定性，好比是否有內存泄漏、是否有崩掉、是否有錯誤日誌等等。若是發現有問題，算法工程師能夠快速調整並從新部署到近線環境進行驗證。

總  結

本文主要介紹了異常檢測的相關背景、應用場景和需求分析，而後咱們給出了百度雲的高級異常檢測算法快速落地方案——異常檢測運行平臺。目前運行在這套異常檢測運行平臺上的高級算法超過20個，天天處理近千萬監控指標的異常判斷。算法的線上迭代週期從周級別減小到天或小時級別，很好地支撐了業務方對不一樣高級異常檢測的需求。另外，咱們還將平臺開放給業務運維人員使用，由業務運維人員研發的異常檢測算法能夠有效引入業務線人員的專家經驗。

關於高級異常檢測算法的落地，有任何想法和疑問，歡迎留言一塊兒交流。

原文連接地址：https://developer.baidu.com/topic/show/290332