【IT168 文档】a.snmp协议的配置以及在Linux下和Windows上的测试方法：

　　刚才我们已经用了不少的篇幅介绍了SNMP简单网络管理协议的基本原理。现在我们即将以Red Hat最新的企业版本Red Hat Enterprise Linux 5 Update 2(简称RHEL5u2)为基础来演示如何配置SNMP服务。

　　在RHEL5u2中提供了一个叫做net-snmp的rpm包，net-snmp是在IPv4和IPv6上执行SNMP的v1，v2和v3版本协议的一组程序。需要特意说明一下的是，由于在大多数环境下针对企业应用都会使用稳定版本的Red Hat Enterprise Linux操作系统，所以后面所有操作所使用的Linux平台也都是RHEL，但是那些对技术体验感兴趣的用户也可以使用Fedora 8或者9来实现上述所有的操作。

　　在该例子中，假设服务器192.168.1.10是被监测的系统，我们将在其上分别配置和启用基于v1和v3版本的snmp服务，而另外一台主机192.168.1.100充当管理工作站，并且用snmp命令来获得被监测系统的详细信息。

　　在服务器192.168.1.10上，首先配置v1版本的SNMP协议：

　　挂载DVD安装光盘，并从光盘中安装snmp相关的软件包：lm_sensor，net-snmp，snmp-utils。关于net-snmp包的作用刚才已介绍，而至于net-snmp-utils主要提供了使用snmp协议管理网络的一系列工具。

　　装完所需要的软件包之后，我们可以直接修改snmp的主配置文件/etc/snmp/snmpd.conf并重启服务来直接启用SNMPv1。采用SNMPv1版本的重要标志之一就是使网络管理设备访问代理时需要使用基于Community的团体的验证方式。这里的Community使用默认的public，当然也可以根据自己的需求去修改为任意一个字符串。完成之后保存该档并运行命令重启服务：

　　# service snmpd start

　　# chkconfig snmpd on

　　为了监测是否能够正确获得整个系统中每个MIB的OID值，可以运行snmpwalk命令以获得响应的结果，snmpwalk命令可通过snmp的GETNEXT动作获得MIB树上的管理信息。

　　# snmpwalk –v1 –cpublic 192.168.1.10

　　至此为止，被监测对象上的snmp就算配置完成。为了说明结果，我找了一个运行于Windows的操作系统上的利用snmp协议的监测软件来看看效果。在Windows平台上能够实现该功能的软件有很多，例如Whatsup，Solawins等等。这里以Whatsup为例，我的监测主机上操作系统选用的是Windows Server 2003 Enterprise Edition。IP地址是192.168.1.100。按照图示的步骤安装Whatsup软件，其实秉承Windows软件的安装风格——一路回车即可搞定。由于我安装的是一个30天的免费试用版本，所以需要在启动产品的时候选择“Activate Later”，并且在“Device Discovery Method”中选择“IP Range Scan”。之后起始地址都填入被监测设备的地址192.168.1.10，按照在/etc/snmp/snmpd.conf档中的内容输入团体名称“public”按照下图确定扫描内容并开始扫描，扫描时间需要根据设备的数量决定。在“Action Policy Selection”中选择“Do Not Apply an Action Policy”并结束扫描。最后通过“Report View”标签选择“Device Reports”并最终获得所有设备的Health状况。

　　在众多的性能监测软件中Whatsup的功能相对比较强大，而且设置方便，接口友好。在很多企业的服务监测中是一个不错的选择，而且Whatsup的其它视图模式和功能也比较多。至于其它的例如Solawins等类似的软件，在配置方面的步骤基本大同小异，所以这里就不花时间详述了。

　　然后配置v3版本的SNMP协议：

　　与v1版本的SNMP协议不一样，v3版本最重要的特征是更强的安全性，因为团体信息在网络上是以明文形式传送。因此v3版本不再使用团体信息来实现认证，而是采用对称或者非对称加密方式加密用户名和密码实现认证。所以安全方面自然要比v1版本的高很多，不过在配置方面也显然会比v1版本的更加麻烦。所幸的是net-snmp-utils工具包为我们准备了另外一个强有力的SNMP配置工具——net-snmp-config，因此一般用户仍然可以通过他非常方便地实现v3版本的SNMP配置。

　　我们先切换到光盘，由于net-snmp-config工具由net-snmp-devel包提供，所以在安装一系列依赖包包括beecrypt，elfutils-devel，elfutils-devel-static后，最后还是要安装net-snmp-devel包。之后将snmpd服务停止并备份其主配置文件，然后运行命令：

　　# net-snmp-config --create-snmpv3-user -A 12345678 -X 12345678 -a MD5 -x DES admin

　　关于这条命令的说明：

　　--create-snmpv3-user [-A authpass] [-X privpass] [-a MD5|SHA] [-x DES|AES] [username]

　　命令执行之后将自动建立新的配置文件snmpd.conf，而内容也十分简单。只有用户名和权限，而关于认证方式的信息则会存储在/var/net-snmp/snmpd.conf文件中。

　　最后重启snmpd服务，并再次用snmpwalk指明通过v3的认证方式获取MIB上的OID信息。

　　命令是：

　　# snmpwalk -v3 -u admin -l auth -a MD5 -x DES -A 12345678 -X 12345678 192.168.1.10

　　如果要验证配置的信息是否OK，还是可以通过Windows下的Whatsup来监测信息，步骤基本上和上例一样，只不过更改一下SNMP版本并填入相应的认证信息即可。

　　b.snmp + mrtg实现对网络负载的监测：

　　上述的操作方法是利用了一些闭源的商业软件在Windows下进行性能监测，对于一些经费充足的企业，这种方案不乏考虑的价值。

　　不过在了解了snmp协议的基本工作原理和配置方法之后，我们来看一下利用snmp在Linux操作系统上进行监测的解决方案。提到在Linux上的开源方案，不得不提及一个老牌的网络流量监测工具mrtg。

　　Mrtg(Multi Router Traffic Grapher,MRTG)是一个完全免费的监测网络链路流量负载的工具软件， 它通过snmp协议从设备得到流量信息，并将流量负载以包含PNG格式图形的HTML 文文件以Web页面显示给用户。Mrtg能够以非常直观的形式显示流量负载，而且在工作过程中所占用的系统资源很低。

