Zabbix + Express: настройка алертинга для DevOps и сисадминов

Подготовка к интеграции: что нужно знать перед началом

Интеграция Zabbix с Express-уведомлениями требует минимального набора компонентов. Проверьте их до начала работ, чтобы не прерывать настройку на полпути.

Вам потребуется:

Zabbix версии 5.0 или новее. На более старых выпусках механизм webhook может работать нестабильно. Если вы используете Zabbix 6.0 LTS, все шаги из этого руководства применимы без изменений.
Права администратора в веб-интерфейсе Zabbix. Без роли Super Admin вы не сможете создавать медиа-типы и действия.
URL эндпоинта Express и токен аутентификации. Эти данные вы получите в личном кабинете Express при создании канала уведомлений.
Сетевая доступность: Zabbix-сервер должен достучаться до API Express по HTTPS. Проверьте файрвол и исходящие правила.

Сделайте бэкап конфигурации Zabbix перед изменениями. В веб-интерфейсе перейдите в Administration → General → Housekeeping, нажмите Export. Сохраните дамп - это страховка на случай отката. Если вы только начинаете выстраивать мониторинг, посмотрите стек мониторинга серверов с Prometheus и Grafana - там разобран полный цикл от установки до первых алертов.

Создание медиа-типа Express в Zabbix

Медиа-тип - это транспорт для доставки уведомлений. Сейчас мы создадим новый канал, который будет отправлять алерты в Express через HTTP-запрос.

Зайдите в Administration → Media types. Нажмите Create media type. Заполните поля:

Name: Express
Type: Webhook
Parameters - здесь мы определим, как Zabbix будет общаться с API Express.

Настройка параметров webhook для Express

Express принимает уведомления через REST API. Вам нужно передать три обязательных параметра: URL эндпоинта, заголовок с токеном и тело запроса в JSON.

Добавьте следующие параметры в секции Parameters:

Name	Value
URL	https://api.express.example.com/v1/alerts
HTTPMethod	POST
Headers	Content-Type: application/json Authorization: Bearer {your_token_here}
Post	{ "subject": "{ALERT.SUBJECT}", "message": "{ALERT.MESSAGE}", "severity": "{TRIGGER.SEVERITY}" }

Замените URL на реальный адрес из вашего дашборда Express. Токен скопируйте из раздела Integrations → API Keys. Express поддерживает два метода аутентификации: Bearer token (рекомендуем) и Basic Auth. При использовании Basic Auth заголовок будет выглядеть как Authorization: Basic base64(login:password).

После заполнения параметров нажмите кнопку Test. Zabbix отправит пробный запрос и покажет ответ сервера. Успешный ответ - HTTP 200 или 201. Если получили ошибку, проверьте URL и токен.

Шаблоны сообщений: макросы Zabbix для информативных алертов

Сырое сообщение с одним лишь именем триггера бесполезно. Хороший алерт сразу даёт контекст: что случилось, где и когда. Для этого используйте макросы Zabbix.

Пример шаблона темы сообщения:

{TRIGGER.STATUS}: {HOST.NAME} - {TRIGGER.NAME}

Пример шаблона тела сообщения:

Проблема: {TRIGGER.NAME}
Узел: {HOST.NAME} ({HOST.IP})
Значение: {ITEM.VALUE}
Время: {EVENT.DATE} {EVENT.TIME}
Ссылка: https://zabbix.example.com/tr_events.php?triggerid={TRIGGER.ID}&eventid={EVENT.ID}

Макрос {ITEM.VALUE} подставляет значение метрики в момент срабатывания. Для триггера «CPU load > 90%» вы увидите конкретную цифру - например, 94.7%. Ссылка на событие ведёт прямо в карточку инцидента в Zabbix, экономя время при разборе.

Полный список макросов доступен в документации Zabbix, но для 90% сценариев хватит перечисленных выше. Если вы мониторите Nginx, обратите внимание на мониторинг Nginx в Zabbix с готовыми шаблонами и триггерами - там есть примеры специфичных макросов для веб-сервера.

Настройка действий (Actions) для отправки уведомлений в Express

Медиа-тип создан, но сам по себе он ничего не отправляет. Действия (Actions) определяют правила: при каком условии, кому и через какой канал слать оповещение.

Перейдите в Configuration → Actions. Выберите Trigger actions в выпадающем списке и нажмите Create action. Дайте действию имя, например «Critical alerts to Express».

Вкладка Operations определяет, что произойдёт при срабатывании условия. Добавьте операцию:

Operation type: Send message
Send to users: выберите пользователей, которым назначен медиа-тип Express
Send only to: Express (медиа-тип, который мы создали)

Разница между немедленной отправкой и эскалацией проста. Немедленная отправка - это одна операция без шагов. Эскалация - цепочка операций с нарастающей серьёзностью: сначала сообщение дежурному, через 5 минут звонок, через 10 минут оповещение руководителя. Шаги эскалации настраиваются там же, во вкладке Operations, через добавление новых шагов с задержкой.

Привязка Express к пользователям Zabbix

Чтобы уведомления доходили до конкретного инженера, в профиле пользователя нужно указать его идентификатор в Express.

Откройте Administration → Users, выберите пользователя. В блоке Media добавьте запись:

Type: Express
Send to: ID чата или пользователя в Express (например, user_abc123 или chat_xyz789)

Где взять этот идентификатор? В Express перейдите в раздел Channels, откройте нужный канал и скопируйте Target ID. Для личных уведомлений это ваш User ID из профиля. Для каналов команды - Chat ID.

