基于相似度匹配的微服務(wù)故障診斷方法①

陳 皓,許源佳,2,王 燾,3,張文博,3

1(中國科學(xué)院 軟件研究所,北京 100190)

2(中國科學(xué)院大學(xué),北京 100049)

3(中國科學(xué)院 軟件研究所 計算機科學(xué)國家重點實驗室,100190)

1 引言

面對互聯(lián)網(wǎng)時代的海量請求,短時間內(nèi)的服務(wù)失效會導(dǎo)致用戶體驗和評價的下降,而長時間的服務(wù)失效甚至?xí)蛊髽I(yè)面臨嚴重的經(jīng)濟損失.隨著云計算數(shù)據(jù)量的迅速增長,集群規(guī)模的不斷膨脹,如何對集群內(nèi)海量的微服務(wù)進行高效、準確的故障檢測,保障集群的高可靠性成為了越來越重要的技術(shù).服務(wù)的監(jiān)測與故障技術(shù)幫助運維人員監(jiān)測分布式服務(wù)的運行情況,進行資源的調(diào)配,保證整個服務(wù)系統(tǒng)的可靠運行.

微服務(wù)故障診斷方法主要包括分析度量信息、日志文件和執(zhí)行追蹤等3 種方法.首先,基于度量信息分析的方法收集某個邏輯計量單元或某時間段內(nèi)的計量值,可以通過設(shè)定固定的指標或是通過一系列運算設(shè)定動態(tài)變化的指標,以此作為系統(tǒng)異常的報警規(guī)則,向運維人員發(fā)送異常警告,或是作為集群任務(wù)的調(diào)度規(guī)則[1-3].這類方法對于系統(tǒng)內(nèi)部服務(wù)的結(jié)構(gòu)和關(guān)系不需要進行了解,但需要事先知道異常類型和異常特征,靈活性較差.其次,基于日志文件分析的方法收集離散日志文件中的元數(shù)據(jù)信息,日志文件記錄了系統(tǒng)運行中海量零散事件或請求信息,通過設(shè)定檢索模式,可以找到運行中的錯誤報告,有效排查系統(tǒng)的異常原因[4-7].這類方法需要收集大量零散的日志文件,并從中提取出關(guān)鍵的故障信息,日志收集和信息提取存在滯后性,難以實時分析系統(tǒng)存在的故障.最后,基于執(zhí)行追蹤的方法收集單次請求內(nèi)的全部信息,構(gòu)建系統(tǒng)內(nèi)部的結(jié)構(gòu)特征,當系統(tǒng)異常發(fā)生時會引起請求處理軌跡發(fā)生偏移,通過對處理軌跡分析以達到異常定位和故障原因診斷的目的[8-10].這類方法可用于排查系統(tǒng)性能問題,但是監(jiān)測粒度過細會帶來巨大的監(jiān)測和分析資源開銷,存在監(jiān)測粒度與監(jiān)測開銷之間難以平衡的問題.

綜上所述,現(xiàn)有微服務(wù)故障診斷方法存在以下問題:(1)現(xiàn)有微服務(wù)故障診斷方法存在多種監(jiān)控方式,其中基于度量信息分析的方法和基于日志文件分析的方法需要預(yù)先知道異常的特征信息,難以應(yīng)對突發(fā)異常,而基于執(zhí)行追蹤的方法缺少對系統(tǒng)運行指標(如CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等)的監(jiān)測.(2)相同請求的執(zhí)行追蹤具有相似性,缺少衡量執(zhí)行追蹤間的相似度指標,因此現(xiàn)有技術(shù)難以通過分析執(zhí)行追蹤間的相似程度來發(fā)現(xiàn)服務(wù)異常,從而造成不能夠快速發(fā)現(xiàn)和診斷故障的結(jié)果.(3)故障原因的診斷依賴系統(tǒng)歷史故障的特征信息,缺乏對未知故障的可能原因的診斷方法,因此現(xiàn)有技術(shù)需要不斷迭代故障特征診斷規(guī)則,對未知故障的診斷依賴運維人員的技術(shù)和經(jīng)驗,從而造成可靠性保障方法靈活性差,難以應(yīng)對罕見的系統(tǒng)故障.

針對以上問題,本文提供一種基于故障相似度的微服務(wù)故障診斷方法,采用預(yù)先向系統(tǒng)注入故障的方式,收集故障的執(zhí)行追蹤,并通過采用字符串編輯距離表示執(zhí)行追蹤間相似度,比較已知故障與異常請求間的相似度,報告可能的故障原因.相較于現(xiàn)有方法,本文提出的方法存在以下優(yōu)點:(1)基于系統(tǒng)歷史運行追蹤數(shù)據(jù)制定故障發(fā)生的判斷條件,對于復(fù)雜多變的微服務(wù)系統(tǒng),能夠更為靈活準確的判斷系統(tǒng)狀態(tài);(2)基于對系統(tǒng)注入故障的表現(xiàn)的真實記錄,因此當生產(chǎn)環(huán)境中,相似的故障再次發(fā)生時,能夠通過對系統(tǒng)行為與注入故障的表現(xiàn)進行評估,快速準確的判斷故障原因;(3)對于系統(tǒng)中罕見故障發(fā)生的情況,本文所提出的方法會將其與已知故障進行比對,通過對于已知故障原因的分析,提出可能的相似故障,運維人員可以此為輔助快速找到系統(tǒng)中真正的故障.同時,通過與相關(guān)微服務(wù)監(jiān)測方法的結(jié)合,可以減少排除故障所需的時間,減少實際損失.

