上海财经大学：搭建一个优良的业务监控系统

文/宫剑 黄杰 孙晓静

随着信息化建设程度的不断提高，越来越多企事业单位的日常业务工作与业务信息系统紧密相关，如协同办公系统、人力资源系统、财务管理系统、资产管理系统等。这些系统的运行情况和各部门业务的捆绑越来越紧密，它们的运行状态一直是IT运维部门关注的焦点，其可用性、性能指标以及出现故障后的响应时间，都会直接影响客户的满意度。一旦系统出现问题，将可能会使各单位遭受巨大的损失，目前采取的主要措施就是引入监控系统来监控各类IT基础设施和系统，但是实际的效益并不显著。虽然绝大多数IT运维部门都对自己的生产系统进行了监控，但由于监控是个系统工程，各类业务系统的部署环境日趋复杂，林林总总的各类网络设备、安全设备、服务器、中间件、数据库、应用程序等软硬件来自不同厂商，而现有的监控技术研究局限于各个产品或模块，或是拓扑发现，或是故障管理，因此未能达到最好的效益，IT运维人员仍疲于应对不同厂商、不同软硬件架构、不同管理工具、不同成熟度的应用软件，由此对业务系统的可用性、安全性的日常运行维护管理的要求也越来越高。

据调查报告显示，大约有三分之一的应用问题是因为客户发现反馈甚至投诉后才被发现的。如何提升对生产系统的预警和监测，甚至自动恢复的能力，在第一时间发现并解决操作隐患、功能故障或性能瓶颈，打造规范化、无盲点的运维监控体系，成为IT运维人员工作者急需解决的问题。我们在总结日常运行维护工作经验的基础上，基于CMDB（Configuration Management Database， 配置管理数据库）中配置项CI（Configuration Item， 配置项）模型的思路，设计了业务可用性监控平台对各类IT基础设施及业务系统进行了监控，并取得一定效果。

本文首先对CMDB进行简单介绍，随后对基于CMDB的业务可用性监控平台的设计进行了详细阐述，具体包括根据CMDB梳理出的常见监控项、监控平台的具体实现思路、CI的变更对监控造成的影响及相应处理流程等，最后对基于开源程序的实现情况和实际应用情况进行了介绍。

CMDB定义及模型

CMDB 是 ITIL (Information Technology Infras-tructure Library，IT 基础架构库 )中最重要、最核心的概念之一。CMDB 在ITIL 中的定义是：提供 IT 相关配置信息，存储与管理企业 IT架构中设备的各种配置信息，它与所有服务支持和服务交付流程都密切相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。

图1 CMDB模型举例

图2 常见业务系统结构及对应的监控项

在CMDB中，被纳入配置管理范围之内的元素都是 CI，它包括由IT 部门控制的所有 PC 硬件、软件、服务器、文档、服务以及由 IT 部门所控制的所有其他 IT组件。从业务角度来看，CMDB实现了对IT系统内部各个元素信息的跟踪，成为迅速查找IT基础设施信息的基础，同时也是实现有效管理决策的基础。一项信息服务背后都有众多的CI项与之关联，其中任何一个CI项或CI之间的关联出现故障，都有可能造成信息服务出现问题。图1为笔者所在部门管理的实际生产系统对应CMDB模型片段。

鉴于CMDB在IT体系结构中所起到的重要作用，我们可以借助其对IT的日常运维工作进行深入分析。一个精确的CMDB能够提供充足的信息让运维人员方便把每一次运维事件进行定位，以便知道什么地方什么组件出了什么样的问题，正是因为CMDB在信息服务中和运维深入分析中所起的重要地位，本文提出了基于CMDB的模型来构建业务可用性监控平台。

业务可用性监控平台的设计

传统对业务系统的监控一般以单个设备、资源或软件告警为主，缺乏系统与业务层面的整体监控和分析能力，难以从整个系统业务可用性的角度加以评价。同样一个从技术角度看起来十分微小的故障或疏忽，有可能对业务几乎没有影响，但也有可能会造成十分重大的影响。本文通过引入CMDB中的配置项建模思路，试图解决监控项的局部性问题，同时在开源监控软件基础上用灵活的监控脚本编写加以实现，以期将整个建模过程变得高效化、自动化和规范化，并能够随着IT 业务对象的变化而不断地动态更新和完善，准确地反映业务对象本身，同时达到及时监控的效果。

