一種在線實時微服務調用鏈異常檢測方法

張 攀，高 豐，周 逸，饒涵宇，毛 冬，李 靜

（1.國家電網有限公司信息通信分公司，北京 100031；2.南京航空航天大學 計算機科學與技術學院，南京 211106；3.國網浙江省電力有限公司信息通信分公司，杭州 310016）

0 概述

云計算技術的發展加速了大規模應用遷移上云的進程，極大提升了大規模應用的開發、擴展和運維效率［1］。當前，微服務架構由于在傳統面向服務的開發模式上進一步去中心化，因此逐漸成為大規模云應用的主流設計架構［2-3］，然而微服務實例之間復雜的依賴關系在增加故障發生頻率的同時也加大了故障診斷難度［4-5］，尤其當微服務調用拓撲中某一微服務發生故障時，故障會隨著調用拓撲擴散，而且微服務間共享CPU、內存等資源也會引發故障傳播，即使微服務之間沒有調用關系，也可能在較短時間間隔內產生大量異常告警［6］。為避免故障在系統內大范圍傳播，需要盡快盡早地檢測和定位故障發生的根因（Root Cause，RT）［7］。目前，微服務系統的監測數據主要包括關鍵性能指標（Key Performance Indicator，KPI）、日志和調用鏈［8］。KPI 數據負責監控系統的資源利用率，例如容器或物理機的CPU、內存以及硬盤等硬件資源利用率［9］。日志主要由代碼中的日志輸出語句輸出非結構化的日志條目，通過日志解析方法抽取為結構化的日志模板后檢測系統異常［10］。調用鏈數據是以類似圖的結構記錄微服務級別的調用關系、執行路徑以及性能參數［11］。目前的微服務性能異常檢測方法主要是基于KPI 和日志的異常檢測，并且只有小部分研究利用了調用鏈數據。

微服務調用鏈異常檢測可以在系統發生故障時及早檢測出受故障影響的微服務實例，并啟動故障根因定位，提高故障應對的響應速度，但微服務之間復雜的調用關系和調用鏈數據的特性給調用鏈異常檢測帶來了很大的挑戰。第一，微服務之間的調用不僅包含單個服務內部的互相調用，而且包括服務與服務間的跨服務層調用。第二，同一微服務往往對應不同的微服務實例，為了保障業務的持續性，這些微服務實例通常部署在不同的容器或物理機上，跨容器或物理機的調用可能會引入通信時延。第三，微服務架構應用具有多線程、高并發的特性，一個微服務通常會在同一時刻內調用多個子微服務。第四，應用的不斷迭代更新通常伴隨著微服務調用拓撲的變化，例如新微服務的上線、舊微服務的下線以及微服務原有調用關系的變化。第五，微服務調用關系中會包含大量遞歸、循環調用。針對上述問題，一些異常檢測方法通過構建調用鏈知識庫［12-14］，在檢測過程中根據匹配算法將新的調用鏈與知識庫中的調用鏈作對比，進而檢測異常調用鏈。但是，若應用于存在高并發、循環以及遞歸調用的大規模微服務系統時，該類方法需要構建規模龐大的知識庫，并且此類方法通常將微服務性能異常檢測和調用路徑異常檢測分為兩個獨立的任務，而衡量微服務性能的響應時間不僅由微服務本身決定，還受其所有的子調用微服務的影響，因而此類方法檢測效果不佳。此外，通過調用鏈匹配來檢測異常的方法計算復雜度過高，檢測過程耗時過長，因此更適用于離線異常檢測，而不適用于對實時性要求更高的在線異常檢測任務［15］。為了保證在線檢測的實時性，一些基于深度學習的異常檢測方法［16-17］被提出，但此類方法通常僅能檢測一種類型的異常，容易產生異常的漏報，并且往往忽略了調用鏈中事件序列的上下文信息，導致難以學習到微服務調用路徑與響應時間之間的關聯關系，因此效果不佳。

