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