謝瓊

摘要：針對(duì)開(kāi)源云平臺(tái)系統(tǒng)，該文通過(guò)分析系統(tǒng)中的異常處理機(jī)制以及日志系統(tǒng)，提出了基于異常信息描述的故障模式提取方法；并過(guò)理論分析系統(tǒng)日志能夠記錄的異常信息特征；系統(tǒng)異常處理機(jī)制拋出的異常特征；并結(jié)合實(shí)驗(yàn)獲取日志中能夠記錄所拋出異常信息的比例，以及提取的異常特征與故障模式的對(duì)應(yīng)關(guān)系，從而提出一種基于日志中的異常描述信息，從而進(jìn)行系統(tǒng)故障診斷。

關(guān)鍵詞： 故障模式提?。蝗罩?；異常機(jī)制；云平臺(tái)；故障診斷

中圖分類號(hào)：TP391 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2015）20-0204-02

A Fault Mode Extraction Method Based on Fault Exception Mechanism of Code

XIE Qiong

（School of Software Engineering， Tongji University， Shanghai 201804， China）

Abstract：Respect to open source cloud platform， we proposed a system based on the exception handling mechanism and system logging mechanism in which the exception information are recorded. After analyses the features of abnormal information which can be recorded by the system log， the features of anomaly which thrown by system anomalys processing mechanism theoretically， we conduct experiments to show the proportion of thrown abnormal information which can be recorded by log， and the corresponding relations between fault mode and fault pattern. Finally we proposed a method to extract information from the log exception description and diagnosis system fault.

Key words：fault mode extract； log； exception mechanism； cloud computing system； fault diagnosis

隨著越來(lái)越多的個(gè)人和企業(yè)將信息放在云上，云計(jì)算[1]在可靠性、信息安全問(wèn)題上面臨著巨大的挑戰(zhàn)。由于計(jì)算機(jī)固有資源的不可靠性和人為操作失誤導(dǎo)致的故障不可避免；同時(shí)，由于云計(jì)算系統(tǒng)復(fù)雜性，使得云計(jì)算系統(tǒng)容易因硬件和軟件故障，在運(yùn)行時(shí)發(fā)生各種失效[2]。因此要獲得系統(tǒng)的可靠性保障，故障診斷是一項(xiàng)重要的技術(shù)。故障診斷主要包括以下幾個(gè)步驟：故障定義、故障的描述（故障集提取）、故障檢測(cè)、故障定位[3]。目前云計(jì)算系統(tǒng)故障診斷主要分為三類方法，一、基于性能異常的故障診斷，該方法前期建立正常或故障時(shí)的性能模式庫(kù)，在系統(tǒng)運(yùn)行時(shí)與系統(tǒng)實(shí)時(shí)性能數(shù)據(jù)進(jìn)行對(duì)比[5-7]；二、端到端的探測(cè)技術(shù)，在每個(gè)節(jié)點(diǎn)插入一些探針收集每個(gè)模塊輸出信息，然后每次診斷都從中選擇一些合適的探針進(jìn)行數(shù)據(jù)分析，故障模式庫(kù)建立通過(guò)故障注入后獲取異常特征信息（如注入故障時(shí)函數(shù)的返回值，每個(gè)模塊的執(zhí)行時(shí)間）[4]；三、心跳機(jī)制，通過(guò)設(shè)置心跳信息判斷機(jī)器是否運(yùn)行狀況良好，這種診斷方法的診斷粒度低。

1 基于日志中異常信息故障模式提取

1.1 函數(shù)異常結(jié)構(gòu)描述

通常入口函數(shù)表示某個(gè)功能操作開(kāi)始，以入口函數(shù)為起點(diǎn)的調(diào)用鏈上的函數(shù)都是與入口函數(shù)對(duì)應(yīng)功能操作相關(guān)，如果調(diào)用鏈上的函數(shù)執(zhí)行異常，將導(dǎo)致該功能執(zhí)行失敗，即系統(tǒng)發(fā)生故障。通過(guò)分析函數(shù)調(diào)用鏈上拋出的異常信息，獲取系統(tǒng)故障的根因。當(dāng)程序故障被激活后，產(chǎn)生的差錯(cuò)可以有多種形式存在，如：返回碼、共享變量、異常等等。在異常得到捕捉之后，程序以不同的方式告知用戶錯(cuò)誤的發(fā)生，如 HTTP 響應(yīng)消息、日志等。

圖1 函數(shù)異常結(jié)構(gòu)描述

