nagios是一款开源免费网络监视工具,做运维的朋友们肯定耳熟能详吧,它不但有丰富的插件(可以网络下载,也可以自己编写)满足我们对任何网络设备或服务的监控,不愧是享誉自动化运维界的‘监控之神’!,而且能够在第一时间通过邮件或者短信的方式通知运维人员,我想这是大家最喜爱的功能了,但是nagios到底是在什么情况下触发告警功能的呢,是在service检测出CRITICAL的时候?非也,看了nagios官方文档,下面做了一点总结。
◆ 首先对介绍下nagios配置文件中的几个重要参数
●max_check_attempts 这个参数决定了当一次探测结果为"非OK"时,nagios会重复探测的次数。(例如,当
max_check_attempts=1的时候,若探测结果非"非OK"的值,那么立刻就会生成告警信息,若max_check_attempts=3时,第一次探测为“非OK”nagios还会进行两次探测,若都为“非OK”,那么才生成告警信息)
●retry_interval 如上,当
max_check_attempts 不等于1时,若检测结果为“非OK”那么nagios会继续检测,retry_interval参数就规定了在max_check_attempts 所规定次数内,前后两次检测的间隔时间(默认单位为分钟)
●check_interval 这个参数决定多长时间进行一次完整的检测(从max_check_attemps的第一检查开始),默认单位为分钟
◆概念了解
soft state :当下面的情况出现时,我们可以认为nagios处于soft state状态
●当一个服务或者一台主机的检查结果处于“非OK”或者“非UP”状态,但是对这个服务的检查还没有达到 max_check_attempts 这个指令所规定的次数的时候,这时我们称这个结果为soft error
●当一个服务或者一台主机从一个soft error状态恢复为OK ,我们称这个行为为soft recover
◆当soft error发生或者soft recover事件发生时,nagios会做如下事情
●记录soft state
●事件处理程序被执行,用来处理soft state ,至于什么是事件处理程序(event handlers),这里不做讨论,请参见其他文档。
hard state :当下面的情况出现时,我们可以认为nagios处于hard state状态
●当一个服务或者一台主机,已经执行了max_check_attempts 指令所规定次数的检查,结果为“非OK”或者“非UP”状态,这个状态被称为hard error state
●当一台主机或者一个服务状态有一个hard error state 变为另一个error state(例如从WARNING的hard error state变为CRITICAL)
●当一个服务处于“非OK”的状态,而相应的主机状态为‘DOWN’或者‘UNREACHABLE’的
●当一个服务或者一台主机从一个hard error date中恢复为OK or UP ,这个动作叫做hard recovery
●如果开启了passive check功能,当一个passive check的检测结果被nagios收到,这也是一种hard state的情况,除非 passive_host_checks_are_soft 指令被打开(此时默认passive_check收到结果都为soft state状态)
◆当hard state出现时,nagios会做如下动作
●记录hard state状态
●实践处理程序被执行
●对联系人发送通知
◆被监控的服务最终到底返回什么状态(status)值,取决于下面两个因素
●服务器或者主机的状态监测值(OK,WARNING,UP,DOWN.....)
●服务或主机的state type(hard state;soft state)
下面用一张图表说明什么时候state type 之间进行转换以及什么时候执行事件处理程序,什么时候发送告警信息等, max_check_attempts默认的值为3
time
|
check
#
|
State
|
State type
|
statetypy
change
|
0
|
1
|
OK
|
HARD
|
No
|
这是第一次检测的初始状态为OK,不做任何动作
|
1
|
1
|
CRITICAL
|
SOFT
|
Yes
|
第一次探测到为“非OK”状态,执行事件处理程序执行。
|
2
|
2
|
WARNING
|
SOFT
|
Yes
|
服务依然处于“非OK”状态. 执行事件处理程序.
|
3
|
3
|
CRITICAL
|
HARD
|
Yes
|
执行完max_check_attempts规定的3次检测,服务依然处于“非OK”状态, 服务进入hard state.执行事件处理程序并且发送告警信息。 Check #回复到1
|
4
|
1
|
WARNING
|
HARD
|
Yes
|
服务状态改变到 hard WARNING state. 执行事件处理程序并且发送告警信息 .
|
5
|
1
|
WARNING
|
HARD
|
No
|
因为状态未改变,因此服务稳定在hard problem error状态 . 这时,取决于告警间隔时间,或许有告警信息发送,或许没有.
|
6
|
1
|
OK
|
HARD
|
Yes
|
服务从hard error状态回复. 执行事件处理程序并发送告警信息
|
7
|
1
|
OK
|
HARD
|
No
|
表示服务仍然OK,不执行任何动作
|
8
|
1
|
UNKNOWN
|
SOFT
|
Yes
|
服务进入soft state .执行事件处理程序
|
9
|
2
|
OK
|
SOFT
|
Yes
|
服务完成了soft recovery .执行事件处理程序,因为并不是“真正的”error,不会发送信息 。check # 重新回复到1 。
|
10
|
1
|
OK
|
HARD
|
No
|
服务仍然OK,不做任何动作
|
●check# 表示max_check_attempts中的第几次测试
●state 表示本次测试的返回值
●state type 表示本次返回值类型
●statetype change 表示本次返回值类型相较上次返回值是否改变
●综上,一个服务只有出于hard state的情况下才会出发告警(但不是所有的hard state)。具体分析的话就是当一个服务出于hard state 且探测的返回值(OK、WARNING、CRITICAL.....)与上一次返回值(OK、WARNING、CTICICAL......)不同时才发送告警信息或者告警恢复信息 。
阅读(4496) | 评论(2) | 转发(0) |