基于Nagios的综合监视系统设计与实现

刘东君

( 中国气象局预报与网络司 北京 100081 )

0 引言

近几年，由于气象业务和公众服务需求的日益增长，气象信息网络系统得到快速发展，信息系统关系到气象业务运转的方方面面，已经成为气象业务稳定运行和未来发展的支撑和保障。其中的实时业务系统，即7*24小时不间断运行的业务系统，承担着气象数据的收集和处理、气象产品的生产和发布的重要工作，是气象信息业务运维部门重点关注和保障的对象。为了提高这些实时业务系统的可用性和服务水平，需要获取这些系统的运行状态信息，以便发现和处理系统故障、排除系统隐患、优化系统性能，从而更好地规划系统发展。因此，建立一套行之有效的监视系统，成为气象信息运维部门亟待解决的问题。

1 现状和需求分析

已提供实时监视的业务系统主要有：中国气象局骨干网、中国气象局Internet接入系统、全国气象宽带MPLS VPN和SDH主干系统、NOTES办公自动化系统、中国气象局电子邮件系统、域名系统、VPN系统、NTP系统等。监视手段大致分为三类：

（1）采用基于简单网络管理协议（SNMP）的第三方监视系统：通过SNMP协议管理工作站可以远程管理支持这种协议的网络设备，包括监视网络状态、修改网络设备配置、接收网络事件警告等，实现对网络设备和服务器硬件资源的监视。

（2）开通系统自带监视功能：通过直接访问和查询系统自带监视模块，获取运行状态信息，及时发现异常，如中国气象局电子邮件系统和NOT ES办公自动化系统。

（3）根据系统默认运行环境编写执行脚本程序：在系统运行后台或内部，通过编写并执行脚本程序或命令获取系统的实时运行状态信息，掌握系统运行情况，如NTP系统。

以上三种手段在不同的业务系统中得到应用，起到了一定的作用。但是由于技术和管理上的制约，多种监视手段未能集成在一个监视系统中，使得监视功能分散，各个业务系统根据需要分别建设监视功能模块（子系统），缺乏统一的规划和有效的管理机制，业务系统之间的连接成为监视的死角，查找定位问题源头较为困难，已有监视方式和手段已经不能很好适应业务发展的需要。除此之外，还面临着以下一些需求：

（1）对多厂商、多类型设备的支持：现运行的第三方的SNMP系统对新增设备的支持不灵活，特别是对于国内制造商的设备支持不够。

（2）对统一监视界面的支持：分散的监视方式和各自独立的监视界面使得业务管理人员频繁访问不同的系统，既给业务的监视带来不便，也不利于从整体结构和宏观上把握业务的运行情况。

（3）对多种监视手段的支持：随着已有系统的升级和新系统的不断出现，要求监视系统具有强扩展能力，来集成和提供更丰富的监视手段，以适应发展需要。

（4）对自定义动作的支持：除了故障报警之外，我们希望监视系统能执行更多的动作，比如：监视系统发现数据库进程异常中止了，在通知管理员之前，自动执行故障修复的操作：重启数据库进程。一旦修复成功就不再通知管理员，这样能够有效地缩减故障时间，提高业务系统的可用率。

2 技术选型分析

该系统的监视对象分为网络系统和应用系统两大类：

（1）网络系统：全国气象宽带网SDH和MPLS VPN主干系统、中国气象局骨干网、中国气象局互联网接入系统。

（2）应用系统：中国气象局NOTES办公自动化系统、中国气象局电子邮件系统、信息中心门户网站、域名系统、VPN系统、NTP系统等。

根据监视对象的特点和监视需求，我们确定了技术选型的主要原则：

（1）支持网络和应用的统一监视：网络监视包括对网络设备的运行状态和网络系统性能指标的监视，而应用监视主要针对应用进程运行状态、应用资源使用情况和应用关键性能指标进行监视。网络监视具有统一的标准，即SNMP网络管理协议，该协议得到网络设备制造商的广泛支持，通过SNMP协议能够获取网络设备的各种运行数据，目前，绝大部分的网络监视和管理软件都是基于SNMP协议来实现的，而应用监视没有统一的标准，实现技术特定于被监视的应用本身，对不同的应用采用的监视技术完全不同。为了实现网络和应用统一监视的目的，要求我们的系统既要支持实现网络监视的SNMP技术，又要支持各式各样的特定于应用本身的监视技术，因此，系统在设计和实现上不能仅仅基于某一种或几种特定的监视技术，而是要在系统架构上实现对任意多种监视技术的支持和融合。

（2）支持自定义的事件处理：监视系统在获取对象的运行状态信息后，根据对象的状态信息执行相应的事件处理程序，如通知系统管理员。事件处理程序将监视、故障处理和业务管理连接起来，扩展监视系统的功能，提高业务运行和维护的自动化水平。事件处理程序的功能和实现是自定义的，这要求监视系统提供灵活的接口来实现对各种事件处理程序的支持。

