Nagios/OMD 中一小时后发出警报的联系组

Nagios/OMD 中一小时后发出警报的联系组

我正在尝试为以下场景找到解决方案。

我在 Nagios 中拥有几百个服务(OMD 安装了 check_mk 和其他有用的工具),它们被定义为不同的服务类型,因此对于不同的类型,我有不同的联系人组,当出现问题时他们会收到警报。

它运行良好,但如果服务在 1 小时后处于关键状态且尚未得到确认/评论等,我想调用一个脚本。

我在参考文档中没有找到任何内容。

提前谢谢你的帮助

典型服务类型:

define contact{
    contact_name                    level1          ; Short name of user
    use                             generic-contact         ; Inherit default values from
    alias                           Gravity Level1          ; Full name of user
    email                           [email protected]         ; email for alerting
    }

define contactgroup{
    contactgroup_name       defcon3
    members                 level1, level2
    }

 define service{
   name                            defcon3-service         ; The 'name' of this service template
   active_checks_enabled           0                       ; Active service checks are enabled
   passive_checks_enabled          1                       ; Passive service checks are enabled/accepted
   obsess_over_service             1                       ; We should obsess over this service (if necessary)
   check_freshness                 0                       ; Default is to NOT check service 'freshness'
   notifications_enabled           1                       ; Service notifications are enabled
   event_handler_enabled           1                       ; Service event handler is enabled
   flap_detection_enabled          1                       ; Flap detection is enabled
   failure_prediction_enabled      1                       ; Failure prediction is enabled
   process_perf_data               1                       ; Process performance data
   retain_status_information       1                       ; Retain status information across program restarts
   retain_nonstatus_information    1                       ; Retain non-status information across  
   is_volatile                     0                       ; The service is not volatile
   check_period                    24x7                    ; The service can be checked at any time of the day
   max_check_attempts              3                       ; Re-check the service up to 3 times in order to 
   normal_check_interval           2                       ; Check the service every 10 minutes under normal 
   retry_check_interval            1                       ; Re-check the service every two minutes until a
   notification_options            w,u,c,r                 ; Send notifications about warning, unknown, 
   notification_interval           60                      ; Re-notify about service problems every hour
   notification_period             24x7                    ; Notifications can be sent out at any time
   contact_groups                  defcon3                 ; default mail to monitoring -v-
   register                        0                       ; DONT REGISTER THIS DEFINITION - ITS NOT A R
}

 define service {
    use                           check_mk_passive_perf
    use                           defcon3-service
    host_name                     gravity-mon
    service_description           CPU load
    contact_groups                +defcon3
    service_groups                +defcon3
    check_command                 check_mk-cpu.loads
}

答案1

我不想直接反驳另一个人的意见,但 NAGIOS 确实可以做到这一点:你正在寻找的内容在文档中被称为通知升级

正如纪录片所说,

当且仅当一个或多个升级定义与当前发出的通知相匹配时,通知才会升级。如果主机或服务通知没有任何有效的升级定义,则主机组或服务定义中指定的联系人组将用于通知。

HTTP因此,如果您在主机上调用了一项服务webserver,该服务通常会sysadmins每 30 分钟(比如说)向小组发出一次故障警报,并且您希望在第三次警报未得到确认且未得到修复时让小组managers知道该情况,您可以尝试:

define serviceescalation{
    host_name           webserver
    service_description HTTP
    first_notification  3
    last_notification   5
    contact_groups      nt-admins,managers
    }

就您而言,您不想通知其他人,而是调用脚本。为此,您需要定义一个新的联系人组,其中包含一名成员,该成员具有service_notification_commmand(例如) /usr/local/bin/my-webserver-handling-script

如果您不想重复调用该脚本,您需要进行调整,first_notification以便last_notification此特定升级仅应用一次。

我还要提醒你不要这样做。我个人不赞成通知系统也成为事件处理系统;我认为它们应该让人类知道某些事情出了问题,然后让人类来处理,原因如下:根据定义,NAGIOS 只会在事情发生时提醒人们不是进展顺利。如果你要自动处理这个问题,你需要极其确保它们以正确的方式失败。例如,如果您要使用此脚本对 Web 服务器进行电源循环,那么您最好非常确定您已正确设置所有主机依赖项,​​以便中间路由器的故障不会导致您的 Web 服务器开始疯狂重新启动,从而导致文件系统损坏,您必须在修复路由器后处理此问题。

相关内容