环境信息化是充分利用现代信息技术，开发环境信息资源，促进环境信息交流和共享，推动环境保护发展转型或改进决策管理的历史性进程。国内的信息化是从20 世纪80 年代中期，在社会进入信息时代后开始规模化建设与发展，90 年代初期，为了适应我国环境保护工作的需要，环境信息化逐渐进入国家信息化领域，较大规模化建设始于“九五”期间，至今已有20 年。

环境问题是多个问题的综合体，是人与自然、发展与环境利益矛盾冲突的结果，是一个多层次、多系统、多视角的复杂问题。从经济角度看，涉及三次产业及各行各业和生产、流通、分配、消费各个环节；从管理角度看，涉及水务、国土、建设、农业和家庭生活的多个方面；从技术角度看，涉及物理、化学、生物、地质等多学科领域；从业务管理角度看，涉及环境质量、环境监测、环境监察、环境统计、污染源在线监控、项目审批和验收、信访投诉等业务板块。环境信息种类繁多、数量巨大，只有深入推进环境信息化建设，实现环境信息采集、传输和管理的数字化、智能化、网络化，才能从大量庞杂的信息中洞察趋势、掌握重点，使环境管理决策体现时代性、把握规律性、富于创造性，提高环境管理决策的水平和能力，推动各类环境问题的有效解决。

实践证明，环境信息化是环保能力建设的重要组成部分，是涵盖环保各项业务的一项基础性工作，是服务环境管理决策的一种技术保障。离开环境信息化谈环保，势必影响环境管理决策的科学化、精准化，制约环境保护服务于政府宏观管理的有效发挥。

各级环境保护行政主管部门积极应用计算机网络、数据库技术、地理信息系统、卫星遥感、自动监控技术以及多媒体技术等先进的信息技术手段，陆续开展了办公自动化、环境质量自动监测数据管理、卫星遥感监测、环境统计、建设项目环境影响评价管理、排污申报与收费、污染源在线监测管理、生物多样性管理、环境应急管理等大规模业务应用系统的建设工作。但环境信息化自身基础和保障体系依然薄弱，人才队伍建设和投入严重不足，重建设、轻运维的情况时有发生，尤其是“云大物移智”等新兴技术的迅速发展，对运维工作的要求不断提升。

随着分布式应用系统理论和技术的高度成熟，以及其所带来的高扩展性、维护与实施的简单性，应用上极受欢迎^{[2, 3]}。传统的三层架构模式发展到多层模式，信息系统规模日益扩大、结构日益复杂。在进行应用系统运行状态监控时，如何获取准确的系统运行信息、准确定位问题节点已经成为进行应用系统监控管理的重点和难点。

本文提出了一种应用系统运行状态监控模型、体系架构和监控方法，为应用系统提供全生命周期的运行状态监控，是进行应用系统运行状态监控体系分析和设计的有效解决方案。

运行状态监控系统是一个观测系统，通过实时收集和分析应用系统内部状态和外部环境信息，判断监控目标的执行行为是否与给定的需求或规约相一致^{[6, 7]}，从而发现系统的异常和健康程度。

分布式系统是指组件分布在连网的计算设备上，组件之间通过传递消息进行通信和动作协调的系统，强调资源、任务、功能和控制的全面分布^{[8, 9]}。分布式系统资源监控管理范围涉及到网络、主机、终端、UPS、中间件、数据库、业务应用、存储等分布式系统中的各类信息资源。由于所监视的IT 资源大多为分布式系统并且软、硬件设施间构成了错综复杂的拓扑环境，某个节点故障的发生可能会同时导致多个应用的运行异常现象。

根据分布式应用系统的运行特点，将整个系统监控管理的对象分为两类：①应用类对象：根据用户需求开发的应用程序或程序组件；②系统类对象：支持应用程序运行的系统资源，主要指应用中间件、数据库、操作系统等软件资源以及主机、网络设备、存储设备等硬件设施。

应用系统运行状态监控需要对纳入监控范围的应用类和系统类资源进行实时全方位监控、预警、定位、问题诊断和辅助故障处理，形成“发现问题—定位问题—解决问题—避免类似问题再次发生—促进应用系统持续优化改进”的监控管理模式；同时，需要形成对应用系统运行环境中网络、安全设备、主机、存储、操作系统、应用中间件、数据库及应用系统自身的基础监控体系，对应用系统的运行状态、运行效率进行监测，形成覆盖应用系统整体运行环境的管理体系。

