Zabbix 8.0 на нашем мониторинг-кластере: встроенная anomaly detection вместо ручных порогов

Zabbix 8.0 вышел на прошлой неделе, и у нас уже поднят тестовый кластер. Основные анонсированные фичи - встроенная anomaly detection на базе локальной ML-модели и переработанный TimescaleDB backend с нативной партиционностью. Без внешних API, без отправки метрик в облако. Для наших клиентов с чувствительной инфраструктурой это принципиально.

Что изменилось в хранилище

TimescaleDB backend в Zabbix был и раньше, но работал как надстройка: Zabbix писал в PostgreSQL, TimescaleDB превращал таблицы в гипертаблицы через расширение. В 8.0 интеграция глубже - Zabbix теперь умеет управлять партициями напрямую, не полагаясь на автоматику TimescaleDB. Это даёт контроль над политиками хранения на уровне конкретных item-групп: метрики ядра хоста держим 90 дней с полным разрешением, агрегаты по приложениям - год, детальные системные метрики - 30 дней. Раньше такую гранулярность приходилось делать через костыли в retention-политиках или заводить отдельные хосты.

Производительность записи тоже ощутимо выросла. На нашем тестовом кластере (около 40 000 item-ов, среднее значение раз в минуту) TimescaleDB backend в 8.0 показывает примерно на треть меньше latency при вставке по сравнению с нашей текущей версией 7.2. Это не маркетинговый замер - просто pgbench поверх Zabbix history table до и после.

Anomaly detection: как оно устроено

Zabbix 8.0 добавляет новый тип item - anomaly detection item. Он не собирает метрику сам по себе, а получает базовую метрику как источник и обучает локальную модель на её истории. Никаких внешних вызовов нет - модель живёт на том же Zabbix-сервере, обучение происходит через встроенный Python-worker.

Схема обучения прямолинейная. Zabbix берёт исторические данные за указанный период (по умолчанию 8 недель), разбивает их по дням недели и часам суток, строит базовый профиль нормального поведения с доверительными интервалами. Алгоритм - вариация seasonal decomposition с добавкой, которую авторы называют adaptive smoothing: модель адаптируется к медленному дрейфу базовой линии, не реагируя на долгосрочные тренды как на аномалии.

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

Что это меняет на практике

Мы посмотрели на наш пул алертов за последние три месяца и прикинули, сколько триггеров можно было бы заменить anomaly detection item-ами.

Грубая оценка: около 60% триггеров по CPU, памяти, latency и disk I/O у нас заданы статическими порогами типа «CPU > 85% 5 минут» или «response time > 2 секунды». Это работает, но требует ручной настройки под каждый хост - то, что нормально для веб-сервера под нагрузкой, будет ложным алертом на аналитическом сервере, который честно ест CPU по расписанию. Anomaly detection закрывает ровно эту проблему: порог для каждого хоста выводится из его собственной истории.

Остальные 40% - это специфические триггеры: конкретные процессы упали, размер очереди превысил N сообщений, репликация отстала больше чем на M секунд. Там аномалии не помогут - нужны точные пороги или структурные проверки.

Как обучить модель на реальных данных

Несколько замечаний из тестовой эксплуатации:

• Период обучения важен. 8 недель - разумный минимум для сервисов с недельной цикличностью. Если у вас есть месячный цикл (финансовые системы, отчётность), ставьте 12-16 недель, иначе модель не увидит паттерн и будет биться об него каждый месяц.

• История до обучения должна быть чистой. Если в период обучения были инциденты с высокой нагрузкой - модель включит их в «нормальный» диапазон. Zabbix позволяет исключить период из обучения через API, и это надо использовать осознанно, а не забыть про эту возможность.

• Adaptive smoothing и плановые изменения. Если вы добавили новый сервис или выкатили релиз с изменённой нагрузкой - модель адаптируется, но это займёт несколько дней. В этот период чувствительность лучше снизить вручную через параметр sensitivity в item-настройках.

• Zabbix Python worker - отдельный процесс. Он запускается рядом с Zabbix server и потребляет ресурсы пропорционально количеству anomaly detection item-ов. На нашем кластере с 200 такими item-ами это около 300 МБ RAM и пара процентов CPU в фоне. Не страшно, но посчитайте до масштабирования.

Что не нравится уже сейчас

Интерфейс настройки модели в веб-GUI сырой. Можно задать период обучения и sensitivity - и почти всё. Посмотреть, на каких данных модель обучена, что она считает аномальным диапазоном для конкретного часа в конкретный день недели - нельзя. Это жирная дыра в observability самого мониторинга. Объяснять клиенту «почему сработал алерт» при наличии anomaly detection item становится сложнее: был порог 85% - понятно. Теперь «модель решила, что это аномалия» - объяснение, с которым не все готовы работать.

Zabbix API в 8.0 добавил endpoint для выгрузки предсказанных baseline-значений - но это JSON с цифрами, без какой-либо визуализации в стандартном GUI. Мы уже сделали дашборд в Grafana через этот API, который показывает предсказанный диапазон поверх реальной метрики. Работает, но это дополнительная работа, которую хотелось бы видеть из коробки.

Подключение для клиентов на сопровождении планируем на следующий месяц - сначала на нескольких пилотных хостах. Посмотрим, как anomaly detection ведёт себя на инфраструктуре, которая не была в тестовой выборке.