隨著中國工商銀行（以下簡稱“工行”）數據大集中工程的完成，數據中心對全行的業務影響力日益提高。截至目前，數據中心運行的各類應用系統已達200多套，各類服務器3000多臺，部分應用系統支撐著全球范圍7×24小時的連續業務運營。在此情況下，如何確保工行應用系統的穩定可靠、高交易成功率和高峰訪問條件下的高性能是數據中心生產管理必須面對的課題。擁有一個高度自動化的應用監控管理工具，特別是全面建成覆蓋各應用系統的端到端業務級監控，是成為國際一流數據中心的必備條件。
一、應用監控需求分析及目標定位
從2003年1月正式啟動的ECC工程集中監控子項目至今，工行監控體系的建設已經走過了8年時間，中間相繼以CA公司Unicenter和IBM公司的TIVOLI等主流產品為基礎，經過軟件開發中心客戶化開發并補充完善，逐步形成了由硬件監控、主機監控、網絡監控、開放平臺系統監控組成的綜合監控格局，基本實現了系統監控自動化，各項IT系統環境指標均能被實時監控。作為支撐全行業務運營的生產管理中心，數據中心只有系統資源監控工具是不夠的，日常運維過程中經常出現系統資源正常而交易異常緩慢的情況。應用監控提出應該以業務為中心管理監控對象和事件，通過對交易響應時間、交易成功率、交易吞吐量等關鍵指標進行跟蹤和分析，配合交易仿真和交易模擬，不但做到故障發生時及時報警，幫助運維人員盡快定位故障源頭，還應該對應用目前可用但狀況變壞的趨勢提前預警，讓運維人員未雨綢繆，及時防范，避免故障發生。同時，應用監控管理要能做到根據不同運維人員關注的不同側重點來展示監控對象和指標。
二、應用監控建設歷程及現狀分析
1.分行外圍應用監控系統
工行首次投產的應用監控工具是在2006年4月啟用的NOVA2.0版本，當時主要是為了實現對分行綜合前置、中間業務平臺和新終端平臺的監控。
2.數據中心應用監控系統
數據中心在2009年3月正式啟動應用監控系統的建設及應用掛接工程項目。截至目前，數據中心已有128個應用掛接了應用監控系統，包含主機和開放平臺應用，占比已經超過60%。目前應用監控系統實現的監控范圍已經涵蓋聯機交易、批量運行、應用可用性三大類指標，在數據中心生產運維過程中發揮了重要作用，同時，極大減輕了運維人員的監控壓力與操作風險，運維人員只需通過單一界面就能實現對全行應用運行狀況的監控。
3.應用產品綜合統計分析平臺
針對數據中心開放平臺應用在業務聯機交易和批量運行情況監控統計分析方面的不足，2008年初，數據中心啟動應用產品綜合統計分析平臺自主研發工作，截至目前，已經完成69個開放平臺應用各項運行指標數據的自動采集及匯總分析展現，涵蓋聯機交易統計、性能管理、批量時效性分析、重點數據服務等多個功能模塊，對于數據中心運維人員掌握應用運行狀況以及向總行安全生產管理部門報送各類應用運行統計數據發揮了重要作用。
4.應用監控現狀分析及改進建議
（1）分行的應用監控管理還比較薄弱。目前，工行應用監控系統采用分布式系統架構，數據中心和各一級分行獨立部署應用監控工具，分別對本地運維的應用進行監控，各應用監控系統之間沒有關聯關系。數據中心作為全行生產運行管理中心，需要對分行關鍵業務系統可用率指標進行監控。分行應用報警事件可以按現有模式在分行應用監控系統展現，但數據中心應用監控要有專用視圖以監控分行發生了哪些報警事件，具體報警信息可以通過鏈接到分行的應用監控模塊進行查詢。另外，數據中心應用監控系統應該能主動發起模擬交易，探測分行關鍵業務系統的可用性，然后通過概率統計測算分行關鍵業務的可用率。
（2）監控指標數據采集周期過長。當前，國內外先進數據中心的監控數據采集周期基本以秒級為單位，比如韓國國民銀行數據中心每秒采集一次，銀聯數據中心也已達到每10秒采集一次。而工行應用監控系統目前的采樣周期還處于分鐘級：主機OMEGAMON可以達到每分鐘刷新一次，而開放平臺采樣周期基本是5分鐘、10分鐘一次，報警的實效性有待提高。為了避免盲目縮短采集周期影響生產，同時又能提高報警實效性，可以結合開放平臺高可用性和災備技術進行。比如，監控數據的采集完全可以在備用數據庫上進行，利用OracleDataGuard使備用數據庫保持為與生產數據庫在事務上一致的副本，備用數據庫以只讀方式打開，然后對其運行查詢。
（3）計劃性重啟引起虛警過多。服務器例行重啟或版本投產可能引發報警問題，盡管可以通過事先設置維護期來規避，但存在人工操作過多以及屏蔽時間和實際停機時間不完全吻合的缺陷。工行已經在實施HPSA無縫重啟以及HPSA自動化版本投產，完全可以在HPSA中嵌入兩段腳本，分別用于向應用監控發布屏蔽報警的指令以及啟用報警的指令，以實現計劃性重啟報警事件屏蔽的自動化。
三、應用監控未來發展規劃與思路
1.面向業務和服務的監控
2010年7月，工行提出“面向業務、面向服務”的監控管理要求。根據數據中心生產運維管理面臨的實際問題，可以從三個維度來定義“面向業務、面向服務”的監控內涵。
（1）面向客戶服務維度。監控應該監測用戶是否能夠訪問目標應用；監測用戶訪問目標應用的響應性能；監測用戶整個交易流程中哪個環節發生了異常。
（2）面向應用支持維度。監控應該使運維人員先于客戶知曉應用系統的健康狀況；盡可能提供對各級運維人員（一線運維人員、二線支持人員、三線應用開發測試人員）有價值的診斷信息，盡快隔離問題。
（3）面向生產管理維度。監控應該提供關于應用運行狀況的統計數據并對各類考核評估提供總體性數據支持；更好地制定服務水平管理標準；提供真正的業務影響視圖。
2.指標聚合及業務影響關聯分析
圖1 綜合監控系統框架
根據規劃，工行未來的綜合監控系統框架如圖1所示。其中，應用監控和綜合監控的關系表述如下：應用監控負責集中采集各應用的性能數據，并將重要的性能數據通過性能數據接口實時上送給綜合監控系統；綜合監控系統負責匯總各專業上送的事件和性能數據，實現面向業務可用性的個性化監控指標展示視圖。
在上述框架中，最有價值的部分是業務影響和關聯分析以及端到端業務監控。數據中心應用系統數量大、復雜性高，大量的監控指標和告警信息都上送給綜合監控平臺后，如何保障運維管理人員或更高級的管理人員在短時間內方便快捷地了解業務系統整體的運行情況并作出評價與判斷，將在一定程度上影響監控系統在企業中的價值。指標聚合是針對這一問題的有效方法。可以借助建模技術，將與業務服務相關聯的對象組織在一起，通過影響分析將底層的可用性及健康情況逐級傳遞上去，形成類似金字塔型的KPI指標體系，從而使管理人員能夠通過關注幾個較少的指標完成對系統整體運行情況的把握。通過對韓國國民銀行材料的研究得知，韓國國民銀行就通過與咨詢公司合作，分別建立“業務分類樹”和“系統分類樹”模型，實現了業務影響度的分析和規劃。
3.端到端監控的實現思路
目前，工行應用監控系統已經初具規模，為了進一步實現“面向業務、面向服務”的監控管理要求，要求我們必須建立覆蓋各應用系統的端到端業務級監控，可以遵循以下兩種思路來實施。
（1）主動監控。主動監控包括主動執行仿真交易來檢查應用系統的性能和可用性。可以考慮在所有一級分行抽取部分重要網點部署探測腳本，定時發起模擬用戶行為的仿真交易，記錄整個交易流程（例如ATM→綜合前置→通用網關→主機)的響應時間，與相關交易的平均響應時間進行比較，如果超過平均交易響應時間，則進行報警，從而為關鍵業務交易的可用性問題提供優先的早期預警。同時，這還可以幫助數據中心運維人員判斷是分行的問題還是數據中心的問題，是所有分行問題還是個別分行問題。
通過引入支持HTTP協議的客戶端編程工具包HttpClient，我們利用HttpClientAPIs實現了基于POST表單模式模擬用戶自動登錄BS應用的監控工具，該工具每隔5分鐘定時運行，可以從終端用戶角度主動探測部署在數據中心的BS應用的可用性。
（2）被動監控。被動監控主要用于測量實際最終用戶執行交易時的響應時間。實現被動監控的方法可以通過基于國際標準的應用程序響應評測(ApplicationResponseMeasurement，ARM)接口，在應用程序源代碼中包含對ARMAPI的調用，通過ARM可以實現對貫穿整個應用架構的交易路徑實施跟蹤，包括端對端交易響應時間的度量，ARM的工作原理如圖2所示。
圖2 ARM工作原理
ARM是一個應用程序接口（API），它可以監控不同應用和系統下的業務交易的可用性和性能。要監測應用程序的響應時間，可以在應用程序開發階段根據ARM標準將ARMAPI調用嵌入應用程序代碼，主要是在需要監控性能的應用交易代碼前后添加ARM調用，然后可以通過專用軟件工具進行監控。現在業界領先的軟件提供商如IBM、HP、SAS等已在自己的軟件中內置了ARM。工行應該盡早組織開發人員深入研究ARM標準，以推動工行在應用監控程序功能實現方面的標準化，這不但可以提高數據中心的運維管理水平，同時可以提高測試中心對應用程序性能的檢測能力，最終保障應用系統的穩定高效運行，從而能夠為客戶提供優質的產品和服務，持續提升銀行在國際金融市場的競爭力。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.hanmeixuan.com/
本文標題：數據大集中模式下的應用監控分析
相關文章
