Настройка оповещений Zabbix: готовые триггеры, эскалация и интеграция с Telegram, Slack, E-mail за 1 час

Zabbix превращает сырые метрики в оповещения по цепочке: данные агента → триггер → событие → действие → уведомление. Триггер - это логическое выражение, которое вычисляет состояние метрики. Действие определяет, кому, как и когда отправлять сообщение. Если вы пропускаете этап настройки эскалации, критичный инцидент рискует остаться незамеченным - один пуш в Telegram легко потерять среди других уведомлений.

В этом руководстве разобрана полная настройка оповещений Zabbix: от создания триггеров на загрузку CPU, заполнение диска и падение сервиса до интеграции с Telegram, Slack и E-mail. Вы получите готовые конфигурации для типового сервера и сценарий эскалации, который гарантирует реакцию дежурной смены. Внедрение занимает около часа, если следовать шагам последовательно.

Что настроим

• Триггеры Zabbix для CPU, диска, доступности хоста и веб-сервиса.
• Media type для Telegram, Slack и E-mail.
• Action с фильтрацией по severity и шаблонами сообщений.
• Эскалацию в Zabbix с повторными уведомлениями и сменой получателей.
• Проверку цепочки через Test и тестовое событие.

Итоговый маршрут: триггер создаёт событие в состоянии PROBLEM, Action отправляет уведомление по выбранному каналу, а Recovery operations сообщает о возврате в OK.

Быстрый чеклист настройки оповещений Zabbix

1. Создайте и проверьте триггеры с подходящим уровнем severity.
2. Настройте и протестируйте media types для Telegram, Slack и E-mail.
3. Добавьте media type пользователям или группам получателей.
4. Создайте Action в разделе Configuration → Actions, задайте Conditions и Operations.
5. Добавьте Recovery operations и шаблоны для PROBLEM и восстановления.
6. Настройте Escalation steps для критичных событий.
7. Выполните Test, сгенерируйте тестовое событие и проверьте логи Zabbix server.

Базовые принципы оповещений в Zabbix: триггеры и действия

Система оповещений Zabbix опирается на два компонента. Первый - триггер, который по расписанию вычисляет условие на основе собранных данных и генерирует событие. Второй - действие, которое реагирует на событие и запускает цепочку операций: отправку сообщения, выполнение скрипта или переход к следующему шагу эскалации. Без чёткого понимания этой связки невозможно построить надёжный алертинг.

Как работают триггеры: от метрики к событию

Триггер - это выражение, которое Zabbix вычисляет каждый период обновления данных. Если выражение возвращает истину, триггер переходит в состояние PROBLEM и создаёт событие. Когда условие перестаёт выполняться, триггер возвращается в OK. Синтаксис построен на функциях, которые применяются к данным элемента данных за указанный интервал.

Основные функции для триггеров:

• last() - последнее полученное значение. Подходит для мгновенных проверок: упал сервис, хост недоступен.
• avg(период) - среднее значение за интервал. Используйте для метрик, которые могут кратковременно скакать: загрузка CPU, сетевой трафик.
• min(период) и max(период) - минимальное и максимальное значение. Полезны для выявления аномалий.
• nodata(период) - отсутствие данных. Критично для обнаружения зависших агентов или обрыва связи с хостом.

Примеры триггеров, которые вы скопируете и адаптируете под свои хосты:

Высокая загрузка CPU - среднее значение за 5 минут превышает 5 (для 4-ядерного процессора это эквивалент 80% утилизации):

{host:system.cpu.load[all,avg1].avg(5m)}>5

Мало места на диске - корневой раздел заполнен более чем на 90%:

{host:vfs.fs.size[/,pused].last()}>90

Недоступность хоста - нет данных от агента более 3 минут:

{host:agent.ping.nodata(3m)}=1

Падение веб-сервера - порт 80 не отвечает:

{host:net.tcp.service[http].last()}=0