2 故障診斷方法

本文提出一種基于故障相似度的微服務(wù)故障診斷方法(圖1),采用預(yù)先向系統(tǒng)注入故障的方式,收集故障的執(zhí)行軌跡,并通過采用字符串編輯距離表示執(zhí)行軌跡間相似度,比較已知故障與異常請求間的相似度,報告可能的故障原因,具體包括以下3 個環(huán)節(jié):

(1)執(zhí)行軌跡建模:對于分布式系統(tǒng)內(nèi)服務(wù)之間的調(diào)用,采用注入代理的方式攔截和轉(zhuǎn)發(fā)流量,借由分布式追蹤系統(tǒng)收集請求信息.通過收集請求的執(zhí)行ID,父請求ID,執(zhí)行時間,調(diào)用服務(wù)等信息,可以獲得原始的請求信息.通過對追蹤信息進行規(guī)范化處理和建立調(diào)用關(guān)系模型,可以將請求刻畫為相應(yīng)的有向帶權(quán)圖的形式進行存儲.同時,對于每一個請求的有向帶權(quán)圖,都可以通過對于頂點進行映射,從而轉(zhuǎn)化為一個標識該請求的調(diào)用關(guān)系的調(diào)用字符串.

圖1 故障診斷方法總體設(shè)計

(2)系統(tǒng)運行與故障概況統(tǒng)計:對于被檢測系統(tǒng),對系統(tǒng)服務(wù)正常運行時應(yīng)用的追蹤信息進行收集,構(gòu)建正常運行下請求的有向帶權(quán)圖信息進行存儲,作為系統(tǒng)正常運行的參考依據(jù),設(shè)定正常服務(wù)間調(diào)用請求的正常執(zhí)行時間區(qū)間,以服務(wù)間請求是否超出執(zhí)行時間區(qū)間作為判斷請求是否出現(xiàn)異常的標準.此后,通過注入已知原因的故障引發(fā)系統(tǒng)出現(xiàn)異常,觀察系統(tǒng)應(yīng)用間執(zhí)行軌跡的變化關(guān)系,將出現(xiàn)故障后系統(tǒng)內(nèi)執(zhí)行軌跡的有向帶權(quán)圖進行收集,并且對于請求內(nèi)服務(wù)間的調(diào)用關(guān)系,通過映射關(guān)系轉(zhuǎn)化為請求字符串,作為系統(tǒng)故障原因的參考依據(jù)進行存儲.

(3)未知原因故障發(fā)現(xiàn)與原因診斷:對于運行時的系統(tǒng),通過對系統(tǒng)服務(wù)間的執(zhí)行軌跡的不斷監(jiān)測.一旦系統(tǒng)內(nèi)出現(xiàn)執(zhí)行時間異常的請求,將請求追蹤信息作為分析該異常請求的數(shù)據(jù)來源.通過對于未知原因故障的請求的有向帶權(quán)圖模型的建立和將請求內(nèi)服務(wù)調(diào)用關(guān)系轉(zhuǎn)化為調(diào)用請求字符串的方式,通過計算與已知故障的請求字符串之間的編輯距離來衡量未知故障請求與已知故障請求間的相似度,從而找到能夠產(chǎn)生最為相似的調(diào)用請求的已知故障,作為本文判斷異常原因結(jié)果.

3 關(guān)鍵技術(shù)

3.1 執(zhí)行軌跡建模

對于一條執(zhí)行軌跡T,本文采用有向帶權(quán)圖的結(jié)構(gòu)來表示發(fā)送和接收事件的調(diào)用關(guān)系,其中:每一個頂點S都對應(yīng)應(yīng)用依賴關(guān)系中的某一個服務(wù);對于應(yīng)用中存在服務(wù)A和服務(wù)B,并且服務(wù)A 對服務(wù)B 產(chǎn)生了調(diào)用請求,那么在有向帶權(quán)圖中,服務(wù)A和服務(wù)B 對應(yīng)的頂點a和頂點b之間建立有向邊,其權(quán)值為調(diào)用請求被接受所消耗的時間t;根據(jù)請求的內(nèi)容和應(yīng)用的功能,對同一服務(wù)的多次調(diào)用可能會產(chǎn)生不同的調(diào)用關(guān)系,因此請求的執(zhí)行軌跡T和對應(yīng)的帶權(quán)有向圖D可能不唯一.

