Когда ваш сервер говорит «возьмите зонтик», или Прогнозирующие функции в Zabbix

О чём эта статья

Хорошо настроенная система мониторинга должна не просто сигнализировать о проблемах, а предупреждать о них заранее. Не просто «диск переполнен», а «завтра к обеду он будет полным, если ничего не сделать». Это и есть магия проактивного подхода. Вместо того, чтобы как синоптик, ошибаться насчёт «возможного дождя», встроенные инструменты Zabbix анализируют тренды и чётко предсказывают: «Через 12 часов на сервере db-01 начнётся ливень из ошибок, связанный с нехваткой памяти».
Давайте разберёмся, как настроить такого метеоролога для вашей ИТ-инфраструктуры, чтобы вы могли брать «зонтик» заранее, а не бежать под внезапным «дождём» проблем в панике.

Функции прогнозирования в Zabbix

В Zabbix имеются средства прогнозирования будущего поведения наблюдаемой системы на основе исторических данных. Эти средства реализованы в виде прогнозирующих функций триггеров.
Перед настройкой триггера необходимо определить состояние проблемы и сколько времени нужно для принятия мер. Далее есть два способа настроить триггер, сигнализирующий о возможной нежелательной ситуации. Первый: триггер должен сработать, когда ожидается, что после «времени реагирования» система будет в проблемном состоянии. Второй: триггер должен сработать, когда прогнозируется, что система достигнет проблемного состояния за время, меньшее, чем «время реагирования». Для этого используются функции триггеров forecast и timeleft соответственно. 
Функция forecast отвечает на вопрос «Какое значение примет метрика через заданное время?» и в результате своего выполнения возвращает прогнозируемое значение в виде числа.

Синтаксис:
forecast(/узел_сети/ключ,(сек|#число)<:сдвиг_времени>,время,<аппроксимация>,<режим>)
Пример:
«Какая будет загрузка CPU через 30 минут, если текущий тренд продолжится?»
forecast(/host/system.cpu.load, 1h, 30m)
Пояснения:
• host – Имя узла
• system.cpu.load - Ключ элемента данных, для которого строится прогноз.
• 1h - Исторический интервал для анализа тренда (здесь — последний час).
• 30m - Смещение в будущее, на которое делается прогноз (здесь — через 30 минут).

На основе этого примера можно сразу составить триггер:
forecast(/host/system.cpu.load, 1h, 30m) > 90

Таким образом, если прогнозируемая через 30 минут загрузка CPU превысит 90% - активируется триггер, и вы получите оповещение (если они у вас настроены, разумеется).

Функция timeleft отвечает на вопрос «Через сколько времени метрика достигнет заданного порога?» и в результате своего выполнения возвращает время в секундах до достижения порога.
Синтаксис:
timeleft(/узел_сети/ключ,(сек|#число)<:сдвиг_времени>,порог,<аппроксимация>)
Пример:
«Через сколько секунд свободное место упадет ниже 10 ГБ?»
timeleft(/host/vfs.fs.size[/,free], 1h, 10G)
Пояснения:
• /host/vfs.fs.size[/,free] - Ключ элемента данных, отслеживающий свободное место на корневом разделе (/).
• 1h - Период исторических данных для анализа текущего тренда изменения (здесь — последний час).
• 10G - Пороговое значение, время достижения которого рассчитывается. Единицы должны соответствовать единицам элемента данных (ГБ, байты и т.д.).

Заполнение диска:
Сработает, если до достижения критического порога в 5 ГБ свободного места осталось менее 12 часов. Условие <> -1 исключает ложные срабатывания при ошибках прогноза.
timeleft(/host/vfs.fs.size[/,free], 6h, 5G) < 12h and timeleft(..., 6h, 5G) <> -1
Рост лог-файла:
Предупреждение, если лог-файл достигнет 100 МБ менее чем за час.
timeleft(/host/vfs.file.size[/var/log/app.log], 3h, 100M)<1h
Исчерпание памяти процесса:
Если процесс потребляет память по экспоненте, триггер спрогнозирует, когда он превысит 2 ГБ.
timeleft(/host/proc.mem[myservice],2h, 2G, "exponential")<4h
Занятие inode:
Предсказывает, когда количество свободных inode упадёт ниже 1000.
timeleft(/host/vfs.fs.inode[/,free], 1d, 1000) < 2d
Рост таблицы БД:
Долгосрочный прогноз роста таблицы базы данных на основе недельного тренда.
timeleft(/host/db.size[main_table], 7d, 50G) < 14d
Пиковая нагрузка CPU:
Если максимальная прогнозируемая загрузка CPU на ближайшие 15 минут превысит 90%.
forecast(/host/system.cpu.load, 30m, 15m, "max") > 90
Прогноз температуры:
Для мониторинга аппаратных датчиков — предупреждение о перегреве.
forecast(/host/sensor.temp[CPU], 5m, 2m) > 80

Итак, прогнозирующие функции — это не просто технический инструмент, а ваш штатный синоптик в мире серверов и сетей. Их использование позволяет заменить авральные работы - плановым обслуживанием, а стресс - контролем. Настройте эти функции для ключевых метрик вашей инфраструктуры, и вы переведёте мониторинг из режима «скорой помощи» в режим превентивной диагностики. 
А курсы Zabbix будут в этом помощником.