羅理機(jī),唐 華,周 昕,張 濤

(湖北工業(yè)大學(xué) 信息技術(shù)中心,武漢 430068)

隨著云計算技術(shù)的發(fā)展與市場規(guī)模的擴(kuò)大,越來越多的企業(yè)建立了云平臺為應(yīng)用程序提供統(tǒng)一的資源池和通用的平臺組件服務(wù). 由于云平臺組件的通用性,極大地便利了應(yīng)用程序的規(guī)模部署[1].

對于應(yīng)用程序開發(fā)者和云平臺運(yùn)維人員而言,最為關(guān)注的是應(yīng)用程序與云平臺的兼容性,他們希望實(shí)時檢測應(yīng)用程序的運(yùn)行情況并及時發(fā)現(xiàn)異常和定位原因,以便于進(jìn)行針對性的調(diào)整[2]. 因此,收集云平臺上應(yīng)用程序的運(yùn)行數(shù)據(jù)和分析異常原因的能力變得尤為重要.

云平臺的架構(gòu)包含3 個基本層次: 基礎(chǔ)設(shè)施層(infrastructure layer)、平臺層(platform layer)和應(yīng)用層(application layer)[3]. 基礎(chǔ)設(shè)施層是最底層,提供標(biāo)準(zhǔn)化的硬件資源池服務(wù). 中間的平臺層為應(yīng)用程序的開發(fā)、測試、部署和運(yùn)行提供相關(guān)的中間件和基礎(chǔ)服務(wù).應(yīng)用層是最高層,提供種類繁多的應(yīng)用程序集合. 云平臺為了給用戶提供通用便捷的組件服務(wù),相比于傳統(tǒng)的服務(wù)器架構(gòu)來說底層更為封閉,并且多層架構(gòu)的云平臺也成為了主流,以上兩點(diǎn)因素都增加了對其中應(yīng)用程序運(yùn)行數(shù)據(jù)的收集和分析的難度[4]. 目前,云平臺上的應(yīng)用程序監(jiān)控主要面臨以下問題: (1)應(yīng)用程序權(quán)限限制. 大多數(shù)云平臺自身不具備應(yīng)用程序級別的性能監(jiān)控能力,主要依賴于應(yīng)用程序自身的檢測異常機(jī)制和第三方檢測軟件的支持. 因此,云平臺運(yùn)維人員必須賦予應(yīng)用程序足夠的權(quán)限,這大幅度增加了云平臺的運(yùn)維成本和安全風(fēng)險[5]. (2)全流程收集分析異常能力不足. 云平臺的組件服務(wù)對調(diào)用它的應(yīng)用程序是不透明的,這使得應(yīng)用程序很難識別造成異常的根本原因. 并且,隨著大型企業(yè)云的層次結(jié)構(gòu)變得愈發(fā)復(fù)雜[6],每一層中多種交互組件服務(wù)的存在加大了準(zhǔn)確判斷性能異常原因的難度[7]. 提高快速準(zhǔn)確查明異常原因的能力,需要在云平臺的不同層進(jìn)行收集和關(guān)聯(lián)異常信息,建立全流程收集分析異常的能力. (3)監(jiān)控程序自定義能力不足. 目前,一些大型的云平臺已經(jīng)具備對在其中運(yùn)行的應(yīng)用程序進(jìn)行監(jiān)控的能力,但這些方法大多是對應(yīng)用程序的進(jìn)程狀態(tài)信息做簡單分析,并傳送給云平臺運(yùn)維人員做人工巡檢. 然而,為滿足不同應(yīng)用程序的監(jiān)控需求,需要對監(jiān)控系統(tǒng)的信息采集速率、采樣數(shù)據(jù)量和性能異常閾值等指標(biāo)進(jìn)行自定義設(shè)置,而不能僅僅依賴于操作系統(tǒng)進(jìn)程表中的數(shù)據(jù). 對云平臺用戶和運(yùn)維來說,提供對應(yīng)用程序多樣化的監(jiān)控需求是十分迫切的,建立適配性強(qiáng)的云平臺應(yīng)用程序性能監(jiān)控系統(tǒng)已經(jīng)成為一項(xiàng)重要的研究課題[8].

