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 操作系统：RHEL 5u8
被监测主机：IP：192.168.1.220 操作系统：RHEL 5u8
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 组：
# useradd -m nagios [ Enter ] # passwd nagios [ Enter ] 并将 nagios 以及 apache 用户加入到 nagcmd 组中 # groupadd nagcmd [ Enter ] # usermod -G nagcmd nagios [ Enter ] # usermod -G nagcmd apache [ Enter ]
完成之后将下载的 nagios 压缩包拷贝到 /usr/local 目录中，并且执行下面的步骤进行编译和安装：
# tar -zxf nagios-3.0.3.tar.gz [ Enter ] # cd nagios-3.0.3 [ Enter ]
首先初始化和建立编译的环境
# ./configure --with-command-group=nagcmd [ Enter ]
如果能看到下面的基本配置信息则说明初始的环境已经成功配置完成：
*** Configuration summary for nagios 3.0.3 06-25-2008 ***: General Options: ------------------------- Nagios executable: nagios Nagios user/group: nagios,nagios Command user/group: nagios,nagcmd Embedded Perl: no Event Broker: yes Install ${prefix}: /usr/local/nagios Lock file: ${prefix}/var/nagios.lock Check result directory: ${prefix}/var/spool/checkresults Init directory: /etc/rc.d/init.d Apache conf.d directory: /etc/httpd/conf.d Mail program: /bin/mail Host OS: linux-gnu Web Interface Options: ------------------------ HTML URL: http://localhost/nagios/ CGI URL: http://localhost/nagios/cgi-bin/ Traceroute (used by WAP): /bin/traceroute Review the options above for accuracy. If they look okay, type 'make all' to compile the main program and CGIs.
之后按照提示执行命令来进行编译：
# make all [ Enter ]
如果编译过程顺利完成，则需要执行下面的命令：
# make install [ Enter ] # make install-init [ Enter ] # make install-config [ Enter ] # make install-commandmode [ Enter ]
分别用于安装二进制文件、初始化脚本、示例配置文件和设置目录权限。
# ls /usr/local/nagios [ Enter ]
安装完成之后，在 /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 [ Enter ]
之后执行下面的命令来安装 Nagios 的 WEB 配置文件到 Apache 的 conf.d 目录下：
# make install-webconf [ Enter ]
在 Apache 中使用基本认证的方式创建一个 nagiosadmin 的用户用于 Nagios 的 WEB 界面登录。记下你所设置的登录口令。该用户登录口令和账号信息会存储到 /usr/local/nagios/etc/passwd.users 文件中：
# htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin [ Enter ]
在 Nagios 主程序安装之后会自动将相关 apache 配置文件放到 /etc/http/conf.d 目录下，文件名是 nagios.conf。文件内容如下：
# cat /etc/httpd/conf.d/nagios.conf [ Enter ] ScriptAlias /nagios/cgi-bin "/usr/local/nagios/sbin" <Directory "/usr/local/nagios/sbin"> Options ExecCGI AllowOverride None Order allow,deny Allow from all AuthName "Nagios Access" AuthType Basic AuthUserFile /usr/local/nagios/etc/htpasswd.users Require valid-user </Directory> Alias /nagios "/usr/local/nagios/share" <Directory "/usr/local/nagios/share"> Options None AllowOverride None Order allow,deny Allow from all AuthName "Nagios Access" AuthType Basic AuthUserFile /usr/local/nagios/etc/htpasswd.users Require valid-user
这就意味着只有通过认证用户才可以通过 http 访问 /usr/loca/nagios/share 以及 /usr/local/nagios/sbin 目录下内容。而这个能够通过认证的用户也就是 nagiosadmin，之后可以重启 apache 来应用配置：
# service httpd restart [ Enter ] # chkconfig --level 345 httpd on [ Enter ]
刚才已经提到 Nagios 主程序只是一个控制中心，而能够起到服务监测和系统监测等功能的是众多 Nagios 的插件，没有插件的 Nagios 系统其实只是一个空壳。因此在安装了 Nagios 平台之后我们还需要安装插件。
Nagios 插件同样是在其官方网站下载，目前版本是 1.4.12。我将下载的源码包放到 /usr/local 目录下，按照下面的步骤进行解压，编译和安装：
# tar -zxf nagios-plugins-1.4.12.tar.gz [ Enter ] # cd nagios-plugins-1.4.12 [ Enter ] # ./configure --with-nagios-user=nagios --with-nagios-group=nagios [ Enter ] # make [ Enter ] # make install [ Enter ]
然后把 Nagios 加入到服务列表中以使之在系统启动时自动启动：
# chkconfig --add nagios [ Enter ] # chkconfig nagios on [ Enter ]
执行下面的命令来验证 Nagios 的样例配置文件：
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg [ Enter ]
如果最后的结果类似下面而没有报错，可以启动 Nagios 服务：
Total Warnings: 0 Total Errors: 0 Things look okay - No serious problems were detected during the pre-flight check # service nagios start
之后可以在浏览器上访问链接 http://192.168.1.10/nagios，如果能够正常看到页面，证明主程序和插件都安装和配置成功（如图 pic32.png 所示）！点击“Service Detail”的链接来查看你本机的监视详情。此时可能需要给点时间让 Nagios 来检测你机器上所依赖的服务（如图 pic33.png-pic34.png 所示）。
实际上在装完 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 负荷，所以当你需要监测大量的主机时这个构件将起到很重要的作用（如图 pic35.png 所示）。
通过该图可以看出，我们需要在被监测主机上部署 NRPE，他相当于一个守护进程负责监听。而监测主机使用 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 账号，这里我使用同样的密码：
# useradd nagios [ Enter ] # passwd nagios [ Enter ]
之后按照和上面相同的步骤来编译和安装 nagios-plugin 软件：
# tar -zxf nagios-plugins-1.4.12.tar.gz [ Enter ] # cd nagios-plugins-1.4.12 [ Enter ] # ./configure [ Enter ] # make [ Enter ] # make install [ Enter ]
然后对相关的目录设置权限和所属用户组：
# chown nagios.nagios /usr/local/nagios [ Enter ] # chown –R nagios.nagios /usr/local/nagios/libexec [ Enter ]
接着 NRPE 包放到 /usr/local 目录下，按照下面的步骤解压缩，并且编译和安装：
# tar -zxf nrpe-2.12.tar.gz [ Enter ] # cd nrpe-2.12 [ Enter ] # ./configure [ Enter ] # make all [ Enter ] # make install-plugin [ Enter ] # make install-daemon [ Enter ] # make install-daemon-config [ Enter ]
同时安装 NRPE 的插件、进程以及进程范例配置文件。
接着执行命令将 nrpe 安装为依赖 xinetd 超级进程的非独立服务，那么前提是必须安装 xinetd。不过一般系统都会自动安装该服务。 最后执行下面的命令将 NRPE 安装为 xinetd 超级进程所管理的进程之一。
# make install-xinetd [ Enter ]
完成之后需要编辑 /etc/xinetd.d 目录下的 nrpe 文件，并且在最后添加允许实施监测的主机 IP 地址，这里是 192.168.1.10，那么整个配置文件全文如下：
# cat /etc/xinetd.d/nrpe [ Enter ] service nrpe { flags = REUSE socket_type = stream port = 5666 wait = no user = nagios group = nagios server = /usr/local/nagios/bin/nrpe server_args = -c /usr/local/nagios/etc/nrpe.cfg --inetd log_on_failure += USERID disable = no only_from = 192.168.1.10 }
然后修改 /etc/services 档，并添加下面的内容：
nrpe 5666/tcp # nrpe
重启服务：
# /etc/init.d/xinetd restart [ Enter ]
此时检查 nrpe 服务启动状况如下：
# netstat -nl | grep 5666 [ Enter ] tcp 0 0 0.0.0.0:5666 0.0.0.0:* LISTEN # lsof -i:5666 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME xinetd 9949 root 5u IPv4 28764 TCP *:nrpe (LISTEN)
现在最关键的一步是确保安装的 NRPE 进程能够正常工作，所以要使用 check_nrpe 插件进行测试。在监测主机 192.168.1.10 上执行命令：
# /usr/local/nagios/libexec/check_nrpe -H 192.168.1.220 [ Enter ]
如果能够出现如下的版本号显示，则证明在被监测主机上配置的 NRPE 已经正常工作，并且监测主机能够通过 SSL 与被监测主机上的 NRPE 正常通信。 NRPE v2.12
但是如果出现一些 error 信息，则需要检查配置，检查的内容包括主要有下面几项：
- nrpe 的版本号和 nrpe-plugin 的版本号是否一致。版本不一致极有可能造成该问题。
- SSL 是否被关闭。确保 NRPE 以及 check_nrpe 插件在编译的时候都加入了 SSL 支持，同时在运行时都开启 SSL。不过一般编译过程中默认都会假如支持 SSL 选项。
- 确保 NRPE 的配置文件 nrpe.cfg 文件可以被 nagios 用户读取并且 nagios 用户可以执行 nrpe 二进制程序。
- 确认在 /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/ 中的各种脚本并添加各项参数来定制自己的监测内容。（如图 pic36.png 所示）
那么到此为止我们就完成了在远程被监测主机上安装和配置 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 [ Enter ] 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：
按照其格式：
define service { host_name x.x.x.x service_description check_ssh …… check_command check_ssh }
host_name 项说明该服务所在的主机名，service_description 项为服务的说明信息，这项内容会显示在 nagios 页面中。check_command 项说明要使用的命令，这个例子中的命令 check_ssh 就是一个插件了。这个服务定义明确了 nagios 在需要监测的内容和监测的手段，即使用 check_ssh 插件来监测主机 x.x.x.x 上的 ssh 服务情况。
除了直接使用插件来做 check_command 项的参数以外，还可以使用自己定义的命令来做 check_command 参数。例如，定义一个需要监测的主机，名字是 localhost.localdomain：
define host { host_name localhost.localdomain alias remotehost01 address 192.168.0.1 …… check_command check-host-alive …… }
在此例中，check_command 项的参数“check-host-alive”并非一个插件，而是在 commands.cfg 档中定义的一个命令。那么在相同目录的 command.cfg 中对该命令又被定义为：
# 'check-host-alive' command definition define command{ command_name check-host-alive command_line $USER1$/check_ping -H 192.168.1.220 -w 300.0,80% -c 500.0,100% -p 1 }
首先，$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 的声明做如下修改。
# 'check_http' command definition define command{ command_name check_http command_line $USER1$/check_http -H 192.168.1.220 -p $ARG1$ }
其中 $ARG1$ 是指在调用这个命令的时候，命令后面的第一个参数。
再把 services.cfg 中，对应服务的检测命令后面加一个参数：
define service { host_name ... ... check_command check_http!8080 }
这样就可以对 8080 埠的 http 服务进行监测了。如果要添加多个参数的时候，也可以类似操作。 综上所述，插件的安装和调用方法也就举例介绍完毕了，大家在使用中也可以使用自己写的检测脚本来完成比较特殊的检测功能。
所以按照上面所叙述的原理，我们开始第二步和第三步的配置，为使用 check_nrpe 插件建立 Nagios 命令定义以及服务定义：
修改配置文件 /usr/local/nagios/etc/objects/command.cfg 并增加下面的内容：
define command{ command_name check_nrpe command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ }
然后针对要监测的目标主机建立主机定义，主机定义的项目和内容有很多，所以定义的项目如下：
host_name host_name # 简短的主机名 alias alias # 别名，可以更详细的说明主机 address address # ip 地址，当然如果 DNS 服务可用也可以写名称。如果你不定义该值，nagios 将会用 host_name 去寻找主机。 parents host_names # 上一节点的名称，也就是指从 nagios 服务器到被监测主机之间经过的节点， 可以是路由器、交换机、主机等等。这个节点也要定义并且要被 nagios 监测。 hostgroups # 简短的主机组名称 check_command # 检查命令的简短名称，如果此项留空，nagios 将不会去判断该主机是否 alive。 max_check_attempts # 当检查命令的返回值不是“OK”时，重试的次数 check_interval # 循环检查的间隔时间。 active_checks_enabled # 是否启用“active_checks” passive_checks_enabled # 是否启用“passive_checks”，及“被动检查” check_period # 检测时间段简短名称，此处只是名称，具体的时间段要写在其他的配置文件 obsess_over_host # 是否启用主机操作系统探测。 check_freshness # 是否启用 freshness 测试。freshness 测试是对于启用被动测试模式的主机而言 的，其作用是定期检查该主机报告的状态信息，如果该状态信息已经过期， freshness 将会强制作主机检查。 freshness_threshold # fressness 的临界值，单位为秒。 如果定义为 0，则为自动定义。 event_handler # 当主机发生状态改变时，采用的处理命令的简短的名字 （可以在 commands.cfg 中对其定义） event_handler_enabled # 是否启用 event_handler low_flap_threshold # 抖动的下限值。所谓抖动，主要定义了这样一种现象：在一段时间内，主机 （或服务）的状态值频繁发生变化，类似一个问题风暴或者一个网络问题。 high_flap_threshold # 抖动的上限值 flap_detection_enabled # 是否启用抖动检测 process_perf_data # 是否启用 processing of performance data retain_status_information # 程序重启时，是否保持主机状态相关的信息 retain_nonstatus_information # 程序重启时，是否保持主机状态无关的信息 contact_groups # 联系人组（这个组会在 contactgroup.cfg 文件中定义），在此组中的联系人都 会受到该主机的告警提醒信息。 notification_interval # 告警临界值。达到此次数之后，才会发送该机的报警提醒信息。 notification_period # 告警时间段 notification_options # 告警包括的状态变化结果 notifications_enabled # 是否启用告警提醒功能 stalking_options [o,d,u] # 持续状态检测参数，o = 持续的 UP 状态， d = 持续的 DOWN 状态，and u = 持续的 UNREACHABLE 状态.
当然在企业的监测环境中很多项目可能都不一定能够用上，这里我只是通过一个简单的例子说明其用法就好了。所以修改 /usr/local/nagios/etc/objects/localhost.cfg 文件，于该文件的“HOST DEFINITION”部分，在原来的基础上增加自己的主机定义内容：
define host{ use linux-box ; Inherit default values from a template host_name localhost ; The name we're giving to this server alias RHEL5u2 ; A longer name for the server address 192.168.1.220 ; IP address of the server }
同时在“HOST GROUP DEFINITION”部分，将 192.168.1.220 这台主机加入到 linux-servers 这个 hostgroup 中。如果有多台主机都属于这个 hostgroup，可以用逗号将其隔开。以下是我添加的内容：
define hostgroup{ hostgroup_name linux-servers ; The name of the hostgroup alias Linux Servers ; Long name of the group members 192.168.1.220 ; Comma separated list of hosts that belong to this group }
而在最后的“SERVICE DEFINITION”部分，所有未注释的部分实际上是关于对 localhost 也就是本机所要监测的内容。其格式和语法就是我在提到 Nagios 监测原理方面举例说明的内容。对于 localhost 来说不需要修改了，但是可以把他的内容复制到自定义的 cfg 档中并照葫芦画瓢修改成对 192.168.1.220 这台 主机的命令定义。我们下面就来做这样的操作：
在 /usr/local/nagios/etc/objects 目录下针对监测的服务建立服务定义，建立一个新的文件 remotehosts.cfg，加入下面内容：
下面是自定义的：
define service{ use generic-service host_name localhost service_description CPU Load check_command check_nrpe!check_load }
表示监测远程主机的 CPU 负载。
如果要监测当前在远程主机的磁盘空间，则加入：
define service{ use generic-service host_name localhost service_description /dev/sda3 Free Space check_command check_nrpe!check_disk /dev/sda3 }
如果要监测当前远程主机的僵死进程数，则加入：
define service{ use generic-service host_name localhost service_description Zombie Processes check_command check_nrpe!check_zombie_procs }
同时使用 vi 编辑器末行模式的 r 功能读取当前目录下的 localhost.cfg 档，删除“HOST DEFINITION”和“HOST GROUP DEFINITION”部分。只保留“SERVICE DEFINITION”部分并修改为下面的内容：
第一个命令定义：
通过 check_ping 脚本确保监测主机和被监测主机的连通性，如果网络丢包率到达 20% 则产生 warning 警告，到达 60% 则产生 critical 警告：
define service{ use local-service ; Name of service template to use host_name 192.168.1.220 service_description PING REMOTE HOST check_command check_ping!100.0,20%!500.0,60% }
第二个命令定义：
监测远程主机根分区磁盘状况，如果根分区可用空间低于 20% 会产生 Warning 警告，如果可用空间低于 10% 则产生 Critical 警告：
define service{ use local-service ; Name of service template to use host_name 192.168.1.220 service_description Root Partition of Remote Server check_command check_local_disk!20%!10%!/ }
第三个命令定义：
监测远程主机当前的登录用户数量，如果登录数量大于 20 用户则产生 warning 警告，如果大于 50 则产生 critical 警告：
define service{ use local-service ; Name of service template to use host_name 192.168.1.220 service_description Current Users of Remote Server check_command check_local_users!20!50 }
第四个命令定义：
监测远程主机当前的进程总数，如果大于 250 进程则产生 warning 警告，如果大于 400 进程则产生 critical 警告：
define service{ use local-service ; Name of service template to use host_name 192.168.1.220 service_description Total Processes of Remote Machine check_command check_local_procs!250!400!RSZDT }
第五个命令定义：
监测远程主机当前的本地负载量：
define service{ use local-service ; Name of service template to use host_name 192.168.1.220 service_description Current Load of Remote Machine check_command check_local_load!5.0,4.0,3.0!10.0,6.0,4.0 }
第六个命令定义：
监测远程主机 swap 文件系统使用量，如果 swap 可用空间低于 20% 则产生 warning 警告，低于 10% 则产生 critical 警告：
define service{ use local-service ; Name of service template to use host_name 192.168.1.220 service_description Swap Usage of Remote Server check_command check_local_swap!20!10 }
第七个命令定义：
监测 SSH 连接可用性，但消息通知功能默认被关闭，因为并不是所有用户都有权限 SSH。
define service{ use local-service ; Name of service template to use host_name 192.168.1.220 service_description SSH of Remote Machine check_command check_ssh notifications_enabled 0 } # Define a service to check HTTP on the remote machine. # Disable notifications for this service by default, as not all users may have HTTP enabled.
第八个命令定义：
监测远程主机上的 HTTP 服务，但类似于 SSH，该服务的消息通知功能默认关闭。
define service{ use local-service ; Name of service template to use host_name 192.168.1.220 service_description HTTP of Remote Machine check_command check_http notifications_enabled 0 }
保存该档后，按照其他 cfg 文件的权限和属性为该文件指定所属用户和组：
# chown nagios.nagios /usr/local/nagios/etc/objects/remotehosts.cfg [ Enter ]
至于想定义的其他内容，我就不再向该文件中添加了，我想大家应该已经掌握了这种命令定义的方法了。
最后不要忘了一步关键的操作——在主配置文件中定义 Nagios 启动之后读取刚才修改的这些配置，也就是确保刚才修改的配置文件在 nagios 主配置文件 /usr/local/nagios/etc/nagios.cfg 中都有正确指定，信息如下：
cfg_file=/usr/local/nagios/etc/objects/commands.cfg cfg_file=/usr/local/nagios/etc/objects/remotehosts.cfg cfg_file=/usr/local/nagios/etc/objects/localhost.cfg
最后校验配置文件正确性：
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg [ Enter ]
如果校验完全通过，则重启 Nagios 服务：
# chkconfig --level 345 nagios on [ Enter ] # service nagios restart [ Enter ]
此时如果再通过浏览器访问 http://192.168.1.10/nagios，我们就可以看到被监测主机 192.168.1.220 上所反应出来的内容信息。下面是几个效果图：（如图 pic37.png-pic39.png 所示）
到此为止，Nagios 的基本原理和强大的功能就基本介绍完了。而事实上 Nagios 不但能在现有的功能基础上实现功能扩展，而且还能够实现和第三方软件的结合，例如和前面所介绍的 MRTG 和 Cacti 联用来构建动态显示图标；同时按照前面所说明的内容可以配置各种事件级别的邮件通知功能。但因为篇幅的限制我们会在下次有机会的时候向大家介绍。尽管在配置的难度上显得比较高，但是其强大的功能和灵活性却给我们留下了极深的印象。因此这也是在一些中型甚至是大型企业中所推崇并逐步采用的一种监测方案。
各种系统监测优缺点比较和总结：
通过该文章的介绍，我们大致了解了多张不同但都比较常用的系统监测解决方案。下面可以简单比较几种不同监测方法的特点。
在大多数监测环境中，采用 SNMP 都是公用的标准和协议。所以除了 Nagios 之外，基本上所有的监测环境也是围绕 SNMP 协议部署，对 SNMP 协议的支持是目前市面上众多网管软件的最基本要求。
通过 SNMP 结合闭源商业软件的部署监测的方案：
拥有配置简单且功能也相对强大的优点，但是缺点是要受到闭源商业软件在功能和灵活性上的限制，而且意味着企业需要为这种类型的监测支付高昂的软件使用成本；
通过 SNMP 结合 MRTG 实现部署监测方案：
优点是费用方面的支出基本为零，但缺点是配置过程要显得相当复杂和繁琐，而且由于 MRTG 本身的一些限制功能比较单一。
通过 SNMP 结合 Cacti 和 RRDtool 实现部署监测方案：
优点是同样不需要支付高昂的费用，而且相对于单纯使用 Mrtg 而言功能方面大大增强，显示的效果方面也要比 Mrtg 好很多，同时在监测内容和灵活性方面也有了很大的改善，相信这种方案能够被很多中小型企业所接受。但最大的问题是在部署的难度增加，对操作管理人员技术方面的要求也大大增加。因此这种方案也能够作为一种折中的选择。
通过 Nagios 实现监测方案：
这是几种不同方案中唯一可以不使用 SNMP 的，但是功能上丝毫不比传统的使用 SNMP 协议的监测软件逊色，甚至实现了更多实用的特性，更何况结合插件也能支持 SNMP。另外 Nagios 的部署和定义非常灵活，和其他软件的兼容性方面也表现出很多创造性的优势。显然在几种监测方案中，这种监测方案无疑是比较优秀的！但缺点自然也不言而喻，强大的功能是以更为繁琐和更高的技术要求作为代价，如果针对一个大型网络要将 Nagios 所有的功能都一一实现，显然对用户的技术水准方面要求会比较高。
总之，在企业系统和应用监测的领域中，尽管有各种不同类型的监测要求，尽管也相应地也提供了各种不同类型的监测部署方案。但不管是利用基本的 SNMP 实现简单和单一的监测，还是利用像 Cacti + RRDtool 甚至 Nagios 这样的软件实现功能更加强大的监测部署；不管是全部利用开源软件本身实现所有监测功能，还是和像 Whatsup 和 Solawins 等这种闭源商业软件结合部署监测环境——各种开源软件以及开源项目上都表现出了极强的共通性和兼容性，而且在功能上丝毫没有逊色。完全能够支撑和满足企业级的监测部署环境要求！
通过本文笔者希望能够为更多中小企业甚至大型企业用户在部署监测环境方面提供一些有用参考和帮助。希望他们能够藉助开源方案量体裁衣地打造适合于自己的企业级监测系统。
关于作者
王基立，现工作于红帽软件（北京）有限公司，具备多年的售前解决方案规划与售后技术支持经验，熟悉红帽所有平台类产品和解决方案。现常驻深圳任红帽软件华南区解决方案架构师一职，主要负责红帽解决方案在华为、中兴等大型电信企业用户环境中的设计、规划、应用以及相关售前工作。同时也为包括各高级分销商以及金融、政府、教育等各方面在内的管道和区域用户提供相关解决方案、技术咨询、技术培训、现场实施、技术支持等服务。
给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论