应用监控 —— 提高IT系统可用率的点睛之笔

前言

在IT系 统运行维护中，监控系统日益成为保障系统安全运行不可或缺的重要工具，在提高系统可用率和故障的预警能力，最大程度缩短故障修复时间方面，日益彰显其巨大 的魅力。监控系统经过多年的发展和实践应用，在针对硬件平台及系统软件方面的技术已经相当成熟，形成了一整套的标准和规范，可以较方便地进行配置完成对各 类IT系统的监控。然而，随着计算机以及网络技术的飞速发展，计算机承载的应用软件日趋复杂，业务流程的自动化水平也在不断提高，业务系统可用率成为衡量IT系 统运行水平的一项重要指标，如何提高也必然成为监控系统的一项至关重要的任务。运行在各类硬件平台上的应用软件五花八门，如何针对众多不同的应用软件，制 定一个既能适应各类应用软件，又能较好的反映应用软件运行状态，及时通过监控平台完成相关监控动作，已经成为当前系统监控工程中一项重要任务，也必将成为 下一步监控系统发展的重要方向。

目前IT监控系统存在的不足之处

在 大中型的计算机业务系统建设中，一般都与之配套建设了监控系统以及一些维护工具产品，针对监控系统的一些告警输出，结合邮件及手机短信等手段及时反馈给维 护人员，做到及时对故障进行相关处理。然而在众多的监控系统中对硬件系统及系统软件的监控实现起来相对容易，而对应用软件的监控目前还没有成型的标准和方 法，有一些是依靠系统监控功能从外围进行一些系统级的判断，由于应用软件故障表现出来就是业务流程出现问题，判断的标准是必须要介入到业务逻辑之中去，从 系统一级进行监控是无法做到这一点的。而对于一个业务系统来说，业务运行的正常与否是最关键的系统运行指标，硬件及系统软件运行再好，应用软件运行不正常 或停止对于整个系统来讲都是致命的问题。因此，对应用软件的监控能力不足是当前监控系统存在的重大问题，必须采取合适的手段提高监控系统对应用软件的监控 能力，从而最大程度提高业务系统可用率。

应用监控的难点以及需要解决的问题

应用监控的难点总的来说有如下三点：

由 于应用软件采用的计算机语言、开发工具、编程方法各不相同，同时，应用软件处理的业务也大不相同，业务逻辑各不相同，系统监控很难深入到应用软件中在业务 处理过程中进行各类判断，采集相关业务系统运行　状态数据。另一方面，应用软件需要根据业务的发展变化经常性地进行版本升级改造，如果监控系统深入到复杂 应用软件业务处理逻辑中，必然造成与应用软件紧耦合，牵一发而动全身，最终造成应用软件运行环境的整体恶化，使应用软件和监控系统均陷入无所适从的地步。

监 控系统如果将应用监控纳入监控范围，将面临标准化的问题。对于硬件系统及系统软件来说，相对来说数量和种类并不多，监控系统完全可以针对不同的硬件平台及 系统软件制定与之相对应的监控标准和规范，而对于应用软件的监控则必须采用异于系统监控的方法，采用与应用软件松耦合的办法采集到应用软件的运行质量数据 并利用系统监控的方法和界面进行展示和处理，并达到与系统监控功能的完美结合，这也是实现应用软件监控的一大难点。

目 前应用开发商大多不考虑自身软件的监控能力，只考虑自己的业务逻辑的实现，往往出现了一些问题才通过修改软件加一些输出功能，进行问题诊断。而监控系统却 往往是产品化的软件，与应用软件天生就存在难以衔接的问题，因此，应用监控需要在系统监控的总体框架下，制定应用软件监控接口标准，应用软件厂商在接口标 准的约束下完成应用软件内部各业务及流程运行质量数据的输出，系统监控厂商通过相对稳定的接口标准在系统监控的框架下完成应用监控的各项功能。

  这样看来，实现应用监控需要解决以下问题：