為了記錄服務(wù)間的依賴關(guān)系,對執(zhí)行軌跡T的每一條追蹤信息,都將表示為:

其中,MID是該服務(wù)id;requestID為服務(wù)請求的id;callerID為調(diào)用服務(wù)的id;duration為請求消耗時間;info包含方法的其他信息,多元組形式如式(2):

其中,operationName為操作名稱;startTime為開始時間戳;tags為請求所包含的標簽.通過對依賴關(guān)系的還原,可以將執(zhí)行軌跡T轉(zhuǎn)化為相應(yīng)的有向帶權(quán)圖D={V,E},其中V為頂點S的數(shù)組,每一個頂點S表示一個服務(wù);E為鄰接矩陣,被調(diào)用的服務(wù)間建立權(quán)值為消耗時間t的有向邊.此外,對于一條執(zhí)行軌跡T,其中的每一條追蹤信息都可以按照調(diào)用的順序,使用哈希函數(shù)將操作名稱轉(zhuǎn)化為表示該操作的一個定長字符串Cm,根據(jù)調(diào)用順序?qū)⑦@些字符串依次拼接,可得到表示執(zhí)行軌跡T的請求字符串C.

3.2 追蹤信息收集

3.2.1 服務(wù)概況收集

本文首先統(tǒng)計系統(tǒng)請求的正確執(zhí)行,收集相應(yīng)的執(zhí)行軌跡Ts,轉(zhuǎn)化為相應(yīng)的請求有向帶權(quán)圖Ds,構(gòu)建服務(wù)概況數(shù)據(jù)庫(Service Profile DataBase,SPDB),依次對于系統(tǒng)的請求的正確執(zhí)行的執(zhí)行軌跡進行存儲.SPDB的建立不僅是對于系統(tǒng)的系統(tǒng)正常請求的一種記錄,更是能作為系統(tǒng)異常的判定標準.微服務(wù)故障主要分為性能衰減與服務(wù)失效兩大類,其中,性能衰減類的故障是由于資源使用率增高,使得服務(wù)處理效率達到瓶頸,微服務(wù)處理請求所消耗的時間增長,并且當資源使用率不斷增高,會導(dǎo)致部分微服務(wù)處理超時返回錯誤代碼或者微服務(wù)間請求處理順序和調(diào)用關(guān)系出現(xiàn)異常改變,其執(zhí)行追蹤表現(xiàn)為微服務(wù)執(zhí)行時間的大幅增長和部分調(diào)用關(guān)系的異常改變;服務(wù)失效類的故障主要是由于服務(wù)未能正確響應(yīng)請求或服務(wù)未被正確配置所引起,會導(dǎo)致部分請求返回錯誤信息或者長時間未能響應(yīng),其執(zhí)行追蹤表現(xiàn)為微服務(wù)執(zhí)行時間大幅縮短或大幅增長,并且存在服務(wù)請求調(diào)用流程的提前終止或重復(fù)請求.因此,系統(tǒng)異常往往伴隨著執(zhí)行軌跡中服務(wù)執(zhí)行和調(diào)用時間的變化,本文將采用執(zhí)行時間作為主要判斷的指標.

通過模擬10 000 次相對穩(wěn)定的運行環(huán)境下被正確處理的請求,本文收集了10 000 次相對穩(wěn)定的運行環(huán)境下被正確處理的請求中的追蹤信息,在剔除異常值和缺失值之后,對收集的50 037 個追蹤中的微服務(wù)執(zhí)行時間進行統(tǒng)計和分析,相應(yīng)執(zhí)行時間如圖2所示.事實上,由于微服務(wù)的運行環(huán)境并非是一成不變的,并且會對微服務(wù)的運行產(chǎn)生難以預(yù)料的影響.對于相同環(huán)境下相同服務(wù)的多次相同類型的請求進行統(tǒng)計,由于網(wǎng)絡(luò)延時等因素造成的隨機性,仍然會使得調(diào)用的時間呈現(xiàn)一定的隨機分布,執(zhí)行時間近似落在某一個區(qū)間之內(nèi),而統(tǒng)計單一因素在請求仍能被正確處理的情況下的波動對執(zhí)行時間所造成的影響并非本文研究的方向.然而,我們將執(zhí)行時間的分布區(qū)間獲取的樣本中位數(shù)為中心,分成100 個相同大小的執(zhí)行時間區(qū)間,并對處在區(qū)間內(nèi)的追蹤樣本數(shù)量進行統(tǒng)計.我們發(fā)現(xiàn),對落在每一區(qū)間段上的執(zhí)行時間數(shù)量使用Kolmogorov-Smirnov 檢驗(K-S 檢驗)[11]進行正態(tài)性檢驗,相應(yīng)的p值分別為0.493、0.135、0.259、0.094,均大于0.05,可以認為執(zhí)行時間的分布區(qū)間符合正態(tài)分布.因此,對于大多數(shù)被正確處理的請求,我們均可以計算得到一個執(zhí)行時間區(qū)間,將這樣的區(qū)間端點作為邊界值,落在區(qū)間之外的執(zhí)行軌跡就可以被認為是一種異常.對于一次新的執(zhí)行請求,本文采用式(1)和式(2)來計算其邊界值:

其中,tmax表示正常執(zhí)行時間的上界,tmin表示正常執(zhí)行時間的下界,表示服務(wù)請求的平均執(zhí)行時間,σ表示服務(wù)請求執(zhí)行時間的標準差,n表示樣本執(zhí)行軌跡的數(shù)量,zα表示正態(tài)分布的α分位點,本文采用95%的置信概率,根據(jù)文獻[12]取為1.96.

當請求的執(zhí)行時間超出這一區(qū)間時,將被認為發(fā)生了一次異常事件,其執(zhí)行軌跡的請求字符串C將被保留.

3.2.2 已知錯誤收集

為了對系統(tǒng)出現(xiàn)故障后的表現(xiàn)進行記錄,本文采用定向注入故障的方式,預(yù)先收集系統(tǒng)失效時的執(zhí)行軌跡Tk,將其轉(zhuǎn)化為相應(yīng)的請求字符串Ck進行存儲,建立已知故障數(shù)據(jù)庫(Known Faults DataBase,KFDB).KFDB 中不僅可以存儲由注入的單個服務(wù)的失效和多個服務(wù)調(diào)用之間的所產(chǎn)生的異常事件執(zhí)行軌跡,還能夠收集由于集群物理資源異常所引發(fā)的執(zhí)行軌跡,并且通過本文的處理,結(jié)果利于量化比較相似度.在系統(tǒng)實際出現(xiàn)失效時,將出現(xiàn)的故障執(zhí)行軌跡與KFDB 中已知故障所產(chǎn)生的所產(chǎn)生的系統(tǒng)執(zhí)行軌跡進行比較,通過本文3.3.2 節(jié)所介紹的算法2 計算出最為相似的故障,以幫助運維人員判斷生產(chǎn)環(huán)境中系統(tǒng)失效的實際位置,最大程度的避免損失.

3.3 故障診斷

系統(tǒng)故障會使請求的執(zhí)行軌跡的產(chǎn)生可監(jiān)測的偏移[13],包括執(zhí)行軌跡內(nèi)服務(wù)調(diào)用關(guān)系的改變和執(zhí)行時間的波動兩種形式.對于本文所建立的請求的模型,即請求的有向帶權(quán)圖,以上兩種執(zhí)行軌跡偏移的形式分別對應(yīng)有向帶權(quán)圖頂點的改變和有向邊權(quán)值的波動.基于以上原理,提出了故障發(fā)現(xiàn)與故障原因診斷的方法.

圖2 執(zhí)行時間分布區(qū)間

3.3.1 故障檢測

對于每一次請求,經(jīng)過3.1 節(jié)所介紹的建模方式,都可以計算出相應(yīng)的請求有向帶權(quán)圖.為了處理有向帶權(quán)圖中復(fù)雜的調(diào)用信息,判斷系統(tǒng)是否發(fā)生故障,本文提出了以下算法思想:

(1)對于當前請求所對應(yīng)的有向帶權(quán)圖Du,檢索其開始時間最早的頂點S1,作為起始頂點,表示請求的第一個服務(wù).對于頂點S1,取其服務(wù)名稱N1,使用映射函數(shù)轉(zhuǎn)化為定長字符串C1;

(2)讀取該頂點請求的消耗時間dt1和所連接的下一個頂點S2;

(3)根據(jù)調(diào)用關(guān)系,進入下一個頂點S2,取其服務(wù)名稱N2,使用與步驟(1)中相同的映射函數(shù)轉(zhuǎn)化為定長字符串C2;

(4)查詢SPDB 中C1與C2間執(zhí)行請求的正常執(zhí)行區(qū)間,若dt1處于正常執(zhí)行區(qū)間之內(nèi),則判斷S1至S2的調(diào)用為正常調(diào)用,取頂點請求的消耗時間dt2,將C1添加至請求字符串Cr末端;反之則為異常調(diào)用,將C1添加至請求字符串Cr末端;

(5)重復(fù)步驟(1)～步驟(4),對于T內(nèi)的每一個頂點進行檢測,直到當前請求的每一次調(diào)用均被檢測,且所有頂點的服務(wù)名稱均轉(zhuǎn)化為字符串C并添加至請求字符串Cr中.如果存在異常,則將請求字符串Cr作為結(jié)果返回,反之則返回空值.

基于以上算法思想,本文提出故障發(fā)現(xiàn)算法如算法1.

算法1.故障發(fā)現(xiàn)算法輸入:Du 未知請求有向帶權(quán)圖輸出:Cr 請求字符串1.function Judgement(Du)2.Cr,C1,C2 ←“ ”3.S1 ←Du.V.root 4.S2 ←null 5.dt,dtmin,dtmax←0 6.state←0 7.while S1.next is not nulldo