為解決上述問題，受自然語言處理技術在日志異常檢測中的成功應用啟發［18-20］，本文提出一種在線實時微服務調用鏈異常檢測方法MicroTrace，利用基于注意力機制的雙向長短期記憶（Bi-directional Long Short-Term Memory，BiLSTM）網絡模型學習正常調用鏈的行為模式。在模型訓練過程中，將調用鏈看作事件序列，對調用鏈中的事件進行解析，將事件解析為包含調用類型、調用發起網元以及服務網元的事件模板。利用詞匯嵌入式表示算法提取調用鏈中事件序列的上下文信息，獲得事件的語義向量表示，將調用鏈表示為語義向量序列。提取事件中包含的響應時間，獲得與語義向量序列相對應的響應時間序列作為微服務性能異常檢測的依據。基于語義向量序列和響應時間序列，采用基于注意力機制的BiLSTM 實現同時檢測調用路徑異常和微服務性能異常。

1 相關工作

1.1 基于調用鏈知識庫構建的異常檢測方法

基于調用鏈知識庫構建的異常檢測方法［12］主要通過采集系統正常運行下產生的調用鏈，從而構建調用拓撲知識庫。此類方法在檢測過程中，利用匹配算法將輸入調用鏈的調用拓撲與知識庫作對比，進而判定是否存在異常。MENG 等［12，15］通過構建調用樹知識庫，在檢測時根據限制自上而下映射（Restricted Top-Down Mapping，RTDM）算法［21］計算輸入調用樹與知識庫中所有正常調用樹的樹編輯距離，從而判定是否存在調用路徑異常。該方法同時通過構建響應時間矩陣并基于主成分分析方法實現了微服務性能的異常檢測。JIN等［13］提出一種基于魯棒主成分分析方法的離線調用鏈異常檢測方法，通過構建標準調用樹知識庫和響應時間矩陣改善了檢測精度。CHEN 等［22］通過構建矩陣草圖線性重建包含所有微服務正常響應時間的高維空間，實現了調用鏈中的微服務性能異常檢測。LIU 等［8］構建包含所有正常調用路徑的知識庫，然后人工設計調用鏈的向量化表示，利用深度貝葉斯神經網絡實現了同時檢測微服務調用路徑異常和性能異常。但是，此類基于知識庫構建的異常檢測方法存在計算復雜度高、檢測耗時長等問題，因此僅適用于離線調用鏈異常檢測任務。

1.2 基于深度學習的異常檢測方法

基于深度學習的異常檢測方法［16-17］主要利用循環神經網絡、深度生成模型等學習正常調用鏈數據的行為模式，在檢測過程中將偏離此模式的輸入數據判定為異常。NEDELKOSKI 等［23］提 出AEVB 方法，通過對調用鏈中的事件分類，將相同類型事件的響應時間組成時間序列，轉化為時序序列異常檢測問題，但此方法不能發現存在調用路徑異常的調用鏈。BOGATINOVSKI 等［24］提出一種基于自監督學習的異常檢測方法MSP，通過訓練一個自編碼器對輸入調用鏈中隨機遮蔽的事件進行重構，在檢測時根據重構結果預測調用鏈中每個位置上可能出現的事件，但此方法僅能檢測微服務調用路徑異常，忽略了微服務性能異常。BOGATINOVSKI 等［16-17］將 調用鏈異常檢測作為日志異常檢測的輔助任務，但都僅利用了調用鏈中部分信息，因此效果不佳。為了實現同時檢測調用路徑異常和性能異常，減少異常的誤報和漏報，NEDELKOSKI 等［25］提出一種基于多模態LSTM（Multiomodal-LSTM）方法，但此方法忽略了調用鏈中事件序列的上下文關系，并且模型結構也無法有效學習到微服務調用路徑與性能之間的關聯關系，因此檢測效果不能達到最優。

2 微服務調用鏈異常檢測方法

為了實現在線實時的微服務調用鏈異常檢測，本文提出MicroTrace 方法，主要包含調用鏈數據解析、事件語義向量化以及調用鏈異常檢測3 個部分。MicroTrace 總體框架如圖1 所示。

圖1 微服務調用鏈異常檢測方法總體框架Fig.1 Overall framework of anomaly detection method for microservice call chains

2.1 調用鏈數據解析