（3）支持集中式和分布式的工作方式：监视系统实时地采集和分析大量数据，系统性能对监视的效果有很大的影响。在监视大规模的网络系统和复杂应用时，系统需要快速地采集和处理海量数据，为了满足这种要求，监视系统需要在数据采集、数据处理等多个层面上同时支持集中式和分布式[1]的工作方式。

3 综合监视系统的设计

3.1 系统总体架构

系统由三层组成，由下至上依次为对象层、插件层和服务层，其逻辑结构如图1所示：

图1 系统逻辑结构图

各层的职责详述如下：

（1）对象层：该层由被监视的对象组成，这些对象可以是各种硬件设备，如服务器、存储、路由器、防火墙、IDS等；可以是各种软件实体，如操作系统、数据库、Apache、WEBSPHERE、自己开发的软件等；也可以是由硬件设备和软件组成的独立系统，如电子邮件系统、DNS系统、Notes系统等。系统对被监视对象没有限制，任意对象都能成为对象层中的一员。

（2）插件层：插件是完成一定功能的可执行的小程序，插件层是众多独立插件的集合。每个插件完成一项具体的监视任务，例如：为了监视设备之间的网络连通性，编写一个程序主体是调用系统PING命令的插件，则任意两台设备间的网络连通性就可以通过调用该插件来检测。插件的输出接口有一定规范，通过该接口将监视结果返回给服务层。对象监视功能的实现是由独立的一个个插件来完成，与系统的结构和实现机制没有关系。因此，一个对象的状态信息只要能够通过执行本地命令或小程序来获得，就可以编写一个插件来实现该对象的监视，从而将该对象纳入到综合监视系统中来。这种将监视功能抽象出来，由插件层中的插件来独立完成的机制，确保了系统对监视对象和监视技术的无限扩展性。

（3）服务层：服务层不负责具体的监视任务，但却为插件的执行和结果的展现提供通用服务，是整个系统的运行框架。该层的主要服务有调度执行管理服务、报警和事件处理服务、数据存储和访问服务、配置管理服务和前端展示服务，其中调度执行管理服务负责插件按照一定的时间间隔自动执行；报警和事件处理服务会根据插件层提交的监视结果执行预定的动作，如短信报警、故障进程重启等；数据存储和访问服务提供监视数据的处理、存储和访问；配置管理服务负责监视对象信息和执行流程信息的管理；前端展示服务负责结果数据的展现。

3.2 主动监视与被动监视

根据监视动作发起方的不同，将监视分为主动监视和被动监视。主动监视是管理端主动访问监视对象获取数据，即由综合监视系统主动发起与完成整个监视过程；而被动监视是由监视对象主动将数据推送给管理端，即由外部程序或应用完成监视过程，监视结果则提交给综合监视系统。大部分情况下，我们采用主动监视，被动监视则用于管理端因为某些原因不能主动访问监视对象的情况，如管理端安全级别低于被监视对象；也可用于被监视数据异步、无规律，不适合按固定时间间隔主动获取的情况，例如：监视IDS发现的入侵事件时，在一个时间间隔内入侵事件可能发生，也可能不发生，因此适合采用被动监视方式，在入侵事件发生时通知综合监视系统。

大部分的监视软件支持主动监视，但对于被动监视支持非常有限，一般仅能支持snmptrap。在本系统的设计中，增加专门的外部文件接口来支持被动监视，外部应用只需按照接口规定格式将监视结果数据写入外部文件接口，统一监视系统会定期读取外部文件接口中的数据，并根据这些数据执行预定动作。被动监视的执行过程如图2所示：

图2 被动监视

（1）外部应用完成对象的监视；

（2）外部应用将监视结果写入外部文件接口；

（3）综合监视系统定期读取外部文件接口中的所有被动监视提交的结果数据，并放入结果检测处理队列中，该队列同时存放被动和主动监视的数据；

（4）综合监视系统扫描队列中的数据并完成相应的动作。

被动监视的这种设计对被监视的外部应用没有任何要求，被动监视的支持范围不再受到限制，对于任意的trap、安全事件或外部应用都能得到很好的支持。

3.3 事件处理

事件处理用于在发现监视对象状态变化或异常时，执行一些特定的动作，例如：重启一个异常进程、自动填写工单启动故障处理流程、删除临时文件、切换并启动备份设备等。这些动作按照需要自己定义。

事件处理包含三部分内容，分别为事件处理命令、事件处理程序和事件处理配置项。其中事件处理程序是外部应用或可执行的程序，由它来最终完成实际的动作；事件处理命令是执行事件处理程序的命令；事件处理配置项用于将监视对象与特定的事件处理命令关联起来。当综合监视系统监测到对象状态变化时，会根据对象配置文件中的事件处理配置项找到对应的事件处理命令，并执行该命令来进行响应。事件处理功能为综合监视系统提供更多的功能，给用户和管理员带来方便和效率。

4 综合监视系统的实现