监控模型就是描述监控对象和对象间关系的问题，通过“对象- 关系”的建立，形成应用系统的监控拓扑。

O={o1,o2,o3,……，on} 表示所有监控对象的集合。

对象间依赖关系：当某个监控对象的运行状态依赖于另外的监控对象时，如o1 依赖于o2 时，用MD(o1，o2) 表示^[10]。当o1 的运行状态依赖于o2 和o3，o2 和o3 存在两种逻辑关系，一种是o2 和o3 共同支撑了o1 的运行，缺一不可，则可表示为MD(o1，o2 AND o3)，第二种是o2 和o3 仅有一个正常运行时即可支撑o1 的运行，这种情况主要存在于o2 和o3 是采用热备或负载均衡的情况，用MD(o1，o2 OR o3)。

依赖关系的传递性：监控体系中的三个监控对象 o1, o2,o3，如果存在o1 依赖于 o2（MD（o1,o2）），并且存在 o2 依赖于o3（MD（o2,o3）），则o1 依赖于o3,即有MD（o1,o3）成立。

应用系统监控中的监控逻辑模型是否正确，是能否在发生问题时及时定位问题的关键因素。在进行应用系统监控时，必须根据上文中定义的监控对象的相关依赖关系，画出监控对象依赖图MODG（Monitoring ObjectsDependence Graph）。监控对象依赖图是一个有向图G =(O,E)，其中O 是顶点的集合，每一个顶点代表监控体系中的一个监控对象。 E 是边集，每一个边 e= ( o1,o2)表示 o1 依赖于o2。根据MODG 图找出监控体系内各个监控对象间的依赖关系 R= { <o1,o2> | o1，o2 属于应用系统中的监控对象且o1 依赖于o2}，然后根据对象依赖关系，可以找出影响监控对象运行状态的对象链，如果某条对象链中出现了问题，可以直接定位到出现问题的监控对象。图1 是某个应用系统的构成情况。图2 是根据图1 的依赖关系画出监控对象依赖图。从图2 中找出6 个监控对象间的依赖关系集 R ={ < o1,o2> ,< o1,o3> ,< o2,o4> ,< o3,o4 > ,< o4,o5> ,< o5,o6>}，当o1 出现问题时，可以根据依赖关系及其传递性从集合 R 找出影响其中某个监控对象运行状态的节点。

图1()

图1 应用系统运行环境

图2()

图2 监控对象依赖图

要反映一个分布式应用系统的运行状态，需要从以下几个方面进行监控：

关键功能组件OK，关键功能组件是一个应用系统的核心部分，是该应用系统使用频率较高、性能消耗较大、直接反映用户体验的部分。

应用中间件OW，应用中间件是位于平台( 硬件和操作系统) 和应用之间的通用服务，是支持应用系统运行的基础环境，如IBM Webshere，Oracle weblogic，tomcat，Jboss 等。

数据库OD，应用系统用来进行数据存储、管理的软件以及运行于该软件上的数据库实例。

操作系统OP，指支撑应用中间件及数据库运行的基础环境，如Windows server2008、UNIX、Linux、AIX。

支撑应用系统运行的其他应用系统或系统组件OS，由于Web Service、组件技术等新兴开发模式的兴起，一些应用系统在运行过程中需要依托、复用其他应用系统的一些功能组件，在这些功能组件发生故障时会直接导致应用系统一些功能的失效。

被其他应用系统调用的功能组件OB，用于支撑其他应用系统使用和运行的功能组件，当该组件发生故障时会导致其他系统运行状态的异常。

基础硬件设施OH，支撑应用系统使用及运行的基础硬件设施，包括相关的主机、网络设备、安全设备、负载均衡设备等。

根据各类监控对象的特征，建立以下的对象间依赖关系：MD(O_A，O_K and O_w and O_D and O_S)、MD(O_w,O_P)、MD(O_D,O_P)、MD(O_P，O_H)。

应用系统的运行状态取决于其所涉及的所有监控对象，根据对应用系统的监控和管理要求，监控对象的运行状态一般可以分为正常运行状态、非正常运行状态和停运状态，造成停运状态的情况一般分为系统故障、正常维护和人为终止服务，即系统的运行状态RS={ 运行、故障、性能问题、维护、停止}。任一监控对象O 在时间t 时，有且只能有一种运行状态，即O(t) ∈ RS。

