Documentation
5 Escalations
概述
通过升级功能，您可以为发送通知或执行远程命令定义自定义场景create。
从实际角度来说，这意味着：
- 用户可以立即获知新的问题。
- 通知可以重复发送，直到问题解决。
- 发送通知可以延迟。
- 通知可以升级到另一个“更高”级别的用户组。
- 可以立即执行远程命令，或者在问题长时间未解决时执行。
动作的升级基于升级步骤。每个步骤都有对应的时间持续长度。
您可以定义默认持续时间和个别步骤的自定义持续时间。一个升级步骤的最小持续时间为 60 秒。
您可以从任意步骤开始执行动作，例如发送通知或执行命令。第一步用于立即执行的动作。如果您希望延迟某个动作，可以将其分配到后面的步骤。对于每个步骤，可以定义多个动作。
升级步骤的数量没有限制。
升级操作是在配置操作中定义的。升级仅支持问题处理操作，不支持恢复操作。
升级行为的其他方面
让我们考虑如果一个动作包含多个升级步骤，在不同情况下会发生什么。
| 情况 | 行为 |
|---|---|
| 在初始问题通知发送后，相关主机进入维护状态 | 根据动作中的 暂停抑制问题的操作 设置 配置操作，所有剩余的升级步骤要么因维护期而延迟执行，要么不延迟执行。维护期不会取消操作。 |
| 在初始通知发送后，时间周期动作条件中定义的时间周期结束 | 所有剩余的升级步骤都会执行。时间周期 条件无法停止操作；它仅影响动作的启动与否，不影响操作本身。 |
| 问题在维护期间开始，并在维护结束后仍未解决 | 根据动作中的 暂停抑制问题的操作 设置 配置操作，所有升级步骤要么在维护结束后立即执行，要么立刻执行。 |
| 问题在无数据维护期间开始，并在维护结束后仍未解决 | 必须等待触发器触发后，所有升级步骤才会执行。 |
| 多个升级步骤接连发生并重叠 | 每个新升级的执行将取代前一个升级，但至少会执行前一个升级中的一个升级步骤。这种行为适用于触发器每次问题评估生成事件时触发的动作。 |
| 在升级进行中（例如正在发送消息）时，基于任何类型的事件： - 动作被禁用 基于触发器事件： - 触发器被禁用 - 主机 或 监控项 被禁用 基于触发器的内部事件： - 触发器被禁用 基于 监控项/低级别自动发现规则的内部事件： - 监控项 被禁用 - 主机 被禁用 |
正在发送的消息会完成发送，然后还会发送一条关于该升级的后续消息。后续消息将在消息体开头包含取消文本（注意：升级已取消），并说明取消原因（例如，注意：升级已取消：动作 '<动作名称>' 被禁用）。这样接收者就能知道升级已被取消，后续步骤将不再执行。该消息将发送给所有之前收到通知的人。取消原因也会记录到服务器日志 file 中（从 Debug Level 3=Warning 开始）。 请注意，如果操作已完成，但配置了恢复操作且尚未执行，也会发送 升级已取消 消息。 |
| 在升级进行中（例如正在发送消息）时，动作被删除 | 不再发送任何消息。相关信息将记录到服务器日志 file 中（例如：escalation canceled: action id:334 deleted）（从 Debug Level 3=Warning 开始）。 |
升级示例
示例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 管理员。
- 在问题开始后的 2:00 和 2:10 时间点发送给数据库管理员。 （而不会在 3:00 发送；由于步骤 5 和 6 与下一个操作重叠，下一个操作中较短的自定义步骤持续时间 10 分钟覆盖了此处尝试设置的较长步骤持续时间 1 小时）。
- 在问题开始后的 2:00、2:10、2:20 时间点发送给 Zabbix 管理员（此处使用的是自定义步骤持续时间 10 分钟）。
- 在问题开始后的 4:00 时间点发送给访客用户（步骤 8 和 11 之间恢复使用默认步骤持续时间 30 分钟）。