5 Эскалации
Обзор
Используя эскалации, вы можете создавать пользовательские сценарии для отправки оповещений или выполнения удаленных команд.
С практической точки зрения эскалации означают, что:
- Пользователей можно информировать о новых проблемах незамедлительно
- Оповещения могут повторяться до решения проблемы
- Отправка оповещения может быть выполнена с задержкой
- Оповещения могут эскалироваться другой "более высокой" группе пользователей
- Удаленные команды могут быть выполнены незамедлительно или когда проблема не будет решена за длительный период времени
Действия эскалируются на основании шага эскалации. Каждый шаг имеет длительность по времени.
Вы можете задать и длительность по умолчанию, и пользовательскую длительность для каждого отдельного шага. Минимальная длительность одного шага эскалации 60 секунд.
Вы можете начать действия, такие как отправка оповещения или выполнение команд, с любого шага. Шаг первый используется для немедленных действий. Если вы хотите отложить действие, вы можете назначить его на следующий шаг. Для каждого шага можно назначать несколько действий.
Количество шагов эскалаций не ограничено.
Эскалации задаются при настройке операции. Эскалации поддерживаются только операциями на проблемы, не восстановления.
Различные аспекты поведения эскалаций
Давайте рассмотрим что произойдет при разных обстоятельствах, если действие содержит несколько шагов эскалаций.
| Ситуация | Поведение |
|---|---|
| Узел сети, о котором идет речь, переходит в состояние обслуживания после отправки первоначального оповещения о проблеме | В зависимости от опции Приостановить операции для подавленных проблем в настройках действия, все оставшиеся шаги эскалаций выполнятся либо с задержкой, вызванной периодом обслуживания, или без задержки. Период обслуживания не отменяет операции. |
| Период времени указанный в условии Период времени действия завершается после первоначальной отправки оповещения | Выполнятся все оставшиеся шаги эскалации. Условие Период времени не может прервать операции; это условие имеет влияние в отношении действия началось/не началось, но не имеет влияния на операции. |
| Проблема началась в процессе обслуживания и продолжается (не исправлена) после окончания обслуживания | В зависимости от опции Приостановить операции для подавленных проблем в настройках действия, все шаги выполняются либо с момента завершения обслуживания или сразу же. |
| Проблема началась в процессе обслуживания без сбора данных и продолжается (не исправлена) после окончания обслуживания | Действие должно дождаться пока триггер не перейдет в состояние проблема, до выполнения всех шагов эскалации. |
| Разные эскалации следуют в тесном порядке и перекрываются | Выполнение каждой новой эскалации заменяет предыдущую эскалацию, но по крайней мере для одного шага эскалации, который всегда обязательно выполняется при предыдущей эскалации. Такое поведение тесно связано с действиями на события, которые создаются на КАЖДОЕ вычисление проблемы триггера. |
| В процессе выполнения эскалации (например, во время отправки сообщения), основанном на любом типе событий: - действие деактивировано - событие удалено На основе события на триггер: - триггер деэактивирован или удален - узел сети или элемент данных деактивирован На основе внутреннего события о триггере: - триггер деактивирован или удален На основе внутреннего события о элементах данных/правилах низкоуровневого обнаружения: - элемент данных деактивирован или удален - узел сети деактивирован |
Будет отправлено сообщение, которое уже в процессе отправки, затем будет отправлено еще одно сообщение эскалации. Последующие сообщения будут иметь следующий текст в начале тела сообщения (NOTE: Escalation cancelled) с указанием причины (например, NOTE: Escalation cancelled: action '<Имя действия>' disabled). Таким образом получатель будет проинформирован о том, что эскалация отменена и дальнейшие шаги не будут выполнены. Это сообщение будет отправлено все кто получал оповещения ранее. Причина отмены также будет записана в файл журнала сервера (начиная с уровня отладки 3=Предупреждения). Обратите внимание, что сообщение Escalation canceled также будет отправлено, если все операции завершены, а также операции восстановления настроены, но еще не выполнялись. |
| В процессе выполнения эскалации (например, во время отправки сообщения) удалено действие | Сообщения более не отсылаются. Информация будет записана в файл журнала сервера (начиная с уровня отладки 3=Предупреждения), например: escalation cancelled: action id:334 deleted |
Примеры эскалаций
Пример 1
Отправка повторяющегося уведомления один раз каждые 30 минут (всего 5 раз) группе "MySQL Administrators". Для настройки:
- На вкладке Операции установите Стандартную длительность шага операции в значение "30m" (30 минут).
- Установите Шаги эскалации от "1" до "5".
- Выберите группу "MySQL Administrators" в качестве получателей сообщения.
Уведомления будут отправлены через 0:00, 0:30, 1:00, 1:30, 2:00 часа после начала проблемы (если, конечно, проблема не будет устранена раньше).
Если проблема устранена и настроено сообщение о восстановлении, оно будет отправлено тем, кто получил хотя бы одно сообщение о проблеме в рамках данного сценария эскалации.
Если триггер, создавший активную эскалацию, отключён, Zabbix отправит информационное сообщение об этом всем, кто уже получил уведомления.
Пример 2
Отправка отложенного уведомления о длительно существующей проблеме. Для настройки:
- На вкладке Operations установите Default operation step duration в значение "10h" (10 часов).
- Установите Steps эскалации от "2" до "2".
Уведомление будет отправлено только на шаге 2 сценария эскалации, или через 10 часов после возникновения проблемы.
Вы можете настроить текст сообщения, например: "Проблеме уже более 10 часов".
Пример 3
Эскалация проблемы руководителю.
В первом примере выше мы настроили периодическую отправку сообщений администраторам MySQL. В этом случае администраторы получат четыре сообщения, прежде чем проблема будет эскалирована менеджеру базы данных. Обратите внимание, что менеджер получит сообщение только в том случае, если проблема еще не подтверждена, то есть, предположительно, никто ею не занимается.
Подробности операции 2:
Обратите внимание на использование макроса {ESC.HISTORY} в пользовательском сообщении. Макрос будет содержать информацию обо всех ранее выполненных шагах этой эскалации, таких как отправленные уведомления и выполненные команды.
Пример 4
Более сложный сценарий. После нескольких сообщений Администраторам MySQL и эскалации менеджеру, Zabbix попытается перезапустить базу данных MySQL. Это произойдет, если проблема присутствует еще 2:30 часов и еще не была подтверждена.
Если проблема все еще существует, спустя еще 30 минут Zabbix отправит сообщение всем гостевым пользователям.
Если и это не поможет, спустя еще час Zabbix перезагрузит сервер с этой базой данных MySQL (вторая удаленная команда), используя IPMI команды.
Пример 5
Эскалация с несколькими операциями, у которых диапазоны шагов перекрываются и заданы пользовательские интервалы. Длительность шага операции по умолчанию составляет 30 минут.
Уведомления будут отправлены следующим образом:
- Администраторам MySQL через 0:00, 0:30, 1:00 и 1:30 после начала проблемы.
- Менеджеру базы данных через 2:00 и 2:10 (более короткая пользовательская длительность шага в 10 минут, заданная в последующей операции, переопределяет более длительную длительность шага в 1 час, настроенную здесь, как описано в разделе Сведения об операции для Длительность шага при перекрытии шагов).
- Администраторам Zabbix через 2:00, 2:10 и 2:20 после начала проблемы (применяется пользовательская длительность шага 10 минут).
- Гостевым пользователям через 4:00 после начала проблемы (между шагами 8 и 11 действует длительность шага по умолчанию 30 минут).