5 通知升级
概述
通过升级，您可以创建用于发送通知或执行远程命令的自定义场景。
实际来说，这意味着：
- 用户可以立即获知新问题。
- 通知可以重复发送，直到问题被解决。
- 发送通知可以延迟。
- 通知可以升级到另一个“更高”的用户组。
- 远程命令可以立即执行，或者在问题长时间未解决时执行。
操作会根据升级步骤进行升级。每个步骤都有一个持续时间。
您既可以定义默认持续时间，也可以为单个步骤定义自定义持续时间。一个升级步骤的最短持续时间为 60 秒。
您可以从任意步骤开始执行操作，例如发送通知或执行命令。第一步用于立即执行的操作。如果您希望延迟某个操作，可以将其分配到后续步骤。对于每个步骤，都可以定义多个操作。
升级步骤的数量没有限制。
升级是在配置操作时定义的。仅问题操作支持升级，不支持恢复操作。
升级行为的其他方面
让我们来看看，如果一个动作包含多个升级步骤，在不同情况下会发生什么。
| 情况 | 行为 |
|---|---|
| 相关主机在初始问题通知发送后进入维护状态 | 根据动作配置中的 Pause operations for suppressed problems 设置，所有剩余的升级步骤要么因维护期而延迟执行，要么不延迟执行。维护期不会取消操作。 |
| 在初始通知发送后，动作条件中 Time period 定义的时间段结束 | 所有剩余的升级步骤都会执行。Time period 条件不能停止操作；它只影响动作何时启动/不启动，而不影响操作。 |
| 问题在维护期间开始，并在维护结束后继续存在（未恢复） | 根据动作配置中的 Pause operations for suppressed problems 设置，所有升级步骤要么从维护结束时开始执行，要么立即执行。 |
| 问题在无数据维护期间开始，并在维护结束后继续存在（未恢复） | 必须等待触发器触发，然后才会执行所有升级步骤。 |
| 不同的升级紧接着发生并相互重叠 | 每次新升级的执行都会取代前一次升级，但前一次升级中始终至少会执行一个升级步骤。此行为与针对以下事件的动作相关：这些事件是在触发器每次问题评估时都会创建的。 |
| 在升级进行过程中（例如正在发送消息时），基于任意类型事件： - 动作被禁用 基于触发器事件： - 触发器被禁用 - 主机或监控项被禁用 基于有关触发器的内部事件： - 触发器被禁用 基于有关监控项/低级别发现规则的内部事件： - 监控项被禁用 - 主机被禁用 |
正在进行中的消息会被发送，然后该升级还会再发送一条消息。后续消息会在消息正文开头包含取消文本（NOTE: Escalation canceled），并说明原因（例如，NOTE: Escalation canceled: action '<Action name>' disabled）。这样，接收者就会知道该升级已被取消，不会再执行更多步骤。此消息会发送给之前收到通知的所有人。取消原因也会记录到服务器日志文件中（从 Debug Level 3=Warning 开始）。 请注意，如果操作已完成，但已配置恢复操作且尚未执行，也会发送 Escalation canceled 消息。 |
| 在升级进行过程中（例如正在发送消息时）动作被删除 | 不会再发送更多消息。该信息会记录到服务器日志文件中（从 Debug Level 3=Warning 开始），例如：escalation canceled: 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 分钟生效）。