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

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

29 июля 2026 11 мин. чтения
Содержание статьи

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

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

Базовые принципы оповещений в 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. При создании укажите:

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

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

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

Telegram - самый быстрый канал для персональных оповещений. Сообщение доставляется за 1-2 секунды, а настройка бота занимает не более 10 минут. Вам потребуется токен бота и 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. Заполните поля:

  • 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} - дата и время события.

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

Инцидент: {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}

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

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

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

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

Эскалация настраивается в действии на вкладке 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 в зависимости от критичности метрики:

МетрикаВыражениеSeverity
Загрузка диска / > 90%{host:vfs.fs.size[/,pused].last()}>90High
CPU load avg1 > 5{host:system.cpu.load[all,avg1].avg(5m)}>5Warning
Сервис nginx не запущен{host:net.tcp.service[http].last()}=0Disaster

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

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

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

Поделиться:
Сохранить гайд? В закладки браузера