Один пользователь может иметь несколько записей Express с разными идентификаторами - например, для рабочих и личных уведомлений. Zabbix отправит сообщение на все привязанные адреса.

Типовые сценарии: готовые конфигурации для критических ситуаций

Ниже - три конфигурации для самых частых инцидентов. Копируйте и адаптируйте под свою инфраструктуру.

Сценарий 1: Аварийное оповещение - сервер недоступен.

Условие в действии: Trigger name содержит «Host unavailable», Severity = Disaster. Шаблон сообщения:

КРИТИЧЕСКИЙ СБОЙ: {HOST.NAME} недоступен
Узел перестал отвечать на запросы ICMP.
Время простоя: {ITEM.VALUE}
Действие: немедленно проверить питание и сетевую связность.

Рекомендуемая эскалация: первое уведомление дежурному инженеру, повтор через 2 минуты всей группе, через 5 минут - звонок ответственного за инфраструктуру.

Сценарий 2: Падение сервиса - Nginx или Docker.

Условие: Trigger name содержит «Nginx is down» или «Docker service». Severity = High. Шаблон:

Сервис остановлен: {TRIGGER.NAME} на {HOST.NAME}
Значение: {ITEM.VALUE}
Время: {EVENT.TIME}
Проверьте статус сервиса: systemctl status nginx

Для этого сценария часто настраивают автоматический перезапуск через recovery action. Если вы ещё не автоматизировали восстановление, посмотрите готовые скрипты Python и Bash для автоматизации бэкапов и восстановления - они интегрируются с Zabbix через внешние проверки.

Сценарий 3: Перегрузка ресурсов - CPU > 90%.

Условие: Trigger name содержит «CPU utilization», Severity = Warning или Average. Шаблон:

Высокая нагрузка CPU на {HOST.NAME}
Текущее значение: {ITEM.VALUE}%
Порог: 90%
Проверьте top-процессы: ssh {HOST.IP} 'ps aux --sort=-%cpu | head -5'

Для этого сценария эскалацию часто не настраивают - достаточно одного уведомления. Но если нагрузка держится дольше 10 минут, имеет смысл отправить повтор.

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

После настройки убедитесь, что всё работает. Пропущенный алерт в продакшене - это простой, которого можно избежать за 5 минут проверки.

Три способа протестировать:

Кнопка Test в медиа-типе Express. Самый быстрый способ проверить связность и аутентификацию. Не проверяет действия и триггеры, только канал.
Ручная генерация события. Создайте временный триггер с заведомо истинным условием, например {host:system.cpu.load.last()}>0. Привяжите к нему действие с отправкой в Express. Через минуту триггер сработает, и вы получите тестовое уведомление.
Утилита zabbix_sender. Отправьте тестовое значение напрямую в Zabbix-сервер: zabbix_sender -z 127.0.0.1 -s "test host" -k test.key -o 1. Это имитирует работу агента.

Где смотреть логи при ошибках:

Zabbix server log: /var/log/zabbix/zabbix_server.log. Ищите строки с «cannot send message» или кодом HTTP-ответа от Express.
Очередь уведомлений: Administration → Queue. Показывает сообщения, ожидающие отправки. Если сообщение висит в очереди, проблема на стороне Zabbix.

Мониторинг доставки уведомлений в Express

Express ведёт лог всех входящих запросов. В дашборде перейдите в раздел Logs → Delivery. Для каждого сообщения показан статус: delivered, failed, pending. При статусе failed раскройте детали - там будет код ошибки и тело ответа.

Express также поддерживает обратный webhook для подтверждения доставки конечному устройству. Настройте его в разделе Callbacks, указав URL вашего эндпоинта в Zabbix. Тогда Zabbix будет получать подтверждение, что пуш-уведомление действительно дошло до телефона дежурного.

Частые ошибки и их решения:

HTTP 401 Unauthorized - неверный токен. Проверьте, не истёк ли срок действия ключа в Express.
HTTP 400 Bad Request - ошибка в JSON. Проверьте кавычки и экранирование в теле запроса.
Connection timeout - Zabbix-сервер не может достучаться до API Express. Проверьте файрвол и DNS-резолвинг.
Сообщение уходит, но не доставляется на устройство - проверьте статус подписки устройства в Express, возможно, отключены пуш-уведомления.

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

Сокращение времени реакции: эскалации и дежурства в Express

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

Настройка многошаговой эскалации в Zabbix:

В действии откройте вкладку Operations.
Добавьте первый шаг: отправка дежурному инженеру через Express. Задержка - 0 (немедленно).
Добавьте второй шаг: нажмите New operation, задайте задержку 300 секунд (5 минут). Укажите другого получателя - например, группу «Старшие инженеры».
Третий шаг: задержка 600 секунд, получатель - руководитель отдела или вся команда.

Express поддерживает интеграцию с графиками дежурств. Если в вашей команде используется ротация, настройте в Express раздел On-call schedules. Затем в Zabbix, в профиле пользователя, укажите идентификатор дежурного канала Express. Zabbix будет отправлять сообщение в канал, а Express сам определит, кто сейчас на смене, и доставит уведомление на его устройства.

Среднее время реакции на инцидент с настроенной эскалацией сокращается в 3-4 раза по сравнению с одиночными уведомлениями. Причина проста: если первый инженер не ответил за 5 минут, система автоматически подключает второго, а затем и всю команду. Это исключает сценарий «я не видел сообщение».

Для критичных сервисов настройте бесконечную эскалацию - повторяйте последний шаг каждые 10 минут, пока инцидент не будет подтверждён. В Zabbix это делается установкой флажка «Escalation» в операции и указанием периода повтора.