　　下面我们将演示如何通过mrtg来获得以snmp协议所监测到的网络流量方面的信息，为了更好地说明在企业环境中的应用，我们会通过一台运行MRTG的网管工作站同时获取两台被监测服务器的网络流量信息来仿真企业对多台服务器的网络流量监测方式。

　　基本结构如下：

　　网管工作站：RHEL5u2 192.168.1.10

　　被监测主机1：RHEL5u2 192.168.1.100

　　被监测主机2：RHEL5u2 192.168.1.200

　　首先在被监测主机192.168.1.100和192.168.1.200上分别配置并开启snmpd服务(过程同上例)。为了简化配置我只使用上面的v1版本的SNMP配置方法。同时需要在开启服务之后关闭防火墙以及保证主机之间的连通性。

　　之后在网管工作站上安装并且配置mrtg。由于在RHEL5u2中mrtg是系统自带的软件包，所以可直接使用rpm安装。

　　# rpm -ihv mrtg-2.14.5-2.i386.rpm

　　安装完成之后需要运行命令cfgmaker针对两台被监测主机各自生成mrtg的配置文件，在该例子中配置文件分别是test1.cfg和test2.cfg，存放在/etc/mrtg目录中。

　　#cfgmaker --global "WorkDir: /var/www/html/mrtg" \

　　> --global "Options[_]: growright,bits" \

　　> --ifref=ip \

　　> --output /etc/mrtg/test1.cfg \

　　> public@192.168.1.100

　　#cfgmaker --global "WorkDir: /var/www/html/mrtg" \

　　> --global "Options[_]: growright,bits" \

　　> --ifref=ip \

　　> --output /etc/mrtg/test2.cfg \

　　> public@192.168.1.200

　　上述的命令定义了生成配置文件test1.cfg和test2.cfg的全局参数，包括配置文件的主目录，页面存放的主目录，snmp团体信息和建立绘图时指定绘图方式的一些必须参数，如绘制向右方增长的统计图和统计图的计量单位等。

　　之后执行下面的命令将两个配置文件的内容合并到主配置文件/etc/mrtg/mrtg.cfg里面。

　　# cat test1.cfg >> mrtg.cfg

　　# cat test2.cfg >> mrtg.cfg

　　并根据配置文件的需求在/var/www/html目录下建立mrtg页面的主目录：

　　# mkdir /var/www/html/mrtg

　　以及针对mrtg.cfg配置文件运行命令来启动mrtg，注意，在默认的UTF-8语言字符集下这个启动命令无法执行成功，因此需要设置语言环境变量为env=C：

　　[root@localhost mrtg]# env LANG=C /usr/bin/mrtg /etc/mrtg/mrtg.cfg

　　该命令需要执行三次以建立正确的mrtg数据库文件。

　　最后要做的工作是按照配置文件内容在mrtg页面的主目录下生成正确的index檔，命令如下：

　　# indexmaker --output /var/www/html/mrtg/index.html \

　　> --title=MRTG \

　　> /etc/mrtg/mrtg.cfg

　　同时也要按照mrtg.cfg的配置修改和启动apache并最终为mrtg能够定期进行数据采集建立一个每五分钟执行一次的任务计划：

　　# cat /etc/httpd/conf/httpd.conf | grep DocumentRoot

　　DocumentRoot "/var/www/html/mrtg"

　　# service httpd start

　　# chkconfig httpd on

　　# crontab -l

　　*/5 * * * * /usr/bin/env LANG=C /usr/bin/mrtg /etc/mrtg/mrtg.cfg /dev/null 2>&1

　　在启动apache之后，即可以在网管工作站或者是任何可以访问到192.168.1.10的主机上以http://192.168.1.10的方式打开MRTG的页面。可以很直观地看到两台主机的流量页面以及详细信息。

　　c.SYSSTAT + mrtg实现对服务器各种性能参数的监测：

　　一些读者可能会有这样的疑虑：既然我们已经能够通过snmp + mrtg得到网络流量的监测情况，那么如果要实时监测服务器的其它系统参数应该怎么办?这个问题的答案比较遗憾：由于MRTG是一个专门针对网络流量进行监测和绘图的工具，所以默认情况下不提供对系统其它方面信息监测的功能。因此尽管SNMP协议本身可以获得和显示被监测主机上的大量信息但是鉴于MRTG方面的限制而无法显示和显示出来。

　　但是好在天无绝人之路，MRTG本身实际上也是一个强大的数据采集和绘图引擎。于是我们可以利用一些SNMP以外的系统监测工具来实时获取服务器性能信息，包括CPU，内存，磁盘空间使用率以及I/O性能方面的内容，然后交给MRTG来获得我们所需要的其它类型的统计图信息。

　　在清楚了MRTG原理之后，这样做实际上会拥有更大的灵活性。但是由于涉及的内容需要一定脚本编程的知识，所以对一些高级用户是比较适用的。

　　下面我们就举例说明如何将MRTG和SYSSTAT所提供的一系列如sar，iostat以及free等性能监测命令等进行结合来获得系统其它方面的统计信息的配置方法。

　　由于这次网管工作站已经不可能再通过SNMP获取信息，所以我们将环境更改一下，在被监测主机直接安装和配置MRTG，并且结合sysstat一类的系统工具来绘制本机的信息图：

　　此时假设被监测主机的操作系统是：RHEL5u2，IP地址是192.168.1.100

　　Sysstat是在RHEL5u2中自带的一个综合性能监测工具包。其中包括了sar(主要用于cpu，内存方面的信息统计)和iostat(存储设备I/O统计工具)。由于sysstat是系统本身自带的包，所以在两台被监测的主机上分别挂载光盘安装sysstat即可。当然除了sysstat还有一些其它的系统性能显示方面的工具可以使用，我们会分别举例。

　　# rpm -ihv sysstat-7.0.2-1.el5.i386.rpm

　　同时还要分别在被监测的主机上安装mrtg。

　　# rpm -ihv mrtg-2.14.5-2.i386.rpm

