0 引言

國家電網(wǎng)公司信息化建設(shè)在經(jīng)歷了高速發(fā)展階段后,業(yè)務(wù)需求呈井噴式增長(zhǎng),業(yè)務(wù)融合、數(shù)據(jù)共享等高端集成應(yīng)用呈跨越式發(fā)展,信息系統(tǒng)部署模式、運(yùn)行模式日益復(fù)雜^[1-2]。同時(shí),隨著國家電網(wǎng)公司“兩個(gè)轉(zhuǎn)變”的不斷深入,要求業(yè)務(wù)響應(yīng)更快速、服務(wù)更優(yōu)質(zhì),對(duì)信息系統(tǒng)運(yùn)維工作提出了更高的要求^[3-4]。

目前信息系統(tǒng)運(yùn)維工具主要面向基礎(chǔ)架構(gòu)層面,點(diǎn)陣式管理模式又造成運(yùn)維孤島,缺乏端到端的應(yīng)用層監(jiān)控手段^[5]。業(yè)務(wù)系統(tǒng)關(guān)聯(lián)日益復(fù)雜,一旦在應(yīng)用層出現(xiàn)性能下降和不可用問題,即面臨問題現(xiàn)場(chǎng)難以復(fù)現(xiàn),需要效率低下的手工排查,系統(tǒng)管理人員運(yùn)維壓力持續(xù)增長(zhǎng),且無法高效保障信息系統(tǒng)的用戶體驗(yàn)^[6]。

為解決上述問題,運(yùn)維單位將性能監(jiān)測(cè)工具引入信息系統(tǒng)高級(jí)診斷調(diào)優(yōu)工作中^[7-10],針對(duì)信息系統(tǒng)的硬件環(huán)境、操作系統(tǒng)、數(shù)據(jù)庫、應(yīng)用中間件、集成服務(wù)、系統(tǒng)架構(gòu)、典型業(yè)務(wù)等運(yùn)行指標(biāo)進(jìn)行深度診斷,對(duì)直接決定用戶體驗(yàn)的應(yīng)用層級(jí)進(jìn)行代碼級(jí)的深度監(jiān)測(cè)^[11-14],實(shí)現(xiàn)診斷工作的自動(dòng)化,輔助運(yùn)維人員快速定位故障,優(yōu)化系統(tǒng)性能,提高工作效率。

 1 性能監(jiān)測(cè)工具核心原理、關(guān)鍵功能模塊及性能指標(biāo)

1.1 核心原理

性能監(jiān)測(cè)工具在信息系統(tǒng)高級(jí)診斷調(diào)優(yōu)過程中,通過在應(yīng)用服務(wù)器（中間件）中植入Java Agent探針（基于JDK 提供的Instrumentation機(jī)制）,在應(yīng)用代碼類文件被加載時(shí),通過字節(jié)碼技術(shù),動(dòng)態(tài)地對(duì)Framework、數(shù)據(jù)庫、NoSQL、Web Service、組件等實(shí)施監(jiān)控。

用戶在通過終端瀏覽器訪問應(yīng)用頁面時(shí),頁面監(jiān)控模塊即開始頁面用戶體驗(yàn)相關(guān)的性能監(jiān)控。用戶訪問請(qǐng)求進(jìn)入數(shù)據(jù)中心后,由應(yīng)用監(jiān)控模塊對(duì)請(qǐng)求流經(jīng)的Web服務(wù)器、應(yīng)用服務(wù)器、關(guān)系型數(shù)據(jù)庫、非關(guān)系型數(shù)據(jù)庫等組件進(jìn)行代碼級(jí)性能監(jiān)控,從而獲得代碼執(zhí)行效率、數(shù)據(jù)庫調(diào)用效率、應(yīng)用接口調(diào)用效率,構(gòu)建出業(yè)務(wù)層的數(shù)據(jù)流向拓?fù)鋱D,并基于拓?fù)鋵?shí)現(xiàn)代碼級(jí)的信息系統(tǒng)性能和可用性監(jiān)控,實(shí)時(shí)將監(jiān)測(cè)數(shù)據(jù)展現(xiàn)在可視化監(jiān)控模塊上。性能監(jiān)測(cè)工具的實(shí)現(xiàn)機(jī)制如圖1所示。

圖1 性能監(jiān)測(cè)工具的實(shí)現(xiàn)機(jī)制Fig.1 Implementation mechanism diagram of performance monitoring tool

運(yùn)維人員依靠性能監(jiān)測(cè)工具提供的網(wǎng)絡(luò)拓?fù)鋱D,實(shí)現(xiàn)端到端的完整監(jiān)控,快速定位整個(gè)業(yè)務(wù)調(diào)用鏈中存在的問題,及時(shí)解決問題,并結(jié)合業(yè)界標(biāo)準(zhǔn)對(duì)各信息系統(tǒng)性能進(jìn)行持續(xù)的客觀評(píng)價(jià)。