При создании триггера обязательно задайте severity - уровень важности. Шкала от Information до Disaster определяет, как Zabbix будет обрабатывать событие в действиях. Критичные инциденты (High и Disaster) должны запускать эскалацию, предупреждения (Warning) - отправляться в общий канал без дёрганья дежурного.

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

Действие в Zabbix - это набор операций, которые выполняются при наступлении условий. Условия фильтруют события по severity, тегу, имени хоста или группе узлов. Операции определяют, кому отправлять сообщение и через какой media type. Шаги эскалации добавляют задержки и меняют получателей, если проблема не решена.

Настройка действия начинается с вкладки Actions в разделе Configuration. В Zabbix 6.0 и 7.0 названия пунктов и расположение отдельных полей могут немного отличаться в зависимости от типа события и версии интерфейса, но логика Conditions, Operations и Recovery operations сохраняется.

При создании укажите:

• Conditions - какие события обрабатывать. Минимальный набор: Trigger severity >= High и Host group = ваша группа серверов. Это отсечёт информационный шум.
• Operations - что делать сразу. Добавьте операцию отправки сообщения пользователю или группе через выбранный media type. Можно указать несколько операций в одном шаге: одновременно отправить в Telegram и Slack.
• Recovery operations - сообщение о восстановлении. Настройте отдельный шаблон с пометкой «RESOLVED», чтобы команда видела, что инцидент закрыт.
• Escalation steps - шаги с задержками. Первый шаг срабатывает немедленно, второй - через N минут, третий - ещё через M минут. На каждом шаге можно менять получателей и канал.

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

Таблица маршрутизации: событие, severity и канал

Интеграция Zabbix с Telegram: настройка бота и получение алертов

Telegram - самый быстрый канал для персональных оповещений. Вам потребуется токен бота и chat_id получателя. Zabbix будет вызывать скрипт, который через Telegram API отправляет сообщение.

Регистрация Telegram-бота и получение токена

Откройте диалог с @BotFather в Telegram. Отправьте команду /newbot и следуйте инструкциям: задайте имя бота (отображается в списке контактов) и username (уникальный идентификатор, оканчивается на bot). После создания BotFather выдаст токен - строку вида 1234567890:ABCdefGHIjklMNOpqrsTUVwxyz. Сохраните его, он потребуется для настройки media type.

Теперь узнайте chat_id получателя. Напишите боту любое сообщение (просто «test»). Затем в браузере или через curl выполните запрос:

https://api.telegram.org/bot{TOKEN}/getUpdates

В ответе найдите поле chat.id - это числовой идентификатор, который Zabbix будет использовать для отправки. Для групповых чатов chat_id начинается с минуса.

Настройка media type Telegram в Zabbix

Перейдите в Administration → Media types и создайте новый тип. Выберите тип Script. В поле Script name укажите имя файла, который Zabbix будет вызывать - например, telegram.sh. Добавьте три параметра скрипта:

• {ALERT.SENDTO} - chat_id получателя,
• {ALERT.SUBJECT} - тема сообщения,
• {ALERT.MESSAGE} - тело сообщения.

Создайте скрипт на сервере Zabbix в директории, указанной в конфигурационном файле zabbix_server.conf (параметр AlertScriptsPath). Пример на bash:

#!/bin/bash
TOKEN="ВАШ_ТОКЕН"
CHAT_ID="$1"
SUBJECT="$2"
MESSAGE="$3"
curl -s -X POST "https://api.telegram.org/bot${TOKEN}/sendMessage" \
  -d chat_id="${CHAT_ID}" \
  -d text="${SUBJECT}
${MESSAGE}" \
  -d parse_mode="HTML" > /dev/null

Установите права на выполнение: chmod +x telegram.sh. Проверьте владельца - скрипт должен быть доступен пользователю, от которого работает Zabbix server.

Привяжите media type к пользователю: Administration → Users, откройте нужного пользователя, вкладка Media. Добавьте запись с типом Telegram, укажите chat_id в поле Send to. Нажмите кнопку Test - в Telegram должно прийти тестовое сообщение. Если сообщение не пришло, проверьте логи Zabbix server и права на скрипт. Подробный разбор ошибок и альтернативный способ через вебхуки описан в инструкции по настройке медиатипов в Zabbix 6.0/7.0.