　　在正式开始之前，需要花一点时间来介绍一下sar和iostat的基本功能：sar是一个强大的系统监测工具，默认只显示CPU的使用情况，而通过加上不同的参数sar可以显示大量的内存以及I/O使用方面的状况和信息;而iostat主要显示I/O使用方面的信息。如果执行sar不加任何参数通常会显示下面这些信息：

　　其中sar的命令显示内容包括了：

　　 其中iostat命令显示内容包括了：

　　另外sar可以通过增加时间参数来指定执行的频率以及输出的内容量，例如命令是sar –u 5，则表示每5分钟显示一次CPU的使用情况。这样就利于我们将该命令写入到一个脚本/var/www/mrtg/mrtg.cpu中。在执行之前需要首先赋予其执行权限，然后为了监测该脚本是否有语法错误，可以执行该脚本测试。如果显示信息正确，则可以将其嵌入到自建的监测CPU的mrtg配置文件mrtg.cfg.cpu中。当然这个时候本机Apache的访问主目录也要更改为/var/www/html/mrtg并重启apache服务。之后运行命令三次以启动mrtg：

　　# env LANG=C /usr/bin/mrtg /var/www/mrtg/mrtg.cfg.mem

　　最后别忘了建立存放页面的目录，进入该目录中，将localhost.html更名为index.html以及类似上面的例子增加一个每五分钟运行一次的计划任务。此时在任何一台工作站上通过浏览器访问页面http://192.168.1.100/cpu就可以看到192.168.1.100的CPU使用情况。

　　按照上面的方法，对内存使用情况的监测也大同小异：

　　可以使用sar –r选项来显示内存使用情况。同样将该命令写入到一个脚本/var/www/mrtg/mrtg.mem中去，并给予执行权限。在测试执行正常之后即可将其嵌入到自建的监测内存的mrtg配置文件mrtg.mem.cfg中，执行命令# env LANG=C /usr/bin/mrtg /var/www/mrtg/mrtg.cfg.mem三次，并建立存放页面的目录，将localhost.html更改为index.html，并建立类似上面的计划任务。完成之后从任何一台工作站通过浏览器都可以访问页面http://192.168.1.100/mem来查看该主机的内存使用情况。

　　接着按照上面的例子，来建立磁盘读写情况的监测：

　　由于原理一致，方法接近。我就不再赘述，只是会将基本的过程和需要的脚本内容给出来：

　　# cd /var/www/mrtg/

　　建立监测脚本及其内容：

　　赋予权限：

　　# chmod 755 mrtg.disk

　　测试执行情况：

　　建立配置文件及显示其内容：

　　建立主页面主目录：

　　[root@localhost mrtg]# mkdir /var/www/html/mrtg/disk

　　运行mrtg：

　　重命名index檔：

　　建立任务计划：

　　重启httpd服务：

　　完成之后从任何一台工作站通过浏览器都可以访问页面http://192.168.1.100/disk来查看该主机的磁盘读写效率情况。

　　到此为止我们基本上对mrtg在各方面的功能已经有了一个比较全面的认识。而且针对其配置和管理方法也有了一个初步的了解。相信在企业中会有更多的朋友能够藉助手工定制的方式来灵活发掘和获取mrtg在其它方面更多的功能和特性。

　　d.更加强大和灵活的性能监测方案：SNMP + Cacti + RRDtool

　　通过对MRTG这个软件的使用很多用户不难发现。像MRTG这样的软件尽管有系统资源占用少和低成本等方面的优点，其实也存在着一些功能方面的限制：

　　例如MRTG本身只是通过SNMP协议来监测网络流量的一个工具软件，所以在设计上并没有考虑到提供足够的和SNMP协议结合的功能以实现对服务器其它方面的性能参数进行监测。简单的说，SNMP获得的信息尽管足够全面，但是MRTG默认的配置方式只能对其网络信息作监控，这样对于SNMP协议来说就有点大材小用之嫌。

　　所以如果要实现对SNMP所获得的更多信息进行统计就必须要像上面那样手动定制脚本并将获取的数据指定到MRTG配置文件上。这实际上只是利用MRTG来做一个信息采集与绘图的软件。这种操作给我个人的感觉似乎有些不伦不类，况且手动定制脚本尽管的确可以拥有一定的灵活性，但这对于一些初级用户来说还是存在一些技术上的困难。另外如果这样的结构扩展到拥有多个服务器的网络中，就需要在每一个服务器上都要部署同样的架构来实现多台服务器同步监测，显然工作量就显得比较大了。

　　另外mrtg的数据库是一种文本式的数据库，一般数据不能重复使用，只能画出两个DS(一条线，一个块)并且缺乏管理功能。

　　能否有一款方案能够完全利用SNMP协议中众多的MIB和OID信息绘制出内容综合全面而且接口美观的系统性能分析图表呢?答案就是现在即将出场的RRDtool和Cacti。

　　RRDtool其实和mrtg是同一家族, 主要目的都是产生time-series的图文件(如流量，负载，温度......)。不过因为mrtg当初的考虑是画两种资料在图上(或四个值)，原作者觉得这样的功能十分不足，所以后来另外又开发了Rrdtool。

　　RRDtool本身可和mrtg结合，但其结合基本上仅在于将mrtg的文字文件的log转成rrd储存格式，使用rrd存储格式，数据能重复使用，例如可以将一个rrd文件中的数据与另一个rrd文件中的资料相加;可以定义任意时间段画图，即你可以画出一张半年以来的数据的图，也可以画出一张半小时以来的图;能画任意个DS;CDEF也可以任意定制。所以 RRDtool 变成了几乎最终也是最好的选择。但由于RRDTool的指令非常复杂，对于使用者来说显得非常的麻烦，而且RRDtool作为一个强大的绘图引擎缺少mrtg那种数据采集功能。

　　幸运的是有一套软件Cacti的发展就是基于让RRDtool使用者更方便使用该软件，除了基本的SNMP流量跟系统信息监测外，Cacti也可外挂Scripts及加上Templates来作出各式各样的监测图。

