Documentation
Table of Contents
5 Эскалации
Обзор
Используя эскалации, вы можете создавать пользовательские сценарии для отправки оповещений или выполнения удалённых команд.
С практической точки зрения эскалации означают, что:
- Пользователей можно информировать о новых проблемах незамедлительно
- Оповещения могут повторяться до решения проблемы
- Отправка оповещения может быть выполнена с задержкой
- Оповещения могут эскалироваться другой "более высокой" группе пользователей
- Удалённые команды могут быть выполнены незамедлительно или когда проблема не будет решена за длительный период времени
Действия эскалируются на основании шага эскалации. Каждый шаг имеет длительность по времени.
Вы можете задать и длительность по умолчанию, и пользовательскую длительность для каждого отдельного шага. Минимальная длительность одного шага эскалации 60 секунд.
Вы можете начать действия, такие как отправка оповещения или выполнение команд, с любого шага. Шаг первый используется для немедленных действий. Если вы хотите отложить действие, вы можете назначить его на следующий шаг. Для каждого шага можно назначать несколько действий.
Количество шагов эскалаций не ограничено.
Эскалации задаются при настройке операции. Эскалации поддерживаются только для операций на проблемы, но не восстановления.
Различные аспекты поведения эскалаций
Давайте рассмотрим, что произойдёт при разных обстоятельствах, если действие содержит несколько шагов эскалаций.
| Ситуация | Поведение |
|---|---|
| Узел сети, о котором идёт речь, переходит в состояние обслуживания после отправки первоначального оповещения о проблеме | В зависимости от опции Приостановить операции для подавленных проблем в настройках действия, все оставшиеся шаги эскалаций выполнятся либо с задержкой, вызванной периодом обслуживания, либо без задержки. Период обслуживания не отменяет операции. |
| Период времени, указанный в условии Период времени действия, завершается после первоначальной отправки оповещения | Выполнятся все оставшиеся шаги эскалации. Условие Период времени не может прервать операции; это условие влияет на то, когда начинается или не начинается действие, а не операция. |
| Проблема началась в течение периода обслуживания и продолжается (не исправлена) после окончания обслуживания | В зависимости от опции Приостановить операции для подавленных проблем в настройках действия, все шаги выполнятся либо с момента завершения обслуживания, либо сразу же. |
| Проблема началась в течение периода обслуживания без сбора данных и продолжается (не исправлена) после окончания обслуживания | Прежде чем выполнятся все шаги эскалаций, нужно дождаться срабатывания триггера. |
| Разные эскалации следуют в тесном порядке и перекрываются | Выполнение каждой новой эскалации заменяет предыдущую эскалацию, но по крайней мере для одного шага эскалации, который всегда обязательно выполняется при предыдущей эскалации. Такое поведение уместно для действий на события, которые создаются на КАЖДОЕ вычисление проблемы триггера. |
| В процессе выполнения эскалации (например, во время отправки сообщения), основанном на любом типе событий: - действие деактивировано На основе события на триггер: - триггер деактивирован - узел сети или элемент данных деактивирован На основе внутреннего события о триггере: - триггер деактивирован На основе внутреннего события об элементах данных/правилах низкоуровневого обнаружения: - элемент данных деактивирован - узел сети деактивирован |
Будет отправлено сообщение, которое уже в процессе отправки, затем будет отправлено ещё одно сообщение на эскалацию. Это последующее сообщение будет иметь следующий текст в начале тела сообщения (NOTE: Escalation cancelled) с указанием причины (например, NOTE: Escalation cancelled: action '<Имя действия>' disabled). Таким образом получатель будет проинформирован о том, что эскалация отменена и дальнейшие шаги не будут выполнены. Это сообщение будет отправлено всем, кто получал оповещения ранее. Причина отмены также будет записана в файл журнала сервера (начиная с уровня отладки 3=Предупреждения). Обратите внимание, что сообщение Escalation canceled также будет отправлено, если все операции завершены, а операции восстановления настроены, но ещё не выполнялись. |
| В процессе выполнения эскалации (например, во время отправки сообщения) удалено действие | Сообщения более не отсылаются. Информация будет записана в файл журнала сервера (начиная с уровня отладки 3=Предупреждения), например: escalation cancelled: action id:334 deleted |
Примеры эскалаций
Пример 1
Отправка повторяющихся оповещений каждые 30 минут (в общей сложности 5 раз) группе 'MySQL администраторы'. Для настройки:
- Задайте Длительность шага операции по умолчанию равным '30m' (30 минут) на вкладке Операции
- Укажите шаги эскалаций С '1' До '5'
- Выберите группу 'MySQL администраторы' получателями сообщений
Оповещения будут отправлены в 0:00, 0:30, 1:00, 1:30, 2:00 часов после начала проблемы (если, конечно, проблема не будет решена раньше).
Если проблема решена и сообщение о восстановлении настроено, оно будет отправлено всем тем, кто получил хотя бы одно сообщение в этом сценарии эскалаций.
Если триггер, который вызвал активную эскалацию, был деактивирован, Zabbix отправит информационное сообщение об этом всем, кто уже получил оповещения.
Пример 2
Отправка оповещения с задержкой о давней проблеме. Для настройки:
- Задайте Длительность шага операции по умолчанию равным '10h' (10 часов) на вкладке Операции
- Укажите шаги эскалации С '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 (но не в 3:00; учитывая, что шаги 5 и 6 перекрываются со следующей операцией, более короткая пользовательская длительность в 10 минут перекрывает более длительную пользовательскую длительность, равную 1 часу)
- Zabbix администраторам в 2:00, 2:10, 2:20, 2:30 после начала проблемы (задана пользовательская длительность шага, равная 10 минутам)
- гостевым пользователям в 4:00 часа после начала проблемы (интервал по умолчанию, равный 30 минутам, возвращается между шагами 8 и 11)