本發(fā)明涉及分布式軟件的異常診斷方法，尤其涉及一種基于執(zhí)行軌跡追蹤的分布式軟件異常檢測(cè)與故障定位方法，屬于軟件技術(shù)領(lǐng)域。

背景技術(shù)：

云計(jì)算環(huán)境下，分布式軟件的動(dòng)態(tài)性和復(fù)雜性不斷增加，傳統(tǒng)的軟件架構(gòu)已經(jīng)難以適應(yīng)用戶需求的快速變化。分布式軟件架構(gòu)旨在設(shè)計(jì)與開(kāi)發(fā)可維護(hù)性和可擴(kuò)展的軟件，將復(fù)雜的軟件系統(tǒng)拆分成功能單一，可獨(dú)立開(kāi)發(fā)部署的模塊，通過(guò)輕量級(jí)通信機(jī)制使得這些模塊協(xié)同配合，從而形成一種高內(nèi)聚低耦合的分布式軟件。但是，分布式軟件的模塊眾多，依賴關(guān)系復(fù)雜，大大增加了故障發(fā)生的概率和診斷的難度。特別是，當(dāng)其中一個(gè)分布式軟件模塊出現(xiàn)故障時(shí)，故障的影響會(huì)隨著模塊間的相互調(diào)用不斷擴(kuò)散，最終導(dǎo)致整個(gè)服務(wù)失效或違約。因此有效檢測(cè)分布式軟件故障，并準(zhǔn)確定位問(wèn)題原因是保障分布式軟件性能與可靠性的關(guān)鍵技術(shù)之一。