為了解決以上問題,本文設(shè)計了一種針對云平臺應(yīng)用程序的性能監(jiān)控系統(tǒng),可以跨層收集應(yīng)用程序的運(yùn)行時數(shù)據(jù),快速準(zhǔn)確的識別導(dǎo)致應(yīng)用程序異常的云服務(wù)組件. 系統(tǒng)的主要特性有: (1)具有完備的云平臺應(yīng)用程序監(jiān)控運(yùn)維能力. 能夠全層次收集并分析云平臺上應(yīng)用程序的運(yùn)行數(shù)據(jù),并利用平臺即服務(wù)(platform as a service,PaaS)提供的管理服務(wù)接口(management service interface,MSI)實(shí)現(xiàn)自動運(yùn)維. (2)具有快速準(zhǔn)確的異常檢測能力. 通過對平臺服務(wù)調(diào)用的持續(xù)時間分析,識別異常調(diào)用事件,為不同應(yīng)用程序設(shè)置自定義的異常事件指標(biāo)值,保證了異常檢測的準(zhǔn)確性. (3)提供云平臺組件層面的瓶頸識別功能. 通過對應(yīng)用程序調(diào)用組件的時間值進(jìn)行異常偏離判斷,系統(tǒng)能夠識別引發(fā)瓶頸的云平臺服務(wù)組件. 綜上所述,本文構(gòu)建了一個在私有云平臺中基于服務(wù)組件的應(yīng)用程序異常檢測和瓶頸識別系統(tǒng),適用于多層架構(gòu)云平臺上的應(yīng)用程序監(jiān)控分析. 提供該能力有助于增強(qiáng)云平臺運(yùn)維人員對平臺資源的管控能力,降低應(yīng)用程序開發(fā)人員對程序代碼檢測的壓力,進(jìn)一步推動了云平臺資源使用的合理化.

1 相關(guān)研究

現(xiàn)有關(guān)于云平臺系統(tǒng)資源或應(yīng)用程序運(yùn)行性能監(jiān)控與分析的研究,主要途徑是通過在不連續(xù)的時間間隔內(nèi)收集重要的性能指標(biāo)數(shù)據(jù),并進(jìn)行分類、聚類、統(tǒng)計等異常檢測分析. 在此基礎(chǔ)上建立的異常監(jiān)控分析系統(tǒng)框架,一定程度上保證了云平臺的性能、可靠性和服務(wù)質(zhì)量.

文獻(xiàn)[9]中提出了一種稱為云平臺自動異常檢測(autonomic anomaly detection,AAD)的系統(tǒng)框架,通過特征提取和數(shù)據(jù)變換整理性能指標(biāo)數(shù)據(jù),并對異常事件進(jìn)行聚類分析,實(shí)現(xiàn)了異常事件的自動監(jiān)控與分析.在此基礎(chǔ)上,文獻(xiàn)[10]引入互信息(mutual information,MI)參數(shù)來降低不同性能指標(biāo)之間的冗余,使性能指標(biāo)數(shù)據(jù)的特征提取更為精確. 然后采用主成分分析法(principal component analysis,PCA)對提取的數(shù)據(jù)降維,最后采用決策樹分析性能指標(biāo)從而識別異常事件. 饒翔等[11,12]提取云平臺的日志信息構(gòu)造故障特征模型,關(guān)聯(lián)時間窗口內(nèi)外的異常事件,并采用改進(jìn)的決策樹訓(xùn)練基于日志信息的故障分類器,實(shí)現(xiàn)了前后異常事件的關(guān)系判斷. 但是,該模型只針對的是系統(tǒng)的日志信息,要求云平臺對日志進(jìn)行分類并使用標(biāo)準(zhǔn)語義記錄,故障分類器需要大量的日志信息進(jìn)行分析,所需的時間成本和存儲空間較大. 賈統(tǒng)等[13]提出通過提取日志模板變量,構(gòu)建日志異常檢測模型,然后使用機(jī)器學(xué)習(xí)、聚類等方法識別異常數(shù)據(jù),并對異常事件預(yù)警.