調用鏈記錄了業務應用內部微服務之間的調用關系以及微服務本身的響應時間。調用鏈由一系列帶有時間戳的event（稱為事件）構成［11］，表1 為微服務調用鏈數據示例，給出了一條調用鏈中的部分數據。本文將調用鏈T表示為按時間戳StartTime 排序的事件序列[e0，e1，…，eN-1]，即T=[e0，e1，…，eN-1]，其中N代表調用鏈T的長度。在表1 中，CallType 代表調用類型，StartTime 代表調用發起時間，即時間戳，ElapsedTime 代表被調用的微服務的響應時間，TraceId 代表此條調用鏈的唯一標識，SpanId 代表該事件在調用鏈中的唯一標識，Pid 代表該事件在調用鏈中的父事件的SpanId，Cmdb_id 代表發起此次調用的網元唯一標識，ServiceName 代表響應此次調用的服務網元（包含微服務和數據庫等）。為保證在語義向量化步驟中能以數值向量的形式準確地描述事件的行為，本文采用CallType、Cmdb_id以及ServiceName 3 個字段對事件進行分類，并將上述3 個字段組成正則表達式CallType_Cmdb_id_ServiceName 作為事件類別的標記，稱為事件模板。例如，表1 中序號為#0 的事件模板可以表示為OSB_os_021_osb_001。本文還提取出事件中的微服務響應時間并組成響應時間序列[η0，η1，…，ηN-1]。

表1 微服務調用鏈示例Table 1 Example of microservice call chain

在完成調用鏈數據解析后，一個長度為N的調用鏈T就可以被表示為按時間戳排序的兩條序列，分別是事件模板序列Tρ=[ρ0，ρ1，…，ρN-1]以及響應時間序列Tη=[η0，η1，…，ηN-1]。

2.2 語義向量化

為了利用事件序列中的上下文信息，本文基于自然語言處理思想，采用詞匯嵌入式表示方法Word2vec［26］提取事件序列中的上下文語義信息并將事件模板轉換為固定維度的數值型向量（稱為語義向量化）。由于事件模板的種類較少，本文省略了原Word2vec 算法中的負采樣過程。Word2vec 主要包含跳字（Skip-Gram）模型和連續詞袋（Continuous Bag-of-Words，CBOW）模型兩類，本文采用跳字模型來實現事件模板的語義向量化，如圖2 所示，主要包含事件模板預處理以及語義信息提取兩個步驟。

圖2 語義向量化框架Fig.2 Framework of semantic vectorization

2.2.1 事件模板預處理

在完成調用鏈數據解析后會得到一個事件模板集合S={ρ0，ρ1，…，ρV-1}，其中V代表事件模板種類。本文利用獨熱編碼（one-hot encoding）將集合S中的事件模板e映射為維度為V的向量o，得到集合S對應的獨熱編碼向量集合O={o0，o1，…，oV-1}，其 中oi∈RV，i∈[0，V-1]。

2.2.2 語義信息提取

描述事件模板的語義向量需要滿足可區分性和可對比性兩個需求。可區分性指語義向量可以高度區分不同的事件模板。例如事件模板CSF_os_021_csf_001 和JDBC_docker_005_db_003 有不同的行為模式，因此兩者的語義向量應該具有較小的余弦相似度。可對比性指相似事件應該有相似的語義向量。例如，事件模板CSF_os_021_csf_001 和CSF_os_022_csf_001 不僅在事件的行為模式上相似，在調用鏈中的位置也經常有交集（兩者都經常作為OSB_os_0xx_osb_0xx 的下一個調用），因此兩者的語義向量應該具有較高的余弦相似度。為滿足以上兩點需求，給定一條調用鏈的事件模板序列Tρ=[ρ0，ρ1，…，ρN-1]，通過查詢集合O將Tρ映射為To=[o0，o1，…，oN-1]，其 中，oi∈RV，i∈[0，N-1]。在跳字模型中，采用一個事件模板ρi預測它的上下文ρb來完成事件模板的語義向量化，具體過程如下：

首先，將ρi對應的oi映射到低維空間中：

其中：h∈RD代表oi的低維表示，且D＜V。

然后，根據式（2）和式（3）由事件模板的低維表征h預測ρb：

