Zabbix 7.4 и ML-аномалии: как алерт поймал деградацию диска раньше SMART

Zabbix 7.4 вышел в ноябре с двумя заметными вещами: переработанным движком предиктивных триггеров и новым алгоритмом обнаружения аномалий на основе ML - точнее, на основе статистического моделирования временных рядов, которое в документации называется AI/ML. Мы подняли 7.4 на одном из крупных кластеров под сопровождением и через неделю получили алерт, который поймал умирающий диск раньше, чем это сделал SMART. История небольшая, но показательная.

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

Основное в части аномалий - это новый детектор, который строит базовую линию поведения метрики за скользящее окно (по умолчанию 7 дней, настраивается) и сигнализирует, когда текущее значение выходит за границы статистически ожидаемого диапазона. Это не просто threshold - алерт срабатывает не потому что значение больше X, а потому что оно ведёт себя не так, как вело себя последние N дней в этот же час.

Zabbix умел что-то похожее и раньше через функцию baseline(), но в 7.4 это переработали: модель учитывает сезонность (дневную, недельную), адаптируется к долгосрочному дрейфу и позволяет задавать чувствительность через параметр уровня отклонения.

Второе - улучшенный forecasting. В триггерах теперь можно писать forecast(метрика, 24h) и алертить если прогноз на 24 часа вперёд пересекает порог. Для дисков это стандартный сценарий - не «диск заполнен», а «диск заполнится через сутки».

Как мы настраивали

Кластер - несколько десятков серверов, смешанная нагрузка. Zabbix 7.2 там уже стоял, обновление до 7.4 прошло штатно, ничего особенного.

Включение ML-детекции для нужных метрик делается через интерфейс или через API - в шаблоне айтема добавляется тип детектора. Мы включили для:

• IOPS на дисках - исторически самая информативная метрика при деградации.
• Latency операций ввода-вывода - vfs.dev.read.time и vfs.dev.write.time.
• Сетевые ошибки - там своя специфика, про неё ниже.

Первый же день показал, почему с чувствительностью надо быть осторожным. На дефолтных настройках (уровень чувствительности - средний) мы получили несколько десятков алертов за сутки. Большая часть - ложные: плановый бэкап ночью, пиковая нагрузка утром при старте рабочего дня, репликация с характерным паттерном. Модель этого не знала, потому что 7 дней истории у неё ещё не было - она строила базовую линию на том, что успела собрать.

Решение простое, но его надо понимать заранее: детектор нужно дать «поучиться» - выдержать минимум полную неделю с репрезентативной нагрузкой прежде чем переводить алерты в production-severity. Мы поставили детекцию в режим «информационных» алертов (severity: Information) на две недели, смотрели что приходит, настраивали maintenance windows для регулярных задач.

Для сетевых метрик ML-детекция дала слишком много шума - там паттерн слишком нерегулярный, коротких всплесков много. Оставили классические thresholds, ML убрали.

Алерт, который нас удивил

На девятый день после включения пришёл алерт по vfs.dev.write.time на одном из серверов - латентность записи отклонилась от базовой линии. SMART на том же диске в этот момент был зелёным: reallocated sectors - 0, pending sectors - 0, все атрибуты в норме.

Мы поначалу отнеслись к алерту скептически - свежая модель, могло быть что угодно. Но решили проверить: посмотрели на iostat -x в реальном времени, подняли исторические данные по тому же диску за неделю. Картина интересная: латентность записи начала медленно расти трое суток назад - не резко, а плавно, в рамках, которые не задели бы threshold. Именно эту медленную деградацию и поймал детектор.

SMART отчитался о проблеме через двое суток - появились первые pending sectors. Ещё через день диск начал сыпать ошибками в dmesg. Мы к этому моменту уже сделали замену в плановом порядке, без инцидента.

Точные цифры не называем - они специфичны для железа и профиля нагрузки. Но логика ситуации воспроизводится: SMART ловит уже случившиеся ошибки, а изменение поведения латентности можно заметить раньше.

Что по false positive

За первые две недели в «тихом» режиме мы насчитали около трёх десятков алертов, из которых после разбора реальными проблемами оказались два (деградирующий диск и один случай сетевой деградации на коммутаторе). Остальное - шум от регулярных паттернов, которые модель ещё не включила в базовую линию.

После двух недель обучения и настройки maintenance windows ситуация улучшилась. Не идеально - периодически что-то приходит ложное. Но соотношение сигнал/шум стало приемлемым для того чтобы не игнорировать алерты.

Несколько практических наблюдений:

• Чувствительность лучше начинать с низкой и повышать постепенно - проще добавить чувствительности потом, чем два дня разгребать шум.
• Maintenance windows - обязательно. Ночные бэкапы, плановые дефрагментации, скрипты аналитики - всё это надо внести, иначе модель будет считать их аномалиями бесконечно.
• Не все метрики подходят. Нерегулярные метрики с высокой дисперсией дадут только шум. ML-детекция лучше всего работает там, где есть чёткий суточный или недельный ритм.

Где мы сейчас

ML-аномалии в Zabbix 7.4 - не магия, и не замена классическому мониторингу. Это дополнительный слой, который ловит медленные изменения, не видимые через пороговые алерты. В нашем случае один конкретный кейс с диском уже окупил время на настройку.

Мы сопровождаем инфраструктуру в рамках managed-сервиса - если интересно как настроить подобный мониторинг на вашем стеке, можем обсудить.