然而,以上方法均利用獲取云平臺底層運(yùn)行數(shù)據(jù)(例如虛擬機(jī)日志信息)或檢測應(yīng)用程序代碼來實(shí)現(xiàn)對云平臺資源的監(jiān)控與分析,雖取得了較多成果,但已難以適應(yīng)當(dāng)前部署應(yīng)用程序數(shù)量劇增和底層愈加封閉的主流大型云平臺(例如PaaS)的要求.

現(xiàn)有的云服務(wù)提供商提供的資源監(jiān)測服務(wù)(例如亞馬遜云CloudWatch[14],阿里云CloudMonitor[15]以及華為云監(jiān)控服務(wù)[16]等)通過在云平臺底層添加數(shù)據(jù)采集器,監(jiān)控底層云資源,然后在開發(fā)測試環(huán)境中執(zhí)行并檢測應(yīng)用程序代碼,實(shí)現(xiàn)了對云資源和應(yīng)用程序的有效監(jiān)控. 但是,開發(fā)測試環(huán)境中的檢測結(jié)果并不一定總是能適用于實(shí)際的生產(chǎn)環(huán)境,并且云平臺的底層數(shù)據(jù)隱藏在對外提供的托管服務(wù)層之下,接口不對外開放[17,18],適用范圍有限.

在以上研究基礎(chǔ)上,本文設(shè)計了一種基于云平臺服務(wù)組件的應(yīng)用程序異常檢測和瓶頸識別系統(tǒng). 通過跨層關(guān)聯(lián)和分析服務(wù)調(diào)用請求數(shù)據(jù),識別導(dǎo)致應(yīng)用程序異常的云服務(wù)組件,實(shí)時準(zhǔn)確地判斷異常原因.

2 云平臺異常檢測和瓶頸識別系統(tǒng)模塊設(shè)計

系統(tǒng)設(shè)計的主體思想是利用對應(yīng)用程序調(diào)用云平臺組件響應(yīng)時間的實(shí)時監(jiān)控,為云平臺的運(yùn)行維護(hù)人員提供一個集成應(yīng)用程序性能檢測、平臺組件異常檢測和異常問題定位功能的云平臺監(jiān)控分析整體解決方案. 系統(tǒng)通過嵌入云平臺的內(nèi)置服務(wù)收集應(yīng)用程序與云平臺的組件交互數(shù)據(jù),并且對數(shù)據(jù)進(jìn)行儲存和分析.獲得的分析結(jié)果根據(jù)不同需求分別反饋給云平臺管理員和程序開發(fā)人員. 系統(tǒng)通過監(jiān)控云平臺組件的響應(yīng)時間,對云平臺的整體性能進(jìn)行分析,并且對單個應(yīng)用程序的異常響應(yīng)情況做出即時反應(yīng),避免了傳統(tǒng)云平臺監(jiān)控系統(tǒng)利用應(yīng)用程序監(jiān)聽器對應(yīng)用程序進(jìn)行監(jiān)控的弊端[19]. 同時,對不同類型云組件響應(yīng)時間的分析可以快速、準(zhǔn)確地定位產(chǎn)生異常問題的原因.

云平臺監(jiān)控分析系統(tǒng)以應(yīng)用程序調(diào)用服務(wù)組件的響應(yīng)時間為指標(biāo)識別和描述應(yīng)用程序的異常響應(yīng),并以此為基礎(chǔ)搭建整體功能框架. 首先,設(shè)計一種自動識別異常響應(yīng)的檢測器,以建立應(yīng)用程序異常與監(jiān)控事件分析的觸發(fā)機(jī)制; 然后,提出了應(yīng)用程序工作負(fù)載變化監(jiān)控方法,以識別應(yīng)用程序異常響應(yīng)是由于工作負(fù)載變化還是云平臺組件瓶頸引發(fā); 最后,對于非應(yīng)用程序工作負(fù)載變化引發(fā)的異常響應(yīng),提供了云平臺組件瓶頸識別功能.

2.1 系統(tǒng)框架

