为什么选择Nagios

在我来看，Nagios这款系统和网络监控工具，是目前可用的、开源的或其他方面中最棒的一款工具。它模块化的设计、直观的监控方式，使其很容易使用，而且高度可扩展。进一步来说，Nagios的开源许可证使其免费可用，并很容易扩展以满足用户自身的特殊需求。Nagios擅长与其他开源工具互操作，而非帮你完成所有的工作，这也是其灵活性所在。如果读者想通过本书寻找一个整体化的软件解决方案，能够通过勾选一系列复选框来解决所有的问题，那我可以很明确地说，本书不适合你。但在放下本书之前，希望你能继续阅读一到两个段落，看我是否能够说服你——那种整体化解决方案不是你真正寻找的。

而现实中，绝大多数商业化产品都搞错了方向，因为它们解决问题的方式是假设所有人都希望采用相同的解决方案。在某种程度上来说，这是事实。拥有大量计算机和网络设备的用户都希望如果某些地方故障时能够收到通知。所以如果读者希望销售监控软件，很明显的方式就是创建一款软件，它要了解如何监控现有计算机软件以及网络设备。但对于那些销售监控软件的人来说，他们认为监控系统是个一站式解决方案，在这场较量中，谁能监控的东西最多，谁将最终胜出。

我使用过的所有大型商业软件似乎都遵从着这一逻辑。与（Google的）Borg不同，这些商业软件有条不紊地寻找着新的计算机设备并将必要的监控代码加入解决方案中。更糟糕的情况是，某些公司通过直接收购那些已经知道如何监控大量计算机设备的公司，并将这些公司的代码集成到自己的产品中。他们很快痴迷于功能，并创建了一份庞大的产品功能列表，上面写满了支持的设备。因为他们有软件工程师，所以售前工程师会来到你的办公室，露出一排整齐洁白的牙齿，笑着对你的经理说：“没问题，我们的系统可以监控这个。”

问题就在于监控系统不是一站式解决方案。在它能够解决问题之前需要完成大量的定制工作，监控软件的销售者和设计实施软件的工程师之间的差异就在这里。当用户试图构建一套监控系统时，一款通过点击复选框的方式来进行监控的软件不会是用户想要的，用户真正需要的是可以很方便地监控需要监控的设备。专有解决方案往往关注要监控什么，而忽略如何监控，这使得专有解决方案很难满足实际应用。

比如，使用Ping程序。我所用过的所有监控系统都会使用ICMP回显请求，或者叫做Ping，以这种或那种方式来检测主机可用性。如果想控制一套专有监控系统如何使用Ping，则可能会立刻发现架构上的限制。比如想设置ICMP包发送的数量或者想根据包往返时间的毫秒数而非简单的通过/失败，来发送通知。在更复杂的环境下，可能必须使用IPv6的Ping，或者在Ping之前先进行端口试探（PortNock ）。这个问题从整体、功能上的解决方式是这些改变意味着核心应用程序逻辑的改变，因此，必须实施。

在我使用过的商业化监控应用程序中，如果上述Ping的例子可以引申，那它们可能需要在监控系统专用脚本语言中重新实现Ping逻辑。或者换句话说，就是不得不完全抛弃内置的Ping功能。对用户来说，可能对Ping检测细节上的控制不一定有价值，但是如果用户连最基本的Ping都无法控制，那么在用户环境中，对其他更重要的检测，用户又有多少能够完全控制呢？他们假设知道用户想如何Ping某个设备，至此，游戏结束，他们永远不会再次考虑这个问题。为什么呢？因为Ping功能已经在产品功能列表上了。

目前，监控设备要面向层出不穷的设备，而Nagios关注的是模块化，Nagios包含很多插件，即专用监控小程序，为专用设备和服务提供支持。Nagios不会去增加特性而搞军备竞赛，硬件支持方面是社区驱动的。当社区成员需要监控某个新设备或新服务时，就会有人编写新的插件并发布，速度往往比商业应用程序支持同等服务更快。实际上，Nagios将永远支持用户所需的一切，而且无须对Nagios进行升级。Nagios还提供了两全其美的方案，当用户需要支持时，有商业化的选择，也有兴旺繁荣、乐于助人的社区通过众多的论坛和邮件列表提供免费支持。

选择Nagios作为监控平台意味着监控效果只受你的想象力、技术能力以及管理环境的限制。Nagios能够到达你想监控的任何目的，而且过程极为简单。尽管Nagios能完成商业应用程序所做的一切，或者更多，无须安装笨重不安全的Agent，但它常常无法与商业监控系统相媲美，因为当分析表格时，Nagios没有那么多的检测项目。实际上，如果他们统计正确，Nagios本身不做任何检测，因为从技术上来说，它并不知道如何进行监控，它希望你能告诉它如何监控。“如何”监控这个问题，很难通过一个复选框来回答。