监控系统Nagios系列(二) 架构

在监控的世界里,存在太多不可预知性(当然,在当下这个世界里,存在太多不可预知性。也成立:-)),因为监控的对象总是在不断的更新(摩尔定理)。Nagios在设计其架构的时候,充分考虑到了变化这个因素,把可变的与不变的部分隔离,让可变的部分可以定制,可二次开发

当然,不变与可变分离,这个原则很容易理解,但是要实施起来并成功,并不是那么容易。一个好的架构并不是完全设计出来的,最终看到的好的架构,是设计+演进共同达到的。

架构的设计固然十分重要,架构设计是针对软件需要解决问题领域的分析,结合其未来存在的彼变化,给出的一个解决方案。

如果设计错了,就是说问题没有分析清楚,那当然解决不了问题,软件注定是失败的。
但是如果设计没问题,那么最终开发出来的软件架构也不一定就是没问题的。因为世界总是在变化,架构设计出来只是一个静态的结构,在面对新的变化,需要不断的演进。如果演进的不好,那么最终架构也不是一个好架构。

我们套用熵定律,随着时间的流逝熵总是不断增加的(不会减少),那么架构的熵也是如此,我们把架构演进称为架构的逆熵,那么一个好的架构就是不断的逆熵结果。

说了这么多废话,继续回到Nagios的架构。从下面的图开始。

1. Nagios 架构总揽

image

从上到下,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会将这些数据都保存到文件种。

说实话,这种格式确实不好用。

转载请注明:运维派 » 监控系统Nagios系列(二) 架构

0
3.5k
0

最新评论

还没有评论,抢沙发!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>