　　Cacti其实是一套php程序，它运用snmpget采集数据，使用RRDtool绘图。使用Cacti能统计网络设备的流量、CPU、系统负载等参数，也可以自定义监测的指标。它的界面非常漂亮，能让你根本无需明白RRDtool的参数能轻易的绘出漂亮的图形。更难能可贵的是，它提供了强大的数据管理和用户管理功能，一张图是属于一个host的，每一个host又可以挂载到一个树状的结构上。

　　RRDtool与Cacti配合的工作流程如下：

　　Cacti会通过SNMP定时采集并存储被监测设备的各种数据信息，而这些数据信息会被以rra文件形式存储在Mysql数据库中。如果当用户需要查询这些数据信息的时候会通过Cacti将请求提交给Mysql数据库来查找设备对应的rra文件名称，并同时通过RRDtool绘制流量图以及返回给用户。

　　用户的管理上，作为一个开源软件，它可以做到为指定一个用户能查看的“树”、host、甚至每一张图，还可以与LDAP结合进行用户的验证，可以说，Cacti将RRDtool的所有“缺点”都补足了!

　　有关于Cacti和RRDtool方面的更多信息可以访问其官方网站：

　　http://www.cacti.net/

　　http://oss.oetiker.ch/rrdtool/

　　下面我们将通过一个实际的例子讲解如何在企业中部署SNMP + Cacti + RRDtool。

　　操作的环境：

　　监测主机IP地址是192.168.1.200，RHEL5u2系统，这里也称为Server或者网管主机(工作站)

　　被监测主机IP地址是192.168.1.220，RHEL5u2系统，这里也称为Client

　　由于这些都是系统光盘中自带的Red Hat官方提供的包。所以挂在光盘后执行rpm –ihv就可以逐一装上。

　　在安装完成之后，配置并开启本机的SNMP。简单起见我仍然只开启V1版本的SNMP，由于在上面说明SNMP配置原理的时候已经有了具体步骤，所以这里就不再赘述。

　　在SNMP服务启动之后可以下载和编译rrdtool以及cacti。

　　从以下站点下载这两个软件：

　　cacti：http://www.cacti.net/downloads/cacti-0.8.7b.tar.gz

　　rrdtool：http://oss.oetiker.ch/rrdtool/pub/rrdtool-1.2.28.tar.gz

　　目前这两个软件的版本都是最新版本。

　　首先将这两个软件拷贝到/usr/local目录下，然后分别按照下面的步骤对其进行解压，编译以及安装。

　　为了保证编译能够顺利进行，需要预先在系统中安装gcc编译器等开发工具包。

　　至于cacti，将其解压后把整个目录拷贝到/var/www/html目录下并重命名为cacti。

　　下面我们需要为cacti创建所需的数据库，这也是当时安装mysql-server的原因。

　　先启动mysql服务，并且指定mysql管理员的账号以及密码，然后以新的用户名和密码重新登录mysql数据库。

　　下面的操作是在mysql的交互接口下进行。首先需要通过T-Sql语句建立cacti数据库，然后为方便管理，需要给root以及cactiadmin用户授予所有管理权限，并且定义cactiadmin用户的密码。完成之后退出交互接口，并且将cacti预先定制的cacti.mysql文件导入到mysql中去。

　　这时再通过交互接口进入mysql之后就可以看到刚才所导入的cacti预先定制好的表了。

　　接着按照刚才导入到数据库中的内容用vi编辑器修改cacti管理接口的配置文件：

　　# vi /var/www/html/cacti/include/config.php

　　修改的内容如下：

　　由于我们需要定制cactiadmin通过SNMP定时到被监测设备中获取数据信息，所以要建立cactiadmin用户并以该用户的身份建立一个任务计划。

　　同时指定下面两个目录的属主是cactiadmin

　　# chown -R cactiadmin /var/www/html/cacti/rra /var/www/html/cacti/log

　　之后我们需要安装一个叫做cactid的东西，这个所谓的cactid是cacti的数据收集器的守护进程。

　　安装和配置的方法也很简单。

　　最新的cactid版本是0.8.6k，可以从该地址获得：http://mirrors.rootservices.net/cacti/cactid/cacti-cactid-0.8.6k.tar.gz

　　下载之后将其放到/usr/local目录下：

　　然后按照下面步骤进行编译安装：

　　为了保证编译成功，还需要下面的几个软件：

　　在该软件编译完成之后，在/usr/loca/目录下会自动建立cactid目录，进入该目录修改etc/cactid.conf档，修改之后的结果如下：

　　并且将该文件复制到/etc目录下。

　　# cp /usr/local/cactid/etc/cactid.conf /etc/

　　最后配置HTTP服务，只需要将网站服务的主目录指向/var/www/html/cacti然后重启httpd服务即可：

　　DocumentRoot "/var/www/html/cacti"

　　完成之后可以在监测主机上开启一个浏览器并且直接访问http://192.168.1.200，由于已经将cacti设置为网站的主目录，所以上述的配置一切正常的话可以获得一个cacti的初始安装页面。点击“Next”之后开启下一个页面准备安装cacti。在出现的页面中如果确认所有信息无误则选择“New Install”并进入下一步。在新出现的Installation guide页面中cacti会自动探测原先安装到一些基本文件的位置。在这里需要确保安装程序能够找到所需要的所有文件和信息。针对第一个地方出现的“RRDtool binary path not found”的情况，需要手动更改一下路径为：/usr/local/rrdtool/bin/rrdtool，并点击“Finish”。

　　在接着出现的新页面中输入用户名和密码。此处默认的用户名和密码都是admin。进入之后cacti会强制用户更改密码，为了简化起见，我这里仍然更改为123456并保存密码。在当前页面点击console卷标之后点击setting按钮并选取path卷标，在该页面上需要指定“Cactid Poller File Path”，这里就是cactid程序的绝对路径/usr/local/cactid/bin/cactid，同时确认其它的RRDtool required path的设定是正确的，保存该配置。到此为止，整个cacti主页面的全局设置就基本完成，最后开启添加要监测的目标服务器。点击“Console”然后点击“Create”标签下面的“New Graphs”按钮以及在出现的页面上点击“Create New Host”进入建立被监测服务器的页面，按照下面的页面来添加被监测系统的信息，其中包括：描述(可随便填写)，主机名称(IP地址)，监测的主机类型(Local Linux Machine)，SNMP版本(V1)和与之对应的埠号(161)与团体信息。最后点击“Create”。

