一、序言

机房中,服务器等设备往往有数十台、上百台;有些大型机房,甚至达到了数百台、上千台。这些机房中,网络设备也很多,比如各种交换机,防火墙,路由器等等。对于专业应用领域的机房,通常还有其他的硬件设备,如广电机房中的卫星接收机、×××、编码器等各种工程机。

通常情况下,机房中的运维人员都是24小时轮流值班,运维工作基本都靠运维人员长期积累的工作经验进行。一般的运维人员,是无法在系统发生故障前,能够对系统的运营状况进行准确了解,而是在故障发生后,通过一线用户的投诉才能得知系统出现了故障。即使是运维经验非常丰富的工作人员,维护上百台的服务器等设备,并且要在系统发生故障前能够准确获取有用的信息,如果没有一套好的监控软件,也是会力不从心。

对于关键的系统,出现故障是十分可怕的事情。如果有一套系统,能够实时的监控系统的运营状况;并能在系统超过预警阈值后,能够准确的将信息通知到有关的运维人员,运维人员就能在故障发生之前,及时定位出故障潜在的原因并解决,系统就不会发生宕机现象。

这里有一个例子,某航天研究院有一天深夜通知我,说有一个系统出现故障,技术人员无法判断到底是哪台服务器出现问题。经过简单的了解后,我发现这套系统运行已经超过5年,期间没有进行过任何维护工作,因此,很有可能是当中的机器出现硬盘空间用完了。对系统进行进一步了解后,发现是数据库机器2T容量的硬盘空间已经全部用光。找到原因后,接下去的工作就比较明确了:将5年来的系统日志、数据库日志进行了删除;在对数据库进行必要的恢复工作后,对数据库中的历史数据进行了清理。数据库系统的硬盘使用空间一下子缩减到500G,整个系统恢复正常运行。

上述问题,如果能够事先部署一套系统实时监控软件,并且能够在这台服务器硬盘使用量达到80%时,将信息第一时间通知到技术维护人员。此后,技术人员只要在第二天上班时,简单的删除日志、清理下历史数据,系统就不会宕机,也无需做数据库恢复等需要专业人员操作的工作。

那些已经上线运营的系统,由于先前有严格的测试过程,一般情况下,引起系统出现不能正常运行的那些问题,不太会是非常深的、需要研发人员才能解决的问题。那些导致系统出现不能运行的问题往往会出现在比较浅显的、易发现,诸如磁盘空间不够、CPU超负载、内存使用超负载、网络流量超载,或者某个进程使用的这些资源超过预警值等方面。对于数量少的服务器,可以通过人工进行周期性的巡检,而对于数量庞大的设备群,就需要专门的实时监控软件,来帮助运维人员及时发现系统运行过程中出现的一些状况。

二、需求分析

2.1 技术现状

在服务器监控领域,市面上出现的监控软件分商业软件和开源软件。对市面上的各类软件进行比较分析和试用后,发现开源软件应用空间非常广泛,而且监测效果也非常好。

与商业软件相比,开源软件是源码公开的。对于专业的应用,可以进行定制化的开发。目前开源软件应用最广的监测软件有:nagios、cacti、Zabbix、mrtg等。每个软件的应用领域各有所长,nagios 适合监视大量服务器上面的服务器性能,大批服务是否正常, 重点并不在图形化的监控,最大的优点是集成了好几种报警功能,能够及时将预警告警信息发送给相关联系人。cacti 主要用来收集设备运行历史数据和制作系统使用过程中的图形化报表。zabbix能监视各种网络参数,保证服务器系统的安全运营;并提供柔软的通知机制以让系统管理员快速定位/解决存在的各种问题。对于需要在第一时间得到服务器及程序或者其他设备执行状况已经超过阈值的消息,nagios最为适合。

Nagios不仅能够做一些基本的监测和预警,而且能够进行深层次的监控和预警,还能够根据专业的需要开发定制监控脚本,来对特殊设备或特殊服务进行监控和预警。基本的监测包括:对服务器的硬盘空间、CPU、内存,对交换机的流量、端口使用情况的监测和预警;深层次的预警有:对某项服务如数据库的运行情况,web服务器tomcat的执行状况进行监控;对于如数据库表空间使用情况,是否出现了异常问题等可通过编写定制化脚本进行更加高级的监控。

2.2 用户需求

