1.2　处理和开销

监控系统会不可避免地带来一些额外的开销，主要以网络流量和资源占用的形式体现在被监控主机上。大多数监控系统通常都有一些特定的操作模式，所以系统的功能、实现方式的选择，决定了产生开销的对象和开销的数量。

1.2.1　远端处理与本地处理

Nagios将服务检测逻辑输出到插件中，插件是一种专用的小程序。这种架构能够方便快捷地扩展对新型服务的检测，也能整合已有的监控脚本。这种模块化的方式使其能够调用插件本身，无论是在本地监控服务器还是在远端被监控的主机上。

一般情况下，人们更加喜欢集中式的执行方式，因为这样被监控主机的资源占用就会更少一些，而且所有的配置都保存在一个地方。然而，远端处理是不可避免的，在某些情况下，可能这种方式更受欢迎。如在一个有上万台主机的超大型环境中，集中式的执行对于一台监控服务器来说可能负担过重而无法掌控。在这种情况下，监控系统可能需要依赖客户端自行进行服务检测并返回检测结果。有些类型的检测可能根本完全无法在中央服务器上执行，比如，检测系统负载或者剩余内存的插件需要在远端执行。

为了避免大家困惑，我需要说明的是，本地和远端的处理界线已经很模糊，有几种方式，例如Check_MK这样的插件（参见第6章），实现了“超级检测”，即一条服务检测命令能够返回多个服务的检测结果。类似的还有多种分布式监控方案（参见第7章），它可以通过多台Nagios服务器来分散服务检测的负载，通过与其他系统的集成，如Ganglia（参见第8章），可实现同类监控系统的状态共享和检测结果的复用。

1.2.2　带宽方面的考虑

几乎所有的插件都会产生一定的IP流量，这些流量在必须通过的每台网络设备上产生了网络开销，或者说系统中的设备之间产生了依赖关系。图1-1中，在服务器Nagios和服务器1之间有一台路由器1。因为Nagios必须通过路由器1才能连接服务器1，所以可以说服务器1是路由器的子节点。 在监控系统和目标主机之间，要尽量少进行3层路由，特别是类似连接了防火墙和广域网（WAN）链路的地方。所以监控系统（或监控系统群）在网络拓扑中的位置成为了实施时的一个重要细节。

图1-1　在Nagios和服务器1之间的路由以第三层路由决策的形式形成了一个依赖，并带来一些网络开销

此外，为了尽量减少来自监控主机的第三层路由流量，我们也希望确保监控主机发出的流量尽可能少。这意味着需要注意诸如轮询间隔的设置以及冗余插件。冗余插件是指2个或以上的插件都在有效地监控着同一个服务。

冗余插件可能不是很明显。它们经常以两个插件的形式监控同一个服务，但是在不同的目录中。比如，一个Web服务镜像在服务器1上运行，而监控系统可能一开始设置为检测80端口连通性，以判断Web服务是否可用。而过了几个月之后，可能服务器1上的Web网站在用户验证方面存在问题，于是有人创建了用于检测验证有效性的插件。在这种情况下，我们只需要第二个插件，因为如果能够登录网站（用户验证通过），就表明80端口是可以连通的，而第一个插件不仅没用而且在浪费资源。冗余插件对于小型网站来说不是什么问题，但是小型网站往往发展成大型网站，而对大型网站来说，剔除冗余插件（能够一开始就避免它出现则更好）能够有效地降低监控系统和网络的负载。

最大限度减少环境的开销是从全局的角度考虑维护资源的一种手段。对于连接主机的广域网链路速度慢而且利用率过高，或者其他方面对资源利用非常敏感的地方，应该进行逻辑分组。这里可以使用Nagios提供的“主机组”（hostgroup）。使用主机组可以通过对配置进行优化，来满足该组的需求。比如，可以将主机组“远程办公室”某个插件的超时时间设置得更高，以确保主机在较慢的网络中不会因网络时延而产生误报。尤其要特别考虑监控系统的位置，以降低它对网络的影响，此外也要考虑到最小化它对其他设备的依赖（本章稍后会讨论这个问题）。此外，确保配置调整不会对所监控的系统和网络增加不必要的负担，冗余插件也一样。最后，监控系统要做的就是自身的调优。