Table of Contents
4 Escalations
概述
通过Escalations，您可以创建发送通知或执行远程命令的自定义场景。
实际应用中，这意味着：
- 用户可以立即收到新问题通知
- 通知可以重复，直到问题解决
- 发送通知可以延时
- 通知可以升级到另一个“较高”的用户组
- 可以立即执行远程命令，或者长时间不解决问题
操作会根据升级步骤进行升级。 每一步都有一段时间.
您可以定义默认持续时间和单个步骤的自定义持续时间。一个升级步骤的最短持续时间为60秒。
您可以从任何步骤开始执行操作，例如发送通知或执行命令。 第一步是立即采取行动。 如果要延迟操作，可以将其分配给稍后的步骤。 对于每个步骤，可以定义几个操作。
升级步骤的数量不受限制。
配置操作是即可定义Escalations. Escalations仅对问题操作支持，而不是恢复.
Escalations的其他方面
让我们考虑如果一个操作包含几个升级步骤，在不同的情况下会发生什么。
| 情况 运 | |
|---|---|
| 在发送初始问题通知后，所涉及的主机进入维护状态 取决于action[配置](/manual/ | onfig/notifications/action/operation#configuring_an_operation)中设置的在维护期间暂停操作 , 所有剩余的升级步骤都由维护期间或延迟引起的延迟执行。 维护期不能取消操作。 |
| 在时间段操作条件中定义的时间段在发送初始通知后结束 执行所有剩余的升级步骤。 时间段 条件不能停 | 操作; 它对于何时启动/未启动操作而不是操作具有效果。 |
| 维护过程中出现问题，维护结束后继续（未解决） 取决于action[配置](/manual | config/notifications/action/operation#configuring_an_operation)中在维护期间暂停操作 的设置，所有升级步骤都可以从维护结束或立即执行。 |
| 在无数据维护期间会出现问题，并在维护结束后继续（未解决） 在执行所有升级步骤之前，必须等待触发器触发。 | |
| 不同的升级紧随其后并重叠 每个新的升级的执行取代 | 前的升级，但是至少一个升级步骤总是在以前的升级中执行。 在针对触发器的每个事件评估创建的事件的操作中，此行为都是相关的。 |
| 在升级过程中（如正在发送的消息），基于任何类型的事件： 发送正在发送的消息，然后再发送一条关于升级的消息。后- 该操作被禁用 - 该事件被删除 基于触发事件： - 触发器被禁用或删除 - 主机或项目被禁用 基于关于触发器的内部事件： - 触发器被禁用或删除 基于关于项目/低级发现规则的内部事件： - 该项目被禁用或删除 - 主机被禁用 |
消息将在邮件正文的开头有取消文本（注意：取消邮件已取消) 命名原因（例如，注意：取消升级：动作'<动作名称>'禁用）。 通过这种方式，收件人被通知升级被取消，不再执行任何步骤。 此消息将发送给接收通知的所有人员。 取消的原因也记录到服务器日志文件中(从Debug Level 3=Warning)开始。 |
| 在升级过程中（如发送消息），删除该操作 不再发送消息。 信息被记录到服务器日 | 文件 (从Debug Level 3=Warning)开始, 例如: escalation cancelled: action id:334 deleted |
Escalation 示例
示例 e 1
Sending a repeated notification once every 30 minutes (5 times in total) to a 'MySQL Administrators' group. To configure:
- in Operations tab, set the Default operation step duration to '1800' seconds (30 minutes)
- Set the escalation steps to be From '1' To '5'
- Select the 'MySQL Administrators' group as recipients of the message
Notifications will be sent at 0:00, 0:30, 1:00, 1:30, 2:00 hours after the problem starts (unless, of course, the problem is resolved sooner).
If the problem is resolved and a recovery message is configured, it will be sent to those who received at least one problem message within this escalation scenario.
If the trigger that generated an active escalation is disabled, Zabbix sends an informative message about it to all those that have already received notifications.
示例 2
Sending a delayed notification about a long-standing problem. To configure:
- In Operations tab, set the Default operation step duration to '36000' seconds (10 hours)
- Set the escalation steps to be From '2' To '2'
A notification will only be sent at Step 2 of the escalation scenario, or 10 hours after the problem starts.
You can customize the message text to something like 'The problem is more than 10 hours old'.
示例 3
Escalating the problem to the Boss.
In the first example above we configured periodical sending of messages to MySQL administrators. In this case, the administrators will get four messages before the problem will be escalated to the Database manager. Note that the manager will get a message only in case the problem is not acknowledged yet, supposedly no one is working on it.
Note the use of {ESC.HISTORY} macro in the message. The macro will contain information about all previously executed steps on this escalation, such as notifications sent and commands executed.
示例 4
A more complex scenario. After multiple messages to MySQL administrators and escalation to the manager, Zabbix will try to restart the MySQL database. It will happen if the problem exists for 2:30 hours and it hasn't been acknowledged.
If the problem still exists, after another 30 minutes Zabbix will send a message to all guest users.
If this does not help, after another hour Zabbix will reboot server with the MySQL database (second remote command) using IPMI commands.
示例 5
An escalation with several operations assigned to one step and custom intervals used. The default operation step duration is 30 minutes.
通知将发送如下：
- to MySQL administrators at 0:00, 0:30, 1:00, 1:30 after the problem starts
- to Database manager at 2:00 and 2:10 (and not at 3:00; seeing that steps 5 and 6 overlap with the next operation, the shorter custom step duration of 600 seconds in the next operation overrides the longer step duration of 3600 seconds tried to set here)
- to Zabbix administrators at 2:00, 2:10, 2:20 after the problem starts (the custom step duration of 600 seconds working)
- to guest users at 4:00 hours after the problem start (the default step duration of 30 minutes returning between steps 8 and 11)