2.2.1设备分类

我们对机房中的系统进行分类,设备类型主要有服务器,交换机,防火墙,路由器,专业设备,UPS电源等。

2.2.2设备上下级关系

设备之间有平列的关系,也有上下级的关系。如在同一个VLAN内的服务器是平列的关系;而交换机与服务器之间,是上下级的关系。在进行监测时,用户可能需要了解上下游设备之间的关系。特别是在上级设备出现故障时,应该需要知道哪些设备当前处在不可监测状态。

2.2.3监测项

对服务器性能的监测项包括:CPU负载、内存使用情况、硬盘使用空间、硬盘IO性能、网卡吞吐量、登录服务器的用户数等;

对服务器上运行的程序的监测项包括:程序占用的CPU资源、占用的内存空间、程序进程是否存在、运行是否正常等;

对交换机的监测项包括:端口使用是否正常、流量是否正常、丢包率如何等;

对打印机的监测项包括:打印机是否在线、是否缺纸、卡纸、是否需要人工干预等;

对UPS的监控包括:UPS运行是否正常,充电量百分比情况,是在充电状态、放电状态、还是直接使用交流电等;

2.2.3告警信息通知

机房中的设备根据不同用途,会有不同的人员进行维护。对于一线人员,需要在设备出现预警后第一时间需要了解设备情况;对于层次较高的主任级人员,可能需要在设备出现严重问题时,第一时间需要了解设备情况;对于领导级人员,可能在平时工作时间需要知道设备严重的问题。

告警的通道也有好多种,一般使用email和短信通知比较普遍。不同的用户可以使用不同的告警通道。

因此,实时监测系统需要对不同设备、不同等级的告警,在不同的时间段,将信息发送给不同级别的人员。

另外,如果已经知道设备处于维护状态,也不能老是将告警信息发送给相关人员,因此监测系统还能够对这种处于维修状态的设备可配置不发送告警信息。

三、技术方案设计

Nagios的部署有单机部署、热备部署和分布式部署。对于网络比较简单,设备不超过100台,监测项不超过1000个的机房,建议使用单机部署。对于监测100台到500台设备,监控项低于5000个的机房,可以采用热备部署。而对于网络结构复杂,设备超过500台,跨业务跨地域的设备群,由于单机监控负载会过大,而且为了方便管理,建议使用分布式部署。

3.1 设计要点

Nagios监控使用C/S架构形式。服务器端安装Nagios服务器端软件,并在配置文件里配置需要的所有参数,这些参数包括被监控设备的设备组、设备属性(如服务器、交换机等设备类型、ip地址)、监控项(如CPU、内存、硬盘、IO)及阈值(如预警,报警),联系人组、联系人及属性(如email、手机号),发送通知的时间(24小时?工作日还是其他时间?),通知方式(email,短信)。

对于需要监控本地资源如CPU、内存、硬盘使用空间、系统服务等信息,需要在被监控的服务上安装插件。插件软件得知服务器需要参数值时,负责定时获取本地信息并将获取的信息发送给服务器。

对于公共的网络服务,可以不需要安装插件,Nagios服务器就能获得有用的信息。例如http、POP3、IMAP、FTP、SSH服务等。

Nagios服务器可通过CGI接口,以及Apache系统,给运维人员提供实时监测的WEB界面。为了让运维人员更加直观的看到整个机房的拓扑结构布局,Nagios可以根据设备定义的父子关系,展现这种关系。一般,交换机为“父”,交换机下面的服务器等设备为“子”。这种父子关系还能够级联。

在设计中,需要理清:

1,被监控的所有设备之间的关系;

2,被监控设备上哪些性能参数、哪些程序或进程的哪些信息参数需要监控;

3,监控参数的预警值和报警值;

4,发送通知的渠道,如email还是手机短信;

5,获取通知信息的人群;

6,获取通知信息的时间,如24小时,还是工作日还是某特定的时间;

3.2 拓扑图

p_w_picpath

3.3 硬件配置要求

对于单机部署的Nagios系统,只需要一台单独安装linux操作系统的服务器。服务器的性能要求视被监控的设备的数量以及监控项数量的不同而不同。

对于数量级别在200台设备,监控项不超过2000个情况下,可以配置IBM3550 M4,内存8G或同等级别的服务器。对于超过200台的设备,可以配置性能较高的IBM3650 M4,内存8G或同等级别的服务器。