8.S2 ←S1.next 9.C1←Hash(S1.name)10.C2←Hash(S2.name)11.dt←GetArc(Du.E,S1,S2)12.dtmin←GetMinDuration(C1,C2)1,C2)13.dtmax←GetMaxDuration(C 14.if dtmin＞dt or dtmax＜dt then 15.state←1 16.end if 17.Cr←Cr+C1 18.S1←S2 19.end while 20.if state ==0 then 21.Cr← null 22.else 23.Cr←C +C2 24.end if 25.return Cr 26.end function

算法1 通過以歷史系統(tǒng)正常請求的調(diào)用時間區(qū)間作為判斷依據(jù),能夠有效設(shè)立有針對性的檢測閾值.其中輸入為未知請求有向帶權(quán)圖Du=｛V,E｝,V為頂點數(shù)組,包含該請求所涉及的所有服務(wù),E為鄰接矩陣,包含服務(wù)間的調(diào)用關(guān)系和消耗時間.算法首先從請求開始的頂點,獲取其服務(wù)名稱和調(diào)用關(guān)系(第3 行～第9 行),之后依次將服務(wù)名稱轉(zhuǎn)化為字符串(第9 行、第10 行),查詢調(diào)用時間是否在正常范圍之內(nèi)(第11行～第16 行),然后將服務(wù)名稱添加至請求字符串(第17 行)并重復(fù)這樣的檢測過程,直至所有頂點均被檢測(第7 行～第19 行).如果存在調(diào)用時間超出正常區(qū)間,則返回值為調(diào)用字符串,反之為空值(第20 行～第25 行).

當算法1 判斷系統(tǒng)出現(xiàn)故障后,將根據(jù)所建立的請求模型分析系統(tǒng)可能出現(xiàn)的故障,本節(jié)中所生成的請求字符串將作為描述故障請求重要依據(jù)而輸入3.3.2節(jié)的原因診斷.

3.3.2 原因診斷

故障原因診斷基于對系統(tǒng)注入的已知故障進行相似度的判斷,在3.2.2 節(jié)中我們建立了存有已知故障的數(shù)據(jù)庫KFDB.為了提取和比較KFDB 中執(zhí)行軌跡與未知原因故障的執(zhí)行軌跡間的相似程度,我們將故障執(zhí)行軌跡轉(zhuǎn)化為相應(yīng)的調(diào)用字符串的形式,采用字符串編輯距離作為相似程度的衡量指標,詳細算法如算法2 所示.

算法2 通過已知故障的執(zhí)行軌跡與未知故障執(zhí)行軌跡的對比,返回多個可能的故障原因.其中輸入為請求字符串Cr,輸出為相似故障F.算法對于KFDB 中記錄的每一個故障Fk,依次取出請求字符串Ck,計算未知請求字符串Cr與已知故障請求字符串Ck間的編輯距離(第6 行～第10 行).由于KFDB 內(nèi)每一個故障記錄了多個已知故障請求字符串,因此計算出的匹配值為編輯距離的平均值(第9 行～第12 行),并且返回值為匹配值最小的KFDB 中已記錄的故障F(第13 行～第18 行).對于有經(jīng)驗的運維人員,本文所提供的結(jié)果可以幫助快速排查系統(tǒng)故障,查找真正的故障原因.

算法2.原因檢測算法輸入:Cr未知請求字符串輸出:F 相似故障1.function SimilarityMatching(Cr)2.Cr,Ck←“”3.Fk,F←null 4.dk,d←0 5.i←0 6.for each Fk ∈ KFDB do 7.for each Ck ∈ Fk do 8.i ++9.dk←dk+GetEditDistance(Ck,Cr)10.end for 11.dk←dk/i 12.i←0 13.if dk＜d then 14.F←Fk 15.d←dk 16.end if 17.end for 18.return F 19.end function

4 實驗分析

4.1 實驗環(huán)境

為了驗證本文所提出的故障檢測方法,本文采用測試應(yīng)用的包含4 組微服務(wù),微服務(wù)之間存在相互調(diào)用的關(guān)系,總計包含36 個微服務(wù)實例,并且被部署在兩臺應(yīng)用服務(wù)器上,用于驗證本文所提出方法的可行性.實驗平臺基于Kubernetes和Istio 框架,其中Kubernetes提供對底層容器自動部署、擴展和管理的容器編排管理功能[14],而Istio 通過注入sidecar 代理的方式攔截微服務(wù)之間的網(wǎng)絡(luò)通訊,提供統(tǒng)一的微服務(wù)連接、安全保障、管理與監(jiān)控方式[15],簡化了本文對測試系統(tǒng)的微服務(wù)的監(jiān)控和管理.包括流量管理,實驗測試應(yīng)用基于Istio 所提供的微服務(wù)書店應(yīng)用Bookinfo[16]進行實現(xiàn),實驗系統(tǒng)的架構(gòu)圖如圖3所示.

圖3 被測系統(tǒng)架構(gòu)

當用戶請求發(fā)送至測試應(yīng)用后,首先由Service A處理請求,并且Service A 會調(diào)用Service C和隨機版本的Service B 進行處理,而v2和v3 版本的Service B會繼續(xù)調(diào)用Service D.測試應(yīng)用內(nèi)各微服務(wù)功能單一,可獨立運行,服務(wù)之間基于HTTP/HTTPS 協(xié)議的RESTful API 進行通信協(xié)作,與微服務(wù)應(yīng)用具有的職責(zé)單一,可獨立部署、擴展和測試,通過消息進行交互的特點[17]相契合.測試應(yīng)用運行在Kubernetes 集群上,經(jīng)過服務(wù)網(wǎng)格Istio[18]對于應(yīng)用運行和監(jiān)測的解耦,其中應(yīng)用鏈路數(shù)據(jù)經(jīng)過開源鏈路追蹤工具Jaeger[19]收集并存儲至后端Elasticsearch[20]數(shù)據(jù)庫內(nèi).經(jīng)過本方法處理的請求的有向帶權(quán)圖和相應(yīng)的調(diào)用字符串存儲至數(shù)據(jù)庫中.運行被測系統(tǒng)并發(fā)送請求,收集正常運行時系統(tǒng)的執(zhí)行軌跡信息,建立SPDB.實驗節(jié)點的軟硬件信息見表1.

表1 實驗節(jié)點配置信息

4.2 執(zhí)行追蹤建模

4.2.1 服務(wù)執(zhí)行信息收集

被測系統(tǒng)在正常請求中會首先調(diào)用服務(wù)A,再由服務(wù)A 對服務(wù)B和服務(wù)C 進行調(diào)用.其中服務(wù)B 同時有3 個運行中的版本,B2和B3 版本的服務(wù)會繼續(xù)調(diào)用服務(wù)D 處理請求.在實驗中,本文將模擬1000 次的用戶請求,收集測試系統(tǒng)的正常追蹤信息以構(gòu)建SPDB.在經(jīng)過分布式追蹤系統(tǒng)Jaeger的收集后,得到的服務(wù)追蹤中對4 個微服務(wù)的調(diào)用數(shù)量和服務(wù)之間調(diào)用所耗費的平均執(zhí)行時間如圖4、圖5所示.

圖4 被測系統(tǒng)收集的微服務(wù)追蹤數(shù)量

圖5 服務(wù)調(diào)用的平均執(zhí)行時間

對于正常請求的執(zhí)行追蹤,均存在由服務(wù)A 開始的調(diào)用其他服務(wù)的處理流程.如圖6所示,還原了一次正常請求的有向帶權(quán)圖.其中,每一次正確請求的均處在相對穩(wěn)定的區(qū)間內(nèi),并且服務(wù)B 并非每次都需要調(diào)用服務(wù)D 處理請求.

4.2.2 故障注入

為了建立KFDB,驗證方法的有效性,向被測系統(tǒng)注入了多種故障.對于每一次的故障注入實驗,均向被測系統(tǒng)發(fā)送500 次請求,并收集注入故障的系統(tǒng)的追蹤信息.通過對于追蹤信息的收集和處理,對于被測系統(tǒng)的表現(xiàn)進行記錄,建立KFDB.注入故障信息見表2.

其中,注入節(jié)點的節(jié)點或服務(wù)表示注入故障的應(yīng)用服務(wù)器或服務(wù),故障描述簡述了注入的故障,有效故障追蹤數(shù)量表示每次實驗所收集到的可處理和分析的追蹤數(shù)量.由表2可見,實驗中對此被測系統(tǒng)中單次請求均在8 次調(diào)用內(nèi)處理完成.對于生成的系統(tǒng)正常運行時的追蹤模型進行與系統(tǒng)設(shè)計架構(gòu)中的調(diào)用關(guān)系進行人工比對,可以確認得到請求的追蹤模型能夠準確的描述每一次的請求信息.

圖6 一次正常請求的有向帶權(quán)圖

表2 注入故障信息

對于異常請求的執(zhí)行追蹤,仍然以服務(wù)A 作為調(diào)用開始的起點調(diào)用其他服務(wù)的處理流程.如圖7所示,還原了已知故障1 中一次請求的有向帶權(quán)圖.其中,我們可以觀察到,同樣的微服務(wù)的執(zhí)行時間有較明顯的變化,并且由于容器所在節(jié)點的不同,已知故障對于不同的微服務(wù)之間的影響幅度并非完全相同.此外,由于服務(wù)A和服務(wù)B 中出現(xiàn)部分超時請求,后續(xù)的服務(wù)不能被正確調(diào)用,使得部分執(zhí)行軌跡出現(xiàn)改變.

4.3 故障診斷

為了檢驗故障檢測方法的有效性,我們分別在系統(tǒng)處理正常請求的過程中,引發(fā)待測故障,包含性能衰減與服務(wù)失效類型的故障.對于每一次的故障注入實驗,均向被測系統(tǒng)發(fā)送20 次請求,并收集注入故障的系統(tǒng)的追蹤信息,待測信息如表3所示.

圖7 一次已知故障請求的有向帶權(quán)圖

表3 待測故障信息

與表2類似,表3中注入節(jié)點的節(jié)點或服務(wù)表示注入故障的應(yīng)用服務(wù)器或服務(wù),故障描述簡述了注入的故障,有效故障追蹤數(shù)量表示每次實驗所收集到的可處理和分析的追蹤數(shù)量.

對于收集到的待測故障請求的追蹤數(shù)據(jù),其中以待測故障1為例,各服務(wù)的追蹤數(shù)據(jù)數(shù)量與所占比例如圖8、圖9所示.

圖8 各服務(wù)的追蹤數(shù)據(jù)數(shù)量

注入故障會引發(fā)服務(wù)的性能衰減與失效,因此由于故障的注入,系統(tǒng)中應(yīng)用服務(wù)的處理請求所消耗的時間會發(fā)生改變.以待測故障1為例,各服務(wù)平均調(diào)用時間的變化如圖10所示.

圖9 各服務(wù)的追蹤數(shù)據(jù)所占比

圖10 服務(wù)平均執(zhí)行時間變化

4.4 試驗結(jié)果分析

4.4.1 結(jié)果展示

本文采用查準率P(precision)、查全率R(recall)和F1 值對本方法的異常發(fā)現(xiàn)結(jié)果進行評價.其中:

其中,真正例TP(True Positive)表示異常發(fā)現(xiàn)算法判斷為故障時系統(tǒng)確實發(fā)生故障的次數(shù),假正例FP(False Positive)表示異常發(fā)現(xiàn)算法判斷為故障時系統(tǒng)實際未發(fā)生故障的次數(shù)、假反例FN(False Negative)為異常發(fā)現(xiàn)算法判斷為正常時系統(tǒng)確實發(fā)生故障的次數(shù).

對于待檢測的故障,將注入故障的請求的追蹤數(shù)據(jù)和同樣次數(shù)的系統(tǒng)正常運行下的請求的追蹤數(shù)據(jù)使用本文所提出的異常發(fā)現(xiàn)方法進行分析,其異常發(fā)現(xiàn)結(jié)果展示如表4所示.

表4 異常發(fā)現(xiàn)性能

同樣,對于原因診斷,同樣采用查準率P、查全率R和F1 值對結(jié)果進行評價.計算式同式(3)-式(5).其中,真正例TP表示原因診斷算法判斷的最可能的已知故障與待測的未知故障的類型相同的次數(shù),假正例FP與假反例FN均表示原因診斷算法判斷的最可能的已知故障與待測的未知故障的類型不同的次數(shù).原因診斷結(jié)果如表5所示.

表5 原因診斷性能

4.4.2 結(jié)果分析

實驗結(jié)果表明,對于服務(wù)性能衰減類型的故障,本文所提出的方法,本文所提出的故障發(fā)現(xiàn)算法可以很好地發(fā)現(xiàn)故障,查準率、查全率、F1 值分別達到0.886、0.975、0.928,可見由于性能衰減類的故障會引起服務(wù)處理請求時間的相應(yīng)延長,因此本文所提出的故障發(fā)現(xiàn)算法可以很好地發(fā)現(xiàn)這種類型的故障;而對于服務(wù)失效類的異常,本文所提出的原因診斷算法可以較好地診斷原因,查準率、查全率、F1 值均為0.625,可見由于服務(wù)失效類的異常會使得調(diào)用請求的處理出現(xiàn)較為明顯的變換,因此本文所提出的原因診斷算法能夠較好的發(fā)現(xiàn)這種故障的原因.

此外,本文所提出的方法雖然可以發(fā)現(xiàn)故障和檢測故障原因,但是仍有一些情況下會存在對于系統(tǒng)狀態(tài)和故障原因判斷不準確的情況.經(jīng)過分析,未能有效發(fā)現(xiàn)的故障主要與pod 狀態(tài)異常有關(guān),主要包括pod未能正確提供服務(wù)功能的情況,在實驗中的判斷準確率.這是因為本文所提出的異常發(fā)現(xiàn)方法基于服務(wù)的性能表現(xiàn),但是對于可能出現(xiàn)服務(wù)失效的應(yīng)用,由于請求未能被正確處理而返回,這一過程與部分應(yīng)用正常請求所消耗的時間相似,因此未能正確反映出故障的發(fā)生.而對于未能正確檢測原因的故障,主要與集群節(jié)點物理資源異常所導(dǎo)致的故障有關(guān),主要包括CPU 使用率高和內(nèi)存占用率高等情況.這是因為資源使用異常類的故障發(fā)生時,仍有部分請求在性能衰減的系統(tǒng)中完成整個處理流程,返回正確的結(jié)果,因此這一部分的請求雖然處理時間異常,但仍能描述正確的調(diào)用關(guān)系,本文所提出的根據(jù)執(zhí)行追蹤所建立模型并未對于這一類請求進行更為詳細的描述.關(guān)于這一類故障,可以結(jié)合對于集群節(jié)點的物理資源度量和對容器資源的運行時監(jiān)測進行分析和檢測.

5 相關(guān)工作

近年來,微服務(wù)軟件架構(gòu)由于其可控制的復(fù)雜性、資源可伸縮性、容錯性、高可用性等優(yōu)點逐漸受到各大互聯(lián)網(wǎng)巨頭的青睞.在服務(wù)模型搭建和故障診斷方面,各有其研究的展開.

在服務(wù)模型搭建方面,文獻[21]提出了一種評估程序架構(gòu)信息的方法,基于模糊的開發(fā)代碼和不精確的需求,評估基于所提出框架的微服務(wù)開發(fā)能否契合原本非功能性需求.文獻[22]提出了基于SDN (Software-Defined Networking)和NFV (Network Functions Virtualization)自我診斷框架,該框架基于對物理、邏輯、虛擬和服務(wù)層的監(jiān)督內(nèi)容進行定義,動態(tài)生成診斷模型,逐漸確定故障區(qū)域.文獻[23]提出了一種通過分析服務(wù)調(diào)用鏈以生成關(guān)系依賴圖的方法,通過分析服務(wù)依賴關(guān)系來找到可能存在風(fēng)險的調(diào)用,從而找到目標系統(tǒng)存在的異常.然而,以上幾種方法所建立的模型均沒有對異常請求和正常請求分別進行建模和歸類,同時對于系統(tǒng)出現(xiàn)故障的歷史表現(xiàn)缺乏記錄,從而當相同的故障發(fā)生時診斷效率低下.本文通過已有的歷史模型對未知請求的模型進行比對,由于使用系統(tǒng)正確處理請求的歷史數(shù)據(jù)模型作為故障判別的標準,無需修改現(xiàn)有模型即可判斷當前系統(tǒng)所處的狀態(tài)以及可能的產(chǎn)生故障的原因.

在故障診斷方面,文獻[24]提出了一種通過記錄Netfiix的網(wǎng)關(guān)Zuul[25]活動,從微服務(wù)的請求中收集指標的方法,這種方法的開銷很小,但是存在著缺乏對于服務(wù)之間調(diào)用的因果關(guān)系計算的過程,因此會對后續(xù)原因診斷造成一定的困擾.文獻[26]提出了一種非侵入式的方法,收集追蹤信息和生成日志,幫助運維人員排除相關(guān)故障的方法.該方法通過捕獲網(wǎng)絡(luò)數(shù)據(jù)包的形式分析其中的HTTP 標頭,判斷請求的類型并計算跟蹤信息.這種方法由于只依賴網(wǎng)絡(luò)獲取數(shù)據(jù)包,不需要對應(yīng)用進行修改,但是存在一定的性能消耗,并且在高負載情況下會減少日志文件的生成.本文所提出的方法通過預(yù)先記錄系統(tǒng)正確請求處理的概況和注入故障后系統(tǒng)的行為,當未知狀態(tài)請求產(chǎn)生時,只需將當前請求的追蹤信息進行建模比對,無需對已知請求模型進行修改,具有較小的資源開銷.

6 總結(jié)與展望

本文針對微服務(wù)監(jiān)測存在粒度較粗、故障定位不準確等缺點提出一種基于相似度匹配的微服務(wù)故障診斷方法.首先,使用注入代理轉(zhuǎn)發(fā)請求流量的方式收集并建模微服務(wù)的追蹤信息;然后,收集系統(tǒng)正常運行下的狀態(tài)信息,并通過注入已知故障來收集并刻畫故障發(fā)生后應(yīng)用的運行狀態(tài);最后,將未知故障的執(zhí)行追蹤信息與已知故障的執(zhí)行追蹤信息相匹配,采用字符串編輯距離衡量相似度以診斷可能的故障原因.相較于現(xiàn)有方法,本文提出的方法存在以下優(yōu)點:(1)基于系統(tǒng)歷史狀態(tài)表現(xiàn)分析,能夠靈活準確的判斷當前系統(tǒng)狀態(tài);(2)對于歷史故障真實還原和記錄,相似故障發(fā)生時能夠快速匹配和反饋;(3)對未知故障自動進行相似度匹配,基于已有故障的表現(xiàn)提出可能的故障原因,幫助快速排查故障.同時,通過與相關(guān)微服務(wù)監(jiān)測方法的結(jié)合,可以減少排除故障所需的時間,減少實際損失.

該方法還存在以下待改進的問題:首先,故障注入可能會造成部分罕見故障和復(fù)雜故障的遺漏,后續(xù)工作將引入對已檢查故障的追蹤信息補充錄入,增大故障判斷類型的廣度;其次,檢測方法的性能開銷與已記錄的追蹤數(shù)量呈正比,我們后續(xù)將對故障注入種類數(shù)量和注入點的選取進行研究,以較小的性能開銷獲得較高的故障判斷準確性.