Пользователи могут быть немедленно проинформированы о новых проблемах.
Уведомления могут повторяться до тех пор, пока проблема не будет устранена.
Отправка уведомления может быть отложена.
Уведомления могут быть эскалированы в другую, «более высокую», группу пользователей.
Удаленные команды могут выполняться немедленно или если проблема не решается в течение длительного времени.

Действия эскалируются на основе шага эскалации. Каждый шаг имеет определенную продолжительность.

Можно задать как продолжительность по умолчанию, так и пользовательскую продолжительность для отдельного шага. Минимальная продолжительность одного шага эскалации составляет 60 секунд.

Можно запускать действия, такие как отправка уведомлений или выполнение команд, с любого шага. Первый шаг предназначен для немедленных действий. Если вы хотите отложить действие, можно назначить его на более поздний шаг. Для каждого шага можно определить несколько действий.

Количество шагов эскалации не ограничено.

Эскалации определяются при настройке операции. Эскалации поддерживаются только для операций при проблеме, но не для восстановления.

Прочие аспекты поведения эскалации

Рассмотрим, что происходит в различных обстоятельствах, если действие содержит несколько шагов эскалации.

Ситуация	Поведение
Соответствующий узел сети переходит в обслуживание после отправки первоначального уведомления о проблеме	В зависимости от настройки Pause operations for suppressed problems в конфигурации действия все оставшиеся шаги эскалации выполняются либо с задержкой, вызванной периодом обслуживания, либо без задержки. Период обслуживания не отменяет операции.
Период времени, заданный в условии действия Time period, заканчивается после отправки первоначального уведомления	Все оставшиеся шаги эскалации выполняются. Условие Time period не может остановить операции; оно влияет на то, когда действия запускаются/не запускаются, а не на операции.
Проблема начинается во время обслуживания и продолжается (не устраняется) после его окончания	В зависимости от настройки Pause operations for suppressed problems в конфигурации действия все шаги эскалации выполняются либо с момента окончания обслуживания, либо немедленно.
Проблема начинается во время обслуживания типа no-data и продолжается (не устраняется) после окончания обслуживания	Необходимо дождаться срабатывания триггера, прежде чем будут выполнены все шаги эскалации.
Разные эскалации следуют одна за другой с небольшим интервалом и перекрываются	Выполнение каждой новой эскалации заменяет предыдущую эскалацию, однако как минимум один шаг эскалации всегда выполняется для предыдущей эскалации. Такое поведение актуально для действий по событиям, которые создаются при КАЖДОМ вычислении проблемы триггера.
Во время выполняющейся эскалации (например, при отправке сообщения), на основе любого типа события: - действие отключено На основе события триггера: - триггер отключен - узел сети или элемент данных отключен На основе внутреннего события о триггерах: - триггер отключен На основе внутреннего события об элементах данных/правилах low-level discovery: - элемент данных отключен - узел сети отключен	Сообщение, отправка которого уже выполняется, будет отправлено, а затем будет отправлено еще одно сообщение в рамках эскалации. Последующее сообщение будет содержать текст отмены в начале тела сообщения (NOTE: Escalation canceled) с указанием причины (например, NOTE: Escalation canceled: action '<Action name>' disabled). Таким образом получатель будет проинформирован, что эскалация отменена и дальнейшие шаги выполняться не будут. Это сообщение отправляется всем, кто ранее получил уведомления. Причина отмены также записывается в журнал сервера (начиная с Debug Level 3=Warning). Обратите внимание, что сообщение Escalation canceled также отправляется, если операции завершены, но настроены операции восстановления и они еще не выполнены.
Во время выполняющейся эскалации (например, при отправке сообщения) действие удаляется	Больше никаких сообщений не отправляется. Эта информация записывается в журнал сервера (начиная с Debug Level 3=Warning), например: `escalation canceled: 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 минут).

What’s next?

3 Получение оповещений о неподдерживаемых элементах данных

Docs

5 Эскалации

Обзор