1.2 關(guān)鍵功能模塊

性能監(jiān)測(cè)工具的關(guān)鍵功能模塊主要包括應(yīng)用拓?fù)浞治觥eb應(yīng)用過程分析、數(shù)據(jù)庫性能分析、錯(cuò)誤分析、外部應(yīng)用分析等。

1.2.1 應(yīng)用拓?fù)浞治瞿K

性能監(jiān)測(cè)工具構(gòu)建業(yè)務(wù)層的數(shù)據(jù)流向拓?fù)鋱D,并基于拓?fù)鋵?shí)現(xiàn)代碼級(jí)的業(yè)務(wù)系統(tǒng)性能和可用性監(jiān)控。該模塊不僅可展示應(yīng)用與應(yīng)用、應(yīng)用與服務(wù)之間的調(diào)用關(guān)系,而且可以顯示應(yīng)用與應(yīng)用間的性能數(shù)據(jù)以及當(dāng)前應(yīng)用的語言環(huán)境。將光標(biāo)懸停到該應(yīng)用或被調(diào)用其他應(yīng)用的圖標(biāo)上時(shí),會(huì)彈框顯示相關(guān)的性能數(shù)據(jù),包括調(diào)用服務(wù)數(shù)、吞吐率、響應(yīng)時(shí)間、錯(cuò)誤率等相關(guān)數(shù)據(jù)。

1.2.2 Web應(yīng)用過程分析模塊

在該模塊可查詢所選應(yīng)用下事務(wù)的整體性能和具體事務(wù)的性能。當(dāng)事務(wù)的響應(yīng)時(shí)間大于設(shè)置的閾值時(shí),可以通過慢事務(wù)追蹤列表對(duì)該事務(wù)進(jìn)行詳細(xì)追蹤。通過查看慢事務(wù)追蹤詳情,可獲取該事務(wù)所屬應(yīng)用、慢追蹤發(fā)生的時(shí)間、響應(yīng)時(shí)間、請(qǐng)求URL、線程名稱、請(qǐng)求參數(shù)以及該事務(wù)中的代碼處理耗時(shí)信息。

1.2.3 數(shù)據(jù)庫性能分析模塊

數(shù)據(jù)庫分析模塊包括使用SQL的關(guān)系型數(shù)據(jù)庫分析以及非關(guān)系型數(shù)據(jù)庫NoSQL分析,用來以數(shù)據(jù)庫語句訪問的維度來查看應(yīng)用性能數(shù)據(jù)。運(yùn)維人員可查看各應(yīng)用數(shù)據(jù)庫語句的整體性能,也可查看具體數(shù)據(jù)庫語句的性能。當(dāng)數(shù)據(jù)庫語句的響應(yīng)時(shí)間大于設(shè)置的閾值時(shí),可對(duì)數(shù)據(jù)庫語句進(jìn)行詳細(xì)追蹤。通過查看慢數(shù)據(jù)庫操作詳細(xì)信息,可獲取操作發(fā)生時(shí)間、總耗時(shí)長(zhǎng)、調(diào)用次數(shù)、完整的數(shù)據(jù)庫語句信息及Trace信息。

1.2.4 錯(cuò)誤分析模塊

錯(cuò)誤分析模塊用于分析當(dāng)前應(yīng)用或應(yīng)用實(shí)例中發(fā)生的錯(cuò)誤或異常情況。分析結(jié)果包括錯(cuò)誤類型、錯(cuò)誤率、錯(cuò)誤發(fā)生次數(shù)、Trace信息等。

1.2.5 外部應(yīng)用分析模塊

外部應(yīng)用指應(yīng)用通過HTTP、Thrift、Dubbo或Web Service方式調(diào)用外部應(yīng)用提供的服務(wù),該模塊用于分析應(yīng)用使用外部服務(wù)的相關(guān)性能。

1.3 性能指標(biāo)

性能監(jiān)測(cè)工具各模塊分析結(jié)果以圖表形式展示在性能監(jiān)測(cè)平臺(tái)中,涉及到的主要性能指標(biāo)及含義如下。

1）響應(yīng)時(shí)間：指應(yīng)用系統(tǒng)（包括應(yīng)用服務(wù)器、數(shù)據(jù)庫、事務(wù)、外部應(yīng)用等）從收到請(qǐng)求到返回響應(yīng)的時(shí)間。

2）請(qǐng)求阻塞時(shí)間：請(qǐng)求到達(dá)前端服務(wù)器及應(yīng)用服務(wù)器收到請(qǐng)求的時(shí)間。

3）代碼執(zhí)行時(shí)間：指純粹用于執(zhí)行當(dāng)前函數(shù)代碼的時(shí)間。