常见业务系统结构及对应的监控项

常见的业务系统软硬件架构如图2所示，一般包括物理设备、逻辑资源、操作系统、中间件、应用实例以及业务服务等，针对各个层次的监控项也各不相同，以下说明对于业务系统结构中各个层次的常见监控内容。

图2为常见应用系统的部署层次结构，一般最底层为物理设备，包括各类物理主机、网络设备、物理存储等。随着虚拟化技术的广泛采用，部署在虚拟主机上的操作系统越来越多，因此我们专门在物理设备层上搭建了逻辑资源层，不仅包括虚拟主机，还包括逻辑的存储资源和网络资源等直接可供操作系统使用的逻辑资源。第三层为操作系统层，基于其上的是中间件层，包含数据库、应用服务器、HTTP服务等，而具体的业务系统应用实例搭建在中间件层上。最后面对用户的是业务服务层，它通过负载均衡与应用实例进行关联。

对物理设备的监控一般主要包括机房环境监控，主机资源的使用率监控等。针对不同的物理设备，监控侧重点有所不同。对于物理主机，主要关注CPU、内存、IO、系统平均负载等实时状态，对存储设备则主要是对物理磁盘空间使用率的监控，而网络设备主要是对物理网络传输性能、可访问性的监控等。

随着虚拟化的应用逐步增多，越来越多的应用已部署在虚拟主机中，因此需要考虑对逻辑资源的监控。与物理设备类似，关注点也主要包括逻辑磁盘空间使用率，逻辑主机、逻辑网络资源使用率和性能等。

对操作系统层面的监控内容首先是对操作系统安全方面的监控，比如操作系统版本、补丁、各类防护软件、重要服务端口的设置情况、用户访问级别等，其次为一些重要参数的设置是否正确，如linux中的可打开文件个数参数默认值较小，经常会影响部分应用程序的正常使用。

中间件层一般包括http服务(apache，nginx等)、数据库和应用服务器（比如Oracle 、MySQL、Tomcat等），因此对中间件层的监控主要包括数据库性能的监控和应用程序服务状态的监控。数据库性能状态通过监控数据库的缓存、缓冲区命中率、表空间使用率等核心性能指标获得，针对应用服务器，以J2EE组件为例，监控的内容包括相应时间、调用次数、并发量、延迟量、对象数、连接池、线程数以及Java内存情况等。

为了保障业务服务的可用性，很多应用系统都采用了硬件或软件的负载均衡措施，因此面对最终用户的一项服务的后面常常由多个应用系统实例构成，对这类应用系统实例的监控，除了保证功能可用性方面的监控之外，还要注意保证各个应用实例之间的一致性，这一点往往容易被忽略，应用实例之间不一致导致的后果既难定位，也难以发现核实。

业务服务层主要是针对面向最终用户的服务功能可用性和业务系统安全性进行监控，其中功能可用性又包括整体可用性和关键功能可用性等内容。

具体思路

第一步，我们归纳出常见的监控点并进行分类。

我们通过对以上梳理出来的常见监控内容进行分析，结合CMDB中的信息得到其对业务系统可用性的影响程度，从而确定一般监控内容需要关注的类型：可用性、安全性、资源利用率、一致性、时效性等，具体如下：

可用性——可用性和系统组件的失败率相关，系统的失败只有当其导致服务的失效性足以影响到系统用户的需求时才会影响其可用性的指标。对于可用性的监控方式，我们主要根据软件测试的思路，使用各类主动模拟技术，通过脚本主动模拟访问各类CI项，可以直接取得其具体功能（事务）的响应时间和成功率。