圖1 給出了私有云環(huán)境下云平臺監(jiān)控分析系統(tǒng)的整體架構(gòu),分為數(shù)據(jù)收集、異常檢測和異常分析3 個模塊. 數(shù)據(jù)收集模塊用標(biāo)識符對相關(guān)聯(lián)的用戶請求進(jìn)行標(biāo)記,并負(fù)責(zé)在云平臺的每一層上收集有關(guān)應(yīng)用程序調(diào)用的信息; 異常檢測模塊把收集到的模塊存入數(shù)據(jù)庫中,進(jìn)行數(shù)據(jù)分析判斷是否需要啟動異常分析; 異常分析模塊負(fù)責(zé)分析異常事件發(fā)生的原因并識別造成性能瓶頸異常的原因. 本節(jié)余下的部分將對云平臺監(jiān)控分析系統(tǒng)架構(gòu)中的每一模塊的功能進(jìn)行詳細(xì)說明.

圖1 云平臺監(jiān)控分析系統(tǒng)架構(gòu)

2.2 前端數(shù)據(jù)收集模塊

云平臺的多層架構(gòu)使用戶能夠以按需、易擴(kuò)展的方式獲得所需的資源,同時也提高了云平臺的安全性.在云平臺的每一層只能收集與其本層狀態(tài)變化相關(guān)的數(shù)據(jù),且層次之間的封裝結(jié)構(gòu)使其中一層無法監(jiān)測到其他層的狀態(tài)更改. 因?yàn)閼?yīng)用程序調(diào)用組件的行為跨越云平臺的多個層次,所以為了對云平臺的系統(tǒng)資源進(jìn)行整體監(jiān)控,系統(tǒng)必須從每個層次收集數(shù)據(jù),并把與同一調(diào)用行為相關(guān)聯(lián)的數(shù)據(jù)進(jìn)行跨層組合.

為了解決這個問題,云平臺監(jiān)控分析系統(tǒng)在前端設(shè)置了數(shù)據(jù)收集模塊. 數(shù)據(jù)收集模塊通過在服務(wù)接口的入口攔截內(nèi)核調(diào)用來收集應(yīng)用程序的組件調(diào)用請求數(shù)據(jù). 具體的做法是首先在每一個HTTP 請求的消息頭中添加唯一的數(shù)據(jù)標(biāo)識符,使云平臺的每一層都能夠識別請求的關(guān)聯(lián)對象. 然后,把數(shù)據(jù)收集工具部署到平臺內(nèi),抓取組件調(diào)用請求并根據(jù)消息頭中的數(shù)據(jù)標(biāo)識符關(guān)聯(lián)與之相關(guān)的應(yīng)用程序和平臺組件. 最后,數(shù)據(jù)收集模塊組合調(diào)用請求并記錄與之相關(guān)的資源變化信息,再根據(jù)需要對不同的信息分類保存. 組合后的信息記錄使系統(tǒng)能夠跨層監(jiān)控應(yīng)用程序?qū)ζ脚_組件的請求調(diào)用,以及與之相關(guān)聯(lián)的資源變化信息,而不需要考慮云平臺各層之間的耦合關(guān)系. 同時,不同調(diào)用請求對應(yīng)的數(shù)據(jù)收集工具相對獨(dú)立,互相之間無須發(fā)送關(guān)聯(lián)消息,因此也提高了模塊的擴(kuò)展性.

2.3 異常檢測模塊

系統(tǒng)收集到組合信息之后,以應(yīng)用程序ID、時間為索引將其存入數(shù)據(jù)庫中,便于長期存儲和查詢. 異常檢測模塊讀取這些數(shù)據(jù)并進(jìn)行定時分析. 模塊對每個應(yīng)用程序配置定制化的異常檢測方法,不同應(yīng)用程序可以對應(yīng)不同的檢測方法. 不同種類應(yīng)用程序調(diào)用的平臺組件服務(wù)類型、頻率不同,因此其所適配的異常檢測方法也不同. 為了解決應(yīng)用程序和對應(yīng)檢測方法的適配問題,模塊還支持對同一應(yīng)用程序進(jìn)行并發(fā)檢測,從而比較不同檢測方法的準(zhǔn)確性,找出與應(yīng)用程序匹配度最高的檢測方法進(jìn)行配置.

