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......)不同时才发送告警信息或者告警恢复信息 。
阅读(4510) | 评论(2) | 转发(0) |
