基于服務(wù)的云平臺(tái)應(yīng)用程序監(jiān)控分析系統(tǒng)①

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

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

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

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

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

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

1 相關(guān)研究

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

文獻(xiàn)[9]中提出了一種稱為云平臺(tái)自動(dòng)異常檢測(autonomic anomaly detection,AAD)的系統(tǒng)框架,通過特征提取和數(shù)據(jù)變換整理性能指標(biāo)數(shù)據(jù),并對異常事件進(jìn)行聚類分析,實(shí)現(xiàn)了異常事件的自動(dòng)監(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]提取云平臺(tái)的日志信息構(gòu)造故障特征模型,關(guān)聯(lián)時(shí)間窗口內(nèi)外的異常事件,并采用改進(jìn)的決策樹訓(xùn)練基于日志信息的故障分類器,實(shí)現(xiàn)了前后異常事件的關(guān)系判斷. 但是,該模型只針對的是系統(tǒng)的日志信息,要求云平臺(tái)對日志進(jìn)行分類并使用標(biāo)準(zhǔn)語義記錄,故障分類器需要大量的日志信息進(jìn)行分析,所需的時(shí)間成本和存儲(chǔ)空間較大. 賈統(tǒng)等[13]提出通過提取日志模板變量,構(gòu)建日志異常檢測模型,然后使用機(jī)器學(xué)習(xí)、聚類等方法識別異常數(shù)據(jù),并對異常事件預(yù)警.

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

現(xiàn)有的云服務(wù)提供商提供的資源監(jiān)測服務(wù)(例如亞馬遜云CloudWatch[14],阿里云CloudMonitor[15]以及華為云監(jiān)控服務(wù)[16]等)通過在云平臺(tái)底層添加數(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)境,并且云平臺(tái)的底層數(shù)據(jù)隱藏在對外提供的托管服務(wù)層之下,接口不對外開放[17,18],適用范圍有限.

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

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

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

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

2.1 系統(tǒng)框架

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

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

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

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

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

2.3 異常檢測模塊

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

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

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

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

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

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

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

異常檢測模塊也能夠?qū)?yīng)用程序匹配的檢測方法進(jìn)行分析間隔時(shí)間和統(tǒng)計(jì)持續(xù)時(shí)間兩個(gè)參數(shù)的配置,其中分析間隔時(shí)間即為檢測方法定時(shí)啟動(dòng)分析的間隔時(shí)間,這個(gè)參數(shù)在系統(tǒng)測試中被設(shè)置為15 s. 統(tǒng)計(jì)持續(xù)時(shí)間指檢測方法提取和統(tǒng)計(jì)異常事件發(fā)生的時(shí)間跨度,通常時(shí)間跨度越長則內(nèi)存中存放的數(shù)據(jù)量越大,為限制系統(tǒng)運(yùn)行時(shí)占用的內(nèi)存大小,統(tǒng)計(jì)持續(xù)時(shí)間參數(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)行檢測,算法生成一個(gè)負(fù)載變化的變點(diǎn)列表來表示一段時(shí)間內(nèi)工作負(fù)載的重大變化. 系統(tǒng)利用CPD 對負(fù)載變化點(diǎn)的歷史數(shù)據(jù)批量分析,實(shí)現(xiàn)對平臺(tái)負(fù)載變化的持久跟蹤,能夠準(zhǔn)確識別平穩(wěn)的大數(shù)據(jù)量請求(非峰值請求)造成服務(wù)器性能異常的情況.

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

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

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

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

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

3.1 異常事件檢測

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

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

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

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

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

3.2 分析負(fù)載變化

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

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

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

3.3 性能瓶頸原因識別

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

為了測試系統(tǒng)對其他原因引起性能瓶頸的識別能力,接下來本實(shí)驗(yàn)修改用戶驗(yàn)證組件的邏輯,使應(yīng)用程序向用戶驗(yàn)證組件發(fā)送請求時(shí),組件延遲返回消息,延遲時(shí)間大于tmax時(shí),則產(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)證組件超時(shí)引發(fā)的異常,另外還有兩次異常被識別為由數(shù)據(jù)儲(chǔ)存組件超時(shí)引發(fā). 通過手動(dòng)檢查云平臺(tái)系統(tǒng)日志發(fā)現(xiàn),例外的兩次異常都是由于數(shù)據(jù)庫查詢超時(shí)引起用戶驗(yàn)證組件異常,系統(tǒng)將異常歸結(jié)為第一個(gè)出現(xiàn)異常的數(shù)據(jù)儲(chǔ)存組件是準(zhǔn)確的.

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

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

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

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

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

4 小結(jié)

監(jiān)控和分析云平臺(tái)上托管的應(yīng)用程序運(yùn)行情況是云平臺(tái)運(yùn)維中的一項(xiàng)核心需求,應(yīng)用程序開發(fā)和云平臺(tái)運(yùn)維人員希望能夠具備監(jiān)控云應(yīng)用程序的性能異常,并分析其產(chǎn)生原因的能力. 但隨著云計(jì)算技術(shù)的發(fā)展,云平臺(tái)的規(guī)模急速擴(kuò)大,多層架構(gòu)日益復(fù)雜,傳統(tǒng)云平臺(tái)應(yīng)用程序監(jiān)控系統(tǒng)存在依賴云平臺(tái)賦權(quán)、異常溯源不準(zhǔn)確、分析方式單一等問題,已無法滿足現(xiàn)有大規(guī)模云平臺(tái)的需求. 本文設(shè)計(jì)并實(shí)現(xiàn)了一種面向云平臺(tái)應(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)確檢測不同類別的異常事件并識別性能瓶頸,能夠滿足云平臺(tái)下對應(yīng)用程序運(yùn)行性能的監(jiān)控需求.

增強(qiáng)出版

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