首先感谢孔峰同志赠书，让我能够对nagios这个世界级的开源监控产品有了一个系统级的认识。

对于一个曾经的运维，监控系统会变成夜夜狼嚎，让人无法安睡，是深有体会。一个好的监控系统尤为重要，nagios这个应用是如何解决这个问题呢？我理解应该是采用众创的方式，但这种众创的方式有点像免费游戏，每个使用者又是免费玩家，你可以通过自己的勤奋练级（编码），打怪（集成插件）来定制一套符合自己的监控系统。

所以，nagios推崇的不是一次性整体的解决方案，而是与其他开源工具互操作，组合完成。作者认为：现实中大多数商业软件的产品方向，他们解决问题的方式是假设所有人都希望采用相同的解决方案（注：可复制性是商业软件的盈利基础。商业的解决方案目前也趋向于自助选择按需服务，但是与nagios这样的产品由用户创造内容还差距较大）。商业软件希望通过一站式解决方案满足所有监控需求，这就造成不断的监控代码加入到了监控软件，逐渐也就形成了一份庞大的监控功能清单。

监控系统的构建需要能够有效的与环境中的其他系统交互，要适用于各种客户，包括菜鸟和专家。监控平台的构建不仅仅需要技术能力，还需要精心的规划、全局的视角以及良好的人际沟通技巧。可能很重要的是，所构建的系统不能对现有系统影响。拙略的监控系统不仅会占用网络、系统资源、还会产生安全问题，甚至会影响到新人他的运维人员。“首先，不要带来伤害”。

下面这个案例是一个典型的监控所带来的的问题，或者不合理的监控s带来的一种变向伤害：

**经理：你把我加入监控系统中，我想接收所有系统的警告消息。

管理员：所有的？

经理：是的，所有的警告消息。

管理员：呃，好的。

------第二天

经理 ：昨晚传呼机响个不停，害我一夜没合眼，这意味着什么？

管理员：哦，服务器I的/var分区满了，连接站点site5的VPN隧道时断时续。

经理：你就不能通知我实际的问题？

管理员：这就是实际的问题。**

并不是说管理员需要服务器1 的/var分区满了的时候发出告警，而说在收到通知的时候，他应该明白了通知的什么以上，管理层是希望立刻修复还是明天再说？还应该通知谁呢？如果他不响应会发生什么？这种完备的信息对管理层抉择是非常有帮助的，只有明确的定义问题的构成，管理层才能给出自己的意见。监控系统应该执行组织的制度，而非仅仅将问题反应处理来，如果组织需要有人能够10分钟内查看服务器1的所有问题，那么监控系统应当给我们的管理员明确提供指示（比如优先级），确认告警消息的机制以及告警的自动升级（例如超出10分钟自动通知他人）。

监控规划过程中，关键系统是有运营公司的管理层确定的，有点类似于灾难恢复顺序，当所有IT系统崩溃时，恢复的顺序应该是监控的优先级的顺序。获得关键系统顺序后，各专业系统的不同组件顺序的优先级应该由专业系统的管理员给出定义。

建立减少监控系统到监控目标的三层路由，避免对路由决策的依赖。避免拥塞阻塞，例如部署再内网的监控主机，监控主机在防火墙故障时候无法监控dmz区域设备。一般解决的方法是在监控主机上增加网卡，完成两个网段的监控。（减少监控过程中的黑洞，避免影响监控数据的传递路径。）

nagios 遵循UNIX哲学：”只做一件事，并把它做好“、沉默是金（合适的监控力度，不能太多，也不能太少）；监控阈值应该跟随环境的变化，例如CPU阈值70%，但新增了一个批量执行脚本，再中午时段会引起75%的占用率，这种情况下应该优化阈值，对于羽翼未丰的监控系统大量误报会削弱可信度；设置通知时需要考虑联系人的关系，例如DBA 不会关心主机的CPU利用率过高。