Подключение Slack для командных уведомлений

Slack удобен для командной видимости инцидентов: оповещения попадают в общий канал, их видят все участники дежурной смены. Интеграция строится через Incoming Webhook - Slack предоставляет URL, на который Zabbix отправляет POST-запрос с JSON-телом сообщения.

Создание приложения и webhook в Slack

Перейдите на api.slack.com/apps и нажмите Create New App. Выберите From scratch, задайте имя приложения (например, «Zabbix Alerts») и выберите рабочее пространство. После создания приложения в боковом меню выберите Incoming Webhooks, активируйте переключатель и нажмите Add New Webhook to Workspace. Slack запросит выбор канала - укажите тот, куда должны приходить алерты. Скопируйте полученный Webhook URL вида https://hooks.slack.com/services/T.../B.../xxxx.

Интеграция webhook с Zabbix

В Zabbix перейдите в Administration → Media types и создайте новый тип с типом Webhook. Укажите параметры:

• URL - скопированный Webhook URL,
• HTTP method - POST,
• Media type - JSON.

В поле Message template вставьте JSON-шаблон:

{
  "text": "{ALERT.SUBJECT}\n{ALERT.MESSAGE}"
}

Для форматирования сообщений используйте Slack-разметку. Пример расширенного шаблона с цветовой индикацией severity:

{
  "attachments": [
    {
      "color": "{EVENT.SEVERITY}",
      "title": "{ALERT.SUBJECT}",
      "text": "{ALERT.MESSAGE}",
      "footer": "Zabbix"
    }
  ]
}

Добавьте media type пользователю аналогично Telegram: вкладка Media, тип Slack, в поле Send to укажите Webhook URL. Нажмите Test - в выбранном канале Slack появится тестовое сообщение. Если вы ещё не определились с выбором основного канала, сравните скорость доставки и надёжность в статье Express, Telegram или Email: какой канал уведомлений выбрать.

Настройка E-mail уведомлений: SMTP и шаблоны

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

Конфигурация SMTP в Zabbix

Откройте Administration → Media types → Email. В Zabbix 6.0/7.0 часть параметров может отображаться в расширенной форме настроек media type. Заполните поля:

• SMTP server - адрес сервера (например, smtp.gmail.com),
• SMTP server port - 587 для STARTTLS или 465 для SSL/TLS,
• SMTP helo - доменное имя вашего сервера Zabbix,
• SMTP email - адрес отправителя,
• Connection security - STARTTLS или SSL/TLS,
• Authentication - Username and password.

Для Gmail и Yandex требуется пароль приложения, а не пароль от аккаунта. В Gmail: Настройки → Безопасность → Двухэтапная аутентификация → Пароли приложений. Сгенерируйте пароль для приложения «Почта» и устройства «Другое (Zabbix)». В Yandex: ID → Безопасность → Пароли приложений. Корпоративный Exchange настраивается аналогично, но уточните у администратора почтовой системы разрешённые методы аутентификации.

После сохранения настроек нажмите Test и проверьте логи Zabbix server на наличие ошибок аутентификации или таймаутов соединения.

Кастомизация шаблонов писем

Шаблоны сообщений настраиваются в действии, на вкладке Operations. Для каждого шага эскалации можно задать свой шаблон. Используйте макросы Zabbix для подстановки данных инцидента:

• {HOST.NAME} - имя хоста,
• {HOST.IP} - IP-адрес,
• {TRIGGER.NAME} - имя триггера,
• {TRIGGER.STATUS} - PROBLEM или OK,
• {TRIGGER.SEVERITY} - уровень важности,
• {ITEM.VALUE} - значение метрики в момент срабатывания,
• {EVENT.DATE} {EVENT.TIME} - дата и время события.

Готовые шаблоны сообщений для PROBLEM и RECOVERY:

Инцидент: {TRIGGER.NAME}
Хост: {HOST.NAME} ({HOST.IP})
Статус: {TRIGGER.STATUS}
Важность: {TRIGGER.SEVERITY}
Значение: {ITEM.VALUE}
Время: {EVENT.DATE} {EVENT.TIME}

RESOLVED: {TRIGGER.NAME}
Хост: {HOST.NAME} ({HOST.IP})
Статус: {TRIGGER.STATUS}
Время восстановления: {EVENT.DATE} {EVENT.TIME}

Пример тела письма для критичного инцидента:

Инцидент: {TRIGGER.NAME}
Хост: {HOST.NAME} ({HOST.IP})
Статус: {TRIGGER.STATUS}
Важность: {TRIGGER.SEVERITY}
Значение: {ITEM.VALUE}
Время: {EVENT.DATE} {EVENT.TIME}

Ссылка на событие: https://zabbix.example.com/tr_events.php?eventid={EVENT.ID}

Добавление прямой ссылки на событие сокращает время реакции - инженер переходит к графику или истории одним кликом.

Эскалация уведомлений в Zabbix: как не пропустить критичный инцидент

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

Как работает эскалация в Zabbix

Эскалация настраивается в действии на вкладке Operations. Каждый шаг - это отдельная операция с задержкой относительно предыдущего шага. По умолчанию первый шаг выполняется немедленно. Второй и последующие шаги добавляются кнопкой Add escalation step.

Параметры шага эскалации:

• Step duration - задержка в секундах перед выполнением этого шага. Отсчитывается от момента отправки предыдущего уведомления, а не от начала инцидента.
• Operation type - Send message, Run remote command, Send recovery message.
• Send to user groups / Send to users - получатели этого шага. Можно указать других пользователей или группы, отличные от первого шага.

Условия остановки эскалации настраиваются в разделе Recovery operations. Когда триггер возвращается в OK, Zabbix автоматически прекращает эскалацию и отправляет сообщение о восстановлении, если оно настроено.

Сценарий эскалации для критичного сервиса

Рассмотрим веб-сервер с триггером на недоступность порта 80. Сервис критичен для бизнеса, простой дольше 5 минут недопустим. Настроим трёхшаговую эскалацию:

1. Шаг 1 (немедленно) - отправка в Telegram дежурному инженеру. Это самый быстрый канал, инженер получает пуш мгновенно.
2. Шаг 2 (через 10 минут) - повторная отправка в Telegram плюс сообщение в общий канал Slack. Если инженер не отреагировал, инцидент становится видимым для всей команды.
3. Шаг 3 (через 30 минут) - отправка E-mail руководителю отдела с пометкой «Критичный инцидент не решён». Письмо содержит все детали и ссылку на событие.

В действии это выглядит так: создаёте операцию отправки в Telegram на первом шаге. Добавляете шаг эскалации с длительностью 600 секунд (10 минут), в нём - две операции: Telegram и Slack. Добавляете третий шаг с длительностью 1800 секунд (30 минут от начала инцидента), в нём - операция Email руководителю. Обязательно настройте операцию восстановления, чтобы при закрытии инцидента всем получателям ушло сообщение «Проблема решена».

Типовой сценарий: мониторинг сервера с алертами на диск, CPU и сервисы

Соберём все компоненты в единый кейс. Настроим хост «Production Server» с тремя триггерами и одним действием, которое маршрутизирует уведомления в зависимости от severity. После настройки проверим срабатывание ручной генерацией события. Если вы настраиваете алертинг впервые, предварительно изучите готовые конфигурации действий и шаблоны сообщений - это сэкономит время на базовых операциях.

Настройка триггеров для типовых метрик

Создайте три триггера на хосте. Каждый триггер получает свой severity в зависимости от критичности метрики:

Загрузка диска - High, потому что заполнение раздела до 90% требует скорого вмешательства, но сервер ещё работает. Высокий CPU - Warning: это сигнал к расследованию, но не повод будить дежурного ночью. Падение nginx - Disaster: сервис недоступен, каждая минута простоя приносит убытки.