安全性——国际标准化委员会的对计算机安全的定义是“为数据处理系统和采取的技术的和管理的安全保护，保护计算机硬件、软件、数据不因偶然的或恶意的原因而遭到破坏、更改、显露。”从该定义可知，安全性在中间件、应用实例、业务系统、操作系统等各个层面上都有所体现，而对于操作系统、中间件等偏底层的安全性尤为重要。在《信息系统安全等级保护基本要求》中，针对不同等级的信息系统在技术防护角度上提出了不同的安全要求，包括标识与鉴别、访问控制、密码技术、安全审计、恶意代码防范、备份与恢复等方面的技术。运用监控手段，结合灵活的脚步设计，可以对安全设备的运行、防护措施的落实、备份恢复的有效性等多方面工作进行实时监控。

资源利用率——资源使用率指对软硬件等资源的负载情况，一般包括CPU使用率、磁盘空间使用率、系统平均负载、内存使用率、开机时间、I/O以及网络负载等。资源利用率一般会直接与应用系统的性能有关，对用户的体验造成影响。

一致性——这里的一致性主要是指逻辑上应该相同的内容，其物理上也应该是相同的。以负载均衡环境下的多个应用实例而言，只有保证各个实例之间的一致性，应用实例才可以对外提供一致的应用服务。其他的例子还包括不同介质上保存的相同备份内容，其文件大小及md5也应该是相同的。

时效性——响应时间主要指数据库和业务服务的响应时间，数据库的响应时间可以通过监控数据库的关键指标来获得，业务服务的响应时间可以通过模拟浏览器访问的行为，从而获取业务服务的响应时间。此外，时效性也包括其他CI项的类似倒计时提醒，如针对维护合同的到期日期、关键用户账户的到期日期等，通过扫描程序，定时扫描合同日期、重要系统的管理员及其它高级权限的用户账号等，不同类型账号的有效期、修改密码的要求设置不一样，通过对比账号的有效期，从而完成倒计时提醒功能。

第二步，针对上述整理出的监控内容分类，进一步返回到CMDB中，对每一层面、每一类型的CI项分别针对上述监控点类型进行筛查，并建立具体的对应矩阵，尽可能减少监控点的遗漏。监控矩阵示例如表1。

表1中，CI项一列为CMDB中的每一个配置项，矩阵中的数字则代表该CI项所对应监控类型对业务可用性可能造成的影响大小，5为最大，0为最小。具体针对矩阵中每一个非0值，都需要制定出对应的checklist检查表，对具体监控内容及监控方法进行描述，为监控的具体实施提供参考依据。最后形成一个CMDB中所有CI项对应的监控点检查表矩阵，检查表的样式如下：

第三步，结合CI变更管理流程对监控项同时进行变更。

基于CMDB的变更管理是ITIL管理的核心，CI数据的时效性和准确性是CMDB成功实施的重要标准。如果一名运维工程师在做处理故障前，获得了不准确的CI信息，从而做出错误的诊断结论，后果不堪设想。这样就要求我们要规范的变更管理流程，使用标准的模版记录、跟踪那些原始信息，并与ITIL的流程紧密结合，同时需要定期审计。

在进行CI项的变更过程中，由于监控系统紧密依赖于CMDB，因此监控项也需要做出相应的变更。也就是说，在变更管理流程中，需要在某个步骤加入对与CI相关联的所有监控项也要进行变更，具体可从管理和技术两个角度进行实现。

从管理角度，在变更的某个环节加入监控项的审核，由运维人员完成此类工作；从技术角度，还可以使用监控程序对CMDB与监控项进行一致性监控，也就是通过监控系统来监控自身的业务是否存在风险，比方说通过监控CMDB的新增、修改的内容和最后修改时间，与监控检查点的内容、最后修改时间进行比对，从而在变更第一时间发现哪些CI项缺少监控点，哪些CI项变更后但其监控点没有变更，这样完成对CI变更后内容的监控。

表1 监控矩阵示例

图3 监控模块

关键技术实现和具体应用

基于CMDB的业务可用性监控平台的实现分为两大部分，CMDB配置管理和监控系统。在实现过程中，我们均采用现有的开源框架，其中CMDB采用的是CMDBuild，监控系统采用的是pandorafms。