　　但是由于我使用的是RHEL5u2系统上自带的firefox 3浏览器，在这个时候会出现一些问题。如图，提示“由于密码不符，该设备无法建立”，但事前我们并没有设置过任何密码。这其实是在该版本的cacti上的一个bug而已，在RHEL系统上尤其针对比较新的firefox3浏览器，当提交到该页面的时候由于一些缓存方面的影响而导致无法最终完成该步骤。不过解决的方法也很简单。就是使用IE系列浏览器或者版本比较低的firefox浏览器来访问，那么在做到该步骤的时候就可以正常完成配置。

　　在该步骤完成之后可以看到默认的配置将会监测目标主机的内存、负载、登录用户以及CPU方面的信息。而用户完全可以在“Add Graph Template”以及“Add Data Query”处添加更多的监测类型。并选择右边的“Add”，最后将配置保存并切换到“Graph”标签下复选需要监测的参数类型，一般着重选择的内容包括CPU，内存，Swap分区，Buffer缓冲区，网络流量，磁盘使用量以及登录用户等。完成之后在“Graph”的“Preview”卷标中即可获得动态的统计图信息。由于我选的内容太多，所以在当前页面无法全部显示出所有统计图来，只能一个个项目点击进去。

　　和Mrtg类似，每一个项目的监测统计都有5分钟、30分钟、2小时和1天为计算单位。所以从各种统计图来看，即可获得一个参数当前的信息，又可获得相对长久的信息便于比较。

　　而作为被监测主机，其实需要配置的内容只有两个：第一，修改SNMP配置文件并启动服务，使之与网管主机的SNMP版本和认证方式一致;第二，确保网络连通性以及确保网管主机能够通过snmpwalk获得被监测主机上的全部MIB内容。由于配置方法和上面的例子一样，只要从监测主机上将其已经修改过的snmpd.conf配置文件拷贝到/etc/snmpd目录下覆盖原有配置文件，然后启动snmpd服务并关闭防火墙就行了。当然可以分别在监测主机和被监测主机上运行命令来测试：

　　# snmpwalk –v1 –cpublic 192.168.1.220

　　如果能够获得所有的MIB信息，则证明客户端的配置没有问题，所以这里也不再赘述。

　　到此为止Cacti + RRDtool的结构就已经配置完成，相对于Mrtg而言，Cacti + RRDtool的方式有一个更大的好处就是利于用户时刻调整监测的对象。例如，用户需要调整当前的监测内容并新增一些监测项目。那么就可以随时编辑监测设备并修改需要监测的参数，相当方便。同时Cacti + RRDtool提供了在Mrtg上不具备的管理功能，以及Cacti的绘图功能相对更强大，图像更加美观。

　　尽管第一次部署网管主机比较复杂，但是后续对配置对多个设备的集中监测就相对简单多了。可以说是一劳永逸。

　　这些都是这种结构尽管在配置方面略显复杂，但是越来越受欢迎并在企业中广泛应用的原因。和Mrtg一样，Cacti和RRDtool也是一个目前在企业中越来越广泛应用的开源监测方案。

　　e.企业级性能监测方案：Nagios

　　在大多数情况下Cacti + RRDtool已经实现对系统各种参数的监测。但一些要求更高更严格的企业可能不满足于仅仅监测系统基本参数的需求，而是需要监测除基本参数之外的各种应用程序的运行状况。很显然在这种情况下对于一些系统或者是自定义的程序Cacti + RRDtool的局限性就显示出来了。而此时就轮到了另外一种监测系统的登场。这就是我们现在要介绍的Nagios。

　　Nagios是一个功能非常强大的开源的系统网络监测程序，通过访问http://www.nagios.org可以了解其基本特性。Nagios不但能够实现对系统CPU，磁盘、网络等方面参数的基本系统监测，而且还能够监测包括SMTP，POP3，HTTP，NNTP等各种基本的服务类型。另外通过一些插件的安装和监测脚本自定义用户可以针对自己的应用程序实现监测，并针对大量的监测主机和多个对象部署层次化的监测架构。而且在监测信息统计方面，Nagios也能够和例如Cacti等程序结合来提供动态统计图表。除此之外Nagios拥有强大的日志管理系统，可以实现详细的日志记录以及回卷。最难能可贵的是Nagios提供了优秀的事件报警功能，能够将一些突发的事件以电子邮件的形式通知管理员并能够针对出现的问题提供一些主动的解决建议和方案，并支持冗余监视。

　　相对于Mrtg以及RRDtool + Cacti而言Nagios最大的特点之一是其设计者将Nagios设计成监测的管理中心尽管其功能是监测服务和主机，但是他自身并不包括这部分功能的代码，所有的监测、监测功能都是由相关插件来完成的，包括报警功能。Nagios自身也没有报警部分的代码和插件，而是交给用户或者其它相关开源项目组去完成。对于Nagios这个监测中心来说，细致的工作必然是交给其它的软件来实现。

　　下面我们就开始实施Nagios的基本安装和配置。

　　我的操作环境是：

　　监测主机：IP：192.168.1.10 操作系统：RHEL5u2

　　被监测主机：IP：192.168.1.220 操作系统：RHEL5u2

　　Nagios的所有软件包可以从其官方网站获得http://www.nagios.org/download/。这里无论是基本软件包还是插件我都使用的最新版本。因为我使用的操作系统是Red Hat最新版本，所以自然要好马配好鞍。

　　首先在监测主机也就是192.168.1.10上安装Nagios的基本软件包，在安装Nagios之前首先需要保证系统中有下面这些软件包：Apache，gcc，gd，gd-devel，glibc，glibc-devel。可以用rpm –qa | grep的方式去逐一检查。

　　如果确认上面这些包都安装之后需要先建立Nagios的用户和nagcmd组：

　　并将nagios以及apache用户加入到nagcmd组中

　　完成之后将下载的nagios压缩包拷贝到/usr/local目录中，并且执行下面的步骤进行编译和安装：

　　首先初始化和建立编译的环境

　　# ./configure --with-command-group=nagcmd

