Pulse для Proxmox: подняли мониторинг 6-нодового кластера за день — что нашёл Pulse Patrol на первой неделе

До внедрения администратор начинал утро с ручного обхода. Он открывал веб-интерфейс каждой PVE-ноды, проверял загрузку, статусы ВМ, хранилище, резервные копии и обновления. На шести нодах такой обход занимал 30 минут. Проблема была не в сложности отдельных действий, а в том, что ручной список быстро превращается в привычку: если статус не красный прямо сейчас, риск легко уходит из внимания.

Так пропали несколько эксплуатационных долгов. Одно задание PBS осталось остановленным после перезагрузки сервера. Два ZFS scrub-таймера были выключены после обслуживания. На части нод сохранились старые no-subscription репозитории после перехода с PVE 7 на PVE 8. На одной ноде висели обновления ядра, потому что она когда-то была исключена из Ansible-плейбука. Каждый пункт по отдельности выглядит мелко. Вместе они повышают риск простоя, долгого возврата сервиса и медленной работы ВМ.

Zabbix рассматривали как альтернативу. Он сильнее как универсальный мониторинг, но старт для этой задачи был тяжелее: агенты, шаблоны, Grafana, правила, обслуживание самого сервера мониторинга. Клиент хотел сначала стабилизировать Proxmox после миграции, а не запускать отдельный проект наблюдаемости.

Pulse выбрали за узкий фокус на Proxmox. Проект живёт на GitHub, поддерживает Proxmox VE, Proxmox Backup Server и контейнерную инфраструктуру, а его можно поставить в формат одного LXC-контейнера. Перед запуском мы проверили upstream: основной репозиторий rcourtman/Pulse, обсуждения по связке с Proxmox и открытые issues. Для клиента это было важнее красивых графиков: нужен инструмент, который развивается и не требует закрытой агентской схемы.

Вторая причина — модель доступа. Для Proxmox VE (PVE) мы использовали токен с правами PVEAuditor, для PBS — Datastore.Audit. Это доступ только для чтения: Pulse читает состояние кластера, но не может создать, остановить или удалить виртуальную машину. Для внутреннего ИБ это сильно проще согласовать, чем агент с административными правами.

Третья причина — Telegram и локальный AI-чат. Telegram уже был рабочим каналом дежурных. AI-чат подключили к локальному серверу Ollama; запросы не уходили во внешний LLM-сервис. BYOK здесь означает “bring your own key” или локальный адрес API: команда сама выбирает, куда отправляются запросы.

Pulse развернули в отдельном LXC. LXC в Proxmox — это Linux Container: лёгкий контейнер рядом с виртуальными машинами. Он стартует быстрее VM и потребляет меньше ресурсов, поэтому для небольшого сервиса мониторинга это нормальный формат. В нашем случае контейнер получил 1 vCPU и 2 ГБ RAM, потому что кластер уже был не лабораторный.

Начали с официального скрипта. Команду мы оставили в отдельном блоке кода, чтобы её можно было скопировать из статьи без ручного выделения. После установки Pulse поднялся на стандартном порту, затем мы добавили 6 PVE-нод, один PBS и два Docker-хоста.

Автообнаружение нашло большую часть кластера быстро, но сеть клиента была разделена: сеть кластера и сеть API жили в разных подсетях. Это известный практический нюанс, который обсуждали в Pulse Discussion #781. В таких схемах адрес API лучше указывать вручную, иначе Pulse может увидеть не тот адрес или не пройти до API с контейнера.

После подключения источников мы настроили Telegram-бота через BotFather в Telegram, добавили chat_id в Pulse, проверили тестовое уведомление и только потом включили рабочие правила. Такой порядок важен: сначала проверяется доставка сигнала, потом включаются пороги. Иначе можно получить красивую панель, которая не будит дежурного при реальной проблеме.

Больше всего пользы дал Pulse Patrol. Это не замена расследованию инженера, но хороший первый слой проверки. Он проходит по заданиям резервного копирования, хранилищам, ZFS, версиям пакетов и базовой конфигурации, затем показывает не только метрику, но и эксплуатационный смысл проблемы.

Резервные копии PBS не создавались 11 дней. На одной ноде задание резервного копирования осталось в состоянии stopped после перезагрузки PBS. Команда не увидела сбой вовремя и считала, что задание работает. Мы включили задачу обратно, проверили свежую точку восстановления и добавили правило: если резервное копирование не запускалось больше 24 часов, уведомлять в Telegram.

ZFS scrub не запускался 3 месяца. На двух пулах systemd-таймеры были выключены после ручного обслуживания. Scrub не восстанавливает данные сам по себе, но помогает раньше найти ошибки чтения и деградацию. После включения таймеров добавили контроль “scrub старше 30 дней”.