短信报警:如果想要通过发送短信进行报警,则可以安装短信猫(项目初期也可以使用飞信进行报警);

Email报警:如果需要通过Email报警,则需要将nagios服务器连接到公网。

如果外网能够访问nagios服务器,则维护人员还可以实时登录到nagios服务器获取监测信息。

3.4监测范围

3.4.1 Linux服务器系统状态监测

通过在Unix或类Unix及linux下安装NRPE插件监测这类系统上的各种私有资源使用情况,包括CPU负载、内存使用率、硬盘空间使用率、IO性能、用户登录情况、进程执行情况等。

p_w_picpath

3.4.2 Windows服务器监测

通过在windows操作系统上安装NSClient++插件,Nagios就能够监测看windows系统上的各种私有资源使用情况,包括CPU负载、内存使用率、硬盘空间使用率、进程、服务执行情况等:

p_w_picpath

3.4.3网络打印机监控

通过使用check_hpjd插件可以监测支持JetDirect协议的打印机的各种状态,如缺纸、卡纸、离线、请求人员干预、调色剂低、内存不足等等。

p_w_picpath

3.4.4交换机/路由器监控

对于可管理的交换机/路由器(可管理的交换机/路由器指的是具有固定IP地址,并且支持SNMP协议的设备),Nagios可以通过SNMP协议获取到这些设备的有关参数。这些设备还包括防火墙、路由器,以及绝大部分支持SNMP协议的设备,如UPS等。

对于交换机、路由器或防火墙,可监测的数据包括报文丢失率、往返时间、SNMP状态信息、带宽、负载、端口状态等。

p_w_picpath

3.4.5服务器应用软件监测

服务器应用软件五花八门。对于WEB应用的服务器软件,开源软件有apache、tomcat、Nginx、jboss,付费软件有weblogic、websphere等。对于WEB应用,通常会有相关的数据库作为数据的存储,开源的数据库常用是mysql,付费的有oracle、sqlserver、db2等。这些软件一般都会注册到操作系统上,也可配置为随操作系统而启动。另外还有通过脚本直接启动的自定义软件。

对于这些软件,Nagiso都能应付自如。Nagios系统可以对这些软件进行常规的监测,如查看这些软件是否启动,是否能够登录,端口是否已经打开等。Nagios系统也可以编写自定义的监测脚本,对这些软件进行监测,如查看这些应用占用的系统资源,监测数据库表空间的使用百分比等。

3.4.6 UPS监控

对于特殊用途的设备,如UPS,如果设备本身不支持SNMP协议,可购买针对这类设备支持SNMP协议的专用监控硬件。Nagios可通过编写自定义的监控脚本,使用SNMP协议对这类设备进行实时监控。目前,已经实现使用Smart-UPS 3000 XL监控卡,对某些UPS设备进行实现监测。

3.5热备冗余部署

单机部署的系统,当Nagios主机出现问题时,监测就会终止。热备冗余部署就能够解决这一问题。

热备冗余系统部署后,正常情况下,主机负责对管辖范围的服务器及服务进行监测,并将预警和报警的通知发送给联系人员。当主机出现宕机或主机上的Nagios系统发生问题时,备机能够立即顶替主机的位置,承担监测服务器及各应用服务的工作,并对外发送预警或告警通知。当主机恢复正常运行后,监测和发送通知的工作由备机再次移交给主机。

以下为热备容灾部署的拓扑图:

p_w_picpath

以上拓扑图中,HostA为Nagios服务主机,HostE为Nagios服务备机。Nagios系统负责对Host B、C、D、F、G、H 6台服务器的监测工作。正常工作时,HostA负责监测和发送通知工作;HostE为休眠工作状态。当HostA发生问题时,由HostE接管监测和发送通知的工作。当HostA恢复后,监测和发送通知的工作由HostE移交给HostA进行,HostE再次回到休眠状态。

3.6分布式部署

对于公司服务器分布广,有多个独立的业务系统,且需要监测的设备有数百台、上千台时。一台监测系统往往满足不了监测需求;而如果独立的部署多套监测系统,管理上也会十分不便。在这种情况下,可以使用分布式监测系统。分布式监测系统拓扑图如下:

p_w_picpath