傳統(tǒng)方式監(jiān)控云平臺性能往往是直接在云平臺基礎(chǔ)設(shè)施層部署采集插件,通過分析系統(tǒng)吞吐量、儲存設(shè)備讀寫速度、CPU 時鐘頻率等指標(biāo)達(dá)到監(jiān)控云主機(jī)性能的目的[11–13],但這種方式已不能適用于目前主流的封閉底層資源監(jiān)控接口的大型云平臺. 異常檢測模塊通過調(diào)用平臺層提供的服務(wù)響應(yīng)接口分析云平臺對應(yīng)用請求的回應(yīng)速度,來衡量云平臺對請求的響應(yīng)快慢,系統(tǒng)無須獲取云平臺底層的資源監(jiān)控權(quán)限即可達(dá)到監(jiān)控云平臺性能的目的,提高了系統(tǒng)的通用性和安全性. 具體做法是當(dāng)應(yīng)用程序啟動時,異常檢測模塊同時啟動檢測過程,該過程定期測量目標(biāo)應(yīng)用程序的響應(yīng)時間Tresp和性能異常偏離率Ppad兩個指標(biāo).

應(yīng)用程序的響應(yīng)時間用來衡量程序的性能,響應(yīng)時間越長,性能越低,可以用以下公式表示:

其中,tri和tsi分別為第i個組件調(diào)用的服務(wù)回應(yīng)時間和觸發(fā)時間,n為統(tǒng)計持續(xù)時間內(nèi)檢測到的組件調(diào)用總個數(shù).

為了衡量云組件服務(wù)對調(diào)用的響應(yīng)快慢,我們還定義了性能異常偏離率指標(biāo),用來反映應(yīng)用程序響應(yīng)時間落在正常范圍以外的概率. 當(dāng)?shù)趇個組件調(diào)用的響應(yīng)時間高于應(yīng)用程序響應(yīng)時間Tresp與統(tǒng)計持續(xù)時間內(nèi)組件調(diào)用響應(yīng)時間的標(biāo)準(zhǔn)差σresp之和時,組件調(diào)用響應(yīng)時間被判定為偏離正常范圍. 因此,性能異常偏離率Ppad可通過統(tǒng)計持續(xù)時間內(nèi)偏離正常范圍的組件調(diào)用數(shù)目Ndev和組件調(diào)用的總數(shù)Ntotal比例計算得到:

當(dāng)Ppad大于5%時,表示在統(tǒng)計持續(xù)時間內(nèi)有5%以上的組件調(diào)用響應(yīng)時間偏離了正常范圍,則此時異常檢測模塊認(rèn)為應(yīng)用程序性能發(fā)生異常.

為減少對應(yīng)用程序的性能損耗,異常檢測模塊間隔啟動對響應(yīng)時間Tresp和性能異常偏離率Ppad兩項(xiàng)指標(biāo)的計算和分析,當(dāng)Ppad偏離正常范圍時,就觸發(fā)異常事件.

異常檢測模塊也能夠?qū)?yīng)用程序匹配的檢測方法進(jìn)行分析間隔時間和統(tǒng)計持續(xù)時間兩個參數(shù)的配置,其中分析間隔時間即為檢測方法定時啟動分析的間隔時間,這個參數(shù)在系統(tǒng)測試中被設(shè)置為15 s. 統(tǒng)計持續(xù)時間指檢測方法提取和統(tǒng)計異常事件發(fā)生的時間跨度,通常時間跨度越長則內(nèi)存中存放的數(shù)據(jù)量越大,為限制系統(tǒng)運(yùn)行時占用的內(nèi)存大小,統(tǒng)計持續(xù)時間參數(shù)在系統(tǒng)測試中被設(shè)置為30 min.

2.4 異常分析模塊

異常分析模塊對異常檢測模塊發(fā)出的異常事件進(jìn)行分析,首先分析異常事件的發(fā)生原因,如果是由工作負(fù)載大小變化引起,則不做處理,如果是則進(jìn)行瓶頸識別.

