基于無監督學習的接口異常檢測及根因定位方法

孫健飛

中國移動通信集團江蘇有限公司

0 引言

當前，業務故障發現主要依賴對黃金指標（如交易量、交易響應時間、交易成功率）設定閾值或者同環比的對比。這種檢測方法適用場景單一，在面對業務系統中大量差異化的KPI 數據檢測時顯得力不從心；對監控指標需配置大量規則，且無法做到規則與業務指標的準確匹配，導致誤告警數量較多，需要投入人力篩選出有效告警。告警出現后，需對日志、報文進行分析排查原因，無法快速有效地判定根因。近年來，系統運維領域開始應用AIops 技術，以期提升運維效率，減少人工成本，但當前的技術主要采用有監督學習算法進行異常檢測，采用單維分析方法進行故障根因定位，存在以下問題：

有監督學習易用性差：現有的AIops 算法，基本為有監督學習，使用時需要大量的人工標注；難以適應多樣時間序列的數據特性，難以支持不同領域的異常檢測，普適性較差；為獲得更好的效果，需要頻繁調整參數，易用性較差。

單維分析根因定位難：故障出現后，需要人工對日志、報文進行分析排查原因，隨著接口依賴關系的增多，不僅需要分析接口本身性能，還需要人工從地市、渠道、分組、資源池等多個維度，進行聯合分析，工作量巨大且難以快速有效根因定位。

因此，如何快速有效進行接口監控及故障定位是亟待解決的問題。

1 研究背景

軟件系統作為服務或者能力提供方，通常以接口的形式對外提供服務，供外部渠道調用。為了便于對內部系統的服務接口進行集中化管理，一般將能力開放平臺作為內外部系統交互的樞紐，將內部系統的接口信息在能力開放平臺進行注冊，由該平臺作為對外提供服務的核心網關，便于對服務接口進行統一管理，包括注冊、注銷、業務量監控、失敗告警、性能監測等。

隨著業務規模的快速發展以及外部需求的日益增多，內部系統服務接口數量也越來越多，如何對這些接口準確地進行異常指標檢測、故障預警、根因定位，第一時間提醒運維人員介入處理，成為亟待解決的運維難題。目前，能力開放平臺對所有接口都配置了固定閾值監控，但是存在閾值設置依賴運維專家經驗、閾值大小設定不合理、無法通過固定閾值覆蓋全部接口、告警誤報漏報、告警后根因定位困難等問題，亟待采用一套智能化的、快速精準的接口異常檢測及根因定位方法，進行接口故障預警和性能管理。

2 方案描述

2.1 整體方案

搭建大數據處理平臺，接入能力開放平臺實時訪問日志，按分鐘級聚合出接口交易量、響應時間、成功率、響應率等核心指標。

建設業務指標異常檢測和根因定位算法引擎，實現的算法包括變分自編碼器、漸進梯度回歸樹、差分指數滑動平均、極值理論、周期性中值檢測、LightGBM、蒙特卡洛搜索樹等。

實現基于動態閾值的告警設定、告警列表查看、異常指標詳情查詢、根因定位查詢、算法頁面調參、模型訓練等多種功能。

算法引擎對接大數據處理平臺數據，實現業務指標實時異常檢測，發現異常后發送告警短信，并自動觸發根因定位算法，給出故障根因，縮小故障排查范圍。系統架構及數據流圖如圖1 所示。

圖1 系統架構及數據流圖

2.2 功能架構

系統主要包括采集、存儲、分析、服務、展示這5 個層級。

采集層：包括數據源層和數據處理層，通過Kafka 實時對接能力開放平臺接口訪問數據；

存儲層：主要存儲時序指標、日志文檔、系統設置；

分析層：實時聚合計算能開訪問數據，供業務指標異常檢測算法和業務多維根因定位算法消費；

服務層：整合分析結果，向上層提供展示接口；

展示層：告警信息、指標異常波動、根因定位分析、儀表盤統一展示。

3 方法實現

通過引入AI 組合算法，結合接口歷史數據指標進行無監督學習，可對接口的成功率、響應時長、失敗量等性能指標進行實時異常檢測，通過動態閾值觸發機制實現智能告警，相較于傳統的固定閾值觸發告警，準確度更高。異常檢測后，從故障接口出現時間段的大量交易明細中，利用渠道、應用集群、業務可用性等維度組合檢測故障前后指標的劣化趨勢進行根因排序，可快速對故障進行定界分析。

3.1 引入時序數據解析框架，提升海量數據處理能力

