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

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

0 概述

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

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

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

1 相關(guān)工作

1.1 基于調(diào)用鏈知識庫構(gòu)建的異常檢測方法

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

1.2 基于深度學(xué)習(xí)的異常檢測方法

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

2 微服務(wù)調(diào)用鏈異常檢測方法

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

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

2.1 調(diào)用鏈數(shù)據(jù)解析

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

表1 微服務(wù)調(diào)用鏈?zhǔn)纠齌able 1 Example of microservice call chain

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

2.2 語義向量化

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

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

2.2.1 事件模板預(yù)處理

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

2.2.2 語義信息提取

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

首先，將ρi對應(yīng)的oi映射到低維空間中：

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

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

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

其中：C為ρi對應(yīng)的上下文事件模板的個數(shù)。

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

2.3 異常檢測

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

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

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

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

然后，由每個時刻對應(yīng)的LSTM 塊的輸出H以及對應(yīng)的權(quán)重λ得到注意力層的輸出：

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

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

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

然后計算r的均值μ以及標(biāo)準(zhǔn)差σ，根據(jù)坎特立不等式（Cantelli inequality），對于?ε≥0：

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

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

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

MicroTrace 模型訓(xùn)練算法如算法1 所示。

算法1MicroTrace 模型訓(xùn)練算法

3 實驗結(jié)果與分析

3.1 數(shù)據(jù)集

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

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

3.2 對比方法與評價指標(biāo)

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

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

3.3 檢測效果對比

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

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

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

表3 AT_1 異常調(diào)用鏈Table 3 Anomalous call chain AT_1

表4 AT_2 異常調(diào)用鏈Table 4 Anomalous call chain AT_2

3.4 模型超參數(shù)分析

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

圖5 超參數(shù)m 的實驗結(jié)果Fig.5 Experimental results of hyper parameter m

圖6 超參數(shù)l 的實驗結(jié)果Fig.6 Experimental results of hyper parameter l

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

3.5 消融實驗分析

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

表5 消融實驗結(jié)果Table 5 Ablation experiment results %

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

4 結(jié)束語

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