4）Apdex：為用戶滿意度指標(biāo),把最終用戶體驗(yàn)和應(yīng)用性能量化為一個(gè)0或1的數(shù)值,反映系統(tǒng)性能和可用性狀況。1表示所有用戶都滿意,0表示沒有滿意的用戶。

5）吞吐率：指單位時(shí)間內(nèi)應(yīng)用、事務(wù)及外部應(yīng)用等模塊收到的請(qǐng)求次數(shù)。

6）錯(cuò)誤率：指應(yīng)用、事務(wù)、數(shù)據(jù)庫及外部應(yīng)用等模塊在某個(gè)統(tǒng)計(jì)周期內(nèi)發(fā)生錯(cuò)誤的次數(shù)與總請(qǐng)求（或調(diào)用/訪問）次數(shù)的比值。

7）墻鐘時(shí)間比：該數(shù)值反映Web應(yīng)用過程的繁忙程度和對(duì)CPU資源的消耗程度,比值越高表示消耗的資源越多。

 2 性能監(jiān)測(cè)工具用于高級(jí)診斷及調(diào)優(yōu)實(shí)例分析

以部署性能監(jiān)測(cè)工具的某信息系統(tǒng)2017年9月的性能監(jiān)測(cè)結(jié)果為實(shí)例進(jìn)行詳細(xì)分析。

圖2為某系統(tǒng)應(yīng)用拓?fù)鋱D,該系統(tǒng)共調(diào)用系統(tǒng)服務(wù)12個(gè),且各服務(wù)調(diào)用響應(yīng)時(shí)間均較少,系統(tǒng)運(yùn)行狀態(tài)良好。若某應(yīng)用響應(yīng)過慢,系統(tǒng)圓形圖標(biāo)會(huì)改變?yōu)橄鄳?yīng)狀態(tài)顏色,方便運(yùn)維人員及時(shí)發(fā)現(xiàn)問題。

圖2 某系統(tǒng)應(yīng)用拓?fù)鋱DFig.2 Application topology of a system

系統(tǒng)Web應(yīng)用過程分析結(jié)果如圖3、圖4所示。圖3展示了系統(tǒng)耗時(shí)排在前5的Web應(yīng)用過程,其中,SpringController/…troller/應(yīng)用過程耗時(shí)最高。圖4顯示當(dāng)月應(yīng)用吞吐率,13日—15日系統(tǒng)被頻繁調(diào)用,平均響應(yīng)時(shí)間較長(zhǎng)。查看該應(yīng)用過程所執(zhí)行代碼,發(fā)現(xiàn)在調(diào)用“SendController.startTask”方法時(shí)耗時(shí)較多,運(yùn)維人員及時(shí)進(jìn)行了調(diào)優(yōu)處理。

圖3 系統(tǒng)最耗時(shí)Web應(yīng)用過程堆疊Fig.3 The stack diagram of most time-consuming Web application process

圖4 系統(tǒng)響應(yīng)時(shí)間和吞吐率Fig.4 Response time and throughput diagram

圖5顯示系統(tǒng)運(yùn)行過程中耗時(shí)排在前5的SQL操作,運(yùn)維人員在查看SQL語句的相關(guān)表及完整SQL語句信息后,對(duì)SQL語句進(jìn)行調(diào)優(yōu)。從圖6可知應(yīng)用數(shù)據(jù)庫各操作的吞吐率。

圖5 最耗時(shí)SQL操作堆疊Fig.5 The most time-consuming SQL operation stack diagram

圖6 數(shù)據(jù)庫吞吐率堆疊Fig.6 Database throughput stack diagram

在錯(cuò)誤分析模塊中,應(yīng)用錯(cuò)誤率如圖7所示,該月系統(tǒng)錯(cuò)誤率較低,均在0.3%以下,系統(tǒng)運(yùn)行狀態(tài)良好。圖8為系統(tǒng)錯(cuò)誤列表,運(yùn)維人員查看具體錯(cuò)誤類型及相關(guān)信息時(shí),可獲取該錯(cuò)誤的Web應(yīng)用過程、調(diào)用堆棧等信息,及時(shí)發(fā)現(xiàn)系統(tǒng)故障,并與研發(fā)人員聯(lián)系,對(duì)代碼做出相應(yīng)優(yōu)化。

圖7 應(yīng)用錯(cuò)誤率Fig.7 Application error rate diagram

圖8 錯(cuò)誤列表Fig.8 Application error rate diagram

外部應(yīng)用分析結(jié)果展示了應(yīng)用系統(tǒng)平均響應(yīng)時(shí)間及吞吐率（見圖9）,若系統(tǒng)某一服務(wù)平均響應(yīng)時(shí)間過高,運(yùn)維人員可查看具體服務(wù)名稱及調(diào)用者耗時(shí)等數(shù)據(jù),進(jìn)而對(duì)其進(jìn)行優(yōu)化。