　　如果能看到下面的基本配置信息则说明初始的环境已经成功配置完成：

　　*** Configuration summary for nagios 3.0.3 06-25-2008 ***:

　　General Options:

　　Web Interface Options:

　　之后按照提示执行命令来进行编译：

　　# make all

　　如果编译过程顺利完成，则需要执行下面的命令：

　　分别用于安装二进制文件、初始化脚本、示例配置文件和设置目录权限。

　　# ls /usr/local/nagios

　　安装完成之后，在/usr/local/nagios目录下如果能够看到这些目录：bin etc sbin share var就表示Naigos安装成功了。

　　不过在完成之后还不能启动Nagios，因为还有一些操作需要执行。

　　Nagios的样例配置文件默认安装在/usr/local/nagios/etc目录下，这些样例文件可以配置Nagios使之正常运行，只需要做一个简单的修改。用你擅长的编辑器软件来编辑这个/usr/local/nagios/etc/objects/contacts.cfg配置文件，更改email部分，在nagiosadmin的联系人定义信息中的EMail信息为你的EMail信息以接收报警内容。

　　# vi /usr/local/nagios/etc/objects/contacts.cfg

　　之后执行下面的命令来安装Nagios的WEB配置文件到Apache的conf.d目录下：

　　# make install-webconf

　　在Apache中使用基本认证的方式创建一个nagiosadmin的用户用于Nagios的WEB界面登录。记下你所设置的登录口令。该用户登录口令和账号信息会存储到/usr/local/nagios/etc/passwd.users文件中

　　# htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

　　在Nagios主程序安装之后会自动将相关apache配置文件放到/etc/http/conf.d目录下，文件名是nagios.conf。文件内容如下：

　　这就意味着只有通过认证用户才可以通过http访问/usr/loca/nagios/share以及/usr/local/nagios/sbin目录下内容。也就是nagiosadmin，之后可以重启apache来应用配置：

　　刚才已经提到Nagios主程序只是一个控制中心，而能够起到服务监测和系统监测等功能的是Nagios插件，没有插件的Nagios系统只是一个空壳。因此在安装了Nagios平台之后需要安装插件。

　　Nagios插件同样是在其官方网站下载，目前版本是1.4.12。我将下载的源码包放到/usr/local目录下，按照下面的步骤进行解压，编译和安装：

　　然后把Nagios加入到服务列表中以使之在系统启动时自动启动：

　　执行下面的命令来验证Nagios的样例配置文件：

　　# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

　　如果最后的结果类似下面而没有报错，可以启动Nagios服务：

　　之后可以在浏览器上访问http://192.168.1.10/nagios，如果能够正常看到页面，证明主程序和插件都安装和配置成功!点击“Service Detail”的链接来查看你本机的监视详情。此时可能需要给点时间让Nagios来检测你机器上所依赖的服务。

　　实际上在装完Nagios之后此时网络监控工作只是刚开始，毫无疑问用户的需求不是只监控本地系统，而是大量的远程服务器上的系统状况以及服务运行状况。

　　有几种不同方式来监控远程Linux/UNIX服务器的服务与属性。一个是应用共享式SSH密钥运行check_by_ssh插件来执行对远程主机的检测。这种方法会导致安装有Nagios的监控服务器产生很高的系统负荷，尤其是要监控成百个主机中的上千个服务时，这是因为要建立SSH连接的总开销很高。

　　另一种方法是使用NRPE外部构件监控远程主机。NRPE外部构件可以在远程的Linux/Unix主机上执行插件程序。如果是要象监控本地主机一样对远程主机的磁盘利用率、CPU负荷和内存占用率等情况下，NRPE外部构件将非常有用。

　　提到“外部构件”这个概念的时候需要说明一下，Nagios有许多"外部构件"软件包可供使用。外部构件可以扩展Nagios的应用并使之与其它软件集成，而且能够通过WEB接口来实现管理配置文件，监控远程主机(*NIX，Windows等)，对远程主机的强制监测，减化并扩展告警逻辑等功能。

　　NRPE是一个可在远程Linux/Unix主机上执行的插件的外部构件包。如果你需要监控远程的主机上的本地资源或属性，如磁盘利用率、CPU负荷、内存利用率等时是很有用的。像是用check_by_ssh插件来实现的功能一样，但是它不需要占用更多的监控主机的CPU负荷，所以当你需要监控大量的主机时这个构件将起到很重要的作用。通过该图可以看出，我们需要在被监测主机上部署NRPE，他相当于一个daemon负责监听。而监测主机使用check_nrpe并通过SSL连接访问这个daemon，然后调用被监测方的check_disk，check_load等脚本获取信息并将结果传递到监测主机。同时这些脚本也有能力监测到其它主机的相关信息。

　　NRPE的使用环境有direct check和indirect check两种，direct check指的是NRPE运行在被监测主机的本地，而indirect check意味着运行NRPE的服务器只是一个中间人，他会继续通过刚才所提及的脚本来监测其它更多远程主机上的服务和系统信息。层次化的监测就是通过这种方式来实现。

　　为了简单说明问题，我们将要部署基于direct check的环境部署NRPE。所以下面的操作在被监测主机192.168.1.220上进行。

　　首先要建立Nagios账号，这里我使用同样的密码：

　　之后按照和上面相同的步骤来编译和安装nagios-plugin软件：

　　然后对相关的目录设置权限和所属用户组：

　　接着NRPE包放到/usr/local目录下，按照下面的步骤解压缩，并且编译和安装：

　　同时安装NRPE的插件、进程以及进程范例配置文件。

　　接着执行命令将nrpe安装为依赖xinetd超级进程的非独立服务，那么前提必须安装xinetd。不过一般系统都会自动安装该服务。

　　最后执行下面的命令将NRPE安装为xinetd超级进程所管理的进程之一。

　　# make install-xinetd

　　完成之后需要编辑/etc/xinetd.d目录下的nrpe文件，并且在最后添加允许实施监测的主机IP地址，这里是192.168.1.10，那么配置文件全文如下：

　　然后修改/etc/services档，并添加下面的内容：

　　现在最关键的一步是确保安装的NRPE进程能够正常工作，所以要使用check_nrpe插件进行测试。在监测主机192.168.1.10上执行命令：