引發(fā)分布式軟件故障的原因有很多，比如軟件設(shè)計(jì)缺陷、代碼問(wèn)題、配置錯(cuò)誤。故障會(huì)導(dǎo)致系統(tǒng)行為異常，表現(xiàn)為請(qǐng)求失敗、響應(yīng)延時(shí)等。當(dāng)前的分布式軟件異常診斷方法可以分為基于規(guī)則和異常檢測(cè)等兩類。基于規(guī)則的方法根據(jù)歷史故障所表現(xiàn)的現(xiàn)象來(lái)定義故障出現(xiàn)時(shí)可辨別的特征，而后將觀察到的現(xiàn)象與已定義的故障特征進(jìn)行匹配。當(dāng)匹配成功則檢測(cè)為故障，發(fā)出警報(bào)；否則認(rèn)為軟件運(yùn)行正常(Chen H，Jiang G，Yoshihira K，Saxena A.Invariants based failure diagnosis in distributed computing systems//Proceedings of the 29th IEEE Symposium on Reliable Distributed Systems.India，2010：160-166)?；谝?guī)則的方法由于事先已知故障及其表現(xiàn)，具有較高的準(zhǔn)確性和及時(shí)性。然而，當(dāng)此前未曾出現(xiàn)該故障，或者該故障的表現(xiàn)難以刻畫，基于規(guī)則的方法就不能夠準(zhǔn)確識(shí)別。

另一方面，基于異常檢測(cè)的方法為目標(biāo)系統(tǒng)建立模型作為基準(zhǔn)，將系統(tǒng)行為與基準(zhǔn)進(jìn)行對(duì)比。根據(jù)軟件監(jiān)測(cè)分析對(duì)象的不同，基于異常檢測(cè)的方法可以分為度量分析和日志分析等方法。度量分析方法通過(guò)調(diào)用操作系統(tǒng)提供的接口收集監(jiān)測(cè)數(shù)據(jù)，將當(dāng)前監(jiān)測(cè)數(shù)據(jù)與歷史監(jiān)測(cè)數(shù)據(jù)進(jìn)行對(duì)比分析。(Wang T，Zhang W，Wei.J，Zhong H.Workload-aware online anomaly detection in enterprise applications with local outlier factor//Proceedings of the IEEE 36th Annual Computer Software and Applications Conference.Izmir，Turkey，2012：25-34.)。該方法無(wú)需事先知道錯(cuò)誤類型并描述其特征，但由于云計(jì)算環(huán)境具有動(dòng)態(tài)性與復(fù)雜性，建立具有魯棒性和普適性的基準(zhǔn)相當(dāng)困難?；谌罩痉治龅姆椒?，通過(guò)分析日志信息可以推斷出分布式軟件的部分執(zhí)行路徑，進(jìn)而分析軟件是否正確執(zhí)行(Fu Q，Lou JG，Wang Y，Li J.Execution anomaly detection in distributed systems through unstructured log analysis//Proceedings of the 9th IEEE International Conference on Data Mining.Miami，F(xiàn)L，2009：149-158.)。該方法能夠定位到具體的故障組件，但其準(zhǔn)確性取決于日志記錄的數(shù)量和位置。同時(shí)，由于需要收集大量的日志文件，從中抽取固定的模式，難以滿足在線故障檢測(cè)的需求。

面向分布式軟件架構(gòu)的分布式軟件，當(dāng)前的異常診斷方法面臨以下挑戰(zhàn)。首先，分布式軟件的一個(gè)請(qǐng)求處理需要多個(gè)相互獨(dú)立的組件協(xié)同配合完成，因而難以監(jiān)測(cè)與特定請(qǐng)求相對(duì)應(yīng)的跨節(jié)點(diǎn)請(qǐng)求處理路徑。其次，分布式軟件的業(yè)務(wù)邏輯種類繁多，因而難以分析得到眾多不確定的執(zhí)行軌跡。最后，分布式軟件組件通常會(huì)有多個(gè)運(yùn)行實(shí)例，因此難以準(zhǔn)確定位出現(xiàn)故障的運(yùn)行實(shí)例與具體位置。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明的技術(shù)解決問(wèn)題：克服現(xiàn)有技術(shù)的不足，提供一種基于執(zhí)行軌跡追蹤的分布式軟件異常診斷方法，通過(guò)代碼注入監(jiān)測(cè)請(qǐng)求處理的執(zhí)行路徑，刻畫分布式軟件的執(zhí)行軌跡，從而通過(guò)與基準(zhǔn)執(zhí)行軌跡進(jìn)行對(duì)比分析，以準(zhǔn)確定位故障原因，從而準(zhǔn)確定位發(fā)生錯(cuò)誤的位置。

本發(fā)明技術(shù)解決方案：一種基于執(zhí)行軌跡追蹤的分布式軟件異常診斷方法，包括以下步驟：

第一步：執(zhí)行軌跡監(jiān)測(cè)：利用動(dòng)態(tài)插樁的方式，在分布式軟件的函數(shù)調(diào)用處插入監(jiān)測(cè)代碼，收集該函數(shù)的執(zhí)行信息，執(zhí)行信息包括該函數(shù)唯一標(biāo)識(shí)、處理時(shí)間、服務(wù)組件唯一標(biāo)識(shí)和遠(yuǎn)程調(diào)用協(xié)議中加入的該函數(shù)調(diào)用關(guān)系；根據(jù)以上函數(shù)的執(zhí)行信息利用調(diào)用樹(shù)描述函數(shù)的執(zhí)行序列，即執(zhí)行軌跡；

第二步：在覆蓋測(cè)試階段對(duì)分布式軟件進(jìn)行監(jiān)測(cè)，以構(gòu)建執(zhí)行軌跡的集合，上述執(zhí)行軌跡的集合構(gòu)建過(guò)程如下：

針對(duì)當(dāng)前的執(zhí)行軌跡，通過(guò)寬度優(yōu)先搜索的樹(shù)匹配算法與上述執(zhí)行軌跡的集合中已有的執(zhí)行軌跡進(jìn)行匹配；如果匹配成功，則繼續(xù)下一個(gè)執(zhí)行軌跡的匹配；如果匹配失敗，則在上述執(zhí)行軌跡的集合中新增當(dāng)前的執(zhí)行軌跡；

第三步：將第二步建立的執(zhí)行軌跡集合作為檢測(cè)分布式軟件的故障的基準(zhǔn)，通過(guò)比較與分析監(jiān)測(cè)得到的當(dāng)前執(zhí)行軌跡與上述執(zhí)行軌跡集合中的執(zhí)行軌跡，以定位分布式軟件故障的原因；

將分布式軟件的故障分為系統(tǒng)錯(cuò)誤故障和性能異常故障兩類，針對(duì)這兩類故障分別提出相應(yīng)的異常診斷方法，實(shí)現(xiàn)了函數(shù)粒度的故障定位。

所述第三步中，具體實(shí)現(xiàn)如下：

(1)在系統(tǒng)錯(cuò)誤診斷方面，利用樹(shù)編輯距離來(lái)評(píng)估執(zhí)行軌跡的異常程度，通過(guò)對(duì)比分析歷史執(zhí)行軌跡的差異，定位發(fā)生錯(cuò)誤的函數(shù)調(diào)用；

樹(shù)編輯距離為：

其中，T_i為監(jiān)測(cè)得到的當(dāng)前第i個(gè)執(zhí)行軌跡；C_j為執(zhí)行軌跡集合中的第j個(gè)基準(zhǔn)執(zhí)行軌跡；V(T_i)和V(C_j)分別為T_i和C_j中函數(shù)的數(shù)量；δ(T_i，C_j)為T_i和C_j的編輯距離。

T_i的異常程度：

AD＝1-max(Sim(T_i,C_j))；

如果AD大于預(yù)置的閥值γ，則表示該執(zhí)行軌跡發(fā)生了錯(cuò)誤；

利用寬度優(yōu)先搜索比較T_i和C_j的軌跡差別，能夠定位到錯(cuò)誤出現(xiàn)在具體函數(shù)；

(2)在性能異常方面，利用主成分分析提取引起性能異常的函數(shù)調(diào)用，如果當(dāng)前執(zhí)行軌跡的執(zhí)行時(shí)間出現(xiàn)大幅度波動(dòng)，則該執(zhí)行軌跡出現(xiàn)性能異常，利用變異系數(shù)來(lái)衡量執(zhí)行軌跡的執(zhí)行時(shí)間的波動(dòng)程度：

其中：

其中，x_i為第i個(gè)執(zhí)行軌跡的執(zhí)行時(shí)間；μ為該執(zhí)行軌跡的執(zhí)行時(shí)間的平均值；σ為該執(zhí)行軌跡的執(zhí)行時(shí)間的標(biāo)準(zhǔn)差；CV為該執(zhí)行軌跡的執(zhí)行時(shí)間的標(biāo)準(zhǔn)差與均值的比值，表明分布式軟件的執(zhí)行軌跡的執(zhí)行時(shí)間波動(dòng)幅度；

執(zhí)行軌跡是由函數(shù)調(diào)用的序列組成，在確定出現(xiàn)性能異常的執(zhí)行軌跡后，需要利用主成分分析定位造成該執(zhí)行軌跡性能異常的函數(shù)調(diào)用；

建立線性組合，如下式：

p_i＝a_i1t₁+…+a_ijt_j+…+a_int_n

其中，p_i表示主成分i；變量t_i表示執(zhí)行軌跡中的第i個(gè)函數(shù)的執(zhí)行時(shí)間；a_ij表示主成分p_i對(duì)于t_j的系數(shù)；n為該執(zhí)行軌跡中函數(shù)的個(gè)數(shù)；

利用主成分分析計(jì)算得到k個(gè)主成分為p₁，p₂，..，p_k，其對(duì)應(yīng)的特征值為λ₁，λ₂，...，λ_k，k<n為正整數(shù)，計(jì)算執(zhí)行軌跡中各個(gè)函數(shù)j的權(quán)重對(duì)權(quán)重從大到小排序，選取值最大的m個(gè)權(quán)重，m<n為正整數(shù)，所述權(quán)重所對(duì)應(yīng)的函數(shù)為引起執(zhí)行軌跡性能異常的原因。

本發(fā)明的原理：首先利用跨服務(wù)組件的執(zhí)行軌跡監(jiān)測(cè)及約簡(jiǎn)方法對(duì)執(zhí)行軌跡進(jìn)行了刻畫；然后，從系統(tǒng)錯(cuò)誤和性能異常兩方面進(jìn)行了異常診斷。在系統(tǒng)錯(cuò)誤診斷方面，利用調(diào)用樹(shù)的編輯距離來(lái)評(píng)估請(qǐng)求處理的異常程度，通過(guò)對(duì)比分析執(zhí)行軌跡的差異，準(zhǔn)確定位發(fā)生錯(cuò)誤的函數(shù)調(diào)用。在檢測(cè)性能異常方面，利用主成分分析提取對(duì)響應(yīng)時(shí)間延遲造成影響較大的組件實(shí)例與函數(shù)調(diào)用。

本發(fā)明與現(xiàn)有技術(shù)相比具有如下優(yōu)點(diǎn)：

(1)本發(fā)明利用動(dòng)態(tài)插樁的方式，在分布式軟件的函數(shù)調(diào)用處插入監(jiān)測(cè)代碼，收集函數(shù)的執(zhí)行信息。在遠(yuǎn)程調(diào)用協(xié)議中加入了函數(shù)調(diào)用關(guān)系，以實(shí)現(xiàn)跨組件的請(qǐng)求處理軌跡監(jiān)測(cè)。同時(shí)，為了消除遞歸、循環(huán)調(diào)用等對(duì)執(zhí)行軌跡的影響，增加了相應(yīng)的約簡(jiǎn)規(guī)則。該函數(shù)具有可插拔、易擴(kuò)展的特點(diǎn)，并能夠自動(dòng)化刻畫與構(gòu)建請(qǐng)求處理的執(zhí)行軌跡。

(2)本發(fā)明針對(duì)造成執(zhí)行軌跡改變的故障，采用樹(shù)的編輯距離來(lái)評(píng)估請(qǐng)求的異常程度，通過(guò)對(duì)比分析定位引起故障的函數(shù)調(diào)用。針對(duì)造成服務(wù)響應(yīng)時(shí)間延遲的故障，利用主成分分析對(duì)監(jiān)測(cè)數(shù)據(jù)進(jìn)行降維，進(jìn)而提取異常函數(shù)。本發(fā)明以較低開(kāi)銷，能夠以函數(shù)為粒度準(zhǔn)確定位問(wèn)題原因。

附圖說(shuō)明

圖1為本發(fā)明的實(shí)現(xiàn)流程圖；

圖2為本發(fā)明的實(shí)驗(yàn)環(huán)境；

圖3為本發(fā)明的四種服務(wù)構(gòu)建的執(zhí)行軌跡數(shù)；

圖4為本發(fā)明的系統(tǒng)異常程度變化；

圖5為本發(fā)明中服務(wù)13種執(zhí)行軌跡變異系數(shù)；

圖6為本發(fā)明中服務(wù)軌跡5響應(yīng)時(shí)間；

圖7為本發(fā)明中主成分占比。

具體實(shí)施方式

以下結(jié)合具體實(shí)施例和附圖對(duì)本發(fā)明進(jìn)行詳細(xì)說(shuō)明。

如圖1所示，本發(fā)明一種基于執(zhí)行軌跡追蹤的分布式軟件異常診斷方法，實(shí)現(xiàn)步驟如下：

首先，進(jìn)行執(zhí)行軌跡監(jiān)測(cè)。利用動(dòng)態(tài)插樁的方式，在分布式軟件的函數(shù)調(diào)用處插入監(jiān)測(cè)代碼，收集該函數(shù)的執(zhí)行信息，利用調(diào)用樹(shù)描述函數(shù)的執(zhí)行序列，即執(zhí)行軌跡；

然后，在覆蓋測(cè)試階段對(duì)分布式軟件進(jìn)行監(jiān)測(cè)，以構(gòu)建執(zhí)行軌跡的集合。通過(guò)寬度優(yōu)先搜索的樹(shù)匹配算法與執(zhí)行軌跡集合中已有的執(zhí)行軌跡進(jìn)行匹配；如果匹配成功，則繼續(xù)下一個(gè)執(zhí)行軌跡的匹配；如果匹配失敗，則在執(zhí)行軌跡的集合中新增當(dāng)前的執(zhí)行軌跡；

最后，將建立的執(zhí)行軌跡集合作為檢測(cè)分布式軟件故障的基準(zhǔn)。通過(guò)比較與分析監(jiān)測(cè)得到的當(dāng)前執(zhí)行軌跡與執(zhí)行軌跡集合中執(zhí)行軌跡的函數(shù)調(diào)用序列和函數(shù)執(zhí)行時(shí)間，以定位分布式軟件故障的原因。

具體實(shí)施例的部署環(huán)境如圖2所示，Console為管理組件，提供了測(cè)試參數(shù)配置、錯(cuò)誤注入及監(jiān)控等功能；Agent為負(fù)載發(fā)生代理，接受Console發(fā)送來(lái)的指令，模擬用戶行為，訪問(wèn)網(wǎng)上書店服務(wù)；網(wǎng)上書店應(yīng)用在應(yīng)用服務(wù)器A和應(yīng)用服務(wù)器B各部署一個(gè)實(shí)例；負(fù)載均衡器為應(yīng)用服務(wù)器集群提供負(fù)載均衡，采用輪詢負(fù)載策略；數(shù)據(jù)庫(kù)提供存儲(chǔ)服務(wù)；故障診斷系統(tǒng)為本文所提出方法的實(shí)現(xiàn)。

(1)執(zhí)行軌跡獲得與監(jiān)測(cè)

1)執(zhí)行軌跡獲得

請(qǐng)求的處理是由若干服務(wù)組件協(xié)同完成，其執(zhí)行軌跡是各服務(wù)組件的函數(shù)調(diào)用。采用函數(shù)調(diào)用樹(shù)來(lái)刻畫請(qǐng)求處理的執(zhí)行軌跡，結(jié)點(diǎn)M_i用多元組(1)表示：

M_i＝(requestUID,methodUID,callerUID,calleeList,info) (1)

其中，requestUID為請(qǐng)求標(biāo)識(shí)符，在請(qǐng)求入口處生成；methodUID為函數(shù)標(biāo)識(shí)符；callerUID為父函數(shù)標(biāo)識(shí)符；calleeList為子函數(shù)列表；info包含函數(shù)的其他信息，用多元組(2)表示：

info＝(callType,serviceUID,order,startTime,endTime,duration) (2)

其中，callType為函數(shù)的調(diào)用類型，分為本地調(diào)用和遠(yuǎn)程過(guò)程調(diào)用(Remote ProcessCall，RPC)。serviceUID為函數(shù)所在服務(wù)組件的標(biāo)識(shí)符；order為函數(shù)的調(diào)用順序，子節(jié)點(diǎn)按照從左到右的順序排序?yàn)楹瘮?shù)的調(diào)用時(shí)序關(guān)系；startTime和endTime是函數(shù)開(kāi)始、結(jié)束時(shí)間；duration為函數(shù)的執(zhí)行時(shí)間，但不包括子函數(shù)的執(zhí)行時(shí)間。

