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