系統(tǒng)使用變點(diǎn)檢測算法(change point detection,CPD)[20]對工作負(fù)載的變化進(jìn)行檢測,算法生成一個負(fù)載變化的變點(diǎn)列表來表示一段時間內(nèi)工作負(fù)載的重大變化. 系統(tǒng)利用CPD 對負(fù)載變化點(diǎn)的歷史數(shù)據(jù)批量分析,實(shí)現(xiàn)對平臺負(fù)載變化的持久跟蹤,能夠準(zhǔn)確識別平穩(wěn)的大數(shù)據(jù)量請求(非峰值請求)造成服務(wù)器性能異常的情況.

對于因非工作負(fù)載變化而引起的性能異常,系統(tǒng)對其進(jìn)行瓶頸識別,找出與之關(guān)聯(lián)最大的平臺組件. 系統(tǒng)首先記錄每一次樣本程序調(diào)用平臺組件的時間長度組成數(shù)組C[n] (n為調(diào)用平臺組件次數(shù)),然后使用離群值統(tǒng)計法[21]判斷捕獲的數(shù)據(jù)是否異常,此方法適用于在定時采集時間樣本的數(shù)據(jù)量范圍內(nèi)對樣本的偏離情況進(jìn)行測算,計算出樣本的偏離值. 系統(tǒng)選擇與偏離值最大的時間樣本相關(guān)聯(lián)的組件作為瓶頸識別的結(jié)果,此組件即為引發(fā)瓶頸的云平臺服務(wù)組件.

3 云平臺應(yīng)用程序監(jiān)控分析系統(tǒng)測試

系統(tǒng)測試在OpenStack 私有云環(huán)境下進(jìn)行,操作系統(tǒng)版本為CentOS 7.4,測試節(jié)點(diǎn)配置為8 核CPU (時鐘頻率2.6 GHz),16 GB 內(nèi)存,200 GB 硬盤.

本次測試使用的樣本應(yīng)用程序是一個利用PHP 編寫的Web 應(yīng)用程序,功能是實(shí)現(xiàn)單點(diǎn)登錄并發(fā)布圖文信息. 程序調(diào)用統(tǒng)一身份認(rèn)證(CAS)組件來實(shí)現(xiàn)身份驗(yàn)證,并調(diào)用云平臺的數(shù)據(jù)存儲組件來保存發(fā)布的信息. 用戶的每次發(fā)布請求都會調(diào)用兩次云平臺服務(wù)組件,一次用于檢查用戶的登錄狀態(tài),另一次用于在數(shù)據(jù)庫相應(yīng)表中寫入數(shù)據(jù).

為了全面評測云平臺應(yīng)用程序監(jiān)控分析系統(tǒng)各個模塊的功能,依次測試了系統(tǒng)檢測云平臺異常事件的能力、分析服務(wù)器負(fù)載變化的能力以及識別性能瓶頸原因的能力.

3.1 異常事件檢測

在測試系統(tǒng)的異常事件檢測能力之前,需要先確定樣本程序正常運(yùn)行時的響應(yīng)時間. 因此,樣本程序首先在無任何外部程序干擾的情況下運(yùn)行了10 次,每次持續(xù)1 h,得到正常情況下樣本程序響應(yīng)時間的平均值tavg和標(biāo)準(zhǔn)差 σt. 響應(yīng)時間的閾值tmax由以下公式獲得:

利用操作系統(tǒng)的Page Cache 策略,寫入8 線程單次4 KB 的Buffer,可以模擬云平臺數(shù)據(jù)存儲組件響應(yīng)緩慢造成的性能異常. 設(shè)置此性能異常事件30 分鐘觸發(fā)一次,并在5 s 時間內(nèi)調(diào)用平臺的數(shù)據(jù)存儲組件使響應(yīng)時間升高到tmax以上,響應(yīng)時間超過tmax則視為發(fā)生一次異常事件.

為驗(yàn)證第2.3 節(jié)所述系統(tǒng)異常檢測模塊的性能,將分析間隔時間設(shè)置為15 s,統(tǒng)計持續(xù)時間為30 min,樣本程序的運(yùn)行時間一共為5 h. 觸發(fā)性能異常事件與系統(tǒng)檢測到異常事件的時間點(diǎn)如表1 所示.