2)執(zhí)行軌跡的監(jiān)測(cè)

本發(fā)明采用一種動(dòng)態(tài)插樁的方式獲取執(zhí)行信息，對(duì)JAVA應(yīng)用程序進(jìn)行了字節(jié)碼注入，在虛擬機(jī)啟動(dòng)時(shí)通過(guò)增加代理的方式將監(jiān)測(cè)代碼插入到指定函數(shù)。分布式軟件的函數(shù)調(diào)用包括本地和遠(yuǎn)程調(diào)用，執(zhí)行軌跡的監(jiān)測(cè)主要需要解決以下問(wèn)題：

①多服務(wù)組件的每個(gè)請(qǐng)求的區(qū)分及標(biāo)識(shí)：在系統(tǒng)入口服務(wù)組件處為請(qǐng)求生成唯一標(biāo)識(shí)requestUID，在調(diào)用遠(yuǎn)程函數(shù)時(shí)，調(diào)用函數(shù)將requestUID傳遞給被調(diào)用函數(shù)，被調(diào)用函數(shù)解析該字段，確定該函數(shù)調(diào)用屬于哪個(gè)請(qǐng)求。

②服務(wù)組件間的函數(shù)調(diào)用關(guān)系的確定：被調(diào)用函數(shù)維護(hù)調(diào)用函數(shù)的標(biāo)識(shí)符callerUID，遠(yuǎn)程函數(shù)調(diào)用時(shí)，將本函數(shù)的標(biāo)識(shí)符methodUID傳遞給遠(yuǎn)程函數(shù)，遠(yuǎn)程函數(shù)解析該字段，獲得調(diào)用函數(shù)的標(biāo)識(shí)符。

