Мониторинг Proxmox через Zabbix и Grafana
У Proxmox есть собственные графики — красивые, встроенные и почти бесполезные для эксплуатации. Они показывают, что происходит сейчас, если вы смотрите в экран. А узнать нужно другое: что-то сломалось, пока вы спали.
Разберу, как поставить нормальный мониторинг: откуда снимать метрики, что именно смотреть и как не пропустить главное — состояние пулов ZFS, которого нет ни в одном штатном шаблоне.
Две точки съёма, и нужны обе
Это первое, что стоит понять. У Proxmox два уровня, и они видят разное.
Агент Zabbix на самом хосте видит машину как обычный Linux-сервер: процессор, память, диски, сеть, температуры, состояние служб. Сюда же цепляются собственные проверки — ZFS и SMART.
API кластера видит виртуальную инфраструктуру: какие узлы живы, сколько виртуалок и контейнеров запущено, сколько места в хранилищах, чем закончились задания резервного копирования.
Агент не знает, что вчерашний бэкап упал с ошибкой. API не знает, что диск сыплет ошибками чтения. Ставьте оба.
Агент на хосте
Proxmox — это Debian, поэтому агент ставится штатно из репозитория.
Работать лучше в активном режиме: агент сам отправляет данные на сервер. Так не нужно открывать к нему входящий порт, а для узлов за NAT это единственный рабочий вариант.
В конфигурации указывается адрес сервера в параметре активных проверок и имя хоста, ровно такое же, как заведено в Zabbix. Расхождение в имени — самая частая причина «агент стоит, а данных нет».
Дальше вешается стандартный шаблон Linux, и базовые метрики поедут сразу.
Подключение через API кластера
Официальный шаблон Zabbix для Proxmox работает по HTTP, через API, и ему нужен токен.
В веб-интерфейсе Proxmox: Datacenter → Permissions → API Tokens → Add.
Создайте отдельного пользователя под мониторинг, не используйте root.
Снимите галочку разделения привилегий или выдайте токену права явно.
Дальше — права: Datacenter → Permissions → Add → API Token Permission,
путь /, роль PVEAuditor. Это роль только на чтение, мониторингу больше
ничего не нужно.
Секрет токена показывается один раз при создании — сохраните сразу.
В Zabbix заводите хост, вешаете шаблон Proxmox и заполняете макросы: адрес узла, идентификатор токена и секрет. Через минуту приедут данные по узлам, виртуалкам, контейнерам и хранилищам.
ZFS: то, чего нет из коробки
Вот ради этого раздела статья и писалась.
Ни агентский шаблон, ни шаблон через API не следят за здоровьем пула. Вы увидите, сколько места занято, но не увидите, что пул деградировал.
А разница принципиальная: деградировавший пул работает точно так же, как здоровый. Те же скорости, все файлы на месте, никаких ошибок в приложениях. Единственное отличие — избыточности больше нет, и следующий отказ диска будет последним.
Добавляется своими проверками. Простейший вариант — отдать агенту команду, возвращающую состояние пула:
UserParameter=zfs.pool.health[*],zpool list -H -o health $1
Возвращает одно слово: ONLINE, DEGRADED или FAULTED. Дальше в Zabbix
это обычный текстовый элемент данных, а триггер срабатывает на всё,
что не равно ONLINE.
Если пулов несколько или они появляются и исчезают, добавьте обнаружение —
отдельный UserParameter, возвращающий список пулов, и прототипы элементов
поверх него.
Пара практических моментов:
- Права. Проверьте, что команда отрабатывает именно от пользователя
zabbix, а не от root, под которым вы её тестировали. Если прав не хватает, добавьте правило в sudoers для конкретной команды — не для всей утилиты. - Не только health. Полезно снимать ещё количество ошибок чтения, записи
и контрольных сумм из
zpool status: они растут до того, как пул перейдёт в DEGRADED. Это предупреждение за дни, а не постфактум. - Заполненность. ZFS резко теряет производительность после 80% занятого места. Триггер на этой отметке избавит от загадочных тормозов.
SMART: предупреждение за неделю
ZFS сообщает, когда диск уже подвёл. SMART часто предупреждает раньше: переназначенные секторы, ошибки чтения, растущая температура.
Снимается через smartctl. Ему нужны привилегии, поэтому потребуется
правило в sudoers для пользователя агента.
Смотреть стоит на переназначенные и ожидающие переназначения секторы, ошибки интерфейса и температуру. Рост числа переназначенных секторов — повод заказать диск на замену, не дожидаясь отказа.
Какие триггеры действительно нужны
Соблазн навесить всё подряд велик, а результат предсказуем: через месяц уведомления улетают в отдельную папку не глядя. Минимально достаточный набор:
| Триггер | Почему |
|---|---|
Пул не ONLINE |
ради этого всё и затевалось |
| Растут ошибки чтения, записи или контрольных сумм | предупреждение до деградации |
| Переназначенные секторы SMART увеличились | диск начал умирать |
| Хранилище занято больше 85% | у ZFS это ещё и потеря скорости |
| Узел не отвечает | очевидно |
| Задание бэкапа завершилось с ошибкой | худший вид тишины |
| Температура диска выше 50 °C | летом и в закрытом корпусе бывает |
Последний пункт про бэкапы недооценивают. Резервное копирование ломается молча: расписание отрабатывает, задание падает, никто не знает. Выясняется в день, когда копия понадобилась.
Grafana поверх
Zabbix умеет рисовать графики сам, но Grafana удобнее, когда смотреть надо регулярно.
Ставится плагин Zabbix, добавляется источник данных с адресом API Zabbix и учёткой на чтение. Дальше — дашборды.
Совет из практики: не делайте дашборд на каждый узел. Сделайте один, с переменной для выбора хоста. Иначе через полгода у вас тридцать дашбордов, из которых актуальны три.
Полезная разбивка: отдельный дашборд под физические узлы (процессор, память, диски, ZFS, температуры) и отдельный под сетевое оборудование — метрики у них разные и в один экран не ложатся.
Уведомления
Мониторинг без доставки уведомлений — это красивые графики, на которые никто не смотрит.
В Zabbix есть готовый способ отправки в Telegram: заводится бот, в типе оповещений прописывается токен, в действии — кому и при каких условиях слать.
Настройте эскалацию: первое сообщение сразу, повтор через полчаса, если проблема не закрыта. И обязательно уведомление о восстановлении — иначе непонятно, само прошло или кто-то починил.
Что это в итоге даёт
У меня Proxmox отдаёт метрики в Zabbix, оттуда они идут в Grafana, и когда на одном из узлов выпал диск, уведомление пришло в ту же минуту. Не через неделю, когда я случайно зашёл бы в консоль, и не в момент отказа второго диска.
Это и есть вся ценность мониторинга: он превращает отказ железа из катастрофы в задачу, которую можно спокойно запланировать на выходные.
Если Proxmox у вас ещё не стоит — начните с установки, там подробно разобран выбор конфигурации ZFS. А мониторинг ставьте сразу следом, не откладывая: после того, как он понадобился, ставить поздно.