Пошаговая настройка триггеров и алертинга через Express-уведомления в Zabbix

Express-уведомления в Zabbix - это механизм доставки оповещений через выполнение произвольного скрипта или внешней команды на стороне сервера. В отличие от встроенных интеграций с Telegram, Slack или email, Express не требует внешних API и токенов. Вы передаёте параметры алерта в свой скрипт, а он уже делает всё, что нужно: пишет в лог, дёргает вебхук, отправляет SMS через локальный шлюз. Этот гайд проведёт вас от создания триггера до отладки цепочки оповещений.

Мы разберём синтаксис выражений, настроим уровни серьёзности, привяжем Express к пользователю, сконфигурируем действия с эскалацией и отфильтруем ложные срабатывания. Все примеры проверены на Zabbix 6.4 и 7.0. Если вы уже сталкивались с ситуацией, когда уведомления не доходят, рекомендую свериться с разбором типичных ошибок при настройке оповещений через Express - там чек-лист, который сэкономит время.

Подготовка: что нужно знать перед настройкой

Что такое Express-уведомления и когда их использовать

Express - это тип медиа (media type) в Zabbix, который запускает скрипт на сервере мониторинга при срабатывании действия. Скрипт получает три параметра: адрес получателя, тему и тело сообщения. Этот подход даёт полную свободу маршрутизации: вы можете слать алерты в самописную систему тикетов, дёргать REST API корпоративного портала или писать в syslog для SIEM-системы.

Express стоит выбирать, когда:

нужного вам канала нет среди стандартных интеграций Zabbix;
требуется жёсткий контроль над форматом и содержанием отправляемых данных;
среда изолирована от интернета, а внутренний API доступен;
нужно минимальное время доставки без посредников вроде SMTP-сервера.

Проверка исходных данных: узлы, элементы данных и права

Перед созданием триггеров убедитесь, что в Zabbix есть хотя бы один узел с активным элементом данных. Подойдёт стандартный шаблон Linux by Zabbix agent или Windows by Zabbix agent. Откройте Monitoring → Hosts, выберите узел и перейдите на вкладку Items. Нам нужен элемент, который собирает числовые данные - например, system.cpu.load[all,avg1] или vm.memory.size[available].

Проверьте права учётной записи, под которой вы работаете. Для создания триггеров нужна роль с разрешениями на запись в разделе Configuration, а для настройки действий - доступ к Administration → Media types и Configuration → Actions. Если вы используете Zabbix с разделением ролей, запросите у администратора роль Super admin или кастомную с нужными привилегиями.

Создание триггера: от метрики к условию срабатывания

Выражение триггера: синтаксис и основные функции

Выражение триггера строится по схеме:

{<host>:<key>.<function>(<params>)}<operator><constant>

Где:

host - имя узла или шаблона;
key - ключ элемента данных;
function - агрегирующая или проверочная функция;
operator - сравнение: >, <, =, <>, >=, <=;
constant - пороговое значение (число или строка).

Самые ходовые функции:

last() - последнее полученное значение;
avg(#N) - среднее за N последних замеров;
avg(T) - среднее за временной интервал T (например, 5m - 5 минут);
min() и max() - минимум и максимум за период;
delta() - разница между последним и предыдущим значением;
nodata(T) - возвращает 1, если данные не поступали дольше T;
count(#N,>X) - количество значений больше X в последних N замерах.

Практический пример: триггер на высокую загрузку CPU

Создадим триггер, который переводится в состояние Problem, если средняя загрузка CPU за 5 минут превышает 2.0. Перейдите в Configuration → Hosts, найдите узел, откройте вкладку Triggers и нажмите Create trigger.

Заполните поля:

Name: High CPU load on {HOST.NAME}
Severity: Warning
Expression: avg(/WebServer/system.cpu.load[all,avg1],5m)>2
Problem description: Средняя загрузка CPU за 5 минут превысила 2.0. Текущее значение: {ITEM.LASTVALUE}. Проверьте процессы через top или htop.

Макрос {HOST.NAME} в имени подставит реальное имя узла, а {ITEM.LASTVALUE} в описании - актуальное значение метрики на момент срабатывания. Это делает сообщение информативным без ручной правки для каждого хоста.

Настройка уровней серьёзности и зависимостей

Шкала severity в Zabbix:

Not classified - серый, для информационных событий;
Information - голубой, для сведений, не требующих реакции;
Warning - жёлтый, требует внимания в ближайшее время;
Average - оранжевый, проблема влияет на часть пользователей;
High - красный, серьёзный сбой;
Disaster - тёмно-красный, полная недоступность сервиса.

Зависимости предотвращают каскад алертов. Если у вас есть триггер на недоступность хоста по ICMP и триггер на отказ сервиса на этом хосте, свяжите их. Откройте триггер сервиса, перейдите на вкладку Dependencies и добавьте триггер доступности хоста. Теперь при падении хоста сработает только один алерт - о недоступности, а триггер сервиса будет подавлен.

Настройка Express-уведомлений как способа оповещения

Создание скрипта для Express-уведомления

Скрипты Express должны лежать в директории, указанной в параметре AlertScriptsPath конфигурационного файла zabbix_server.conf. По умолчанию это /usr/lib/zabbix/alertscripts или /etc/zabbix/alertscripts. Проверьте путь:

grep AlertScriptsPath /etc/zabbix/zabbix_server.conf

Создайте файл express_handler.sh:

#!/bin/bash
# $1 - адрес (ALERT.SENDTO)
# $2 - тема (ALERT.SUBJECT)
# $3 - тело сообщения (ALERT.MESSAGE)

LOG="/var/log/zabbix/express_alerts.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

echo "[$TIMESTAMP] TO: $1 | SUBJECT: $2" >> "$LOG"
echo "[$TIMESTAMP] BODY: $3" >> "$LOG"

# Пример отправки в вебхук (раскомментируйте при необходимости)
# curl -X POST -H "Content-Type: application/json" \
#   -d "{\"to\":\"$1\",\"subject\":\"$2\",\"message\":\"$3\"}" \
#   https://your-webhook-url.example.com/alert

Сделайте скрипт исполняемым и дайте права пользователю zabbix:

chmod 755 /usr/lib/zabbix/alertscripts/express_handler.sh
chown zabbix:zabbix /usr/lib/zabbix/alertscripts/express_handler.sh

Регистрация Express-типа в Zabbix и привязка к пользователю

Перейдите в Administration → Media types → Create media type. Заполните:

Name: Express_Handler
Type: Script
Script name: express_handler.sh
Parameters: оставьте три строки с макросами {ALERT.SENDTO}, {ALERT.SUBJECT}, {ALERT.MESSAGE} - именно в таком порядке.

Теперь привяжите тип к пользователю. Откройте Administration → Users, выберите пользователя, перейдите на вкладку Media и нажмите Add. Выберите Express_Handler, в поле Send to укажите идентификатор - это может быть URL вебхука, email или любой другой адрес, который ваш скрипт интерпретирует как получателя. Значение попадёт в макрос {ALERT.SENDTO}.

Связывание триггера с действием: маршрутизация алертов

Определение условий действия: какие триггеры обрабатывать

Действие (action) определяет, на какие события реагировать и что делать. Перейдите в Configuration → Actions → Create action. Дайте имя, например, Notify DevOps - High severity.

На вкладке Conditions добавьте условия:

Condition A: Trigger severity >= Average - обрабатываем только Average, High и Disaster;
Condition B: Host group = Production servers - только продакшн-узлы.

Условия объединяются логическим AND. Действие сработает, когда выполняются все условия одновременно. Для более сложной логики используйте тип условия Tag - вы можете назначать теги триггерам и фильтровать по ним.

Настройка операций: кому и как отправлять Express-уведомления

На вкладке Operations нажмите Add. В блоке Operations выберите:

Operation type: Send message
Send to user groups: выберите группу, в которой состоит пользователь с Express-медиа;
Send only to: Express_Handler - чтобы задействовать именно наш тип оповещения.

Настройте тему и сообщение с макросами. Рекомендуемый шаблон:

Тема: [{TRIGGER.SEVERITY}] {TRIGGER.NAME} on {HOST.NAME}

Сообщение:
Problem started at {EVENT.DATE} {EVENT.TIME}
Severity: {TRIGGER.SEVERITY}
Host: {HOST.NAME} ({HOST.IP})
Trigger: {TRIGGER.NAME}
Current value: {ITEM.LASTVALUE}

Original problem ID: {EVENT.ID}

Этот набор макросов даёт полный контекст: что случилось, где, когда и с каким значением метрики. Инженеру не придётся лезть в дашборд Zabbix для первичной оценки инцидента.

Эскалация и повторные уведомления

Эскалация нужна, чтобы алерт не остался без внимания. Настройте шаги в том же окне операций. Нажмите Add под блоком Steps и задайте:

Step duration: 300 (5 минут) - через этот интервал сработает следующий шаг;
Step 1: отправка пользователю из основной группы;
Step 2: через 5 минут - отправка старшему дежурному (укажите другого пользователя или группу);
Step 3: через 15 минут - отправка руководителю отдела.

Zabbix выполняет шаги последовательно, пока проблема не будет закрыта или подтверждена (acknowledged). Если на шаге 3 проблема всё ещё активна, действие останавливается - дальнейшие шаги не добавляются, если вы их не настроили. Для бесконечного цикла оповещений используйте операцию Recovery operations и настройте повторную отправку.

Тестирование и отладка цепочки алертинга

Симуляция срабатывания триггера

Самый безопасный способ проверки - тестовый хост с искусственным триггером. Создайте хост Test-Alert с элементом данных типа Zabbix trapper и ключом test.trigger. Затем создайте триггер с выражением:

last(/Test-Alert/test.trigger)=1

Отправьте значение через утилиту zabbix_sender:

zabbix_sender -z 127.0.0.1 -s "Test-Alert" -k test.trigger -o 1

Триггер мгновенно перейдёт в состояние Problem, и действие отправит Express-уведомление. Для возврата в OK отправьте значение 0. Этот метод не затрагивает боевые метрики и позволяет проверить всю цепочку.

Анализ журнала событий и решение проблем

Если уведомление не пришло, проверьте три точки:

Monitoring → Problems - отображается ли проблема? Если нет, проверьте выражение триггера и поступают ли данные элемента.
Monitoring → Actions - в колонке Action log видно, какие действия выполнялись и какие операции были запущены. Статус Failed укажет на ошибку в настройке медиа или скрипта.
Лог сервера: tail -f /var/log/zabbix/zabbix_server.log | grep -i express. Типовые ошибки: Media type not found (не создан тип медиа), Script not executable (нет прав на выполнение), AlertScriptsPath not set (не указан путь в конфиге).

Если вы видите ошибку аутентификации или сетевую проблему при отправке через вебхук, сверьтесь с чек-листом диагностики Express-уведомлений - там есть готовые curl-команды для изоляции проблемы.

Оптимизация алертинга: снижение шума и повышение точности

Улучшение сообщений: макросы и контекст

Хорошее уведомление позволяет начать диагностику сразу из мессенджера или почты. Добавьте в тело сообщения инструкцию по исправлению - это сокращает время реакции. Пример расширенного шаблона:

Инцидент #{EVENT.ID}
Время: {EVENT.DATE} {EVENT.TIME}
Узел: {HOST.NAME} ({HOST.IP})
Проблема: {TRIGGER.NAME}
Уровень: {TRIGGER.SEVERITY}
Значение: {ITEM.LASTVALUE}

Действия:
1. Подключиться по SSH: ssh {HOST.IP}
2. Проверить процессы: top -bn1 | head -20
3. При необходимости перезапустить сервис: systemctl restart nginx

Ссылка на дашборд: https://zabbix.example.com/tr_events.php?triggerid={TRIGGER.ID}

Макрос {TRIGGER.ID} формирует прямую ссылку на событие в веб-интерфейсе Zabbix. Это особенно удобно при интеграции с Express-уведомлениями для DevOps-команд, где важна скорость реакции.

Подавление ложных срабатываний: hysteresis и зависимости

Гистерезис предотвращает дребезг триггера при колебаниях метрики около порога. Вместо одного порога задайте два разных условия для перехода в Problem и OK:

Problem: avg(/host/cpu,5m)>90
OK: avg(/host/cpu,5m)<70

Триггер сработает только при превышении 90%, а вернётся в норму, когда нагрузка упадёт ниже 70%. Зазор в 20% исключает многократные переключения при флаппинге.

Функция count() фильтрует кратковременные всплески. Выражение count(#5,>90,"gt")>3 означает: «сработать, если из последних 5 замеров больше 3 превысили 90». Случайный скачок на одном замере не поднимет алерт.

Зависимости триггеров - ещё один слой фильтрации. Если триггер сервиса зависит от триггера доступности хоста, при падении хоста вы получите одно уведомление, а не десяток от всех сервисов на этом узле. Настройка выполняется на вкладке Dependencies в свойствах триггера.

Использование периодов обслуживания для плановых работ

Периоды обслуживания (Maintenance) подавляют алерты на время регламентных работ. Перейдите в Configuration → Maintenance → Create maintenance period. Укажите:

Name: Monthly patching
Maintenance type: No data collection - этот тип подавляет триггеры, связанные с узлами;
Hosts: выберите узлы, которые будут обслуживаться;
Schedule: задайте дату и время начала и окончания работ.

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

Борьба с алертным шумом не ограничивается триггерами. Рекомендую посмотреть руководство по настройке умных уведомлений и борьбе с шумом - там разобраны техники группировки и подавления, применимые как в Zabbix, так и в Prometheus.

Цепочка «триггер → действие → Express-скрипт → получатель» даёт полный контроль над алертингом. Вы не зависите от сторонних API, можете шифровать сообщения, подписывать их или маршрутизировать по внутренним правилам. Начните с одного тестового триггера, добейтесь стабильной доставки, а затем масштабируйте схему на всю инфраструктуру. Если вы мониторите веб-серверы, загляните в гайд по мониторингу Nginx в Zabbix - там готовые выражения триггеров для HTTP-метрик.