Zabbix 5.4: Business Service Monitoring и SLA-репортинг для клиента

Zabbix 5.4 вышел в мае, мы к нему присматривались, и повод обновиться нашёлся быстро: один из клиентов попросил добавить к мониторингу SLA-репортинг. Не просто «покажи, сколько алертов было», а нормальный отчёт по доступности конкретных бизнес-сервисов в разрезе периода. В Zabbix 5.4 переработали Business Service Monitoring (BSM) - именно под этот сценарий.

Что изменилось в 5.4

В прежних версиях BSM существовал в виде IT Services - раздела, про который многие знали, но немногие использовали. Интерфейс был архаичным, логика местами контринтуитивной, и большинство команд просто не доходило до его изучения.

В 5.4 это переписали. Несколько ключевых изменений:

Дерево зависимостей сервисов. Теперь можно строить иерархию: верхний уровень - бизнес-сервис, ниже - его компоненты, ещё ниже - конкретные триггеры Zabbix. Статус сервиса агрегируется снизу вверх по правилам, которые настраиваются: «деградировал, если хотя бы один дочерний упал», «критично, если упали N из M», и так далее.

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

Webhook-интеграция. В 5.4 существенно причесали механизм Media Types. Шаблоны для Telegram, Slack, PagerDuty и других идут в комплекте и настраиваются через UI без правки конфигов руками. Это не революция, но приятно.

Обновлённый UI. Дизайн стал заметно современнее - не радикально, но пользоваться стало легче. Виджет на дашборде теперь показывает статус дерева сервисов в реальном времени.

Что за клиент и зачем им SLA

Клиент - небольшая компания, у которой мы ведём инфраструктуру в рамках managed-сопровождения. Несколько десятков серверов, разношёрстный стек: продакшн на Linux, кое-что на Windows, база на PostgreSQL, внешний сайт, внутренние сервисы. Мониторинг у них был, Zabbix 5.2 стоял давно, всё работало.

Ситуация: клиент начал предоставлять сервис подрядчикам с формальным SLA в договоре. И пришли с вопросом - как мы будем отчитываться по доступности? Spreadsheet с ручными отметками - не вариант, это сразу же история про конфликты «а мы считаем иначе».

Задача: настроить BSM так, чтобы у клиента был объективный отчёт по каждому ключевому сервису, который он обязался держать доступным.

Как выглядит дерево сервисов

Мы разложили инфраструктуру клиента на три верхнеуровневых сервиса: внешний сайт, внутренний портал и база данных. Дальше каждый раскрывается в компоненты.

Внешний сайт (SLA 99,5%)
├── Веб-сервер (nginx)
│   ├── Триггер: nginx процесс не отвечает
│   └── Триггер: порт 443 недоступен
├── Приложение
│   ├── Триггер: сервис упал
│   └── Триггер: ошибки в логах > порога
└── PostgreSQL
    ├── Триггер: сервис недоступен
    └── Триггер: репликация отстала > 5 минут

Логика агрегации: сайт считается недоступным, если недоступен веб-сервер ИЛИ недоступно приложение. Деградация PostgreSQL без падения сайта идёт в статус «деградировал», а не «недоступен» - это важно для правильного расчёта SLA.

Это не просто красивая картинка. Когда прилетает алерт, дашборд сразу показывает: не просто «упал хост БД», а «деградировал бизнес-сервис Внешний сайт». Это меняет восприятие - дежурный сразу видит приоритет инцидента без необходимости держать в голове карту зависимостей.

Процесс настройки

Обновление с 5.2 на 5.4 прошло без сюрпризов - стандартный dnf update, потом обновление схемы базы скриптом из дистрибутива. Примерно полчаса с учётом перестраховочного бэкапа перед началом.

Настройка BSM заняла больше - не потому что сложно технически, а потому что нужно было нормально поговорить с клиентом и выяснить, что они реально считают «сервисом» и при каких условиях он «недоступен» с их точки зрения. Это не вопрос к Zabbix, это вопрос к бизнесу, и без его ответа настраивать нечего.

После согласования структуры - несколько часов в UI на создание дерева, привязку триггеров и настройку правил агрегации. Документация по 5.4 сырая - часть пришлось выяснять экспериментально, благо на тестовом стенде.

Что пока работает не идеально

SLA-расписание - слабое место. Клиент хочет считать SLA только в рабочие часы, а у них плавающий график в зависимости от сезона. В Zabbix это настраивается через Service Times, но интерфейс там довольно неудобный, и сделать что-то нестандартное - много кликов. Пока настроили фиксированное расписание, более точное - на следующей итерации.

Исторические данные в BSM считаются только с момента создания сервисов - прошлые алерты в расчёт не берутся. Для первого отчётного периода это означает, что данных будет меньше месяца. Клиента предупредили заранее.

Где сейчас

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

Webhook на Telegram настроили по шаблону из комплекта Zabbix - занял буквально пятнадцать минут. Это та область, где 5.4 реально улучшился: раньше мы писали custom-скрипты под каждую интеграцию, теперь это не нужно для типовых каналов.

Параллельно обновляем Zabbix у ещё одного клиента - там в задачи входит только апгрейд без BSM, улучшенный UI и webhooks уже сами по себе повод для обновления.