表1 觸發(fā)和檢測到異常的間隔時間統(tǒng)計

綜合實(shí)驗(yàn)結(jié)果,從性能異常事件發(fā)生開始到系統(tǒng)檢測到異常事件,平均用時268 s,最長的時間間隔為299 s. 由于檢測用時與分析間隔時間密切相關(guān),因此可以通過修改檢測工具的分析間隔時間進(jìn)一步對檢測性能進(jìn)行調(diào)優(yōu).

3.2 分析負(fù)載變化

在對系統(tǒng)的分析負(fù)載變化能力進(jìn)行測試的過程中,樣本程序同樣運(yùn)行5 個小時. 程序運(yùn)行期間,更改高頻讀取請求的間隔時間為隨機(jī),以達(dá)到模擬平臺負(fù)載變化的目的. 在隨機(jī)高頻讀取請求發(fā)生期間,請求的頻率在每分鐘450–650 次之間,這遠(yuǎn)高于平臺正常運(yùn)行情況下每分鐘120–150 次的請求頻率,這些讀取請求大部分都無法命中數(shù)據(jù)庫緩沖區(qū),因此會引發(fā)平臺服務(wù)器緩存負(fù)載的急劇上升.

如圖2 所示,每個負(fù)載高峰發(fā)生之后,系統(tǒng)幾乎都能準(zhǔn)確的檢測到異常事件發(fā)生,縱向箭頭指示檢測到異常事件發(fā)生并觸發(fā)瓶頸識別模塊的時刻. 唯一一次例外是發(fā)生在兩次高頻請求短時間內(nèi)集聚發(fā)生,這是由于系統(tǒng)在檢測到第一次異常事件之后對數(shù)據(jù)進(jìn)行回收處理,進(jìn)入等待狀態(tài)以收集更多數(shù)據(jù). 在緊接著另一次發(fā)生負(fù)載高峰情況時,系統(tǒng)認(rèn)為異常事件的發(fā)生是由于工作負(fù)載變化引起的,因此沒有第二次觸發(fā)瓶頸識別模塊工作.

圖2 服務(wù)器負(fù)載與異常檢測能力測試

3.3 性能瓶頸原因識別

在第3.2 節(jié)的實(shí)驗(yàn)中,系統(tǒng)分析所有檢測到的異常都是由云平臺數(shù)據(jù)存儲組件響應(yīng)超時引起的. 實(shí)驗(yàn)結(jié)果符合實(shí)際情況,因?yàn)閷?shí)驗(yàn)中的每一次異常事件都是由大數(shù)據(jù)量的Buffer 寫入造成數(shù)據(jù)存儲組件無法及時響應(yīng).

為了測試系統(tǒng)對其他原因引起性能瓶頸的識別能力,接下來本實(shí)驗(yàn)修改用戶驗(yàn)證組件的邏輯,使應(yīng)用程序向用戶驗(yàn)證組件發(fā)送請求時,組件延遲返回消息,延遲時間大于tmax時,則產(chǎn)生異常事件. 在實(shí)驗(yàn)中設(shè)置每30 min 觸發(fā)一次驗(yàn)證異常,實(shí)驗(yàn)共持續(xù)5 h.

如圖3 所示,系統(tǒng)在每一次的邏輯異常發(fā)生之后都檢測到了性能異常事件,其中7 次異常被系統(tǒng)識別為用戶驗(yàn)證組件超時引發(fā)的異常,另外還有兩次異常被識別為由數(shù)據(jù)儲存組件超時引發(fā). 通過手動檢查云平臺系統(tǒng)日志發(fā)現(xiàn),例外的兩次異常都是由于數(shù)據(jù)庫查詢超時引起用戶驗(yàn)證組件異常,系統(tǒng)將異常歸結(jié)為第一個出現(xiàn)異常的數(shù)據(jù)儲存組件是準(zhǔn)確的.

圖3 識別異常事件原因能力測試