搭建大數據處理平臺，接入能力開放平臺實時訪問日志，按照接口分類分鐘級聚合出交易量、響應時間、成功率、響應率等核心指標。通過Kafka 搭建海量時序數據隊列，以滿足數據短期內接入的緩沖需求，并選擇ElasticSearch 和InfluxDB 作為日志和指標兩類時序數據的主要持久化數據庫，以滿足大量日增時序數據的歸檔和索引需求。

方案數據管理根據存儲策略和對應存儲方式，將數據架構分為數據管道、模型配置存儲、日志持久存儲和指標持久存儲四個模塊，架構模型如圖2 所示。

圖2 數據管理架構模型

在數據處理設計上，提供流式數據處理組件，通過拖拽方式，對指定數據源數據進行格式清洗，并輸出到指定數據源。

3.2 構建業務指標異常檢測算法引擎，實現動態閾值告警

業務指標異常檢測的整體架構設計如圖3 所示。

圖3 異常檢測設計架構

特征描述器：對于一條時間序列，首先對其特征進行表述。關注的特征包括：通過算法自動找到時間序列的周期、是否具有向上/向下的趨勢性、周期偏移情況、數據抖動程度、上下界極限值、是否可以用閾值的方法、閾值采用多少合適。經過特征描述器描述后的數據會帶有KPI 的關鍵特性信息，交給檢測器。

檢測器：根據時間序列的特征，計算資源的分配以及數據的時間，合理選用不同的模型組合來訓練并生成對應的模型。通過分析KPI 歷史數據，提取各項指標的關鍵特征，最終生成檢測模型供后續分類器進行異常判斷。

分類器：根據當前數據特性，并對比檢測器提供的模型特性，最終給出檢測結果。

實現算法：變分自編碼器、漸進梯度回歸樹、差分指數滑動平均、極值理論、周期性中值檢測。

數據積累到一定程度即可開始在實際環境中在線檢測，在線檢測使用已訓練好的模型對應的關鍵特征生成算法來生成新的時間點的特征，并用已訓練好的模型對新的時間點的異常程度打分，在線檢測的過程中，需要對以下實際問題進行處理：

（1）缺點：某一固定時間采集點沒有數據。

（2）亂序：后面的時間先到異常檢測算法，而之前時間的點還在隊列中。

（3）特征變化：由于新的部署等情況，時間序列的特征與之前不一樣。

對于每個時間點對應的值，算法可以給出一個異常分數，根據異常檢測的默認閾值，可以給出一個點是否是異常的結果，由于現實中時間序列的含義千差萬別，一樣的時間序列如果含義不同，預期的異常檢測效果可能會不一樣，所以提供敏感度供用戶調整以達到用戶滿意的效果（用戶唯一需要調整的參數，而且大多數時候并不需要調整），如果用戶不知道如何調整敏感度以達到他們預期的效果，方案也提供標注反饋的方式，用戶將他認為的異常漏報和正常誤報標出，算法可以自動調整以達到用戶預期的效果。

針對不同的場景，選擇適合的算法來進行異常檢測。大量的實驗表明，沒有一種算法或者開源解決方案能夠處理多樣的時間序列類型，而本方案的單指標異常檢測算法也是多個算法的組合，通過特征描述器來指導用戶選擇特征和模型。

3.3 建立根因智能分析方法，快速定位接口降質原因

KPI 指標（請求量、失敗量、響應時間等）與多維屬性（能力提供方、地市、渠道等），是接口重要的監控內容。當一個KPI 的總體值發生異常時，想要解除異常，定位出導致該異常的根因所在的位置是關鍵一步，然而，這一步常常是充滿挑戰的，尤其當根因是多個維度屬性值組合的時候。主要困難和挑戰有以下兩個方面：

（1）不同組合的訪問量是相互依賴和影響的，真正的根因元素的訪問量異常，可導致其他元素的訪問量發生變化。

（2）由于KPI 擁有多維屬性，因此隨著維度的增加或粒度的細化，元素的數目往往呈現指數級增長趨勢，可能需要在成千上萬的多維屬性空間進行搜索。

一種典型場景，當某個業務出現問題時，結合該業務多維度屬性信息（例如地市、機房、交易類型等）盡可能準確地找到故障的根因集合，盡快恢復系統故障。

要解決上述問題，首先，需要解決由于元素間存在復雜關系導致的難以衡量任意一個元素集合接近根因的程度，本方案提出評判多維指標體系中元素集合是異常根因的可能性的評分方法。其次，為了解決巨大空間的搜索問題，使用“先聚類，再搜索”的搜索策略，以及多種剪枝方法，在不影響結果的前提下降低復雜度。