系 统监控与应用软件松耦合的问题。从应用监控的效果来说，应用监控应当也必须做到，在应用软件以及所操纵的数据发生各类变化时所造成的影响不能蔓延到监控系 统之中。造成这种稳定的效果完全依赖于应用系统与监控系统接口标准的科学性和灵活性以及这一标准从始至终对应用软件开发过程中必须要具备监控能力的约束。 在这个体系的约束下，对于新增的软件或模块开发商将自然产生一个软件入网条件(遵循规范的认可以及能力)。

建 立接口规范后，将在监控平台与应用软件间建立起一个应用软件监控数据收集容器，它成为应用软件和监控平台之间的分水岭，也是实现监控平台与应用软件松耦合 的手段。至此，将产生出两项工作，即容器之前应用软件对自己各类业务运行质量数据的输出工作和容器之后监控系统从容灾中采集数据后的展示和应用工作。第一 项工作由应用软件厂商完成，可以说在输出标准确定后这项工作非常容易，从后面的介绍中可以看出这一点。第二项工作则是目前监控软件的薄弱环节，首先容器标 准空白，尽管目前针对业务系统平台运行的各项指标(如CPU、内存、文件系统、进程、SWAP区、网络、存贮设备以及oracle，Weblogic等)的 展示方式已经十分丰富，形式也美观大方，统计功能也十分完善。但针对应用软件的这类最接近前台用户，最受维护人员关心的运行质量数据的处理和展示却十分苍 白。因此，监控厂商针对包括输出容器标准在内的一整套的数据采集、展示、处理的应用软件监控功能开发方面将大有可为。这一功能的实现也必然会促进监控系统 功能的进一步完善。

应用监控的实现

首 先考虑容器之前的工作。应用监控的任务是保证承载在系统平台上的各类业务功能的正常运行，满足各业务使用人员对系统不间断的使用需求，并提供正确的功能和 数据。在应用软件开发中，由于业务功能的复杂性造成编程中难免有一些漏洞或错误存在，当某些操作导致触发这些漏洞或错误时必然会产生业务功能的停顿或出 错。而这些漏洞或错误可能遍布到庞大的应用软件的许多角落，许多漏洞和错误很难在测试中发现，这些问题是无法采用软件设计中常规的“引出例外”(Exeption)来捕捉和处理，因此，应用监控必须要考虑到各种情况以实现最终保证前端应用人员的正确的不间断的使用需求。

要实现这一目的的办法不外乎两种，应用监控虽然难以像系统监控那样具有比较成熟的标准，也难以使用系统监控的监控方法，但应用监控具有自己的特点，那就是在业务系统中几乎所有的应用(或称为业务)均是操纵数据或产生数据的过程，而前端用户往往最终关心的也是这些业务数据，因此通过数据来判断业务或业务流程是否正常是一种最准确最直接的方法。业务运行好坏并不关心业务进程的系统占用指标。因此对容器的业务运行质量数据的输出可以通过如下两种办法实现：

针对业务流程中可知的或可能出现问题的程序段增加输出。这一输出不限于故障，也可反映一种状态，如在一个循环程序段中增加循环次数或处理数据条数的输出，以此来让监控系统反映业务流程的处理进度。需要说明的是，这项工作传统的应用软件中也是经常应用的，如在引出例外时写LOG文件等，但没有做到与监控系统的联动，采用人工查看的方法，不易快速发现故障和处理故障。这种方法只是程序中或在引出例外中增加一条输出语句(insert或update)将相关情况根据容器规范抛入容器，剩下的工作就由监控平台完成了。

针 对未知的所有业务问题，是不能通过程序本身进行状态数据输出的。需要通过对业务程序所操纵的数据或产生的数据进行判断。而众多的业务关注点可以采用相同的 处理过程和不同的判断标准统一向容器输出相关状态数据的。举例说明，在电信用户用缴费卡通过拨打电话进行电话缴费过程中将通过众多的环节最终在计费系统上 完成销帐任务，任一环节出现问题都将影响到“电话缴费卡业务”的正常运行，对这一业务是否正常最直接的办法就是检查计费系统中在一定时间内是否有卡用户缴 费的缴费记录。而扫描计费系统缴费表并根据经验进行数据合理性判断相对来说是比较简单的事情。按照这种办法来扫描这个环节中其它数据便可更详细地确定问题 所在。这一方法可以应用到业务系统各个环节之中。