　　# /usr/local/nagios/libexec/check_nrpe -H 192.168.1.220

　　如果能够出现如下的版本号显示，则证明在被监测主机上配置的NRPE已经正常工作，并且监测主机能够通过SSL与被监测主机上的NRPE正常通信。

　　NRPE v2.12

　　但是如果出现一些error信息，则需要检查配置，检查的内容包括主要有下面几项：

　　1.nrpe的版本号和nrpe-plugin的版本号是否一致。版本不一致极有可能造成该问题。

　　2.SSL是否被关闭。确保NRPE以及check_nrpe插件在编译的时候都加入了SSL支持，同时在运行时都开启SSL。不过一般编译过程中默认都会假如支持SSL选项。

　　3.确保NRPE的配置文件nrpe.cfg文件可以被nagios用户读取并且nagios用户可以执行nrpe二进制程序。

　　4.确认在/etc/xinetd.d/nrpe文件的“only_from=x.x.x.x”中x.x.x.x是访问NRPE的监测主机的IP地址。

　　NRPE的配置文件/usr/local/nagios/etc/nrpe.cfg中实际上已经包含了一些对系统进行监测的命令。由于NRPE安装在本地，这些命令可以直接协助NRPE从被监测主机获取系统和服务运行状况，而且都是在刚才通过nagios-plugin安装的。

　　如果从监测主机上运行这些命令进行监测，一切正确可以看到下面的效果。那么不难看出其中的奥妙——实际上完全可以利用在/usr/local/nagios/libexec/中的各种脚本并添加各项参数定制自己的监测内容。

　　那么到此为止我们就完成了在远程被监测主机上安装和配置RNPE的任务。现在需要在监测主机，也即是192.168.1.10上面安装和配置check_nrpe插件。

　　步骤大概分为：

　　第一，安装check_nrpe插件;

　　第二，为使用check_nrpe插件建立Nagios命令定义;

　　第三，建立Nagios host以及服务定义

　　由于我们刚才已经在安装Nagios之后安装了nrpe，所以实际上第一个步骤已经完成。

　　现在开始执行第二步骤——建立命令定义：

　　这里需要花点时间特别说明一下Nagios利用命令定义进行监测的原理：

　　在安装nagios成功之后可以看到在/usr/local/nagios/libexec目录下有很多可执行监控程序或者脚本，其名称类似check_icmp这样的格式。Nagios并没有提供针对这些监控程序的脚本的说明文档，想了解这些脚本如何工作，需要通过--h参数，显示其使用方法和参数，并会给出一些实际的例子。例如：./check-disk –h。

　　那么我们可以尝试按照其中一个例子执行该脚本，执行和显示的结果如下：

　　# ./check_disk -w 10% -c 5% -p /tmp -p /var -C -w 100000 -c 50000 -p /dev/sda3

　　DISK OK - free space: / 2124 MB (41% inode=90%);| /=2955MB;4820;5088;0;5356

　　可以看到状态值“OK”，以及一些详细的数据信息。

　　上述操作说明这些插件都是可以独立使用，Nagios有很多个cfg档用来定义各式各样的信息，其中template.cfg是用来定义主机和服务信息的模板文件，在目录/usr/local/nagios/etc/objects下。我们按照这些模板来建立新的配置文件，例如同样目录下的server.cfg来定义监控内容，那么这些插件就会从server.cfg中调用。例如要定义一个需要监控的SSH服务，名称为TestSSH：

　　按照其格式：

　　host_name项说明该服务所在的主机名，service_description项为服务的说明信息，这项内容会显示在nagios页面中。check_command项说明要使用的命令，这个例子中的命令check_ssh就是一个插件了。这个服务定义，明确了nagios在需要监控的内容和监控的手段，即使用check_ssh插件来监控主机x.x.x.x上的ssh服务情况。

　　除了直接使用插件来做check_command项的参数以外，还可以使用自己定义的命令来。例如，定义一个需要监控的主机，名字是localhost.localdomain：

　　在此例中，check_command项的参数“check-host-alive”并非一个插件，而是在commands.cfg档中定义的一个命令。那么在相同目录的command.cfg中对该命令又被定义为：

　　首先，$USER1$这个参数在resource.cfg中定义，这个值会指向插件的目录(如：/usr/local/nagios/libexec)。“-H 192.168.1.220”定义目标主机的地址，-w说明后面的一对值对应的是“WARNING”状态，“80%”是其临界值。“-c 500.0,100%” 其中“-c”说明后面的一对值对应的是" CRITICAL"，“100%”是其临界值。“-p 1”说明每次探测发送一个包。

　　所以归根结底就是说通过ping这种方式来证明某台主机处于alive状态。

　　而至于如何监听非默认埠的服务。下面我也举例说明一下这个问题：

　　例如：现需检查的一个运行在8080埠上的http服务。那么我们可以对commands.cfg档中对关于check_http的声明做如下修改。

　　其中$ARG1$是指在调用这个命令的时候，命令后面的第一个参数。

　　再把services.cfg中，对应服务的检测命令后面加一个参数：

　　这样就可以对8080埠的http服务进行监控了。如果要添加多个参数的时候，也可以类似操作。

　　综上，插件的安装和调用方法也就举例介绍完毕了，大家在使用中也可以使用自己写的检测脚本来完成比较特殊的检测功能。

　　所以按照上面所叙述的原理，我们开始第二步和第三步的配置，为使用check_nrpe插件建立Nagios命令定义以及服务定义：

　　修改配置文件/usr/local/nagios/etc/objects/command.cfg并增加下面的内容：

　　然后针对要监测的目标主机建立主机定义，主机定义的项目和内容有很多，所以定义的项目如下：

　　当然在企业的监测环境中很多项目可能都不一定能够用上，这里我只是通过一个简单的例子说明其用法就好了。所以修改/usr/local/nagios/etc/objects/localhost.cfg檔，在檔的“HOST DEFINITION”部分，在原来的基础上增加自己的主机定义内容：

　　同时在“HOST GROUP DEFINITION”部分，将192.168.1.220这台主机加入到linux-servers这个hostgroup中。如果有多台主机都属于这个hostgroup，可以用逗号将其隔开。以下是我添加的内容：