综合监视系统的实现是一个从理论模型设计到业务应用、由业务反馈来修定模型设计的逐步迭代的过程，是监视系统设计经验与气象信息业务现状和发展需求相结合的过程。

4.1 实现思路

系统运行在Centos5.x操作系统下，首先安装工具支持软件：perl、rrdtool、mysql、php、net-snmp等，然后安装nagios和centreon系统。Nagios是一个运行于Linux系统上的第三方监视软件，它功能强大、成熟稳定，有大量用户，不足之处就是web访问接口简单和基于文件的复杂的配置管理[2]。我们选择nagios系统作为基础运行框架，通过完善和增加功能来实现调度执行管理服务、报警和事件处理服务和数据存储和访问服务这三大核心服务模块。监视结果数据默认是存放在数据文件中，为了便于数据的管理和访问，采用数据转换程序将数据存放在mysql数据库中。由于nagios系统前台展现能力不足，在综合监视系统中我们采用centreon系统作为前台的核心。通过实现nagios和centreon系统的集成，并对centreon代码作进一步的修改、完善和汉化之后，综合监视系统能够提供状态和性能数据的直观展现和基于web方式的配置管理，这既弥补了nagios软件的不足，也为用户提供丰富的体验，为管理员提供高效便捷的管理方式。系统中的监视插件放置在插件运行目录下，每个插件都完成一项具体的监视任务。

系统启动后，会周期性的调用插件去检测被监视对象状态，同时维持一个队列，来存放插件返回的数据，系统每次从队首开始读取信息，根据该信息判断监视对象的状态，触发执行相应的事件处理程序，状态结果最后通过Web接口显示出来。

4.2 插件的开发

插件是综合监视系统的基础，是监视任务的具体程序实现。我们根据业务需求开发了大量的插件。这些插件功能各异，分别用于监视远程服务器的资源利用率、网络设备的运行状态、邮件服务收发功能是否正常、DMZ区服务器是否正常访问外网、集群节点的运行状态等等；规模大小不一，有的几行代码，有的几百，甚至上千行代码；支持的编程语言主要有C、Perl、shell。

插件的开发和使用步骤：

（1）编写插件：插件程序的退出代码必须为0、1、2、3中的任意一个整数，其中 0（OK）表示状态正常、1（WARNING）表示出现一定的异常、2（CRITICAL）表示出现非常严重的错误、3 （UNKNOWN）表示被监控的对象状态不明。

（2）注册插件：定义插件执行命令和路径。

4.3 网络设备和应用服务的监视

（1）网络设备的监视：在我们的业务网中，主要的网络设备包括路由器、交换机和防火墙。这些设备支持标准的SNMP网络管理协议。通过开发大量基于SNMP协议的插件，我们实现了监视现有网络设备接口运行状态、CPU和内存的利用率、设备模块的运行状态、风扇和电源的运行状态、路由条数、接口表等。

（2）应用服务的监视：对应用的监视需要在应用所在主机上安装中间代理。该代理负责接收监视请求、监视应用的实时运行状态，并将结果返回给综合监视系统[3]。根据应用的运行环境，实现方式上分为两种：

在Windows系统中，中间代理采用NSClient++，而与代理匹配的监视插件为check_nt；如图3所示。

图3 Windows平台

在Linux系统中，代理采用NRPE，匹配的插件为check_nrpe，如图4所示。

图4 Linux平台

4.4 监视结果展现

为了提高监视结果的展现效果，我们分析了监视系统的用户类型，针对不同的用户类梳理了相应的展示需求，在此基础上实现了三套具有不同展示重点和管理功能的支持多语言的展现应用，其中有一套专门用于图形化的实时展现。展现应用采用Perl实现后端进程开发、PHP实现前端页面开发、性能展现数据存放在rrd数据库中。

5 应用情况

综合监视系统已经投入业务应用，负责网络系统和重要实时应用系统的日常巡视和监视管理。目前，通过该监视系统实现了对129台设备和1689个服务的实时监视，提供监视的主要业务系统有：全国气象宽带网SDH和MPLS VPN主干系统、中国气象局骨干网络系统、中国气象局互联网络系统、全国NOTES办公自动化系统、中国气象局电子邮件系统、全国NTP校时系统、DNS系统、流量管理系统、文档管理系统等。

监视系统在业务运行过程中，多次及时发现系统异常和故障情况，为业务的稳定运行提供技术保障，取得良好的效果。

6 结束语

本文总结了实时业务系统监视现状，分析了存在的问题，提出了监视系统的发展方向，并详细阐释了基于Nagios的综合监视系统的设计、实现和应用情况。

下一步的工作重点是优化和完善该系统，同时，提供与其它业务管理系统的集成。

[1]Alwin Brokmann.Monitoring system and services.Computing in High Energy and Nuclear Physics,March 24-28 2003

[2]David Josephsen.Building a monitoring infrastructure with nagios.PRENTICE HALL 2007.2

[3]Wolfgang Barth.Nagios System and Network Monitoring 2006