产品
解决方案
文档与社区
权益中心
定价
云市场
合作伙伴
支持与服务
了解阿里云
联系我们
4008013260
售前咨询
售后服务
其他服务
我要建议
我要投诉
备案
控制台
开发者社区
首页
探索云世界
探索云世界
云上快速入门,热门云上应用快速查找
了解更多
问产品
动手实践
考认证
TIANCHI大赛
活动广场
活动广场
丰富的线上&线下活动,深入探索云世界
任务中心
做任务,得社区积分和周边
高校计划
让每位学生受益于普惠算力
训练营
资深技术专家手把手带教
话题
畅聊无限,分享你的技术见解
开发者评测
最真实的开发者用云体验
乘风者计划
让创作激发创新
阿里云MVP
遇见技术追梦人
直播
技术交流,直击现场
下载
下载
海量开发者使用工具、手册,免费下载
镜像站
极速、全面、稳定、安全的开源镜像
技术资料
开发手册、白皮书、案例集等实战精华
插件
为开发者定制的Chrome浏览器插件
探索云世界
新手上云
云上应用构建
云上数据管理
云上探索人工智能
云计算
弹性计算
无影
存储
网络
倚天
云原生
容器
serverless
中间件
微服务
可观测
消息队列
数据库
关系型数据库
NoSQL数据库
数据仓库
数据管理工具
PolarDB开源
向量数据库
热门
Modelscope模型即服务
弹性计算
云原生
数据库
物联网
云效DevOps
龙蜥操作系统
平头哥
钉钉开放平台
大数据
大数据计算
实时数仓Hologres
实时计算Flink
E-MapReduce
DataWorks
Elasticsearch
机器学习平台PAI
智能搜索推荐
人工智能
机器学习平台PAI
视觉智能开放平台
智能语音交互
自然语言处理
多模态模型
pythonsdk
通用模型
开发与运维
云效DevOps
钉钉宜搭
支持服务
镜像站
码上公益
开发者社区
开发与运维
文章
正文
开源监控利器nagios--manifold补充版
2017-11-22
835
版权
版权声明:
本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《
阿里云开发者社区用户服务协议
》和 《
阿里云开发者社区知识产权保护指引
》。如果您发现本社区中有涉嫌抄袭的内容,填写
侵权投诉表单
进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
简介:
网友
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域,针对通知的扩展将作用于主机与服务的任何状态之上。
本文转自sery51CTO博客,原文链接: http://blog.51cto.com/sery/189078,如需转载请自行联系原作者
文章标签:
监控
技术小甜
目录
相关文章
我是koten
|
7月前
|
运维
监控
数据库
【运维知识进阶篇】zabbix5.0稳定版详解6(zabbix自动化监控:自动发现+自动注册+监控项目主动式)(上)
【运维知识进阶篇】zabbix5.0稳定版详解6(zabbix自动化监控:自动发现+自动注册+监控项目主动式)
我是koten
151
0
0
我是koten
|
7月前
|
运维
监控
Linux
【运维知识进阶篇】zabbix5.0稳定版详解6(zabbix自动化监控:自动发现+自动注册+监控项目主动式)(下)
【运维知识进阶篇】zabbix5.0稳定版详解6(zabbix自动化监控:自动发现+自动注册+监控项目主动式)(下)
我是koten
100
0
0
我是koten
|
7月前
|
运维
监控
Java
【运维知识进阶篇】Zabbix5.0稳定版详解8(Zabbix监控Java项目+详解JMX与Zabbix-Java-Gateway原理+详解监控Java项目流程原理)
【运维知识进阶篇】Zabbix5.0稳定版详解8(Zabbix监控Java项目+详解JMX与Zabbix-Java-Gateway原理+详解监控Java项目流程原理)
我是koten
188
0
0
我是koten
|
7月前
|
运维
监控
关系型数据库
【运维知识进阶篇】zabbix5.0稳定版详解4(用脚本自定义监控项+监控MySQL状态信息)(一)
【运维知识进阶篇】zabbix5.0稳定版详解4(用脚本自定义监控项+监控MySQL状态信息)
我是koten
95
0
0
我是koten
|
7月前
|
运维
监控
关系型数据库
【运维知识进阶篇】zabbix5.0稳定版详解4(用脚本自定义监控项+监控MySQL状态信息)(二)
【运维知识进阶篇】zabbix5.0稳定版详解4(用脚本自定义监控项+监控MySQL状态信息)(二)
我是koten
67
0
0
科技小先锋
|
网络协议
关系型数据库
Unix
nagios升级要点(从2.x到3.x)
科技小先锋
1207
0
0
余二五
|
监控
网络安全
关系型数据库
监控利器Nagios之二:Nagios的细致介绍和监控外部服务器的私有信息
余二五
1346
0
0
技术小甜
|
Web App开发
监控
Linux
开源监控利器nagios实战(一)
技术小甜
1473
0
0
科技小先锋
|
监控
网络安全
开发工具
监控服务器Nagios之三 监控案例
科技小先锋
1247
0
0
技术小胖子
|
监控
安全
Ossim主要功能实战
技术小胖子
1945
0
0
热门文章
最新文章
1
幻兽帕鲁--游戏服务器阿里云搭建体验:一分钟轻松拥有专属游戏天地
2
通义千问API:用4行代码对话大模型
3
谈谈 RocketMQ 5.0 分级存储背后一些有挑战的技术优化
4
飞书深诺基于Flink+Hudi+Hologres的实时数据湖建设实践
5
芯片竞争格局及最佳匹配场景|开发者分享会
6
ECS热门应用 | 解决Guestosssh异常
7
青团社:亿级灵活用工平台的云原生架构实践
8
掘地三尺搞定 Redis 与 MySQL 数据一致性问题
9
360 企业安全浏览器基于阿里云数据库 SelectDB 版内核 Apache Doris 的数据架构升级实践
10
用AI实现涂鸦变精美画作
1
ECS实例问题之更新镜像后实例启动失败如何解决
55
2
ECS独立站问题之建立独立站如何解决
78
3
ECS网络问题之访问网站失败如何解决
58
4
ECS通知问题之频繁告警如何解决
55
5
ECS绑定问题之使用自带的公网IP绑定ECS如何解决
54
6
阿里云服务器e/u1/c7/c7a/c8a/c8y/g7/g7a/g8a/g8ae实例适用场景汇总
72
7
阿里云服务器实例规格和配置选择参考,根据需求选择云服务器实例规格和配置
63
8
资源编排ROS之模块:实现模板代码复用(进阶篇)
193
9
课程导航 | 学姐领航,共学PolarDB-X:从入门到精通实操课
84
10
淘宝详情数据采集(商品上货,数据分析,属性详情,价格监控),海量数据值得get
76
相关产品
云迁移中心
文档详情
产品详情
相关课程
更多
大数据实战项目:反爬虫系统(Lua+Spark+Redis+Hadoop框架搭建)第四阶段
Linux企业运维实战 - 入门及常用命令
大数据实战项目:反爬虫系统(Lua+Spark+Redis+Hadoop框架搭建)第五阶段
大数据实战项目 - 反爬虫系统(Lua+Spark+Redis+Hadoop框架搭建)第六阶段
大数据实战项目 - 反爬虫系统(Lua+Spark+Redis+Hadoop框架搭建)第七阶段
大数据实战项目:反爬虫系统(Lua+Spark+Redis+Hadoop框架搭建)第一阶段
相关电子书
更多
《Zabbix 监控常用手册》
PHP与APM_技术内幕和最佳实践
Jpom一款低侵入式Java运维、监控软件
相关实验场景
更多
前端开发基础1:前端开发环境的安装和配置
使用阿里云Elasticsearch快速搭建可观测系统
函数计算进阶-IP查询工具开发
下一篇
阿里云学生服务器免费用半年_1个月加6个月_学生验证
注意
下面例子里只给出了服务扩展对象定义,其实主机扩展对象定义也是一样的,当然,主机扩展是给主机对象的,而服务扩展只给服务对象。 :-)
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域,针对通知的扩展将作用于主机与服务的任何状态之上。