Расхождение репозиториев после PVE 7 → 8. На двух нодах остался старый no-subscription repo URL. Pulse показал различие версий пакетов между нодами. Мы выровняли файлы в /etc/apt/sources.list.d/ и прогнали apt update.

Отложенные обновления ядра висели 4 месяца. Нода была исключена из Ansible-плейбука, сценария настройки, потому что на ней раньше жила критичная ВМ. ВМ уже переехала, исключение осталось. Обновления поставили в окно обслуживания и вернули ноду в общий регламент.

NVMe доходил до 70°C во время резервного копирования. Проверка через IPMI, интерфейс управления сервером, показала fan-profile Low. После переключения в Optimal температура при той же нагрузке упала до 58°C. Это не “магия мониторинга”, а пример того, зачем нужен ранний сигнал: проблема была не в диске, а в профиле охлаждения.

После первой недели мы оставили шесть правил. Остальные события смотрели в UI, чтобы не превращать Telegram в шумный журнал.

• Свободное место в хранилище меньше 15%. Такой порог даёт время на реакцию до I/O ошибок и остановки ВМ.
• Резервное копирование не запускалось больше 24 часов. Самое полезное правило для этого клиента: оно быстро показывает сломанные задания PBS.
• Нода offline больше 2 минут. Короткие перезагрузки не должны создавать панику, но потеря ноды требует внимания.
• ВМ перезапускается больше 3 раз за 10 минут. Это поймало сервис, где OOM-killer регулярно убивал PostgreSQL.
• NVMe выше 65°C. Порог ниже критического, но достаточно ранний для проверки охлаждения.
• ZFS scrub не запускался больше 30 дней. Это не авария, а контроль эксплуатационной дисциплины.

Каждое сообщение содержит название проблемы, ноду, значение метрики и ссылку на Pulse. Такой формат не заменяет runbook, но помогает дежурному выбрать первую реакцию: реагировать сразу, передать ответственному инженеру или оставить до планового окна.

У Pulse есть ограничения, и их нужно проговаривать до внедрения. Во-первых, агент может активно писать в syslog при ошибках. На одной ноде за неделю добавилось 300 МБ логов. Мы добавили rsyslog-фильтр, чтобы диагностические сообщения Pulse не забивали системный журнал.

Во-вторых, в версии 5.0.x клиент видел ложный статус cluster degraded. Похожая проблема описана в Pulse Issue #1085. После обновления до ветки 5.1.x ложный сигнал исчез. Поэтому Pulse нужно обновлять так же дисциплинированно, как любой инфраструктурный инструмент.

В-третьих, Pulse Community не заменяет полноценный enterprise-контур. Если нужны долгие ряды метрик, сложные эскалации, SIEM, формальный аудит действий и SLA-отчёты, основным инструментом должны быть Zabbix, Prometheus, Grafana, Alertmanager или другой зрелый стек. Pulse в этом кейсе решал другую задачу: дать быстрый и понятный обзор Proxmox после миграции.

Отдельно проверили безопасность API-токенов. Read-only доступ снижает риск, но не отменяет базовые правила: отдельный токен под Pulse, понятное имя, ограниченные привилегии, ротация при увольнении администратора и хранение секрета вне общих документов.

Через месяц у клиента изменился ежедневный порядок. Утренний обход сократился с 30 минут до 2 минут: администратор открывает Pulse, смотрит общий экран, затем переходит только в проблемные места. Время до обнаружения инфраструктурных событий стало ближе к 1–2 минутам, потому что Telegram приходит до пользовательской жалобы.

Через месяц команда закрыла слепые зоны, которые остались после миграции. Patrol нашёл пять проблем, которые существовали до внедрения и не попадали в регулярный ручной контроль. После исправления команда зафиксировала правила в runbook: кто смотрит Pulse утром и кто реагирует на Telegram, какие события требуют немедленной реакции, какие уходят в плановое окно.

Для MSP такую схему удобно стандартизировать. Один Pulse на клиентский кластер показывает состояние PVE/PBS, а набор стартовых правил можно переносить между проектами. После первого месяца пороги нужно подстраивать: хранилище на файловом сервере, 1С и тестовой среде ведёт себя по-разному, и универсальный процент не всегда даёт одинаковую срочность.

Pulse стоит ставить, когда Proxmox уже работает, но операционный контроль ещё держится на ручных обходах. Он быстро показывает инфраструктурный долг. Дальше команда решает, достаточно ли Community-уровня или нужен отдельный мониторинг с долгой историей, отчётами и интеграцией в процессы ИБ.