③多服務(wù)組件的函數(shù)調(diào)用順序的確定：在遠(yuǎn)程調(diào)用函數(shù)時(shí)，為遠(yuǎn)程函數(shù)分配一個(gè)調(diào)用順序order字段，從而保證了分布式環(huán)境下監(jiān)測(cè)函數(shù)調(diào)用順序的正確性，解決了由于節(jié)點(diǎn)的時(shí)鐘難以實(shí)現(xiàn)完全同步而導(dǎo)致的無(wú)法準(zhǔn)確確定函數(shù)調(diào)用順序的問(wèn)題。

各個(gè)服務(wù)組件以本地入口函數(shù)為根構(gòu)建調(diào)用子樹(shù)，確定函數(shù)的調(diào)用關(guān)系，然后根據(jù)請(qǐng)求標(biāo)識(shí)符requestUID，并根據(jù)函數(shù)調(diào)用關(guān)系實(shí)現(xiàn)執(zhí)行軌跡的調(diào)用樹(shù)的構(gòu)建。由于存在函數(shù)循環(huán)調(diào)用和遞歸調(diào)用，邏輯上等價(jià)的執(zhí)行軌跡生成的調(diào)用樹(shù)不同，將導(dǎo)致同一服務(wù)的執(zhí)行軌跡種類難以確定，需要進(jìn)行約簡(jiǎn)處理，因此增加了約簡(jiǎn)規(guī)則及函數(shù)，確保調(diào)用樹(shù)中的循環(huán)和遞歸可以被識(shí)別出來(lái)，進(jìn)而將循環(huán)和遞歸中的節(jié)點(diǎn)匯總為一個(gè)新節(jié)點(diǎn)消除循環(huán)和遞歸以實(shí)現(xiàn)約簡(jiǎn)，其中執(zhí)行時(shí)間取結(jié)點(diǎn)的平均時(shí)間。

