随着中国工商银行(以下简称“工行”)数据大集中工程的完成,数据中心对全行的业务影响力日益提高。截至目前,数据中心运行的各类应用系统已达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应用的可用性。