再考虑一下容器，它是一张由业务系统进行写操作并由监控系统进行数据读取的表。它是一个连通业务系统与监控系统的桥梁。难点在于其数据结构和标准，这一标准的制定应由系统监控厂商根据系统监控中展示的方法和相关要求结合应用软件的监控特点(如输出指标是否对应用软件监控有帮助等，这里不能去考虑详细的业务实现)来 完成。具体容器的建立可由应用软件厂商完成，监控厂商控制容器标准。应用软件厂商可以针对应用软件使用的数据库的类型、分布情况定制好容器。比如，为了提 高应用系统的输出效率同时考虑写操作大多数发生在业务端，把容器定制在业务系统一端，由监控平台远程调用。应用软件厂商向监控厂商发布相应数据调用方法和 访问端口。下面举例说明一下这个容器的内容：

MOID	Char(10)	管理对象ID，表示某个业务或某段程序，粒度由应用软件方控制
MONAME	Varchar(20)	管理对象名称，某个业务或程序的中文表达，由应用软件方制定
LOCATION	Varchar(20)	管理对象所在位置，可以表示为其所在的业务位置或操作人所属机构等
MOSTATE	Char(2)	管理对象的运行状态，最简单的形式例如：用“00”表示不可知，“01”表示正常，“99”表示出错
MOATT1	Varchar(200)	管理对象的附加属性，例如，管理对象正常运行产生的中间数据，方便使用人员根据数据得到业务运行情况的进一步判断。输出多个附加属性可以通过中间加分割符的形式解决，监控系统完成拆分工作
MOMESS	Varchar(20)	当MOSTATE为“99”时的出错输出信息。
ACTION	Varchar(200)	管理对象针对当前状态要求监控平台触发的动作。如通过如下设置：完成将MOMESS等相关信息发邮件和手机短信，并在指定IP的主机上执行指定脚本程序。
ACTIONTIME	Number(4)	动作的执行时间，如0表示采集后立刻执行，NULL表示不进行动作，其它数据表示采集后经过多少分钟后执行动作。执行完毕将动作执行时间及执行情况填入ACTIONRESULT，在监控系统中备份动作指令并清除ACTION，置ACTIONTIME为NULL。
ACTIONRESULT	Varchar(200)	记录动作相关情况
RECORDSTATE	Char(1)	记录处理情况，如“0”监控系统未读取，“1”监控系统已读取
UPTIME	Datetime	上次本管理对象数据更新时间
CLTIME	Datetime	监控系统采集时间

容器中管理对象(MO)的建立可以通过监控平台提供的功能建立和删除，应用一方可以针对本管理对象附加一定的属性，利用监控平台及时反映各管理对像的各属性的状态。管理对像（MO）一旦建立，本对象就从业务端建立起到监控平台的关联，下一步的任务就是由业务端定时刷新管理对像的各属性状态资料，监控端定时扫描容器各管理对象数据并能展示和相关处理。

容 器之后的监控平台的工作相对来说也变得非常简单，根据从容器中提取的各管理对象的数据应用系统监控的办法进行多方面的展示，使系统维护人员和业务使用人员 对业务运行情况能得到更为方便直观的了解，监控厂商在这一阶段最重要的工作就是能对所有监控对象一视同仁，不关心监控对象的业务含意，只关心各监控对象附 带的相关数据按规则的展示方法，并根据指令完成相应动作(如发邮件、发短信、执行一个脚本等)，由维护人员或业务人员去根据展示的情况判断各业务的运行状态。

结束语

在目前承载业务日益复杂的IT系统环境中，对业务可用率的要求越来越苛刻，应用监控已经成为IT系统实施监控过程中的焦点难点问题。应用监控作为提高业务可用率的重要手段必将成为各监控厂商重点关注的领域，这一问题的完好解决必然会对监控系统在IT运行维护中的广泛应用带来新的动力，也必将会给各应用软件的更安全可靠运行带来新的曙光。