(2)執(zhí)行軌跡的構(gòu)建

在覆蓋測(cè)試階段對(duì)軟件系統(tǒng)的執(zhí)行軌跡進(jìn)行監(jiān)測(cè)，以構(gòu)建執(zhí)行軌跡集合，將其作為檢測(cè)系統(tǒng)故障的基準(zhǔn)。服務(wù)的執(zhí)行軌跡集合S構(gòu)建過(guò)程如下：

①初始階段，軌跡集合S為空；

②針對(duì)軌跡T_i，通過(guò)寬度優(yōu)先搜索的樹(shù)匹配算法與集合S中已有的軌跡C_j進(jìn)行匹配；

③如果匹配成功，則繼續(xù)下一個(gè)執(zhí)行軌跡的匹配；

④如果匹配失敗，則集合S新增執(zhí)行軌跡C_i。

測(cè)試的覆蓋率越高，得到的基準(zhǔn)執(zhí)行軌跡集合就越全面，則異常診斷準(zhǔn)確率越高。為了避免覆蓋測(cè)試階段遺漏的正確執(zhí)行軌跡，在軟件系統(tǒng)上線運(yùn)行階段，管理員發(fā)現(xiàn)異常的執(zhí)行軌跡時(shí)，可以根據(jù)經(jīng)驗(yàn)進(jìn)行修正，發(fā)現(xiàn)、確認(rèn)新的正確執(zhí)行軌跡，并將其加入基準(zhǔn)執(zhí)行軌跡集合。

(3)異常診斷

系統(tǒng)故障會(huì)導(dǎo)致執(zhí)行軌跡發(fā)生偏離，表現(xiàn)為執(zhí)行軌跡結(jié)構(gòu)的變化和執(zhí)行時(shí)間的波動(dòng)，本發(fā)明中依次將其稱為系統(tǒng)錯(cuò)誤故障和性能異常故障，并針對(duì)這兩類故障分別提出相應(yīng)的異常診斷方法，實(shí)現(xiàn)了函數(shù)粒度的故障定位。

1)系統(tǒng)錯(cuò)誤診斷

