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

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

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

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

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

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

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

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

Situation	Behavior
Узел сети, о котором идет речь, переходит в обслуживание после отправки первоначального уведомления о проблеме	В зависимости от настройки Приостанавливать операции для подавленных проблем в конфигурации действия все оставшиеся шаги эскалации выполняются либо с задержкой, вызванной периодом обслуживания, либо без задержки. Период обслуживания не отменяет операции.
Период времени, заданный условием действия Период времени, заканчивается после отправки первоначального уведомления	Все оставшиеся шаги эскалации выполняются. Условие Период времени не может остановить операции; оно влияет на то, когда действия запускаются или не запускаются, а не на операции.
Проблема начинается во время обслуживания и продолжается (не устраняется) после окончания обслуживания	В зависимости от настройки Приостанавливать операции для подавленных проблем в конфигурации действия все шаги эскалации выполняются либо с момента окончания обслуживания, либо немедленно.
Проблема начинается во время обслуживания без данных и продолжается (не устраняется) после окончания обслуживания	Необходимо дождаться срабатывания триггера, прежде чем будут выполнены все шаги эскалации.
Разные эскалации следуют одна за другой с небольшим интервалом и перекрываются	Выполнение каждой новой эскалации отменяет предыдущую эскалацию, но при этом всегда выполняется как минимум один шаг эскалации из предыдущей эскалации. Это поведение важно для действий по событиям, которые создаются при КАЖДОЙ оценке проблемы триггера.
Во время выполняющейся эскалации (например, при отправке сообщения), в зависимости от типа события: - действие отключается По событию триггера: - триггер отключается - узел сети или элемент данных отключается По внутреннему событию о триггерах: - триггер отключается По внутреннему событию об элементах данных/правилах обнаружения низкого уровня: - элемент данных отключается - узел сети отключается	Сообщение, находящееся в процессе отправки, отправляется, а затем в рамках эскалации отправляется еще одно сообщение. В последующем сообщении в начале текста будет указана отмена (NOTE: Escalation canceled) с указанием причины (например, NOTE: Escalation canceled: action '<Action name>' disabled). Таким образом получатель информируется о том, что эскалация отменена и дальнейшие шаги выполняться не будут. Это сообщение отправляется всем, кто уже получил уведомления ранее. Причина отмены также записывается в файл журнала сервера (начиная с уровня отладки 3=Warning). Обратите внимание, что сообщение Escalation canceled также отправляется, если операции завершены, но операции восстановления настроены и еще не выполнены.
Во время выполняющейся эскалации (например, при отправке сообщения) действие удаляется	Больше сообщения не отправляются. Информация записывается в файл журнала сервера (начиная с уровня отладки 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 Эскалации

Обзор