CMDBuild是一个可配置的Web应用，用来对资产以及相关的工作流操作进行配置建模和管理，能配置实现复杂模型。同时我们对其作了一定改造，能够无缝集成到我们运维管理平台中，实现和ITIL中的事件管理、问题管理、变更管理的无缝集成。

开源监控软件pandoraFMS是一款企业级的监控平台，它提供统一的Web界面实时监控各种硬件、软件、操作系统、业务系统、网络设备并在故障发生时发出报警信息。Pandora FMS体系结构清晰，采用高度模块化和分布式的体系架构，由监控代理端、监控服务器、中央数据库服务器以及控制台组成，每个模块都是可复制的独立模块，并且每个模块都支持高可用部署。此外，还支持使用SNMP协议（不需要安装agent）采集监控信息，部署方式更加简化，支持网络自动发现服务，自动搜索探测和监控新增加的设备，支持用户自定义的扩展程序，方便个性化的扩展，提供友好的Web管理控制界面，降低了学习成本，提高了工作效率。

采用CMDBuid和pandoraFMS搭建的业务可用性监控平台具有如下特点：

脚本可灵活设定，灵活扩展

pandoraFMS中，监控代理端是在被监控端中运行的应用程序，它负责将收集到的被监控端的信息发送到监控服务器端。监控代理端软件支持多种平台，包括 Windows、Linux、 Solaris、 AIX、HPUX、BSD等，在各自运行的平台上面编写shell脚本来获取系统的运行信息，如磁盘使用率、CPU负载、网络I/O、内存使用率、系统进程数等等。同时，监控模块的脚本基于操作系统的shell类型，如果同是linux系统，该配置脚本具有普适性，可以复制和移植到其他linux系统使用，对于大规模的监控和部署具有方便快捷的特点。PandoraFMS支持扩展和集成，Web应用的监控可以通过集成第三方的插件或自己编写插件的方式来完成，从而满足监控需求。

多种推送通知方式

PandoraFMS里面有报警模板可以设置多种推送通知方式，在报警模板里可以定义触发报警的条件和触发时间以及触发报警时报警信息的内容和发送报警信息的方式，根据对业务可用性影响的大小，可以选择邮件或是短信进行告知。邮件方式发送报警信息非常简单，配置SMTP服务器即可。但是邮件报警的方式有不足之处，它不能及时地通知到运维人员，只能通过人工查收邮件的方式来获取当期系统的报警信息，所以短信报警的方式是更为及时有效的措施，我们采用短信猫的方式进行短信报警。此外通过PandoraFMS不仅能给个人发送报警短信，也可以设置群组，对群组成员同时进行报警。

实现对监控项的变化自身的监控

如前所述，对监控项的变化自身的监控是通过自动发现的工具来实现的，自动发现的工具是一种扫描工具，扫描周期可以通过人工制定，将扫描所得到的信息通过Webservice接口调用CMDB，查询CMDB中的对应CI项，此时，监控工具就可以找到与CI项的变化内容不匹配的监控项内容，并发出报警。

支持自动监控到自动开单以及自动处理的转换

自动监控到自动开单的转换是指当监控系统监控到异常时，能够根据异常类型触发相应的处理脚本，自动在ITIL的事件管理中开单，直接在单子中记录事件的类型、相关CI项，发生时间等，运维人员只需进行简单补充即可。而自动监控到自动处理，则是通过脚本自动处理发生的异常情况。当然，通过监控能够自动处理的异常情况相对有限，只能应对处理规则比较明确的情况，比如当磁盘空间不足时，可以通过清理N天前的日志情况的方式来释放空间等，比较复杂的异常情况还需要人为的参与解决。

基于CMDB及开源监控软件pandoraFMS系统搭建的业务可用性监控系统，实现了对我校主机服务器、Web业务系统、一卡通设备、网络、数据库等绝大多数CI项进行的实时监控。不仅能够很好地监控整体运行情况，而且能够及时发现故障信息，很大程度上提高了运维部门整体的服务质量，从被动救火转为主动监控，保障业务持续不间断运行。随着学校信息化持续不断的发展，该监控系统还将不断的完善，发挥更大的作用。