同一服務(wù)請(qǐng)求處理的執(zhí)行軌跡集合包含了其可能的執(zhí)行軌跡，以此為基準(zhǔn)，將運(yùn)行時(shí)監(jiān)測(cè)到的執(zhí)行軌跡與之對(duì)比分析，從而對(duì)某一請(qǐng)求進(jìn)行系統(tǒng)錯(cuò)誤定位。本發(fā)明中采用樹(shù)編輯距離來(lái)評(píng)估執(zhí)行軌跡的異常程度，對(duì)超過(guò)異常閥值的請(qǐng)求，實(shí)現(xiàn)了函數(shù)級(jí)別的故障定位。為了確定異常發(fā)生的函數(shù)調(diào)用，需要找出最相近的基準(zhǔn)軌跡進(jìn)行對(duì)比。本發(fā)明基于樹(shù)的編輯距離的定義，使用式(3)來(lái)定義樹(shù)的相似度：

其中，T_i為請(qǐng)求i的執(zhí)行軌跡；C_j為其中一種基準(zhǔn)軌跡；V(T_i)和V(C_j)分別為T_i和C_j的結(jié)點(diǎn)數(shù)；δ(T_i，C_j)為T_i和C_j的編輯距離。

進(jìn)一步，當(dāng)樹(shù)的相似度較較低時(shí)，則異常的程度越大，使用式(4)來(lái)評(píng)估執(zhí)行軌跡T_i的異常程度：

AD＝1-max(Sim(T_i,C_j)),C_j∈T_i所屬服務(wù)的執(zhí)行軌跡集合S (4)

如果AD大于預(yù)置的閥值γ，則表示該請(qǐng)求發(fā)生了錯(cuò)誤。閥值選取將影響異常診斷結(jié)果，如果閥值設(shè)置過(guò)大，則容易造成診斷遺漏；如果設(shè)置過(guò)小，則將導(dǎo)致誤報(bào)率增加。通過(guò)比較T_i和C的軌跡差別，可以定位到錯(cuò)誤出現(xiàn)在具體哪個(gè)函數(shù)，函數(shù)粒度的錯(cuò)誤定位采用寬度優(yōu)先的錯(cuò)誤函數(shù)調(diào)用定位算法。

2)性能異常診斷

同一執(zhí)行軌跡有相同函數(shù)調(diào)用樹(shù)，執(zhí)行時(shí)間也相對(duì)穩(wěn)定，如果執(zhí)行時(shí)間出現(xiàn)大幅度波動(dòng)，則該請(qǐng)求處理出現(xiàn)性能異常。采用變異系數(shù)來(lái)衡量執(zhí)行時(shí)間的異常程度：

其中：

其中，x_i為第i個(gè)請(qǐng)求的執(zhí)行時(shí)間；μ為某類請(qǐng)求的平均執(zhí)行時(shí)間；σ為標(biāo)準(zhǔn)差；CV為標(biāo)準(zhǔn)差與均值的比值。CV較大則表明系統(tǒng)在處理請(qǐng)求時(shí)響應(yīng)時(shí)間波動(dòng)幅度較大，性能異常程度較高，則需要進(jìn)行性能分析。一個(gè)執(zhí)行軌跡往往包含上百個(gè)函數(shù)調(diào)用，而函數(shù)間存在調(diào)用關(guān)系，也就是包含了冗余數(shù)據(jù)，需要從中選取引起性能異常的關(guān)鍵函數(shù)以縮小異常定位范圍。主成分分析(PCA，Principle Component Analysis)是一種常用的多元分析方法，可以利用PCA可有效的降低原始數(shù)據(jù)的維度，從而縮小問(wèn)題定位的范圍。

基于PCA的性能異常診斷步驟如下：

①構(gòu)建請(qǐng)求處理矩陣

PCA的輸入為矩陣，首先需要將執(zhí)行軌跡轉(zhuǎn)換為執(zhí)行序列。采用調(diào)用樹(shù)表示執(zhí)行軌跡，樹(shù)結(jié)點(diǎn)滿足一定父子關(guān)系和時(shí)序關(guān)系，因此可將調(diào)用樹(shù)轉(zhuǎn)換為等語(yǔ)義的執(zhí)行序列。我們利用基于時(shí)間序列的深度優(yōu)先搜索算法，將調(diào)用樹(shù)T轉(zhuǎn)換為執(zhí)行序列。各個(gè)請(qǐng)求的執(zhí)行序列按行排列，組成PCA分析的輸入矩陣A：

其中，m為請(qǐng)求數(shù)量；n為執(zhí)行軌跡的函數(shù)數(shù)量；列表示函數(shù)的執(zhí)行時(shí)間，即t_ij為請(qǐng)求i執(zhí)行軌跡中函數(shù)M_j的執(zhí)行時(shí)間。

②主成分分析

執(zhí)行軌跡序列中每個(gè)函數(shù)的執(zhí)行時(shí)間是不同的，需要對(duì)原始矩陣X進(jìn)行標(biāo)準(zhǔn)化轉(zhuǎn)換，得到標(biāo)準(zhǔn)化矩陣Z：