对UNIX、Linux 操作系统监控的实现，需要预先在被监控操作系统上建立具有执行相关系统命令的用户，以保证能够获取操作系统的关键运行状态信息。UNIX 系统需要ps、svmon、lscfg、vmstat、lsfs、df、hostname、last、/usr/sbin/swapinfo、ioscan、mount 权限；Linux 系统需要cat、df、hostname、last 权限。模拟预先建立的用户使用telnet、ssh2 方式登录到目标操作系统上，执行系统状况查询命令，获取关键系统运行状况数据。使用命令获取的返回结果格式多种多样、不利于程序处理，所以会应用AWK 等语言对结果进行一定的处理，从而降低程序解析命令返回结果的复杂度。对Windows 操作系统，需要安装相关的托盘程序，由托盘程序获取系统运行的各种信息。

代理解析命令返回值后，将数据封装成bean，并与事先设定的监控阀值进行比较，判断是否生成故障、性能和配置事件，然后将数据信息和事件信息发送到数据发送线程中等待发送，通过JMX 方式将各种信息发送至监控中心。

对于应用中间件、数据库、网络设备、安全设备等成熟的软、硬件产品，可以直接调用其已经提供的相关监控工具，如Webshpere 提供的perfServletApp.ear，实现监控信息的获取；或是利用其提供的相关API，通过JMX 的方式获取监控信息，如webSphere 提供的AdminClient API。

应用系统自身的运行状态监控是一种轻量级的验证技术，是软件测试阶段的一种补充，其验证过程基于监控目标的实际运行过程进行，并非去判断应用逻辑是否正确、代码开发是否合理，只关注于特定时间内程序运行是否符合预期^[11]。

对应用系统及其核心功能组件的监控方式主要有实时拨测、基于性能工具的监控以及集成监控模式三种。

实时拨测针对采用B/S 方式对外提供服务的应用系统，通过自动模拟HTTP、HTTPS 等协议实时拨测各应用系统的关键URL 页面，通过判断返回的URL 页面响应，以监控各应用系统的可用性、响应时间：

httpsConn= (HttpsURLConnection) (new URL(urlString).openConnection());

httpsConn.setConnectTimeout(5000); // 建立连接

long begin = System.currentTimeMillis();

int code = httpsConn.getResponseCode(); // 获取返回表示

long end = System.currentTimeMillis();

time = (end - begin) + "";  // 获取访问时间

基于性能工具的监控方式是指通过使用中间件本身提供的性能监控工具，获取包含应用运行状况的信息。获取的信息除了被请求次数、平均响应时间、最长相应时间，最短响应时间、高水位、低水位等Action 或者Servlet 运行的负载情况外，还包括jvm 运行时信息、数据库连接池信息、Servlet 会话信息、Web 应用信息、企业bean 等。利用能够对应用程序提供管理服务的JMX管理功能服务，得到中间件上运行的应用程序信息：

