在监控的世界里，存在太多不可预知性（当然，在当下这个世界里，存在太多不可预知性。也成立:-)），因为监控的对象总是在不断的更新（摩尔定理）。Nagios在设计其架构的时候，充分考虑到了变化这个因素，把可变的与不变的部分隔离，让可变的部分可以定制，可二次开发。
当然，不变与可变分离，这个原则很容易理解，但是要实施起来并成功，并不是那么容易。一个好的架构并不是完全设计出来的，最终看到的好的架构，是设计＋演进共同达到的。
架构的设计固然十分重要，架构设计是针对软件需要解决问题领域的分析，结合其未来存在的彼变化，给出的一个解决方案。
如果设计错了，就是说问题没有分析清楚，那当然解决不了问题，软件注定是失败的。
但是如果设计没问题，那么最终开发出来的软件架构也不一定就是没问题的。因为世界总是在变化，架构设计出来只是一个静态的结构，在面对新的变化，需要不断的演进。如果演进的不好，那么最终架构也不是一个好架构。
我们套用熵定律，随着时间的流逝熵总是不断增加的（不会减少），那么架构的熵也是如此，我们把架构演进称为架构的逆熵，那么一个好的架构就是不断的逆熵结果。
说了这么多废话，继续回到Nagios的架构。从下面的图开始。
1. Nagios 架构总揽
从上到下，Nagios架构的几个组成部件：
Web Interface: Nagios的Web页面，Nagios的Web容器是Apache HTTPD，Nagios开发了一个HTTPD模块，并提供Web页面。Web Interface与Nagios Daemon之间通过文件接口交互，Web逻辑读取Nagios的状态文件(status.dat)，展示其监控信息。
Nagios Daemon: Nagios的主部件，实现了监控，性能，通知，事件处理功能。这些功能都是抽象的逻辑和调度，并没有实际的与设备交互的监控实现，与设备的交互都是在下面一层的Plugin种实现的，这些就是Nagios认为可变部分。
Plugins: 各种与设备交互获取状态或性能数据的实现。Nagios目前有2千多个插件。Nagios通过定义插件的抽象规范，将监控逻辑与实现隔离，也就是变与不变隔离。
Notification Commands: 通知命令。Nagios的Notification也是抽象的，具体的通知实现由Notification Commands实现，Notification Commands可以是一个短信猫，邮件客户端等，负责以各种形式将状态通知到外部。
Event Handlers: 事件处理的存在也是变与不变的博弈结果。Nagios允许用户通过事件处理机制来干预其监控调度和结果。比如Nagios给对象的状态分了Hard, Soft两种类型，Soft状态类型表示一个中间状态，不是最终状态，每次状态变化，Nagios都会回调二次开发者注册的事件处理函数，二次开发者在事件处理函数种判断如果是Soft状态类型，可以尝试自动修复对象的状态。
Performance Processors: 性能处理也是变与不变的结果（这是我最后一次说变与不变，不用再忍耐了：—)）。Nagios允许插件输出性能数据，并会将性能数据保存到性能文件种。但是Nagios自身理解不了插件输出的性能数据，因此，提供 Performance Processor 让开发者定义性能处理函数。
图中最下面一层是Nagios的对象，下面我们就开始介绍Nagios的对象模型。
2. Nagios Objects
Nagios的模型很简单，因为简单才接近真理，只有真理才是不变的，不变就是Nagios的设计目标。是不是很无厘头？
Nagios的对象有：
- Host & Host Group & Host Dependency
Host是一个监控世界里的物理对象。如一台主机，一台以太网交换机等，都是Host。 Host之间可以通过use关键字继承属性。避免重复属性定义。
Host Dependency 是Host之间的依赖，与组网相关。 - Service & Service Group & Service Dependency
Service 是属于Host的服务，比如POP3，HTTPD，自己开发的服务等，都可以定义为Service。 Service Dependency 用来定义Service之间的依赖，假设你将操作系统的0号进程定义为一个Service，那么所有的其他Service都依赖此Service。
- Contact & Contact Group
联系人。通知使用的。联系人可以定义Command的属性，用来实现具体的通知。
- Time Period
时间周期。方便监控世界里描述时间而预定义一些时间段。比如三月的每个周日 12:00，停机。其中三月的每个周日 12:00就是一个时间周期。
- Command
上面的所有对象都是抽象的，与监控设备无关的。只有Command是需要与具体的监控设备交互的。Command可以属于Service或Host。Command的存在是为了使得Service和Host可以抽象定义。比如 Ping 就是一个Command，可以被绑定到所有的Host上，用于检测Host的连通性，而不用每个Host实现一个Ping。
3. 宏
抽象是有代价的。
抽象程度越高，信息量越大，不确定性越多。
上面的Ping Command例子，当此Command被绑定到了多个Host，那么运行时，次Command如何得知，该Ping哪个IP地址？
Nagios通过宏解决这个问题：
Ping -c 8 -H $HOSTADDRESS ...
上面的 $HOSTADDRESS 就是一个宏，代表 Command 在执行时所属的Host的IP地址。Nagios在执行此Command的之前，会预编译，将宏替换为实际的值。
用户可以自定义宏，如何定义后续介绍。
4. 对象状态定义
上面列出的Nagios对象，只有Host和Service是监控实体对象，有状态。其他对象都是辅助监控而存在的。
Host状态定义为：UP, DOWN, UNREACHABLE
Service 状态定义为：OK, WARNING, UNKNOWN, CRITICAL
5. 插件定义规则
Nagios的插件与语言无关，只要是一个可执行文件即可，并同时满足下面两个条件即可。
- 返回值
插件的返回值可以是：0，1，2，3，其意义分别为：OK，WARNING，CRITICAL，UNKNOWN。
Nagios依据插件的返回值判定对象的状态，插件返回值与对象状态之间的关系为：
插件返回值Host 状态Service 状态
| 0 | UP | OK |
| 1 | UP or DOWN/UNREACHABLE | WARNING |
| 2 | DOWN/UNREACHABLE | CRITICAL |
| 2 | DOWN/UNREACHABLE | WARNING |
关于第二行第二列的值后续解释。
- 屏幕输出
屏幕输出的格式为：
TEXT OUTPUT | OPTIONAL PERFDATA
LONG TEXT LINE 1
LONG TEXT LINE 2
...
LONG TEXT LINE N | PERFDATA LINE 2
PERFDATA LINE 3
...
PERFDATA LINE N
上面的输出描述为：
描述信息 | 性能数据
长文本描述信息1
长文本描述信息2
...
长文本描述信息N | 性能数据
性能数据
...
性能数据
Nagios会将这些数据都保存到文件种。
说实话，这种格式确实不好用。
本文链接：http://www.yunweipai.com/2971.html
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/53198.html