开源监控利器nagios--manifold补充版

网友manifold的补充

 

Nagios支持对主机与服务所对应联系人通知的对象扩展。主机与服务中有关通知的对象扩展是由对象定义文件里的主机扩展对象和服务扩展对象来声明的。

注意

下面例子里只给出了服务扩展对象定义，其实主机扩展对象定义也是一样的，当然，主机扩展是给主机对象的，而服务扩展只给服务对象。 :-)
8.9.2. 什么时候做通知扩展？
通知扩展将会且仅会在一个或多个扩展对象与当前要送出的通知相匹配时才做。如果主机与服务的通知与对象扩展不匹配任何一个合法的对象扩展，不会有主机或服务的对象扩展被应用于当前的通知过程中。见下面的例子：


define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      3
     last_notification      5
     notification_interval      90
     contact_groups            nt-admins,managers
}
define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      6
     last_notification      10
     notification_interval      60
     contact_groups            nt-admins,managers,everyone
}
要注意有一个通知的对象扩展定义的“孔洞”(空白区间)。也就是第1与第2个通知不会被扩展对象处理，对于超出10的通知也不会处理。对于第1和第2次通知，与全部的通知一样将使用服务对象里的默认联系人组里的联系人做对象通知。在例子中，假定服务对象定义里的默认的联系人组是名为nt-admins的联系人组。

8.9.3. 联系人组
当定义了通知相关的对象扩展，很重要的一点是要记得“低级别”对象扩展里的联系人组一定要出现在“高级别”对象扩展里的联系人组。这样才会确保每一个将要收到故障通知的人在故障不断扩张的情况下会持续地收到通知。例如：


define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      3
     last_notification      5
     notification_interval      90
     contact_groups            nt-admins,managers
}
define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      6
     last_notification      0
     notification_interval      60
     contact_groups            nt-admins,managers,everyone
}
第一个("低级别")档次的扩展包括了nt-admins和managers两个联系人组。后一个("高级别")档次的扩展包括了nt-admins、managers和everyone等三个联系人组。注意，nt-admins这个联系人组被包含在两个档次的扩展里，这样做可以使这个联系人组的成员可以在前两个通知送达后仍旧可以接到后序的通知。managers联系人组最初是在第一个档次("低级别")的扩展里出现－里面的成员会在第三个通知开始送出时收到通知。肯定是希望managers组里的联系人可持续地收到之后的通知(如果第5次故障通知还在的话)，因而这个组也加到了第2("高级别")档次的扩展定义里了。

8.9.4. 扩展范围的覆盖
关于通知的对象扩展可以被覆盖，见下面的例子：


define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      3
     last_notification      5
     notification_interval      20
     contact_groups            nt-admins,managers
}
define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      4
     last_notification      0
     notification_interval      30
     contact_groups            on-call-support
}
在上例中，

nt-admins和managers两个联系人组将在第3次通知开始时收到通知；
全部的三个联系人组将在第4和第5次通知时收到通知；
仅仅是on-call-support联系人组会在第6次及之后的通知送出时收到通知。
8.9.5. 恢复的通知
当通知被扩展的时候，恢复通知会因故障通知状态不同而稍有不同，见下例：


define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      3
     last_notification      5
     notification_interval      20
     contact_groups            nt-admins,managers
}
define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      4
     last_notification      0
     notification_interval      30
     contact_groups            on-call-support
}
如果在第3次故障通知之后服务检测后要送出一个恢复通知，那么谁会收到通知？事实上，这个恢复通知应该算是第4个通知，然而Nagios的通知扩展代码会“聪明地判断出”其实只有收到第3次通知的联系人组才应该收到这个恢复通知。这时，nt-admins和managers联系人组将收到这个恢复通知。(译者注：那个on-call-support组里的联系人不会收到！)

8.9.6. 通知间隔
还可以修改对指定主机与服务通知的送出频度，用主机扩展与服务扩展对象定义里的notification_interval域来指定不同的频度。如下例：


define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      3
     last_notification      5
     notification_interval      45
     contact_groups            nt-admins,managers
}
define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      6
     last_notification      0
     notification_interval      60
     contact_groups            nt-admins,managers,everyone
}
这个例子中，这个服务的默认通知送出间隔是240分钟(该值是在服务对象定义里设置的)。当该服务的通知被扩展到第3、第4和第5次时，每次通知的间隔将是45分钟。在第6次及之后，通知间隔将变成60分钟，这个是在第2个的服务扩展对象里定义的。

既然主机与服务的对象扩展有可能覆盖，而且某个主机事实上有可能从属于多个主机组，那么Nagios就不得不就在通知间隔有覆盖的情况下取哪个通知间隔做个决定。当对于一个服务通知存在有多个合法有效的对象扩展定义时，Nagios将会取其中最小的通知间隔来做为间隔。见下例：


define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      3
     last_notification      5
     notification_interval      45
     contact_groups            nt-admins,managers
}
define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      4
     last_notification      0
     notification_interval      60
     contact_groups            nt-admins,managers,everyone
}
该例中有针对第4和第5次通知，有两个对象扩展相互覆盖。这两次通知间隔里，Nagios的通知间隔将是45分钟，因为当这几次通知要送出时在现有的合法有效的服务对象扩展里这个值最小。


define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      3
     last_notification      5
     notification_interval      45
     contact_groups            nt-admins,managers
}
define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      4
     last_notification      6
     notification_interval      0
     contact_groups            nt-admins,managers,everyone
}
define serviceescalation{
     host_name            webserver
     service_description      HTTP
     first_notification      7
     last_notification      0
     notification_interval      30
     contact_groups            nt-admins,managers
}
在上例中，故障通知的最大次数是在4。这是因为第二档次的服务对象扩展里的通知间隔值是0，因而(当第4次通知将要被送出时)只会送出一个通知而之后通知被抑制。因此，在第4次通知送出后第三个服务扩展对象无论如何也不会起作用了。

8.9.7. 时间周期的限制
通常的情况下，对通知的对象扩展可以用于任意想要送出主机与服务通知的时刻。这个"通知时间窗口"取决于主机与服务对象定义里的notification_period域值。

可以用主机扩展与对象扩展里的escalation_period域来指定一个特定时间周期使得扩展被限定只处于某个特定时间段内。使用escalation_period域来指定某个时间周期里对象扩展是可用的，对象扩展将只是在指定的时间里可用。如果没有在escalation_period域里指定时间周期，主机扩展与服务扩展将会在"通知时间窗口"内的任意时间里是可用的。

注意

通知扩展依旧会受限于主机与服务对象定义里的notification_period域所指定的时间周期，因而特定的对象扩展里的时间周期是一个更大范围"通知时间窗口"的子集。
8.9.8. 状态限制
如果想只是想用特定的主机与服务的状态限定针对通知的扩展，可以用主机扩展和服务扩展对象里的escalation_options域来指定。如果没有指定escalation_options域，针对通知的扩展将作用于主机与服务的任何状态之上。