其中：

然后，求標(biāo)準(zhǔn)化矩陣Z的協(xié)方差矩陣Σ：

其中：

最后，求協(xié)方差矩陣Σ的特征值和特征向量，求解特征方程：

∑X＝λX (14)

得到特征值λ₁，λ₂，...，λ_n及對(duì)應(yīng)的特征向量μ₁，μ₂，…，，μ_n.

③主成分選取

主成分的選取決定了數(shù)據(jù)壓縮率，設(shè)選取的主成分個(gè)數(shù)為k。特別的，如果k＝n，相當(dāng)于在原始數(shù)據(jù)上進(jìn)行了轉(zhuǎn)換，保留了原始數(shù)據(jù)的100％信息。那么在選擇k值時(shí)，以k個(gè)主成分可以保留的方差百分比為參考依據(jù)，百分比越大，選取的主成分所表示的信息，與原始數(shù)據(jù)越近似，首先對(duì)特征值λ₁，λ₂，...，λ_n按照降序排序，然后計(jì)算主成分方差百分比，如式(15)：

其中β為常量。

④異常函數(shù)的定位

主成分實(shí)際上是原有維度的線性組合，而系數(shù)向量就是對(duì)應(yīng)的特征向量，如式(16)：

p₁＝a₁₁t₁+a₁₂t₂+…+a_1nt_n

p₂＝a₂₁t₁+a₂₂t₂+…+a_2nt_n

…

p_m＝a_m1t₁+a_m2t₂+…+a_mnt_n (16)

其中，p_i表示主成分i；變量t_i表示函數(shù)M_i執(zhí)行時(shí)間；a_ij表示主成分p_i對(duì)于變量t_i的系數(shù)，表示了主成分與原始數(shù)據(jù)維度的相關(guān)性，系數(shù)越大，則表示該維度對(duì)主成分貢獻(xiàn)越大，即該維度對(duì)應(yīng)的函數(shù)即為引起性能問(wèn)題的主要因素，于是給出性能異常故障的定位算法：性能異常故障定位算法。

作為本發(fā)明實(shí)施例方法的使用環(huán)境，選取了中國(guó)科學(xué)院軟件研究所自主研發(fā)的符合TPC-W規(guī)范的基準(zhǔn)測(cè)試套件Bench4Q。系統(tǒng)架構(gòu)如圖2所示，Console為管理組件，提供了測(cè)試參數(shù)配置、錯(cuò)誤注入及監(jiān)控等功能；Bench4Q的Agent接受Console發(fā)送來(lái)的指令，模擬用戶行為，訪問(wèn)應(yīng)用服務(wù)；應(yīng)用服務(wù)器Tomcat部署了Bench4Q的網(wǎng)上書店應(yīng)用；負(fù)載均衡器Nginx為應(yīng)用服務(wù)器集群提供負(fù)載均衡，采用輪詢負(fù)載策略；數(shù)據(jù)庫(kù)MySQL為應(yīng)用提供存儲(chǔ)服務(wù)；異常診斷系統(tǒng)為本發(fā)明所提出方法的實(shí)現(xiàn)。實(shí)驗(yàn)，數(shù)據(jù)庫(kù)、負(fù)載均衡器和應(yīng)用服務(wù)器均采用默認(rèn)配置，Bench4Q設(shè)置10000件商品和1440000個(gè)用戶。

本發(fā)明實(shí)施例流程：

(1)執(zhí)行軌跡構(gòu)建

選取Bench4Q其中典型的4種服務(wù)作為研究對(duì)象進(jìn)行執(zhí)行軌跡的構(gòu)建，分別為Search request(查找)、Product detail(瀏覽)、Buy Request(購(gòu)買)、Buy Confirm(付款)，從而得到選取的4種服務(wù)執(zhí)行軌跡數(shù)如圖3所示。

(2)異常診斷

模擬生產(chǎn)環(huán)境中常見(jiàn)的故障，如表1所示。在實(shí)驗(yàn)過(guò)程中，我們將錯(cuò)誤單獨(dú)注入到系統(tǒng)，并在Console設(shè)置每次負(fù)載持續(xù)時(shí)間為90秒，并發(fā)數(shù)為100，同時(shí)異常診斷系統(tǒng)收集系統(tǒng)的執(zhí)行信息，并進(jìn)行異常診斷。

表1注入故障列表

選取其中三個(gè)典型的故障為例介紹：

故障(1).通過(guò)TC工具造成應(yīng)用服務(wù)器A網(wǎng)絡(luò)丟包15％；

故障(2).設(shè)置應(yīng)用服務(wù)器A數(shù)據(jù)庫(kù)連接數(shù)maxActive為10；

故障(3).使用SELECT…FOR UPDATE語(yǔ)句給訂單表加一個(gè)X鎖；

