自学Zabbix3.12.6-动做Action-Escalations配置

时间 2019-11-11

标签自学 zabbix3.12.6 zabbix action escalations 配置栏目 Zabbix 繁體版

原文原文链接

3.12.6 自学Zabbix3.12.6-动做Action-Escalations配置

1. 概述

Escalation 的意思是“增大，扩大”，在Zabbix中，它指的意思是一个报警在必定条件下，会执行一些额外的操做，比个比方，一台服务器磁盘满了，可能立刻须要通知的是一线的运维工程师。若是6小时后都没人处理，这个故障且还没恢复，那么可能就要汇报给经理了。或者，PHP进程挂了，可能首先是重启PHP进程，那么若是过了一段时间这个故障尚未恢复（即PHP进程没有重启成功），那么就要通知攻城师来进行恢复了。这是一个报警扩散的过程，即Escalation 。运维

Zabbix中，支持的Escalation有如下几种：post

发生问题后，第一时间通知用户。url
在解决问题前，每隔一段时间就向用户报警。spa
延迟报警。scala
报警能够升级，发送给更多的用户。htm
Remote command能够在时间发生后立刻执行，也能够在必定时间没有解决后才执行。blog
能够向用户发送恢复通知。

能够定义一个“Escalation Step”，意为“扩散步骤”，定义什么时候扩散报警，以及如何扩散。

每个步骤能够定义一个Action和持续时间。步骤要在报警后立刻发出，步骤个数没有限制，Zabbix只会从第一个开始逐个执行。

Escalation是一个比较复杂的机制，特别是跟其余东西结合起来后，下面看一些常见状况：

出问题的Host在发出第一个报警后进入了Maintainence状态：这个Action剩余的Escalation Step都会被执行。Maintainence状态不会中止Operation，只会对Action有关系简单的说，一旦这个Action被执行，那么其中的每一步都会执行。
在Time period中定义的时间在发出第一个报警后就结束了：同（A）中的情形，Time period也只会影响Action执行与否，而不会影响Action中的Operation执行与否。
在Maintainence状态时发生了问题，而且在Maintainence状态结束后依然没有恢复：全部Escalation Step都是从Host（或者其余）结束Maintainence状态后开始。
当Host在no-data Maintainence状态时发生问题，在结束no-date Maintainence状态时，这个问题尚未恢复：Trigger 的触发，必定是先于Escalation Step的开始。
不一样的Escalation Step很是接近相互有重叠的部分：没一个Escalation都会接替以前的Escalation，可是因为步骤（A）是在问题发生后立刻执行的，因此“以前的Escalation”至少会执行一个动做。这些行为跟Evnet 和 Action相关。
在Escalation执行过程当中，Action被禁用了：正在发送过程当中的信息和以后的那一条信息会被发送。其中后面的那条信息会在发送的信息以前加上“NOTE：Escalation cancelled：action‘<Action name>’ disabled”。这样，用户就会知道Action已经被禁用了，以后也不会受到关于这个Action的消息了。

2. 几个示例

示例1：

要求每隔30分钟向“MySQL Administration”的User group发送一次报警，一共发送5次。

在Action的Operation标签中，将“Default operation step duration”（默认操做时间间隔）设置为1800秒，即要求中的30分钟。
在Steps的地方设置为“From 1 to 5”，表示Escalation Step的第一步到第五步都是执行这个操做。
选择“MySQL Administration”组做为发送报警的收件人。

经过这样的设置，假设Action是0点0分触发的，那么在0点30分，1点，1:30，2:00 都会将报警发送给“MySQL Administration”用户组中的全部用户，固然，若是在这个过程当中，Trigger 恢复了，那么就会打断这些事件。

示例2：

若是示例1中的问题一直没有解决，咱们但愿吧这个问题通知到更加资深的DBA，能够进行下面的设置。

在Operation标签中，将默认时间设置为36000秒，即10个小时。
将escalation steps设置为“From 2 to 2”，意思就是只在第（2）步中执行。

在问题发生后，若是10个小时还没恢复，那么这个问题就会通知到资深DBA，能够在发送消息的内容中加上相似“这个问题已经10个小时没有处理”之类的话，提醒收到告警的工程师去解决。

示例3：

当出现问题时，先通知MySQL Administration，若是问题持续10个小时，将这个问题发送给DBA经理，若是还解决不了，会尝试重启数据库。若是依然解决不了，那么只能邮件通知用户，最后使用IPMI命令，重启MySQL服务器。

示例4：

最后看一个自定义Duration的例子，先看是如何设置Action的。

假设问题是在00:00发生的，那么它的执行顺序以下。

在00:00、00:30、01:00、01:30 会向Zabbix administrators用户组发送邮件，这是因为咱们设置了默认的时间间隔是1800秒，即30分钟。
在02:00 和 02:10向Admin发送邮件。
在02:00 、02:10 和 02:20 执行远程命令。
在04:00 向Admin 发送邮件。

这里有几个理解起来比较麻烦的地方，一个是在图中，只有02:00 和 02:10 时才会向 Admin发送邮件，而不会在03:00，这是由于在图中 5-6和5-7都设置了Operation，那么5-7中设置的600秒就会覆盖5-6中设置的3600秒。在条目3中，由于设置的600秒生效，因此每隔10分钟向Admin发送一次邮件。在条目4中，因为通过了八、九、十、11则这4个Step，因此是默认的30分钟的4倍，即2个小时，到04:00，向Admin发送报警。