Оповещения не доходят по трём причинам: ошибка в конфигурации медиатипа, неверная логика действий и триггеров, сетевые проблемы или провал аутентификации на стороне Express API. В 90% случаев проблема решается проверкой логов Zabbix Server и тестовым curl-запросом к эндпоинту Express.
Этот разбор построен на практике: каждый пункт - реальная ошибка, с которой сталкиваются системные администраторы при интеграции Zabbix и Express. Вы получите не теорию, а готовые команды, примеры конфигураций и чек-лист для быстрой диагностики.
Почему оповещения Zabbix через Express не доходят: быстрая диагностика
Система оповещений Zabbix состоит из трёх компонентов: медиатип определяет, как отправлять сообщение, триггер генерирует событие, а действие связывает событие с медиатипом и получателем. Сбой любого звена останавливает доставку.
Три группы причин отказа:
- Неверная конфигурация медиатипа. Ошибка в URL эндпоинта, неправильный HTTP-метод, отсутствие обязательных заголовков, невалидный JSON в теле запроса, использование макросов, которые не поддерживаются в контексте медиатипа.
- Ошибки в действиях и триггерах. Условия фильтрации не соответствуют реальным событиям, не указан нужный медиатип в операции, шаг восстановления не настроен, эскалация уходит в бесконечный цикл.
- Сетевые проблемы и аутентификация. Сервер Zabbix не может достичь Express API из-за файрвола, DNS или прокси. Токен аутентификации истёк или не имеет прав на отправку сообщений.
Чек-лист для первичной диагностики:
- Откройте лог Zabbix Server:
tail -f /var/log/zabbix/zabbix_server.log | grep -i express. Ищите строки с ошибками отправки, кодами ответа HTTP и сообщениями о недоступности хоста. - Создайте тестовый триггер с заведомо истинным условием, например,
{host:item.regexp(1)}=1, и привяжите к нему действие с вашим медиатипом Express. Это изолирует проблему от рабочих триггеров. - Выполните curl-запрос с теми же параметрами, что указаны в медиатипе, прямо с сервера Zabbix. Сравните ответ. Если curl работает, а Zabbix нет - проблема в конфигурации медиатипа или прокси.
После этой диагностики вы точно знаете, в каком компоненте искать ошибку. Дальше разбираем каждый узел детально.
Пошаговая настройка медиатипа Express в Zabbix
Медиатип - это шаблон исходящего HTTP-запроса к Express API. Ошибка в любом поле приводит к тому, что Zabbix молча не отправляет уведомление или получает отказ от сервера Express.
Параметры подключения: URL, метод, заголовки
URL должен быть полным, включая протокол и порт. Пример: https://express-api.example.com:8443/api/v1/messages. Частая ошибка - указание относительного пути или пропуск порта, когда API слушает нестандартный порт.
HTTP-метод почти всегда POST. Express ожидает JSON в теле запроса, поэтому метод GET с параметрами в URL не сработает.
Заголовки, обязательные для работы:
Content-Type: application/json Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Токен или ключ API передаётся в заголовке Authorization. Проверьте, что в значении нет лишних пробелов до или после токена. Чувствительность к регистру: Bearer с большой буквы, пробел, затем токен. Ошибка в регистре или двойной пробел - и Express возвращает 401 Unauthorized.
Параметр «Тип» в Zabbix должен быть установлен в Webhook. Это единственный тип, который позволяет отправлять произвольные HTTP-запросы с телом JSON.
Шаблон сообщения: макросы и формат данных
Тело запроса формируется в поле «Сообщение» медиатипа. Express ожидает JSON определённой структуры. Минимальный рабочий шаблон:
{
"channel": "alerts",
"text": "Проблема на {HOST.NAME}: {TRIGGER.NAME}",
"severity": "{TRIGGER.SEVERITY}",
"event_id": "{EVENT.ID}",
"time": "{EVENT.TIME}"
}Критическая ошибка - невалидный JSON. Лишняя запятая после последнего поля, незакрытая кавычка, разрыв строки внутри строкового значения - всё это ломает парсинг на стороне Express. Проверяйте JSON валидатором перед сохранением.
Макросы, которые работают в контексте медиатипа:
{HOST.NAME}- имя узла, на котором сработал триггер{TRIGGER.NAME}- имя триггера{TRIGGER.STATUS}- PROBLEM или OK{TRIGGER.SEVERITY}- числовое значение важности{ITEM.VALUE}- значение элемента данных в момент события{EVENT.ID}- идентификатор события{EVENT.TIME}- время события
Макросы {ITEM.LASTVALUE} и {HOST.IP} не разрешены в медиатипах. Их использование приведёт к тому, что в сообщении останется сырая строка макроса вместо значения. Полный список разрешённых макросов зависит от версии Zabbix, проверяйте в официальной документации для вашей версии.
Content-Type должен быть application/json. Если указать text/plain, Express может отклонить запрос или интерпретировать тело неверно.
Связка действий и триггеров: как избежать ложных срабатываний и пропусков
Действие в Zabbix определяет, кому и при каких условиях отправлять оповещение. Без правильно настроенного действия даже идеальный медиатип бесполезен.
Настройка условий фильтрации
Условия в действиях сужают область применения. Типичная конфигурация для продуктовой среды:
- Тип условия: «Важность триггера» - больше или равно «High». Это отсекает информационные события и предупреждения.
- Тип условия: «Группа узлов» - содержит «Production Servers». Оповещения уходят только по боевым серверам, тестовый контур не шумит.
- Тип условия: «Тег события» - содержит «express_alert». Гибкий способ маршрутизации: вешаете тег на нужные триггеры, и действие срабатывает только для них.
Ошибка: использование условий, которые никогда не выполняются. Например, условие «Узел равен localhost», когда в Zabbix узел зарегистрирован с FQDN. Или условие «Важность триггера меньше или равно Information» для действия, которое должно срабатывать на критические проблемы. Проверяйте фактические значения в таблице триггеров перед настройкой условий.
Действие должно содержать как минимум два условия: для события «Проблема» и для события «Восстановление». Если условие восстановления не задано, вы не получите уведомление о том, что проблема решена.
Операции и эскалации: гарантия доставки
Внутри действия настраиваются операции - конкретные шаги отправки. Для каждой операции указывается медиатип Express и получатель (пользователь или группа).
Базовая операция для немедленного оповещения:
- Шаг: 0 (немедленно)
- Тип операции: «Отправить сообщение»
- Медиатип: ваш медиатип Express
- Получатель: пользователь или группа с настроенным способом оповещения Express
Эскалация добавляет повторные попытки, если проблема не решена. Пример настройки:
- Шаг 1: интервал 300 секунд (5 минут), отправить тому же пользователю
- Шаг 2: интервал 600 секунд (10 минут), отправить группе «Дежурная смена»
- Шаг 3: интервал 1800 секунд (30 минут), отправить руководителю отдела
Критическая ошибка - бесконечная эскалация без условия остановки. В настройках действия обязательно укажите «Продолжительность эскалации» (например, 3600 секунд - один час). После истечения этого времени Zabbix прекратит отправку повторных уведомлений. Без этого лимита система будет слать сообщения бесконечно, пока проблема не закроется вручную.
Другая частая ошибка: в операции не выбран медиатип. Zabbix позволяет сохранить операцию без указания способа отправки, и она просто ничего не делает. Проверьте, что в каждой операции выбран ваш медиатип Express.
Сетевые проблемы и аутентификация Express
Даже при идеальной конфигурации Zabbix оповещения не дойдут, если сервер не может физически связаться с Express API или не проходит аутентификацию.
Диагностика сетевой связности
Первый тест - проверка доступности хоста Express с сервера Zabbix:
ping express-api.example.com
Если ping не проходит, проблема на уровне сети или DNS. Проверьте разрешение имени:
nslookup express-api.example.com
Если DNS работает, но ping заблокирован файрволом, проверьте доступность порта:
telnet express-api.example.com 8443
Главный инструмент диагностики - curl с параметрами, идентичными настройкам медиатипа:
curl -X POST https://express-api.example.com:8443/api/v1/messages \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_TOKEN" \
-d '{"channel":"test","text":"Test from Zabbix server"}'Анализируйте код ответа HTTP:
- 200 OK - соединение и аутентификация работают, проблема в конфигурации Zabbix.
- 401 Unauthorized - токен недействителен, истёк или не передан.
- 403 Forbidden - токен действителен, но у него нет прав на отправку сообщений в указанный канал.
- 404 Not Found - неверный URL эндпоинта.
- 500 Internal Server Error - проблема на стороне Express, проверьте логи Express.
- Connection refused / No route to host - сеть или файрвол блокируют соединение.
Если curl с сервера Zabbix не работает, а с вашей рабочей станции работает - проверьте исходящий файрвол на сервере Zabbix и настройки прокси.
Ошибки аутентификации и авторизации
Токен для Express API обычно генерируется в панели управления Express. Создайте выделенный сервисный аккаунт для Zabbix, не используйте токен администратора или личный токен сотрудника. Сервисный аккаунт решает две проблемы: права доступа ограничены только нужными каналами, и токен не перестанет работать при увольнении сотрудника.
Срок действия токена - частая причина внезапного отказа оповещений. В Express токены могут иметь ограниченный срок жизни. Настройте автоматическое обновление токена или используйте долгоживущие токены для сервисных аккаунтов. Проверьте срок действия вашего токена в настройках Express.
Если Zabbix находится за корпоративным прокси, настройте прокси в конфигурации Zabbix Server. В файле /etc/zabbix/zabbix_server.conf добавьте или раскомментируйте строки:
Proxy=http://proxy.company.com:3128 ProxyUser=username ProxyPassword=password
После изменения конфигурации перезапустите Zabbix Server: systemctl restart zabbix-server.
Тестирование и отладка оповещений
Не ждите реальной аварии для проверки. Zabbix предоставляет встроенные инструменты тестирования, которые выявляют большинство проблем за минуты.
Встроенная функция «Тест» в медиатипе. Откройте ваш медиатип Express в разделе «Администрирование» → «Медиатипы». Нажмите кнопку «Тест». В открывшемся окне укажите тестового получателя и произвольные значения макросов. Zabbix выполнит реальный HTTP-запрос и покажет ответ сервера Express. Это самый быстрый способ проверить URL, заголовки, токен и формат сообщения.
Тестовый триггер. Создайте на любом узле триггер с выражением, которое всегда истинно: {host:item.regexp(1)}=1. Привяжите к нему действие с вашим медиатипом Express. Триггер сработает мгновенно, и вы увидите полный цикл прохождения оповещения. После теста отключите или удалите этот триггер.
Анализ логов. Основной источник информации - /var/log/zabbix/zabbix_server.log. Включите детальное логирование для отладки. В файле /etc/zabbix/zabbix_server.conf установите DebugLevel=4 и перезапустите сервер. В логах появятся записи о каждом исходящем запросе, включая полный URL, заголовки и тело ответа. После отладки верните DebugLevel=3, чтобы не забивать диск.
Типичные сообщения об ошибках в логах и их расшифровка:
Cannot connect to the endpoint- сеть или DNS.SSL certificate verification failed- проблема с сертификатом Express. Временно можно отключить проверку в медиатипе (опция «Проверять SSL»), но для продуктовой среды лучше настроить доверенный сертификат.Timeout while executing webhook- Express отвечает слишком долго. Увеличьте таймаут в медиатипе (по умолчанию 30 секунд).
Оптимизация шаблонов сообщений для Express
Сообщение, которое получает дежурный инженер, должно содержать достаточно информации для немедленного начала диагностики. Недостаток данных заставляет искать детали в интерфейсе Zabbix, избыток - раздувает уведомление так, что ключевая информация теряется.
Рекомендованная структура сообщения для Express:
{
"channel": "alerts",
"title": "{TRIGGER.STATUS}: {HOST.NAME} - {TRIGGER.NAME}",
"text": "Узел: {HOST.NAME}\nТриггер: {TRIGGER.NAME}\nВажность: {TRIGGER.SEVERITY}\nЗначение: {ITEM.VALUE}\nВремя: {EVENT.TIME}\nСобытие: {EVENT.ID}",
"severity": "{TRIGGER.SEVERITY}",
"link": "https://zabbix.example.com/tr_events.php?triggerid={TRIGGER.ID}"
}Поле link с прямой ссылкой на событие в Zabbix экономит время: инженер открывает уведомление в Express и одним кликом переходит к графикам и истории события.
Пользовательские макросы на уровне шаблона или узла позволяют гибко параметризовать сообщения. Например, макрос {$EXPRESS_CHANNEL} можно определить для каждого узла, чтобы маршрутизировать оповещения в разные каналы Express без изменения медиатипа.
Ограничение длины сообщения. Express может обрезать сообщения длиннее определённого лимита (зависит от конфигурации конкретного сервера Express, обычно 4000-16000 символов). Не включайте в сообщение полный вывод логов или дамп данных. Для детальной информации дайте ссылку на Zabbix. Проверьте фактический лимит вашего Express, отправив тестовое сообщение заведомо большой длины.
Если вы только начинаете внедрение мониторинга, обратите внимание на настройку умных уведомлений и борьбу с алертным шумом. Для комплексной автоматизации бэкапов с интеграцией в Zabbix пригодятся готовые скрипты на Python и Bash. А когда мониторинг охватывает веб-серверы, изучите ключевые метрики Nginx для настройки алертов.
Для отправки уведомлений через Express ваш сервер Zabbix должен иметь надёжное сетевое соединение. Если вы разворачиваете инфраструктуру мониторинга в облаке, облачные серверы Timeweb Cloud предоставляют VDS/VPS с гарантированным каналом и возможностью масштабирования. Для автоматизации обработки инцидентов и интеграции с нейросетями можно использовать AiTunnel - единый API для доступа к GPT, Gemini и Claude без VPN с оплатой в рублях.