圖9 平均響應(yīng)時(shí)間Fig.9 Average response time

圖10為該系統(tǒng)9月份的Apdex值曲線圖,平均值達(dá)0.994,系統(tǒng)性能和運(yùn)行狀態(tài)良好。另外,運(yùn)維人員可應(yīng)用此指標(biāo)在監(jiān)測(cè)平臺(tái)設(shè)置警報(bào),當(dāng)Apdex值持續(xù)降低時(shí),系統(tǒng)將自動(dòng)告警,及時(shí)解決問題,提高用戶體驗(yàn)。

圖10 系統(tǒng)9月份的Apdex值曲線Fig.10 The Apdex value curve of the system in September

 3 應(yīng)用效果評(píng)價(jià)及總結(jié)

目前,開展性能監(jiān)測(cè)工具部署試點(diǎn)實(shí)施的28套業(yè)務(wù)系統(tǒng)運(yùn)行正常,性能監(jiān)測(cè)平臺(tái)運(yùn)行穩(wěn)定,性能數(shù)據(jù)抽取準(zhǔn)確及時(shí)。在6個(gè)月的部署實(shí)施期內(nèi),28套系統(tǒng)共部署探針227個(gè),發(fā)現(xiàn)問題144個(gè)。其中,Web應(yīng)用過程問題最多,其次為系統(tǒng)錯(cuò)誤,各問題占比如圖11所示。 針對(duì)性能監(jiān)測(cè)工具發(fā)現(xiàn)的144個(gè)問題,經(jīng)各研發(fā)單位進(jìn)行確認(rèn),將其中77個(gè)問題列入調(diào)優(yōu)計(jì)劃中。其中,某系統(tǒng)應(yīng)用性能監(jiān)測(cè)工具提供的調(diào)優(yōu)建議調(diào)優(yōu)后獲得明顯性能提升,平均響應(yīng)時(shí)間從75 ms降至15 ms。

圖11 系統(tǒng)各問題占比Fig.11 Proportion of problems in the system

在持續(xù)6個(gè)月的監(jiān)測(cè)過程中,平臺(tái)收集的性能數(shù)據(jù)覆蓋了業(yè)務(wù)的高峰期和低谷期。系統(tǒng)在業(yè)務(wù)高峰期時(shí)的性能數(shù)據(jù)更能反映出系統(tǒng)開發(fā)存在的問題,監(jiān)測(cè)結(jié)果充分驗(yàn)證了性能監(jiān)測(cè)工具的兼容性和穩(wěn)定性。在階段性巡檢和消缺工作中,性能監(jiān)測(cè)工具可以為運(yùn)維和開發(fā)單位提供故障和優(yōu)化點(diǎn)的定位分析建議,切實(shí)解決系統(tǒng)性能問題,并形成系統(tǒng)化的使用建議文檔,為后期推廣提供實(shí)踐經(jīng)驗(yàn)支持。

 4 結(jié)語

目前,性能監(jiān)測(cè)工具已在國家電網(wǎng)公司的部分業(yè)務(wù)系統(tǒng)中完成部署與應(yīng)用,自動(dòng)構(gòu)建了業(yè)務(wù)級(jí)和應(yīng)用級(jí)的全景拓?fù)鋱D,實(shí)現(xiàn)了應(yīng)用層的持續(xù)性監(jiān)控能力,輔助運(yùn)維人員掌握當(dāng)前業(yè)務(wù)系統(tǒng)運(yùn)行的整體情況。后期,可基于此性能數(shù)據(jù)集成平臺(tái)將更多的一級(jí)部署系統(tǒng)和二級(jí)部署系統(tǒng)納入監(jiān)測(cè)范圍,形成統(tǒng)一的應(yīng)用系統(tǒng)性能數(shù)據(jù)集成平臺(tái),自動(dòng)構(gòu)建業(yè)務(wù)級(jí)和應(yīng)用級(jí)的全景拓?fù)鋱D,實(shí)現(xiàn)應(yīng)用層的持續(xù)性監(jiān)控,輔助運(yùn)維人員掌握業(yè)務(wù)系統(tǒng)運(yùn)行的整體情況^[15-16]。另外,可考慮基于性能監(jiān)測(cè)平臺(tái)數(shù)據(jù),與現(xiàn)有評(píng)價(jià)數(shù)據(jù)相結(jié)合,建立信息系統(tǒng)質(zhì)量評(píng)價(jià)指標(biāo)和評(píng)價(jià)體系,促進(jìn)運(yùn)維單位與研發(fā)單位間良性互動(dòng),不斷提升國家電網(wǎng)公司的信息化應(yīng)用水平。