优秀的监控系统是专注的而非泛泛。他们监控了许多服务以满足分析需求，但是很少发出通知，而且只发送给想知道的那群人。而对于求知欲很强的人而已，为避免他们全天关机，只能每天定时给他们发送汇总或者摘要。端到端监控可以看到系统存在问题，但是问题的原因却无法反应出来。例如：不出邮件，是因为DNS故障造成的。

监控系统需要一条用于监控自己本身的规则，只需要知道监控系统不宕机即可。监控服务器的作用是通过不同协议与其他系统的交互，以便获得监控结果。

nagios是一个优雅的程序，简单易懂。它能够以用户期望的方式完成用户期望的工作，而且还能扩展出一些惊人的事件。Nagios 能够发挥个人的技术能力，你为了更好的集中化他们的监控工具二花了五个月，通过一个免费的监控平台而实现，这会体现个人价值，并让组织看到并重视你。（注：系统的人性****！管理员的价值！）

nagios主要监控的对象是主机和服务，主机是一切可以进行TCP通信的东西，包括传感器、冰箱等。服务这是由主机提供的逻辑实体，例如守护进程。一个主机会有多个应用被监视，但是主机本身只有启动或者宕机两个状态。Nagios对于每台主机设定唯一的监测机制以及多个服务监测，例如定义check_ping 定义为主机检测，如果检测失败则主机down，对应的所有主机检测服务也不可用。

依赖关系

对于不同主机之间的相互依赖关系有两种，父子关系、，如果父节点down后则子节点的主机不再进行监测。例如防火墙宕机后，防火墙后的服务器1则认为不可达。nagios则不会再去监测主机1和主机1上的服务。依赖关系的定义监测的依赖关系，例如 某台设备的web服务依赖与代理服务器的WEB服务，如果nagios监测到代理服务器的nagios服务失败，则不会监测所以web服务。（个人理解，例如tomcat down 就不会监测web服务）。 nagios对于服务和主机的定义在集群环境下的使用略显不足，主要依靠其他插件完成。

插件：nagios 是一个调度和通知的框架，通过调用成为插件的小型监控程序工作。

退出代码机制（感觉应该翻译为返回码），nagios 对于一切可以提供退出代码的语言都进行支持，共计支持 0 1 2 3 ，分别代表 正常、警告、严重、未知 4种监控结果。nagios根据这些状态码进行反应，决定是否通知谁。（注，从这个机制看IFTTT  这个服务和nagios很像， If this then that-如果这样就怎样。根据不同状态做判断）。 nagios 的的所有调度包括主机和服务的检测，他们都位于一个全局事件队列中，但是并不严格控制绝对的时间，而是通过两个选线组合定义出了了时间间隔，间隔长度、重试间隔。nagios 通过交错因子完成检测的分散负载，部门所有业务检测都集中再一台服务器上。

数据采集包括两种类型，可以并发执行和不能并发执行的。nagios中的服务检测都是可以并发执行的。信息采集事件相当于nagios的心跳，无理论插件执行多快，只要没有出现采集事件，nagios就不会处理这个插件。

通知，如果没有配置过，则每次状态改变nagios都会发出通知，或者是donw足够长后再发送出一次通知。全局通知的启用后，nagios就会进入程序持久化的状态，确保nagios能够保留当期各检测服务的状态。通知选项，主机主要包括：不可达、宕机、恢复、震荡，服务则包括：未知、严重、警告、恢复、震荡。联系人用于设定通知的对象。

模板，可以让定义进行复制，减少文字输入时间。时间段，包括通知发送时间区间和服务检测时间区间。nagios不仅仅是监控系统，更是一套信息收集程序。计划宕机事件、状态确认及升级规则。

作为一本工具书文中也详细描述了nagios的部署以及各种插件集成过程，切实网上也有不少入门教程，相对作者的更易懂，但作者的更为系统和全面。

nagios与商业产品相交互落伍（语法难用），界面太复古，没有时序数据，缺少数据库等等，对于商业用户，他们不愿意百鸟在林（在选择开源插件），更愿意一鸟在手（可靠的解决问的服务）。