第2章　运作原理

监控服务器的作用是通过不同协议与其他系统进行交互，以获取监控结果。它们通过SMTP协议和邮件系统交互，通过SQL协议和数据库系统交互，并通过HTTP、HTTPS、AJP、SOAP等协议和Web服务器交互，可能在读者读到这本书的时候，已经出现了更多的和Web服务器交互的协议。读者可以将监控服务器想象成为一台奇特的多层协议模拟器。由于需要与各种环境中的各种系统交互，所以它必须了解这些系统所使用的协议，不但需要提供输入，并且理解其输出内容。

当创建监控系统的任务分派给你后，应该如何考虑呢？应当如何构建这套系统呢？会蛮干吗？虽然需要监控的协议种类很多，但数量毕竟是有限的，所以创建一个大型程序来监控所有能想到的设备，来满足所有人的监控需求，是完全可能的，对吧？我曾经使用过的那些大型商业化监控系统，其设计思路很可能就是这样。有些公司止步不前，不再深入研究，而有些公司可能是自我感觉良好，傲慢地认为，他们没有想到的东西是不会有人需要的，也没有考虑如果别人做到了会发生什么事。当然如果真有人做到了，他们也会将此提供给用户，当作一份礼物——一份私有的、受限于域名 的脚本语言，运行在专有解释器上，嵌入在他们一体化的监控软件中。

各位读者应该能够想象到，这种方式所带来的一些问题。单是软件的复杂性，就可能是最大的影响。很多大型监控软件包都有GUI（图形用户界面），并且含有10～15层以上嵌套的菜单。而Agent（代理 ）软件臃肿的速度则更快，通常在每台服务器上需要安装超过500MB的东西。安全问题则更加难以管理，因为监控程序假设用户希望在每台被监控主机上启用所有功能集，这使得很难对监控服务器访问监控客户端进行限制。而软件包作为一个整体，也只能符合其后的开发人员和市场销售人员的预期。最终，使用专用脚本语言的直接后果是被厂商套牢。可能有不少系统管理员经历过监控系统的变迁，最后会将多年监控定制化的成果移植到通用语言平台上，相信这是一个痛苦的过程，或者更糟—移植到不同厂商的专用语言。对于这种工作，我肯定会绕过的。

相比较而言，Nagios使用了一种完全相反的方式。它没有内部监控逻辑，并假设对用户所希望监视的环境或者方式不甚了解。它不需要也没有提供Agent，而且没有内置专有解释器。实际上，Nagios不是真正意义上的监控应用程序，因为实际上它不知道如何监控。所以Nagios到底是什么，它究竟如何工作？

本章会让读者洞悉Nagios的用途、工作机制以及原因。在本章中，我将以这一题材为背景介绍一些Nagios中的配置选项，但是本章希望读者对作为程序的Nagios的工作机制有一个概念上的理解。而第4章将会详细讲解Nagios所有的配置选项。