5 通知升级
概述
通过Escalations，您可以创建发送通知或执行远程命令的自定义场景。
实际应用中，这意味着：
- 用户可以立即收到新问题通知
- 通知可以重复，直到问题解决
- 发送通知可以延时
- 通知可以升级到另一个“较高”的用户组
- 可以立即执行远程命令，或者长时间不解决问题
操作会根据升级步骤进行通知升级。 每一步都有一段时间。
您可以定义默认持续时间和单个步骤的自定义持续时间。一个升级步骤的最短持续时间为60秒。
您可以从任何步骤开始执行操作，例如发送通知或执行命令。 第一步是立即采取行动。 如果要延迟操作，可以将其分配给稍后的步骤。 对于每个步骤，可以定义几个操作。
通知升级步骤的数量不受限制。
配置操作是即可定义Escalations. Escalations仅对问题操作支持，而不是恢复。
升级行为的其他方面
让我们考虑一下在不同情况下会发生什么。
包含几个升级步骤。
| 情境 | 行为 |
|---|---|
| 在发送初始问题通知后，相关主机进入维护状态 | 取决于操作配置中的暂停操作抑制问题设置，所有剩余的升级步骤都会在维护期间造成延迟的情况下或不延迟地执行。维护期不会取消操作 |
| 在时间段操作条件中定义的时间段在发送初始通知后结束 | 执行所有剩余的升级步骤。时间段条件不能停止操作；它对操作何时启动/未启动而非操作具有影响 |
| 问题在维护期间开始，并在维护结束后继续(未解决) | 根据操作配置中的暂停被抑制问题的操作设置，所有升级步骤从维护结束时起或立即执行 |
| *问题在无数据维护期间开始，并在维护结束后继续(未解决) | 必须等待触发，然后执行所有上报步骤 |
| 不同的升级紧随其后并重叠 | 每个新升级的执行都会取代上一个升级，但至少有一个升级步骤总是在上一个升级上执行。这种行为与对触发器的每个问题评估产生的事件的操作相关 |
| 在升级过程中(如发送消息)，基于任何类型的事件： -基于触发器事件禁用操作： -禁用触发器 -基于内部事件禁用主机或项目关于触发器： -基于内部事件关于项目/低级发现规则禁用触发器： -禁用项目 -禁用主机 |
发送正在进行的消息，然后在升级已发送。后续消息将在消息正文的开头显示取消文本(注意：升级已取消)以命名原因(例如，注意：升级已取消：操作“<action name>”已禁用)。通过这种方式，收件人将被告知升级已取消，不再执行任何步骤。此消息将发送给之前收到通知的所有人。取消的原因也会记录到服务器日志文件中(从[Debug Level]开始)(/manual/appendix/config/zabbix_server)3=警告) 请注意，如果操作已完成，但恢复操作已配置且尚未执行，则也会发送Escalation Cancelled消息 |
| 在升级过程中(如发送消息)，操作被删除 | 不再发送消息。信息被记录到服务器日志文件中(从[Debug Level]开始)(/manual/appendix/config/zabbix_server)3=Warning)，例如：escalation Cancelled:action id:334 deleted |
升级示例
示例 1
每 30 分钟向 “MySQL Administrators” 组发送一次重复通知（总共 5 次）。 配置方法如下：
- 在 Operations 选项卡中，将 Default operation step duration 设置为 “30m”（30 分钟）。
- 将升级的 Steps 设置为从 “1” 到 “5”。
- 选择 “MySQL Administrators” 组作为消息接收者。
通知将在问题开始后的 0:00、0:30、1:00、1:30、2:00 发送（当然，除非问题更早得到解决）。
如果问题已解决并且配置了恢复消息，则恢复消息将发送给在此升级场景中至少收到过一条问题消息的人员。
如果生成活动升级的触发器被禁用，Zabbix 会向所有已经收到通知的人员发送一条相关提示消息。
示例 2
发送关于长期存在问题的延迟通知。配置方法如下：
- 在 操作 选项卡中，将 默认操作步骤持续时间 设置为“10h”（10 小时）。
- 将升级的 步骤 设置为从“2”到“2”。
通知只会在升级场景的第 2 步发送，也就是在问题开始 10 小时后发送。
您可以将消息文本自定义为类似“该问题已持续超过 10 小时”的内容。
示例 3
将问题升级给老板。
在上面的第一个示例中，我们配置了定期向 MySQL 管理员发送消息。在这种情况下，在问题升级给数据库经理之前，管理员将收到四条消息。请注意，只有在问题尚未被确认的情况下，经理才会收到消息，这意味着可能还没有人正在处理该问题。
操作 2 的详细信息：
请注意在自定义消息中使用了 {ESC.HISTORY} 宏。该宏将包含有关此升级中之前所有已执行步骤的信息，例如已发送的通知和已执行的命令。
例4
更复杂的情况。在向MySQL管理员发送多条消息并升级到manager后，Zabbix将尝试重新启动MySQL数据库。如果问题存在2:30小时，但尚未确认，则会发生这种情况。
如果问题仍然存在，30分钟后，Zabbix将向所有来宾用户发送消息。
如果这没有帮助，再过一个小时，Zabbix将使用IPMI命令使用MySQL数据库（第二个远程命令）重新启动服务器。
示例 5
一个升级，包含多个操作，这些操作具有重叠的步骤范围和自定义间隔。默认的操作步骤持续时间为 30 分钟。
通知将按如下方式发送：
- 在问题开始后的 0:00、0:30、1:00 和 1:30，发送给 MySQL 管理员。
- 在 2:00 和 2:10，发送给 Database manager（后续操作中定义的较短自定义步骤持续时间 10 分钟，会覆盖此处配置的较长步骤持续时间 1 小时，正如 操作详情 中关于 步骤持续时间 在步骤重叠时的说明）。
- 在问题开始后的 2:00、2:10 和 2:20，发送给 Zabbix 管理员（应用 10 分钟的自定义步骤持续时间）。
- 在问题开始后的 4:00，发送给 guest users（在步骤 8 到 11 之间，默认步骤持续时间 30 分钟生效）。