Создание действия и проверка алертов

Создайте действие с условием: Trigger severity >= High. Это захватит оба критичных триггера (диск и nginx) и отсечёт Warning по CPU - для него можно создать отдельное действие с отправкой в общий канал без эскалации.

Настройте операции:

• Шаг 0: Telegram дежурному, Slack в канал #alerts.
• Шаг 1 (600 сек): повтор Telegram, Slack в канал #incidents с упоминанием @oncall.
• Шаг 2 (1800 сек): Email руководителю.

Для проверки не нужно ждать реального сбоя. Остановите nginx на тестовом сервере: systemctl stop nginx. Zabbix на следующем цикле проверки обнаружит недоступность порта 80, триггер перейдёт в PROBLEM, и действие запустит цепочку уведомлений. Проверьте Telegram и Slack - сообщения должны прийти в течение минуты. Запустите nginx обратно: systemctl start nginx. Должно прийти сообщение о восстановлении. Если сообщения не приходят, выполните ручную активацию триггера и анализ логов по инструкции тестирования оповещений Zabbix.

Как проверить оповещения Zabbix и найти ошибки

Проверяйте цепочку последовательно: сначала состояние триггера и события, затем Action, media type и права пользователя. В разделе событий убедитесь, что событие имеет нужный severity и что действие соответствует Conditions. В истории действий проверьте, была ли запущена операция и на каком шаге возникла ошибка.

• Webhook Slack: ошибка HTTP, пустой или неверный URL обычно указывает на недействительный Webhook URL, неверный HTTP method или JSON. Проверьте URL, тело запроса и ответ Slack.
• Script path Telegram: сообщение об отсутствии файла или ошибке запуска указывает на неверный AlertScriptsPath, имя telegram.sh или отсутствие execute permission. Проверьте путь, владельца и запуск от пользователя Zabbix server.
• Telegram API: отсутствие доставки при успешном запуске скрипта проверяйте по TOKEN, chat_id, правам бота в группе и ответу curl.
• SMTP: timeout и connection refused указывают на сетевой доступ или неправильный порт; authentication failed - на логин, пароль приложения или выбранный метод STARTTLS/SSL/TLS.
• Permissions: если Test доступен, но автоматическое событие не отправляется, сравните пользователя, его Media, период активности и разрешения на хост или группу.

Основной источник диагностики - лог Zabbix server. Ищите записи по имени media type, получателю, webhook, скрипту или SMTP и сопоставляйте время ошибки со временем события. После исправления повторите Test, затем отдельно проверьте PROBLEM и Recovery.

За пределами инфраструктурного мониторинга: что нужно знать о бизнес-метриках

Zabbix отлично контролирует доступность и ресурсы: CPU, память, диски, сетевые порты. Но зелёные графики на дашборде не гарантируют, что бизнес-операции выполняются с требуемой скоростью. Доступность нижнего технологического слоя - серверов, виртуальных машин, контейнеров - не равна качеству работы приложений.

На примере 1С это проявляется особенно остро. Сервер приложений 1С может быть доступен, CPU и память в норме, но проведение документа занимает 30 секунд вместо штатных двух. Пользователи жалуются, бизнес-процесс тормозит, а Zabbix молчит - его триггеры не пересекли порог. Контролировать необходимо не только состояние узлов, но и фактическое время проведения документов, открытия форм, выполнения расчётов и обменов. Критичность инцидента должна определяться влиянием на конкретную базу, операцию и группу пользователей, а не цветом отдельного триггера.

Zabbix может собирать такие метрики через пользовательские параметры или внешние скрипты. Вы пишете скрипт, который замеряет время проведения документа в 1С, и передаёте результат агенту Zabbix через UserParameter. Дальше - стандартная цепочка: элемент данных, триггер с порогом по времени, действие с уведомлением. Это требует дополнительной настройки, но даёт полную картину: инфраструктурный мониторинг плюс контроль качества бизнес-операций в одной системе.