　　而在最后的“SERVICE DEFINITION”部分，所有未注释的部分实际上是关于对localhost也就是本机所要监测的内容。其格式和语法就是我在提到Nagios检测原理方面举例说明的内容。对于localhost来说不需要修改了，但是可以把他的内容复制到自定义的cfg档中并照葫芦画瓢修改成对192.168.1.220这台

　　主机的命令定义。我们下面就来做这样的操作：

　　在/usr/local/nagios/etc/objects目录下针对监测的服务建立服务定义，建立一个新的文件remotehosts.cfg，加入下面内容：

　　下面是自定义的：

　　表示监测远程主机的CPU负载。

　　如果要监测当前在远程主机的磁盘空间，则加入：

　　如果要监测当前远程主机的僵死进程数，则加入：

　　同时使用vi编辑器末行模式的r功能读取当前目录下的localhost.cfg档，删除“HOST DEFINITION”和“HOST GROUP DEFINITION”部分。只保留“SERVICE DEFINITION”部分并修改为下面的内容：

　　第一个命令定义：

　　通过check_ping脚本确保监测主机和被监测主机的连通性，如果丢包率到达20%则报warning，到达60%则报critical：

　　第二个命令定义：

　　监测远程主机根分区磁盘状况，如果可用空间低于20%会报Warning，如果可用空间低于10%则报Critical：

　　第三个命令定义：

　　监测远程主机当前的登录用户数量，如果大于20用户则报warning，如果大于50则报critical：

　　第四个命令定义：

　　监测远程主机当前的进程总数，如果大于250进程则报warning，如果大于400进程则报critical：

　　第五个命令定义：

　　监测远程主机当前的本地负载量：

　　第六个命令定义：

　　监测远程主机swap文件系统使用量，如果swap可用空间低于20%则报warning，低于10%则报critical：

　　第七个命令定义：

　　监测SSH连接可用性，但消息通知功能默认被关闭，因为并不是所有用户都有权限SSH。

　　第八个命令定义：

　　监测远程主机上的HTTP服务，但同SSH，该服务的消息通知功能默认关闭。

　　保存该档后，按照其它cfg文件的权限和属性为该文件指定所属用户和组：

　　# chown nagios.nagios /usr/local/nagios/etc/objects/remotehosts.cfg

　　至于想定义的其它内容，我就不再向该档中添加了，我想大家应该已经掌握了这种命令定义的方法了。

　　最后不要忘了一步关键的操作——在主配置文件中定义Nagios启动之后读取刚才修改的这些配置，也就是确保刚才修改的配置文件在nagios主配置文件/usr/local/nagios/etc/nagios.cfg中都有正确指定，信息如下：

　　最后校验配置文件正确性：

　　# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

　　如果校验完全通过，则重启Nagios服务：

　　此时如果再通过浏览器访问http://192.168.1.10/nagios，我们就可以看到被监测主机192.168.1.220上所反应出来的内容信息。

　　到此为止，Nagios的基本原理和强大的功能就基本介绍完了。而事实上Nagios不但能在现有的功能基础上实现功能扩展，而且还能够实现和第三方软件的结合，例如和前面所介绍的Mrtg和Cacti联用来构建动态显示图标;同时按照前面所说明的内容可以配置各种事件级别的邮件通知功能。但因为篇幅的限制我们会在下次有机会的时候向大家介绍。尽管在配置的难度上显得比较高，但是其强大的功能和灵活性却给我们留下了极深的印象。因此这也是在一些中型甚至是大型企业中所推崇并逐步采用的一种监测方案。

　　通过该文章的介绍，我们可以比较几种不同监测方法的特点。

　　在大多数监测环境中，SNMP都是公用的标准和协议。所以除了Nagios之外，基本上所有的监测环境也是围绕SNMP协议部署。

　　通过SNMP + 闭源商业软件的部署监测的方案：

　　拥有配置简单且功能也相对强大的优点，但是缺点是要受到闭源商业软件在功能和灵活性上的限制，而且意味着企业需要为这种类型的监测支付高昂的软件使用成本;

　　通过SNMP + Mrtg实现部署监测方案：

　　优点是费用方面的支出基本为零，但缺点是配置过程要显得复杂和繁琐，而且由于MRTG本身的一些限制功能比较单一。

　　通过SNMP + Cacti + RRDtool实现部署监测方案：

　　优点是同样不需要支付高昂的费用，而且相对于单纯使用Mrtg而言功能方面大大增强，显示的效果方面也要比Mrtg好很多，同时在监测内容和灵活性方面也有了很大的改善，相信这种方案能够被很多中小型企业所接受。但最大的问题是在部署的难度增加，对操作管理人员技术方面的要求也大大增加。因此这种方案也能够作为一种折中的选择。

　　通过Nagios实现监测方案：

　　这是几种不同方案中唯一可以不使用SNMP的，但是其丝毫不比SNMP协议基础上的监测功能逊色，甚至实现了更多实用的特性。同时部署和定义非常灵活，和其它软件的兼容性方面也表现出很多创造性的优势。显然在几种监测方案中，这种监测方案无疑是最优秀的!但缺点自然也不言而喻，强大的功能是以更为繁琐和更高的技术要求作为代价，如果针对一个大型网络要将Nagios所有的功能都一一实现，显然对用户的技术水准方面要求会比较高。

　　总之，在企业系统和应用监测的领域中，尽管有各种不同类型的监测要求，尽管也相应地也提供了各种不同类型的监测部署方案。但不管是利用基本的SNMP实现简单和单一的监测，还是利用像Cacti + RRDtool甚至Nagios这样的软件实现功能更加强大的监测部署;不管是全部利用开源软件本身实现所有监测功能，还是和像Whatsup和Solawins等这种闭源商业软件结合部署监测环境——各种开源软件以及开源项目上都表现出了极强的共通性和兼容性，而且在功能上丝毫没有逊色。完全能够支撑和满足企业级的监测部署环境要求!

　　通过本文笔者希望能够为更多中小企业甚至大型企业用户在部署监测环境方面提供一些有用参考和帮助。希望他们能够藉助开源方案量体裁衣地打造企业级监测系统。