各分布式监测服务器承担其监测范围内的各种设备。并将监测的数据信息通过NSCA Client插件上传给中心监测服务器的NSCA Damon守护进程,并进一步将数据传给中心监测管理模块。中间监测管理模块判断各数据是否超过了阈值,如果超过阈值,则将预警或报警信息根据配置的规则发布给需要接收的人员。

3.7 报警系统

Nagios系统可以将监测的信息,及时发给相关联系人。发送告警信息的途径通常有:Email、短信、MSN、Web声音告警等。

接收通告的实体可以设置联系人组、告警时间范围。如某一组联系人在某个特定时间,接收符合某种规定的告警信息。

还可以设置在某几分钟之内,间隔多少时间发送一次;当超过一段时间后,间隔多少时间发送一次。如在出现问题的5分钟之内,每分钟发一次通告;超过5分钟后,每1个小时发送一次;当系统恢复后,再发一次系统恢复的告知信息。

3.7.1E-mail通知报警

Nagios系统可以通过Email发送告警信息给相关的联系人。当被监测的设备运行参数超过设定的阈值后,Nagios系统就能够将设定的告警信息,通过Email发送给联系人员。

要使用Email发送告警通知,Nagios需要连接外网,即Nagios服务器要有条件将信息通过Email,将告警通告发送到指定联系人的邮件中。

联系人要能够及时收看到Email邮件,现在最好的方式是申请手机@139.com的邮箱。当139邮箱有新邮件时,移动会发一条短信到联系人的手机上,这样,维护人员能够在第一时间得到有用的信息。

3.7.2手机短信通知报警

现在可以让飞信集成到Nagios系统上,但也要求Nagios系统能够连接飞信服务器。当备监测的系统出现故障时,Nagios就能通过飞信,将告警信息发送给相关联系人。飞信的优点是发送短信免费,但由于飞信发送短信的方式为网友自行开发,飞信官网不对此负责任,因此,可能会出现不能发送短信的问题。为了尽可能的避免出现短信在某时不能发送,可以让飞信在每天的某个特定时刻,发送一条短信到某个联系人,以验证飞信发送短信的功能是否正常。

市面上已经有了比较成熟的发送短信的方案,即通过短信猫发送短信,其缺点是需要收费。短信猫的原理跟手机类似,将SIM卡插到短信猫上,通过短信猫的串口或者USB口连到Nagios服务器上。当Nagios服务器监测到某设备发生故障后,可通过短信猫将信息发送给指定联系人。好一点的短信猫还可以插好几张SIM卡,可根据需要将短信通过不同的SIM卡发送给不同区域的联系人。

四、项目实施

4.1 需求调研

对于需要部署Nagios系统进行实时监测的项目,首先要明确需求,细化监测子项;细分联系人组,联系人,告警通道,通告发送的时间等。以下列出的几个表格可以在细化项目需求时参考。

表1 监测实体:  

监控项ID

监控项

预警阈值

告警阈值

实体ID

实体名称

实体类型

实体组

父实体ID

备注

00101

报文丢失率,

80%

90%

001

思科3560G交换机

交换机

交换机组

000

00102

往返时间

......

......

001

思科3560G交换机

交换机

交换机组

000

00201

Cpu负载

Cpu负载超过80%

Cpu负载超过90%

002

Http服务器

服务器

服务器组

001

00202

内存使用率

内存使用率超过80%

内存使用率超过90%

002

Http服务器

服务器

服务器组

001

00203

硬盘空间

硬盘空间超过80%

硬盘空间超过90%

002

Http服务器

服务器

服务器组

001

00204

Http服务

响应时间超过3秒

响应时间超过5秒

002

Http服务器

服务器

服务器组

001

00301

数据库服务

数据库连接响应超过1秒

响应时间超过3秒

003

数据库服务器

服务器

服务器组

001

双机系统需特殊处理

......

......

......

......

......

......

......

......

......


联系人  

联系人ID

联系人昵称

联系人组名称

联系人名称

Email

Phone

通告时间

备注

0001

Sandy

主任

张三

Zsan@126.com

13600010001

8:30am~18:00pm

0002

lillie

主任

王五

13600020002@139.com

13600020002

8:30am~18:00pm

0003

Alice

运维人员

李四

Lisi@163.com

13500030003

7×24小时

......

......

......

......

......

......

......

......


4.2系统实施

略。