業務指標多維根因定位的整體架構設計如圖4 所示。

圖4 業務指標多維根因定位設計架構

當告警發生后，系統自動觸發多維分析算法。算法會選取告警發生前后幾分鐘內的數據作為根因定位的源數據。根據告警發生時刻的維度組合對其他時間的數據進行缺失值填充、按維度聚合、KPI 計算等。例如，當某接口成功率異常，系統會選取異常時間點前后的一批數據按照地市、提供方、渠道、IP 等分維度進行預處理。處理完成后系統根據其數據規模來判斷采用何種檢測方式。算法采用的是可加和指標（整體指標值可由下層指標加和得到，例如，總交易量指標由各交易量相加得出）檢測，維度組合分析過程中，其分析路徑為一個樹狀的結構。在維度過多時，葉子節點的交易量會非常小，極限情況下只會在0-1 之間波動，此時再使用葉子節點的變化來衡量上層節點的“影響”（Potential Score）會不準確，所以數據評估的主要作用就是根據數據量選擇部分異常檢測或全局異常檢測。檢測完成后，系統針對每一個維度組合的異常檢測得分進行極大值、極小值聚類，根據聚類結果確定搜索順序。系統的維度指標通常較多，所以其維度組合也較多，如果對所有的維度組合都進行根因搜索，計算量巨大，對系統性能消耗嚴重，所以要對不相關的維度組合進行“剪枝”，“剪枝”過后的維度組合就會形成備選根因素的集合，最后經過組合、合并形成最終的分析結果。多維指標異常檢測示意如圖5 所示。

圖5 多維指標異常檢測示意圖

規模較小的數據只對最外層（淺藍色）維度組合進行異常檢測，內層異常得分直接來源于其子節點加和。方案會根據參考的歷史時間序列長度以及算法訓練的時間綜合選擇不同的異常檢測算法。主要用到的算法有LightGBM、極值理論。

4 應用效果

目前，該方案已應用于生產系統主要接口。接口觸發告警時，將系統智能識別的結果與運維人員判定進行對比，結果一致，減少了運維人員手動排查問題的工作量。

2021 年06 月17 日17：27：00，接口VOUCHER 響應時間突增到4.1 秒，響應率突降到61%，系統成功率突降到61%，如圖6 所示。

圖6 接口指標異常檢測實例

業務指標異常發生后，系統自動觸發多維度根因定位算法進行根因分析，如圖7 所示。

圖7 指標多維根因分析實例

原因分析：經過系統對告警觸發的維度因素及數據的智能化分析，推薦出引發本次告警的TOP3 維度組合，包括接口使用方（CHANNEL_ID）、接口提供方（APPLYER_ID）、 主機（HOST）， 從圖10 中可以看出， 具 體 為CHANNEL_ID=109000000030、APPLYER_ID=401000000002、HOST 為a19xtf2k6 和a19xtf2k7 的維度組合；從前兩項維度組合可以看出，指標數據發生異常前，接口VOUCHER 平均響應時間是0.3 秒，指標數據發生異常后，接口VOUCHER平均響應時間分別突增到8.4秒和10秒以上。此刻所監控的整體接口響應時間達到2.5 秒，較告警發生前性能下降88.5%?？梢姶司S度組合的數據異常度最高。

效果說明： 經過確認， 接口提供方APPLYER_ID=401000000002、HOST 為a19xtf2k6 和a19xtf2k7 的這兩臺機器，由于定時任務程序被異常觸發，正在進行自動批量備份，占用了大量系統資源，主機CPU 使用率迅速被拉升，程序線程池被打滿，導致接口使用方調用VOUCHER 業務響應時間升高。通過使用系統智能化的根因定位及異常檢測算法，從異常發生到根因定位耗時5 分鐘，傳統方法通過告警及日志分析定位預計耗時30 分鐘，節約了故障處理時長。

5 結束語

本文基于無監督學習技術，實現了對業務指標告警閾值的智能化設定，自適應方式避免了繁瑣的手動配置閾值工作。同時，基于大數據和AI 技術，利用現有的AI 中臺、數據中臺、技術中臺，提出動態基線異常檢測算法和業務根因多維定位算法，實現了對業務指標異常的快速檢測、故障根因快速定位，提升了業務支撐系統的數智化能力。該方案具有易于復制、便于推廣的特點，已在能力開放平臺規模使用，可適配基于虛機、容器環境的各類業務系統，也可進一步在管理信息等其他領域系統中進行推廣使用。