其中：y為跳字模型的輸出；P(ρb=ρk|ρi)為跳字模型在給定ρi的條件下，預測上下文ρb=ρk的概率。模型的優化目標為最大化給定事件模板ρi生成上下文事件模板的概率，等同于最小化式（4）表示的損失函數：

其中：C為ρi對應的上下文事件模板的個數。

最后，在模型收斂后，可由式（5）得到事件模板ρi對應的語義向量vi：

2.3 異常檢測

除了微服務之間復雜的調用關系會對調用鏈異常檢測帶來困難以外，如何同時檢測調用路徑異常和微服務性能異常也是調用鏈異常檢測要面臨的挑戰之一［8］，因此本文采用基于注意力機制的BiLSTM作為調用鏈異常檢測的最后一環。在完成數據解析和語義向量化之后，長度為N的調用鏈就被表示為語義向量序列Tv=[v0，v1，…，vN-1]和響應時間序列Tη=[η0，η1，…，ηN-1]，為了同時檢測調用路徑異常和微服務性能異常，本文將上述序列按元素拼接為雙模態向量序列TV=[V0，V1，…，VN-1]作為BiLSTM 的輸入，其中Vi=[vi，ηi]。

本文將調用鏈異常檢測建模為下一個事件模板預測以及時序數據預測任務。BiLSTM 接收長度為l的子序列Tl=[Vt-l+1，Vt-l+2，…，Vt]作為輸入，從前向和后向兩個方向挖掘子序列中包含的信息，并且每個LSTM 塊都會輸出一個隱向量H。由于不同的事件對于多分類的結果有不同的影響，并且在預測調用鏈中靠近根節點的事件時，通常要在子序列中填充占位符，因此在得到BiLSTM 的輸出后，采用注意力機制自動地為子序列中不同的事件施加不同的權重。

首先，由每個LSTM 塊的輸出H得到每個時刻事件的權重：

其中：為注意力層中第一個全連接層的參數。

然后，由每個時刻對應的LSTM 塊的輸出H以及對應的權重λ得到注意力層的輸出：

其中：pred=[u，ηpred]；w'為注意力層中第2 個全連接層的參數。

最后，將u作為模型輸出的事件模板預測結果，ηpred作為模型預測t+1 時刻對應的事件響應時間，即：

獲取在系統正常運行一段時間內產生的調用鏈數據并將其按照一定比例分為訓練集和驗證集。在模型訓練階段，同時采用多分類交叉熵損失（針對事件模板預測）以及均方誤差損失（針對響應時間預測）之和作為模型的總體損失函數，在此損失函數的引導下采用RMSprop（Root Mean Square Prop）［27］更新模型參數，并對模型參數采用L2 正則化。待模型收斂后，將驗證集輸入模型中，首先利用模型的響應時間預測值ηpred與t+1 時刻的觀測值ηt+1計算均方誤差r：

然后計算r的均值μ以及標準差σ，根據坎特立不等式（Cantelli inequality），對于?ε≥0：

將ε=βσ代入式（10）中得到：

由于驗證集中包含的都為正常的調用鏈數據，因此多數預測值和觀測值之間的均方誤差r會很接近均值μ，在微服務性能異常檢測過程中采用rthreshold=μ+βσ作為判斷r是否異常的閾值，如果模型的預測值ηpred與實際觀測值ηt+1的均方誤差r＞rthreshold，則可判斷此事件中響應的微服務存在性能異常。

在調用路徑異常檢測過程中，由于收斂后的模型學習了正常調用鏈的行為模式，模型的預測值u實際上為在給定歷史事件子序列后下一個可能出現的事件的概率分布，因此本文根據模型預測的各事件出現概率大小，選出最有可能出現的m個候選事件，如果實際觀測值不在這m個候選事件中，則判斷為異常。

MicroTrace 模型訓練算法如算法1 所示。

算法1MicroTrace 模型訓練算法

3 實驗結果與分析

3.1 數據集

