设为首页 收藏本站
查看: 1203|回复: 0

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

[复制链接]

尚未签到

发表于 2019-1-17 09:04:18 | 显示全部楼层 |阅读模式
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域,针对通知的扩展将作用于主机与服务的任何状态之上。


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-664225-1-1.html 上篇帖子: nagios扩展开发之check_ping 下篇帖子: nagios 监控运用(一)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表