0 引言

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

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

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

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

1.1 核心原理

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

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

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

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

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

性能監(jiān)測工具的關(guān)鍵功能模塊主要包括應用拓撲分析、Web應用過程分析、數(shù)據(jù)庫性能分析、錯誤分析、外部應用分析等。

1.2.1 應用拓撲分析模塊

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

1.2.2 Web應用過程分析模塊

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

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

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

1.2.4 錯誤分析模塊

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

1.2.5 外部應用分析模塊

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

1.3 性能指標

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

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

2）請求阻塞時間：請求到達前端服務器及應用服務器收到請求的時間。

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

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

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

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

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

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

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

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

圖2 某系統(tǒng)應用拓撲圖Fig.2 Application topology of a system

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

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

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

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

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

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

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

圖7 應用錯誤率Fig.7 Application error rate diagram

圖8 錯誤列表Fig.8 Application error rate diagram

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

圖9 平均響應時間Fig.9 Average response time

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

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

 3 應用效果評價及總結(jié)

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

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

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

 4 結(jié)語

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