采用AIOps2020 挑戰賽公開的預賽數據集，該數據集是由某大型運營商提供的真實數據，共分為黃金業務指標、調用鏈數據和KPI 數據三部分，其中，黃金業務指標反映了業務系統的整體狀態，記錄了業務系統的平均響應時間、每分鐘接收請求數量、每分鐘成功響應請求數量以及響應請求成功率。調用鏈數據記錄了該微服務架構的業務系統中各微服務之間的調用關系和執行路徑。KPI 數據記錄了物理機、虛擬機和容器的關鍵性能指標數據，例如內存利用率、CPU 利用率等。本文采用標記為2020_04_20中的調用鏈數據作為訓練集，標記為2020_05_22、2020_05_23 以及2020_05_24 中的調用鏈數據作為測試集。訓練集和測試集的黃金業務指標如圖3 所示，其中實線為業務系統的平均響應時間（average_time），虛線為響應請求成功率（success_rate），圓點為故障注入時間節點。從圖3 可以看出，在2020_04_20 訓練集中系統運行平穩，而在2020_05_22、2020_05_23 以及2020_05_24 測試集中由于故障注入導致系統運行狀態產生波動。數據提供方注入故障的類型包括容器CPU 利用率故障、容器內存利用率故障、數據庫類型故障以及主機或容器網絡類型故障等。測試集的部分故障注入類型以及時間如表2 所示。

表2 故障注入類型及時間Table 2 Fault injection type and time

3.2 對比方法與評價指標

選取DeepLog_A、MSP［24］、AEVB［23］以及Multimodal-LSTM［25］4 種當前最優方法作為對比方法，其中DeepLog_A 為DeepLog 的變體，為減少計算量，將DeepLog［10］中執行路徑異常檢測模塊命名為DeepLog_A作為對比方法之一。

采用查準率（P）、查全率（R）以及F1 度量值（F）作為衡量檢測效果的指標。查準率表示在檢測出的異常中真異常的比率。查全率表示在所有真異常中被模型標記為異常的比率。F1 度量值為綜合考慮查準率和查全率的性能衡量指標，計算公式如式（12）所示：

3.3 檢測效果對比

圖4 給出了本文MicroTrace 與4 種對比方法的實驗結果。從圖4 可以看出，MicroTrace 查準率、查全率以及F1 度量值均達到96%以上，相對于檢測效果次優的Multimodal-LSTM 的F1 度量值約提升了6.8%，這主要歸因于MicroTrace 利用語義向量化有效提取了調用鏈數據中事件之間的因果關系，通過異常檢測模型充分考慮了微服務的響應時間與調用路徑之間的關聯關系，同時檢測出了調用路徑異常和微服務性能異常，然而DeepLog_A、MSP 僅能檢測調用路徑異常，AEVB 僅能檢測微服務性能異常，因此在面對同時存在兩種異常的實驗場景下檢測效果欠佳。

圖4 5 種異常檢測方法的檢測效果對比Fig.4 Comparison of detection effect of five anomaly detection methods

結合圖3 和表2 可以看出，在注入db close（關閉數據庫）、db connection limit（數據庫訪問限制）等故障時，系統響應請求成功率會在故障期間降為0。此類型故障可類比于將系統中某一個微服務的所有實例全部下線，從而導致所有需要調用此微服務的調用鏈被截斷，進而產生異常的調用路徑。表3 和表4給出了在2020-05-22 00：07：00 向db_003（數據庫）注入db close 故障時產生的兩種類型的異常調用鏈的部分信息，分別將其稱為AT_1 和AT_2。AT_1 和AT_2 都為系統發生故障時產生的一條完整的調用鏈，可以從表3 和表4 看出兩者都在調用db_003 時發生了截斷，導致一條調用鏈僅包含極少數事件（正常調用鏈通常包含幾十個甚至幾百個事件），即產生了調用路徑異常。然而將表3 和表4 中的異常調用鏈和表1 中正常調用鏈數據相比可以發現，AT_1 中的事件響應時間與正常調用鏈中的事件響應時間明顯不同，而AT_2 中的事件響應時間卻和正常調用鏈中的差距很小，因此如果僅檢測響應時間異常，AT_2類型的異常調用鏈極有可能會被漏報從而導致查全率下降，這也是AEVB 檢測效果不佳的原因之一。在注入CPU fault（CPU 類型故障）、network delay（網絡延遲故障）等故障時，系統的平均響應時間通常會有較大幅度的增加，并有可能會導致系統響應請求成功率下降，此類故障可能會使系統中產生調用路徑正常但響應時間異常的調用鏈數據，然而僅考慮調用路徑異常的檢測方法（比如DeepLog_A 和MSP）在面臨此類型異常時會產生漏報或誤報。MicroTrace 可以同時檢測出調用路徑異常和響應時間異常，因此在所有方法中檢測效果達到了最優。