Private void getApplicationRuntimeInfos(MBeanServerConnection mc,ObjectNameserverRT,ResultBeanrb) {

ObjectName[] applicationRTs = (ObjectName[])mc.getAttribute(serverRT,"ApplicationRuntimes"); // 获取运行状态组}

集成监控机制是指通过对应用系统监控项的分析，制定监控数据采集的Web Services 服务接口规范，监控程序与各应用系统按照约定开发符合标准的Web Services 接口。Web Services 服务接口由各应用系统按标准进行发布，监控平台负责定期调用相应接口，各应用系统在接收到调用请求时，按照规定的接口规范向监控程序返回监控数据。

各应用系统的Web Services 服务接口采用基于XML格式的WSDL(Web Services Description Language) 标准方式进行发布，供平台调用。

平台远程调用被监控业务系统提供的WebService 服务接口，通过接口获取业务系统中关键应用的运行状况，得到返回的XML 格式的查询结果，分析出XML 结果中包含的应用运行状况。

<?xml version=''1.0'' encoding=''UTF-8''?>

<functionResponse>

<modules>

<module name='''' alltime=''''>

<gradation name='''' starttime='''' endtime='''' interval='''' state=''''>

<!—关键功能组件的反馈信息-->

</gradation>

</module>

</modules>

</functionResponse>

监控平台和应用系统针对监控数据的交互，在网络层采用HTTPS 作为传输协议，在数据表现层采用XML格式的SOAP(Simple Object Access Protocol) 协议来约束消息格式，完成通过Web Services 服务方式完成监控平台和应用系统之间的数据传输和消息传递。

应用系统监控的技术体系主要由监控代理服务、规则关联服务、中心服务、数据服务和应用服务5 部分组成，各部分之间主要通过JMS 和JDBC 方式进行通讯。

监控代理服务一般包括6 类重要功能。日志收集引擎进程（Collector）接受、收集监控代理策略和配置，采集、过滤、识别和格式化日志信息，进行事件的简单聚合，并将事件输出到聚合引擎（AE）；监控代理引擎（MonitorAgent）接受监控器配置策略、运营监控器，获取监控数据，向中心发送监控数据；拓扑代理引擎（TopoAgent）负责采集主机、端口和拓扑信息；代理守护引擎（AgentGuard）负责数据存储、维护和清理，以及未知日志的归档和萃取；通讯代理引擎（CommAgent）负责向中心服务器上的进程提供业务API 服务；数据库引擎（DbManager）负责本地存储原始日志和未知日志等。

规则关联服务主要负责对事件进行策略关联分析，并形成高等级事件。聚合引擎（Aggregation Engine，AE）内置消息中间件，负责接收事件、根据策略聚合同义事件，并直接向规则关联引擎发送事件；规则关联引擎（Rule Correlation Engine，RCE）负责规则的加载和预编译，对接收到的事件进行场景模拟，产生高等级事件，并发送至事件中心处理；监控中心引擎（MonitorCenter）接收监控代理的数据，将监控数据入库，将事件信息发送给聚合引擎；通讯代理进程（CommAgent）负责向中心服务器上的进程提供业务API 服务。

中心服务主要负责事件和网络信息的统一处理，包括匹配工单策略、分析网络拓扑结构、统一任务调度等。事件中心进程（EventCenter）负责接收事件，负责匹配工单策略，触发告警。拓扑管理引擎（Topo Center）负责流量信息获取和监控，拓扑关系发现以及资产自动发现；任务中心引擎（TaskCenter）定时进行任务执行如漏扫、校时等，执行即时任务如邮件提醒、短信报警等，并周期性收集采集引擎运行信息；集成中心引擎（IntegrationCenter）负责同第三方软件在业务层进行集成，可支持多种通讯协议的扩展；通讯中心进程（CommCenter） 负责向Web应用进程提供业务API 服务。

数据服务中的数据库集中存储系统中的核心业务数据；数据库守护进程（DBGuard）负责监控应用系统运行管理软件数据库服务器，必要时做表空间清理。

应用服务通过部署并运行Web 程序包，实现数据展现业务，处理用户的http 请求等。

在进行应用系统监控时，如何获取相关监控对象的运行状态数据是整个系统的核心。数据采集的功能主要由监控器和监控代理完成。监控器必须依附于监控代理存在。一个监控代理可以附加多个监控器，监控器主要分为两种：一种为无需在监控目标机上安装监控器程序，另一种为需要安装监控器程序(Windows 和IIS FTP 等)，两种监控器都可以由监控代理统一收集监控数据。需要安装监控器程序的监控器在系统部署时需要进行配置，将监控器程序安装于需要进行监控的系统，同时配置其端口信息。监控器可以由根据监控需求的不同进行配置、添加、删除和编辑某个代理上依附的监控器，当代理处于不可用状态时无法对其已有的监控器进行编辑操作，但可以进行删除操作。

本文介绍了在复杂应用系统运行环境下，对应用系统进行监控的一种方法。应用该方法开发的监控系统既能对基础系统类对象进行监控，又能对个性化定制开发的业务应用系统进行监控，并将应用系统的运行环境进行了建模和关联，便于配置和扩展。

基于上述的软件模型、监控方法和体系架构，针对某大型项目的监控需求，开发了应用系统运行管理软件，用于进行应用系统的日常监控和管理，监控范围包括IBM PC 服务器、小型机、EMC 存储设备、Windows、Linux、Unix、AIX、Websphere 应用中间件、DB2 数据库、IBM MQ、IBM MB、华为网络设备等1000 多套软硬件基础设施以及行政审批、统计调查、数据分析、GIS、数据传输与交换等8 类应用系统。该监控软件提供了丰富的系统运行状态信息，对于实现应用状态分析、故障诊断及处理提供了基础工具，为日常的运维和管理提供了有力的支持。