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