1.2 異常特征信息與故障模式對(duì)應(yīng)關(guān)系

故障模式與異常特征之間的關(guān)系：在本文中異常特征主要指的是異常和異常的具體描述信息，采用一個(gè)三元組FF表示[FF=]。E表示異常類型，D表示異常的詳細(xì)信息，O表示激發(fā)異常的操作

每入口函數(shù)存在一個(gè)調(diào)用鏈，從代碼結(jié)構(gòu)而言，代碼的重用性和可讀性，調(diào)用鏈上函數(shù)可能只被一個(gè)入口函數(shù)調(diào)用，也可能被多個(gè)入口函數(shù)調(diào)用。當(dāng)把函數(shù)中的一條異常和異常信息作為異常特征信息，此時(shí)異常特征信息與故障模式為多對(duì)多的關(guān)系，在系統(tǒng)診斷過(guò)程中獲取到的異常特征信息難以確定故障模式。因此在函數(shù)中提取異常特征信息時(shí)加入功能操作字段，形成異常特征信息三元組FF，使得故障模式與異常特征的關(guān)系為一對(duì)多的關(guān)系，此時(shí)獲取一條異常特征信息時(shí)就能確定一個(gè)故障模式。如OpenStack在創(chuàng)建虛擬機(jī)操作，一條故障模式為“由于無(wú)效請(qǐng)求創(chuàng)建虛擬機(jī)失敗”，那么其異常特征為<由于輸入?yún)?shù)不對(duì)創(chuàng)建虛擬機(jī)失??；由于網(wǎng)絡(luò)的格式不對(duì)無(wú)效的請(qǐng)求；IP無(wú)法申請(qǐng)無(wú)效的請(qǐng)求>。

1.3 異常特征信息的提取

程序中異常被拋出，如果異常所在函數(shù)存在捕捉對(duì)應(yīng)異常機(jī)制，或者該函數(shù)調(diào)用鏈中函數(shù)中存在捕捉對(duì)應(yīng)異常機(jī)制，那么該異常能夠被捕捉。為了獲取系統(tǒng)故障時(shí)的異常特征，通常采用故障注入的方法，加速系統(tǒng)的失效。在其發(fā)生故障時(shí)系統(tǒng)能夠拋出異常，以及異常詳細(xì)信息；因此，通過(guò)分析源代碼，獲取源代碼中的拋出異常類型、異常描述信息、誘發(fā)異常的操作的對(duì)應(yīng)關(guān)系，從而建立異常特征元組FF。獲取系統(tǒng)異常特征信息的步驟：

Step1：獲取故障模式庫(kù)中某條故障模式j(luò)對(duì)應(yīng)功能的入口函數(shù)[fin]。

Step2：獲取入口函數(shù)[fin]調(diào)用的函數(shù)序列為[{fin，...，fi，...，fn}i∈N]。

Step3：獲取每個(gè)函數(shù)中的拋出的異常以及拋出異常的原因描述

[fein={FF1，...，F(xiàn)Fi，...，F(xiàn)Fn}i∈N]

Step4：那么一個(gè)故障模式對(duì)應(yīng)的異常特征集為[FMin={fein，...，fei，...，fen}i∈N]。

2 實(shí)驗(yàn)分析

通過(guò)代碼分析我們得出的結(jié)論為在OpenStack中，系統(tǒng)異常能夠被捕獲，那么被捕獲的異常以及異常描述信息能夠通過(guò)日志模塊，寫(xiě)入到日中。為了驗(yàn)證基于異常提取異常特征的方法，能夠覆蓋所有由異常引發(fā)的故障。利用UnderStand代碼分析工具提供的接口，分析OpenStack代碼中是否所有的拋出的異常都能夠被捕捉。

對(duì)于OpenStack而言，拋出異常的代碼是以Raise開(kāi)頭，捕獲異常的代碼以except進(jìn)行異常捕獲。首先獲取源代碼中能夠拋出異常點(diǎn)[Elocal=]，[Ec]表示拋出異常類型，[Ei]表示拋出異常所在的函數(shù)位置，異常點(diǎn)組成的結(jié)合[Eraise]；然后獲取源代碼中所有except代碼塊所能捕獲到的異常點(diǎn)的集合[Eexcept]；獲取系統(tǒng)中沒(méi)能捕捉到的異常集合[Eno_exception=Eraise-Eexcept]，獲得的實(shí)驗(yàn)室數(shù)據(jù)如表1。對(duì)于異常處理結(jié)構(gòu)性好的代碼，幾乎拋出的所有異常都能夠被捕捉，從實(shí)驗(yàn)數(shù)據(jù)看OpenStack的異常處理幾乎都能被捕捉。