為了在更大的樣本情況下測試多種異常組合發(fā)生時瓶頸識別的能力,系統(tǒng)在私有云平臺上運(yùn)行了1 個星期. 通過分析這段時間內(nèi)系統(tǒng)檢出的125 個異常,發(fā)現(xiàn)除了7 個異常事件外,大多數(shù)情況下系統(tǒng)都能準(zhǔn)確識別第一個引起異常的平臺組件,平臺的瓶頸識別準(zhǔn)確率達(dá)到了94.4%.

3.4 實(shí)驗(yàn)結(jié)果分析

在異常檢測和瓶頸識別實(shí)驗(yàn)的基礎(chǔ)上,測試云平臺應(yīng)用程序監(jiān)控分析系統(tǒng)的通用性和準(zhǔn)確性. 將系統(tǒng)的瓶頸識別準(zhǔn)確率、是否需要平臺底層監(jiān)控權(quán)限、適用的云平臺類型這3 項(xiàng)指標(biāo)作為考察系統(tǒng)通用性和準(zhǔn)確性的因素,對比算法是ATAD[22],vPerfGuard[23],BAD[24],ANN[25]. 為了更好地說明異常識別的性能,測試時采用了相同的引發(fā)云平臺性能異常機(jī)制. 利用統(tǒng)一身份認(rèn)證(CAS)組件仿真大量的隨機(jī)讀取請求發(fā)送至被測平臺,持續(xù)時間均為1 個星期,結(jié)果如表2 所示,可以看出vPerfGuard 的識別準(zhǔn)確率最高,而AAD-PSC次之,然后是BAD,其余算法的準(zhǔn)確率較低. vPerfGuard的識別準(zhǔn)確率高的原因是直接在云平臺底層獲取硬件資源和工作負(fù)載指標(biāo),避免了性能異常集聚發(fā)生時的誤判,但是vPerfGuard 需要云平臺提供底層的資源監(jiān)控權(quán)限,無法適用于PaaS 類型的云平臺,通用性不及其他方法. BAD 構(gòu)建自適應(yīng)的監(jiān)督學(xué)習(xí)任務(wù),識別準(zhǔn)確率依賴大數(shù)據(jù)集的收集和模型擬合,AAD-PSC 是通過直接監(jiān)測云平臺的服務(wù)性能指標(biāo)判斷云平臺的當(dāng)前性能,所以AAD-PSC 比BAD 的判斷準(zhǔn)確率更高.

表2 觸發(fā)和檢測到異常的間隔時間統(tǒng)計

4 小結(jié)

監(jiān)控和分析云平臺上托管的應(yīng)用程序運(yùn)行情況是云平臺運(yùn)維中的一項(xiàng)核心需求,應(yīng)用程序開發(fā)和云平臺運(yùn)維人員希望能夠具備監(jiān)控云應(yīng)用程序的性能異常,并分析其產(chǎn)生原因的能力. 但隨著云計算技術(shù)的發(fā)展,云平臺的規(guī)模急速擴(kuò)大,多層架構(gòu)日益復(fù)雜,傳統(tǒng)云平臺應(yīng)用程序監(jiān)控系統(tǒng)存在依賴云平臺賦權(quán)、異常溯源不準(zhǔn)確、分析方式單一等問題,已無法滿足現(xiàn)有大規(guī)模云平臺的需求. 本文設(shè)計并實(shí)現(xiàn)了一種面向云平臺應(yīng)用程序的性能監(jiān)控系統(tǒng). 通過標(biāo)識符跨層關(guān)聯(lián)應(yīng)用程序請求與相關(guān)事件,簡化了信息收集過程. 采用了基于變點(diǎn)檢測的瓶頸識別方法,實(shí)現(xiàn)了快速、準(zhǔn)確的異常事件溯源. 實(shí)驗(yàn)結(jié)果表明,監(jiān)控系統(tǒng)可以在異常事件發(fā)生后的5 min 內(nèi)準(zhǔn)確檢測不同類別的異常事件并識別性能瓶頸,能夠滿足云平臺下對應(yīng)用程序運(yùn)行性能的監(jiān)控需求.

增強(qiáng)出版

本文附有基于服務(wù)的云平臺應(yīng)用程序監(jiān)控分析系統(tǒng)演示視頻,可點(diǎn)擊視頻鏈接或手機(jī)掃描二維碼觀看.