表3 AT_1 異常調用鏈Table 3 Anomalous call chain AT_1

表4 AT_2 異常調用鏈Table 4 Anomalous call chain AT_2

3.4 模型超參數分析

為驗證MicroTrace 對于超參數的魯棒性，設計模型對于預測候選事件參數m和時間窗口大小l的魯棒性實驗，其中，第1 個實驗固定l=10，m∈{7，8，9，10，11，12}，第2 個實驗固定m=9，l∈{5，6，7，8，9，10}，實驗結果如圖5、圖6 所示。

圖5 超參數m 的實驗結果Fig.5 Experimental results of hyper parameter m

圖6 超參數l 的實驗結果Fig.6 Experimental results of hyper parameter l

從圖5 可以看出，隨著m的增加，模型查準率會逐漸上升，查全率會逐漸下降，但F1 度量值波動不大，這是因為隨著m的增加模型對調用鏈中的事件異常行為的容忍度會越來越高，致使檢測結果中的假陽性數量減少，假陰性數量增加，導致查準率增大，查全率減小。從圖6 可以看出，隨著l的增大，模型查準率、查全率和F1 度量值波動不大，證明了本文方法對于超參數的變化并不敏感，具有較強的魯棒性，便于在真實系統環境中部署。

3.5 消融實驗分析

為驗證MicroTrace各組成部分對檢測效果的影響，設計了該方法的3 種變體，分別命名為MicroTrace_Alpha、MicroTrace_Beta 和MicroTrace_Gama，其 中，MicroTrace_Alpha 相對于原方法僅利用了調用鏈數據中事件之間的依賴關系來檢測調用路徑異常，MicroTrace_Beta 相對于原方法僅利用了調用鏈數據中的微服務的響應時間來檢測微服務性能異常，MicroTrace_Gama 相對于原方法刪去了事件模板的語義向量化過程，僅采用獨熱編碼對事件模板進行向量化。所有上述方法均采用默認參數，即m=9、l=10，實驗結果如表5 所示，其中最優指標值用加粗字體標示。

表5 消融實驗結果Table 5 Ablation experiment results %

從表5 可以看出，MicroTrace 在查準率、查全率以及F1 度量值上均優于其他變體方法，驗證了該方法的各模塊對于檢測效果的貢獻。例如，MicroTrace 的F1度量值相對于其他3種變體方法分別提升了50.2%、7.0%以及2.5%，這體現出同時檢測調用路徑異常和性能異常的策略可以減少模型的誤報和漏報。MicroTrace_Alpha 的檢測效果遠劣于MicroTrace_Beta，這是因為大部分故障會表現為服務延遲增加或者請求超時［14］，即導致調用路徑異常的故障通常也會同時表現為性能異常。MicroTrace 相對于MicroTrace_Gama 的檢測效果有較小幅度的提升，這證明了在事件模板向量化的過程中考慮事件之間的依賴關系有助于異常檢測模型更好地學習到調用路徑與響應時間之間的關聯關系。

4 結束語

本文提出一種在線實時微服務調用鏈異常檢測方法MicroTrace，將調用鏈建模為自然語言序列，采用詞匯嵌入式表示算法提取調用鏈中事件序列中的上下文信息，并利用基于注意力機制的BiLSTM 模型學習正常調用鏈的行為模式，實現了同時檢測調用路徑異常和微服務性能異常。通過在真實調用鏈數據集上的實驗結果證明了該方法的有效性，相比于現有方法減少了異常的漏報和誤報數量。下一步將針對異常的微服務集合研究根因定位算法，并在此基礎上設計微服務系統故障診斷閉環解決方案，實現系統故障的自動定位與診斷。