表1 OpenStack代碼異常捕捉率

[模塊名稱＼&[Eraise]數(shù)量＼&[Eexcept]數(shù)量＼&捕獲率＼&Nova＼&3165＼&2967＼&93.74%＼&Glance＼&765＼&757＼&98.9%＼&Cinder＼&1615＼&1615＼&100%＼&Keystone＼&817＼&817＼&100%＼&neutron＼&1404＼&1404＼&100%＼&]

由異常提取的異常特征信息的驗(yàn)證，采用故障注入的方法，抽取各個(gè)模塊故障模式庫(kù)中的故障模式，注入該故障模式所表示的故障，收集日志中的錯(cuò)誤信息，查看錯(cuò)誤信息是否對(duì)應(yīng)該故障的異常特征。通常的日志字段都包括日志的時(shí)間、日志等級(jí)、日志信息的具體描述；系統(tǒng)故障信息通常能夠在ERROR等級(jí)的日志中找到。

圖2 OpenStack函數(shù)中run_instance的一個(gè)異常點(diǎn)

以上為run_instance中的一段代碼，該段代碼中的異常類型BuildAbortException，在該代碼中對(duì)應(yīng)的異常類型具體描述為變量msg對(duì)于的值。對(duì)于異常函數(shù)BuildAbortException（）或者異常函數(shù)BuildAbortException（msg）獲取函數(shù)中的參數(shù)作為異常的具體描述信息。據(jù)此從代碼獲取的錯(cuò)誤行為特征為：

對(duì)于該異常點(diǎn)而言，注入故障收集到的日志信息如圖3所示：

圖3 向系統(tǒng)中注入故障后的日志信息

從日志中獲取的異常特征為，其結(jié)果與代碼分析結(jié)果一致。系統(tǒng)故障診斷結(jié)果分析，以O(shè)penStack創(chuàng)建虛擬機(jī)為入口函數(shù)，通過(guò)分析源代碼，得到該入口函數(shù)調(diào)用鏈上的異常拋出點(diǎn)的個(gè)數(shù)為83個(gè)（其覆蓋的功能模塊主要為nova和keystone模塊）。通過(guò)故障注入實(shí)驗(yàn)，獲取錯(cuò)誤的日志信息，從日志信息中提取出相應(yīng)的異常特征元組，與通過(guò)代碼分析獲取的特征元組一致。

3 結(jié)束語(yǔ)

程序錯(cuò)誤行為的分析可以指導(dǎo)軟件開(kāi)發(fā)人員如何準(zhǔn)確地處理軟件中可能發(fā)生的錯(cuò)誤，輔助可靠性研究人員在軟件差錯(cuò)注入過(guò)程中合理地生成差錯(cuò)集合。本文提出了一種基于異常代碼結(jié)構(gòu)的異常特征提取方法，對(duì)于開(kāi)源的系統(tǒng)而言，可以通過(guò)分析源代碼的方法提取系統(tǒng)的異常特征，減少提取故障模式的執(zhí)行難度。

參考文獻(xiàn)：

[1] Mell P， Grance T. The NIST Definition of Cloud Computing， NIST Special Publication 800-145， 2011.

[2] Jhawar R， Piuri V. Fault tolerance management in IaaS clouds[C]//Satellite Telecommunications （ESTEL）， 2012 IEEE First AESS European Conference on. IEEE， 2012： 1-6.

[3] 單錦輝， 徐克俊， 王戟. 一種軟件故障診斷過(guò)程框架[J]. 計(jì)算機(jī)學(xué)報(bào)， 2011， 34（2）： 372-373.

[4] Nguyen H， Shen Z， Tan Y. Fchain： Toward black-box online fault localization for cloud systems[C] //Proc IEEE 33rd International Conference on Distributed Computing Systems， 2013： 21-30.

[5]S harma B， Jayachandran P， Verma A. Cloudpd： Problem determination and diagnosis in shared dynamic clouds[C]//Proc 43rd IEEE/IFIP International Conference on Dependable Systems and Networks， 2013： 1-12.

[6] Jia Z， Chen R， Xing X. SFDCloud： top-k service faults diagnosis in cloud computing[J]. Automated Software Engineering， 2014， 21（4）： 461-488.

[7] Mi H， Wang H， Yin G. Performance problems diagnosis in cloud computing systems by mining request trace logs[C]//Proc IEEE Network Operations and Management Symposium.