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, который показывает предсказанный диапазон поверх реальной метрики. Работает, но это дополнительная работа, которую хотелось бы видеть из коробки.

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