Zabbix 7.2: встроенный anomaly detection на исторических данных и нативная Grafana без TSDB-прокси

Zabbix 7.2 вышел несколько недель назад, и у нас как раз подвернулась хорошая причина не откладывать: один из клиентов давно просил поднять Grafana-дашборды поверх Zabbix-данных без городьбы с отдельным Prometheus и Victoria Metrics в роли прокси. В 7.2 появилась нативная интеграция с Grafana через Zabbix Data Source. Плюс переработанный anomaly detection, который теперь встроен прямо в сервер - без внешних скриптов. Обновили, посмотрели, делимся.

Контекст: кто этот клиент и что было до

Клиент - производственное предприятие, около 200 хостов в Zabbix, несколько тысяч активных метрик. История в Zabbix накоплена примерно за три года - это важно для anomaly detection, о котором ниже. До 7.2 жили на Zabbix 6.4 LTS.

Grafana у них уже была, использовалась для операционных отчётов - но данные тянула из отдельного стека: Prometheus с экспортёрами, Victoria Metrics как хранилище. Zabbix при этом собирал практически те же метрики по SNMP и агентам. Получилась классическая ситуация: два параллельных источника правды об одной инфраструктуре, и дежурный инженер иногда видел расхождение между ними.

Смысл перехода на 7.2 был прост: убрать дублирование, сделать Zabbix единственным источником данных и вывести всё в Grafana уже без промежуточного стека.

Обновление сервера

Обновление с 6.4 до 7.2 прошло без сюрпризов - Zabbix достаточно аккуратно ведёт совместимость схемы БД, и миграционные скрипты отработали штатно. Единственная засада: несколько кастомных UserParameters в конфигах агентов использовали синтаксис, который в 7.x слегка изменился в части экранирования. Нашли через лог сервера после обновления, починили за час.

Отдельно стоит сказать про требования к железу: Zabbix 7.2 заметно прожорливее по памяти, чем 6.4 при том же числе хостов. На нашем стенде пришлось добавить RAM серверу - не критично, но закладывать запас нужно.

Нативная интеграция с Grafana

Это главное, ради чего шли на обновление. В 7.2 Zabbix официально поддерживает Grafana Data Source, который работает напрямую с Zabbix API - без никакого TSDB посередине. Плагин существовал и раньше как community-проект, но теперь его поддержка заявлена как официальная, и разница ощутима: документация нормальная, API-эндпоинты, которые нужны плагину, теперь стабильны и не меняются между минорными версиями.

Установка плагина в Grafana - стандартная, через grafana-cli. Настройка Data Source: указываешь URL Zabbix API, логин/пароль пользователя с правами на чтение, и всё. Дашборды начинают работать.

Несколько наблюдений по реальному использованию:

• Навигация по метрикам в Grafana. Плагин предлагает иерархический выбор: Host Group - Host - Application - Item. Это точно соответствует модели данных Zabbix, и для людей, которые знают структуру своего Zabbix, удобно. Для тех, кто привык к PromQL-автодополнению, немного непривычно - но привыкнуть можно.

• Производительность. При больших временных диапазонах (неделя, месяц) плагин делает запросы к Zabbix API, который в свою очередь лезет в историю БД. Это не так быстро, как Victoria Metrics с её специализированным хранилищем. Для оперативных дашборд с горизонтом 6-24 часа - нормально, для аналитических запросов по месяцу данных - медленно. Клиента об этом предупредили.

• Алерты из Zabbix в Grafana Alerting. Плагин умеет тянуть текущие проблемы Zabbix как состояния в Grafana Alerting. Это работает, но мы решили не переключаться: у клиента нотификации из Zabbix уже настроены и работают нормально, а дублировать alerting-логику в Grafana ради этого нет смысла. Дашборды - да, алерты - пусть остаются в Zabbix.

Anomaly detection в 7.2: что внутри

Второй большой блок - встроенный anomaly detection. В Zabbix 7.0 LTS anomaly detection уже был встроен - через preprocessing-шаг ANOMALY_DETECTION и функцию anomaly() в триггерах. В 7.2 механизм переработан: вместо preprocessing-шага появилась функция baseline() прямо в триггерном выражении, что даёт более гибкие настройки периода истории и чувствительности. Мы как раз прошли через внешний Python-сервис три месяца назад на другом клиенте и знаем, что это за удовольствие - встроенного варианта тогда не хватало.

В 7.2 аномалии детектируются через новый тип триггерного выражения - baseline(). Функция строит прогнозный коридор для метрики на основе исторических данных с учётом сезонности (дневной и недельной) и сравнивает текущее значение с ним. Параметры настраиваются в самом триггере: период истории для обучения, чувствительность отклонения.

Три года истории в БД клиента дали модели хорошую базу. Мы попробовали несколько метрик:

• Загрузка CPU на производственных серверах. Модель быстро подхватила суточный и недельный паттерн нагрузки. Тестовый прогон на исторических данных (Zabbix умеет это через режим симуляции триггеров) показал несколько реальных аномалий за последние полгода, которые пороговые алерты не поймали - в частности, один эпизод постепенного роста нагрузки в ночное время, который завершился остановкой процесса под утро. Пороговый алерт сработал на остановке; baseline()-триггер на той же истории показывал отклонение уже за несколько часов до этого.

• Сетевой трафик на некоторых интерфейсах. Тут хуже - хаотичный трафик без выраженной сезонности создаёт много ложных срабатываний. Та же проблема, что мы видели с внешним ML. Для таких метрик оставили классические пороги.

• Время ответа критичных сервисов. Работает хорошо там, где есть предсказуемый дневной паттерн. Это, пожалуй, лучший кейс для baseline() в нашем случае.

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

Что дальше

Сейчас мониторим, как baseline()-триггеры ведут себя в продуктиве в течение нескольких недель. Параллельный Prometheus-стек пока не снесли - клиент хочет убедиться, что переход прошёл без потерь, и только потом убирать дублирование. Так и правильно.

Для клиентов, которых ведём в рамках managed-сопровождения инфраструктуры, обновление до Zabbix 7.2 будем предлагать в плановых окнах - в первую очередь тем, у кого уже есть Grafana в стеке или кто интересовался anomaly detection. Кто на 6.4 LTS и всё устраивает - торопиться некуда.