對(duì)于偶然性故障，比如模擬CPU、網(wǎng)絡(luò)異常等，是可以恢復(fù)的，實(shí)驗(yàn)在第30秒注入，持續(xù)30秒，然后恢復(fù)正常。對(duì)于持久性故障，比如JVM配置、數(shù)據(jù)庫(kù)連接等，需要重啟服務(wù)器才能恢復(fù)，因此此類故障持續(xù)時(shí)間90秒。故障(1)和(3)在第30秒注入，持續(xù)30秒，然后恢復(fù)正常，而故障(2)持續(xù)時(shí)間90秒。

1)系統(tǒng)錯(cuò)誤的異常診斷

Search request(查找)、Product detail(瀏覽)、Buy Request(購(gòu)買)、Buy Confirm(付款)等四種服務(wù)的異常程度變化如圖4所示，選取與監(jiān)測(cè)到的異常執(zhí)行軌跡具有最大相似度的基準(zhǔn)執(zhí)行軌跡集合中的正常執(zhí)行軌跡，將檢測(cè)到的運(yùn)行時(shí)執(zhí)行軌跡與正常執(zhí)行軌跡進(jìn)行對(duì)比，當(dāng)注入錯(cuò)誤時(shí)，請(qǐng)求的執(zhí)行軌跡相應(yīng)發(fā)生了變化，因而異常程度增大。

在第30秒注入故障(1)后，4種服務(wù)均發(fā)生請(qǐng)求失敗，出現(xiàn)了服務(wù)違約，從圖4可知，錯(cuò)誤執(zhí)行軌跡的異常程度分別超過(guò)了0.16、0.41、0.38和0.23.通過(guò)錯(cuò)誤定位算法，得到發(fā)生錯(cuò)誤的函數(shù)均與網(wǎng)絡(luò)相關(guān)，且發(fā)生在應(yīng)用服務(wù)器A的函數(shù)占比約95％，因此進(jìn)一步，可以斷定故障發(fā)生的位置為服務(wù)器A的網(wǎng)絡(luò)。

注入故障(3)后，Buy Request和Buy Confirm服務(wù)失效，從圖7可知，相對(duì)于Search request和Product detail，Buy Request和Buy Confirm的執(zhí)行軌跡異常程度較大，分別超過(guò)了0.63和0.61。采用通過(guò)錯(cuò)誤異常診斷函數(shù)，定位出異常發(fā)生所在的位置為新增訂單函數(shù)和修改訂單函數(shù)，這樣有效地縮小了故障排查范圍。

對(duì)于故障(2)，有意將應(yīng)用服務(wù)器A的數(shù)據(jù)庫(kù)連接數(shù)設(shè)置過(guò)小，在100個(gè)并發(fā)數(shù)下，結(jié)果只有少數(shù)執(zhí)行軌跡結(jié)構(gòu)發(fā)生變化，但服務(wù)響應(yīng)時(shí)間延遲較大，為進(jìn)一步確定問(wèn)題發(fā)生在哪個(gè)環(huán)節(jié)，在下將以Buy Confirm服務(wù)為例進(jìn)一步進(jìn)行診斷性能異常。

2)性能異常的異常診斷

Buy Confirm服務(wù)共有13種執(zhí)行軌跡，在數(shù)據(jù)庫(kù)連接數(shù)設(shè)置過(guò)小的時(shí)間段內(nèi)，各執(zhí)行軌跡的變異程度CV如圖5所示。

實(shí)驗(yàn)中選取變異系數(shù)最大的軌跡5作為分析對(duì)象，由圖6可見(jiàn)，服務(wù)的響應(yīng)時(shí)間波動(dòng)很大，但CPU、內(nèi)存等物理資源使用率并不是很高，僅依據(jù)資源利用率難以定位出問(wèn)題的原因。

執(zhí)行軌跡5包含了57個(gè)函數(shù)調(diào)用，通過(guò)性能異常診斷，得到主成分占比如圖7所示，主成分1、2、3分別占64.9389％、26.2608％和4.1277％，主成分1和2累計(jì)占91.1997％，因此，主成分1和2可以有效的表現(xiàn)了原有數(shù)據(jù)信息。

表2列出了前三個(gè)主成分與其中6個(gè)函數(shù)的系數(shù)，系數(shù)越大則主成分與函數(shù)的相關(guān)性越強(qiáng)。從表4分析結(jié)果可以定位引起性能瓶頸的主要函數(shù)為Database.getConnection()，從異常診斷的輸出結(jié)果中，應(yīng)用服務(wù)器A和B此函數(shù)的平均執(zhí)行時(shí)間為501.46ms和1.75ms，從中可以確定性能瓶頸發(fā)生在應(yīng)用服務(wù)器A的創(chuàng)建數(shù)據(jù)庫(kù)連接環(huán)節(jié)。

表2主成分與函數(shù)的系數(shù)

提供以上實(shí)施例僅僅是為了描述本發(fā)明的目的，而并非要限制本發(fā)明的范圍。本發(fā)明的范圍由所附權(quán)利要求限定。不脫離本發(fā)明的精神和原理而做出的各種等同替換和修改，均應(yīng)涵蓋在本發(fā)明的范圍之內(nèi)。