Как Pulse помог увидеть слепые зоны в Proxmox-кластере
После миграции с VMware клиент IT For Prof получил рабочий Proxmox-кластер: 6 нод Proxmox VE, отдельный Proxmox Backup Server, 80 виртуальных машин и 30 LXC-контейнеров. Инфраструктура работала, но ежедневная проверка держалась на ручном обходе.
Администратор начинал утро с веб-интерфейсов каждой PVE-ноды: загрузка, статусы ВМ, хранилища, резервные копии и обновления. На шести нодах такой обход занимал 30 минут. Главный риск был в привычке: если статус прямо сейчас не красный, эксплуатационный долг легко уходит из внимания.
Почему выбрали Pulse
Команде нужен был не тяжёлый стек мониторинга, а единый экран для оперативного контроля Proxmox. Pulse развернули в отдельном LXC-контейнере. Для Proxmox VE использовали токен с правами PVEAuditor, для PBS — Datastore.Audit.
Такой доступ только читает состояние кластера. Pulse не может создать, остановить или удалить виртуальную машину. Для внутреннего согласования это проще, чем агент с административными правами на каждой ноде.
Подключили 6 PVE-нод, PBS и два Docker-хоста. Отдельно настроили Telegram-уведомления: дежурному инженеру нужен короткий сигнал с названием проблемы, нодой, значением метрики и ссылкой на Pulse.
Что нашёл Pulse Patrol после внедрения
Pulse Patrol подсветил пять проблем, которые существовали до внедрения и не попадали в регулярный ручной контроль.
Резервные копии PBS не создавались 11 дней. На одной ноде задание резервного копирования осталось в состоянии stopped после перезагрузки PBS. Команда включила задачу обратно, проверила свежую точку восстановления и добавила правило: резервная копия не запускалась больше 24 часов.
ZFS scrub не запускался 3 месяца на двух пулах. Причина была не в отказе дисков, а в отключённых systemd-таймерах после ручного обслуживания. Таймеры включили, первый scrub прошёл без ошибок, а событие добавили в контроль эксплуатационной дисциплины.
На двух нодах остались старые no-subscription repo URL после перехода с PVE 7 на PVE 8. Pulse показал различие версий пакетов между нодами. Команда выровняла файлы в /etc/apt/sources.list.d/ и прогнала apt update.
Обновления ядра висели 4 месяца на одной ноде. Нода была исключена из Ansible-плейбука, потому что на ней раньше жила критичная ВМ. ВМ уже переехала, исключение осталось. Обновления поставили в окно обслуживания и вернули ноду в общий регламент.
NVMe доходил до 70°C во время резервного копирования. Проверка через IPMI показала fan-profile Low. После переключения в Optimal температура при той же нагрузке упала до 58°C.
Какие алерты оставили
После первой недели команда оставила шесть правил. Свободное место в хранилище меньше 15%. Резервное копирование не запускалось больше 24 часов. Нода offline больше 2 минут. ВМ перезапускается больше 3 раз за 10 минут. NVMe выше 65°C. ZFS scrub не запускался больше 30 дней.
Остальные события сначала не включали в уведомления, чтобы не получить информационный шум. Для оперативного мониторинга важнее короткий список сигналов, по которым дежурный инженер действительно действует.
Что изменилось через месяц
Утренний обход сократился с 30 минут до 2 минут: администратор открывает общий экран Pulse, смотрит состояние кластера и переходит только в проблемные места. Время до обнаружения инфраструктурных событий стало ближе к 1–2 минутам, потому что Telegram приходит до пользовательской жалобы.
Pulse не заменяет корпоративный мониторинг для долгосрочных метрик, аудита и SIEM. В этом кейсе он закрыл другую задачу: быстрый оперативный контроль Proxmox-кластера малого и среднего размера без сложной обвязки.