Зачем вообще отдельный мониторинг поверх Proxmox

Полчаса в день у меня уходило на ручной обход шести нод Proxmox через веб-интерфейс — он показывает по одной ноде за раз. И часть рутины всё равно проскакивала: задание PBS остановилось — никто не заметил, ZFS scrub отключили на maintenance и забыли включить, на ноде накопились pending kernel updates, и о них узнаёшь, когда уже надо ребутить. На небольшом кластере ручного обхода хватает. На кластере из шести нод с парой сотен виртуалок и контейнеров — уже нет.

На этом кластере после миграции с проприетарного гипервизора накопился вполне типовой операционный долг: отключённые после ручного maintenance таймеры scrub, остановленные после рестарта PBS задания резервного копирования, дрейф конфигурации между нодами после мажорного апгрейда.

Стандартный путь — построить полноценный observability-стэк: Zabbix или Prometheus + Alertmanager + Grafana, метрики, шаблоны, дашборды, рутина по обслуживанию самого мониторинга. Это правильный путь, но он плохо подходит к задаче «быстро получить единый экран по Proxmox-кластеру». В этой статье — про другой вариант: лёгкий read-only слой над Proxmox/PBS, который разворачивается за несколько часов активной работы и закрывает первый уровень видимости. Инструмент называется Pulse, и статья — про то, где он работает, где нет, и что выяснилось в первый месяц эксплуатации.

Сразу обозначу границу: Pulse не заменяет полноценный мониторинг. Это первый экран и базовый набор алертов. Если нужны ролевой доступ (RBAC), журнал аудита, интеграция с SIEM, отчёты по SLO/SLA или формальный compliance — читайте до конца, в разделе «Когда Pulse не подходит» я перечисляю, что он не закрывает.

Исходная инфраструктура

Обезличенная картина того, что нужно наблюдать:

• 6 нод Proxmox VE в кластере;

• 1 отдельный Proxmox Backup Server на отдельной железке;

• ~80 виртуальных машин разного назначения;

• ~30 LXC-контейнеров под внутренние сервисы;

• 2 хоста с Docker для CI и служебных задач;

• ZFS-пулы на части нод;

• разделение management и production VLAN — это важно: API-сеть кластера и сеть управления не совпадают, и Pulse про это придётся знать (об этом ниже).

Конкретные хостнеймы, IP-адреса, состав ВМ и привязку к организации намеренно не привожу — статья о Pulse, а не о конкретной инфраструктуре.

До Pulse «мониторинг» сводился к трём вещам:

1. Веб-интерфейс PVE и его отдельные вкладки по нодам.

2. Уведомления PBS о backup jobs — на email, который у части людей был в спам-фильтре.

3. Ручные обходы дежурного админа раз в день.

Этого недостаточно, чтобы заметить, что задание PBS остановилось неделю назад, а сообщение про это улетело в junk. И уж точно недостаточно, чтобы поймать медленно деградирующие вещи — температуру SSD, отключённые systemd-таймеры, отложенные обновления.

Почему не Zabbix первым шагом

Это самый частый вопрос: «У вас же есть Zabbix/Prometheus, чем не подходит?»

Подходит. Zabbix и связка Prometheus + Alertmanager + Grafana — мощнее и универсальнее Pulse. Они лучше масштабируются, у них развитая экосистема шаблонов, они закрывают не только Proxmox, но и всё остальное.

Цена этой мощи — обвязка:

• Zabbix-сервер сам по себе становится отдельным проектом: его нужно бэкапить, обновлять, мониторить и сопровождать;

• официальные шаблоны для Proxmox VE и PBS дают основу, но без доработки покрывают не всё, что хочется видеть на дашборде;

• Grafana поверх Zabbix или Prometheus — это ещё один слой со своими дашбордами, которые надо собрать и поддерживать;

• порог входа: пара дней админа на стартовую настройку, ещё несколько — на тюнинг порогов.

Когда задача звучит как «через две недели после миграции хочу единый экран по Proxmox-кластеру и понятный канал алертов в Telegram», правильный ответ — не начинать со стэка, который сам требует поддержки. Сначала закрыть первый уровень видимости, потом — если требования вырастут — двигаться в сторону Zabbix/Prometheus.

Pulse — про этот первый уровень.

Что такое Pulse

Pulse — open-source-проект, rcourtman/Pulse на GitHub, лицензия MIT. На момент написания stable-версия v5.1.x, в release candidate уже v6.0.0; релизы выходят каждые 1–3 дня. Звёзд на GitHub — более 5,5 тыс.

Что Pulse делает:

• Подключается к Proxmox VE, Proxmox Backup Server и Proxmox Mail Gateway через API. Показывает состояние нод, ВМ, LXC, storage, ZFS-пулов, заданий бэкапа.

• Мониторит Docker/Podman (контейнеры, Swarm-сервисы) и Kubernetes (через агенты).

• Шлёт алерты в Telegram, по email, webhooks.

• Patrol — встроенный модуль авто-диагностики, работает на правилах из коробки, без LLM. Проходит по нодам, бэкапам, ZFS-пулам и поднимает структурные проблемы; по README ловит «ZFS capacity issues, failed backup jobs, VMs in restart loops, clock drift, container health failures». Опциональная LLM-интеграция (BYOK) усиливает разбор находок, но базовое наблюдение от неё не зависит.

• AI-чат — отдельный опциональный компонент, по модели BYOK (bring your own key). По README поддерживаются OpenAI, Anthropic и Ollama — можно подключить локальную модель, не выпуская данные наружу.

Архитектурно это одно приложение в одном LXC-контейнере, без внешней БД. По умолчанию слушает порт 7655.

Open-core модель

Pulse идёт по open-core: бесплатная Community-редакция для self-hosted (всё, что описано в статье) и платные тиры с удалённым доступом, расширенной AI-аналитикой и RBAC. Я работаю только на Community; платные тиры в статье не разбираю. Когда требования вырастают до полноценного RBAC и аудита, равноценным конкурентом всё равно становятся уже Zabbix или Prometheus + Grafana с настроенными правами — не платная редакция Pulse.

Развёртывание

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

Шаг 1. Поднять LXC с Pulse

Из README проекта:

curl -fsSL https://github.com/rcourtman/Pulse/releases/latest/download/install.sh | bash

Скрипт создаёт LXC, ставит зависимости и поднимает сервис на порту 7655. По умолчанию — 1 vCPU и 1 ГБ RAM. На моём масштабе поднял RAM до 2 ГБ; для кластера в сотни узлов и тысячи ВМ автор проекта рекомендует увеличивать дальше.

Дашборд после установки доступен по http://<lxc-ip>:7655 без TLS «из коробки». Для production-доступа я бы поставил перед ним reverse proxy с TLS (Caddy/Traefik/nginx — что привычнее).

Шаг 2. API-доступ к Proxmox

Pulse подключается к Proxmox по API-токенам. Минимально достаточная роль — PVEAuditor на корне с propagate: она включает привилегии Sys.Audit, VM.Audit, Datastore.Audit, Pool.Audit, SDN.Audit, Mapping.Audit и достаточна для дашборда, метрик и алертов по бэкап-заданиям. Через CLI pveum это делается так (всё запускается на любой ноде кластера от root):

# 1. Отдельный пользователь под мониторинг
pveum user add pulse@pve --comment "Pulse monitoring (read-only)"

# 2. PVEAuditor на корень с propagate — read-only на ноды, ВМ, LXC, datastores, backup-задания
pveum acl modify / --users pulse@pve --roles PVEAuditor --propagate 1

# 3. API-токен с privsep=1 по умолчанию (у токена отдельные ACL)
pveum user token add pulse@pve readonly --comment "Pulse Community"

# 4. Раздать токену ту же роль (privsep=1 — поэтому повторяем явно)
pveum acl modify / --tokens 'pulse@pve!readonly' --roles PVEAuditor --propagate 1

Команда pveum user token add напечатает в stdout поле value — это секрет токена, увидеть его повторно нельзя. Сохранить в Pulse и в свой password manager сразу. Та же операция через UI: Datacenter → Permissions → Users → Add → потом API Tokens → Add → потом Permissions → Add для пользователя и для токена.

Pulse не должен иметь прав на изменение состояния. Никаких VM.Allocate, VM.PowerMgmt, Sys.Modify. При утечке токена это ограничивает возможный ущерб до «видит конфигурацию, не может ничего сломать».

Проверить, что токен живой и API доступен — простым curl (формат header’а — из PVE-документации; в реальной среде токен и секрет не вшиваем в логи и не публикуем):

curl -k -H 'Authorization: PVEAPIToken=<user>@pve!<tokenid>=<secret>' \
  https://pve-node.example.com:8006/api2/json/nodes

Если ответ — JSON со списком нод и их состоянием, API-токен корректно настроен, можно подключать его в Pulse.

Шаг 3. Подключить ноды через UI

В Pulse UI добавляю сами ноды, PBS и Docker-хосты. Автообнаружение кластера находит остальные ноды через одну точку входа за несколько минут.

Подводный камень — cluster network detection. Pulse по умолчанию ожидает, что cluster-network и API-network совпадают. В моём случае это не так: management и production VLAN разнесены, API-endpoint живёт в одном сегменте, кластерный трафик — в другом. В этом случае API-endpoint каждой ноды надо указывать вручную. Этот же сценарий обсуждается в Discussion #781 — там подробности и обходы.

Шаг 4. Telegram-уведомления

Создаю бот через BotFather (/newbot, имя, username), получаю токен. Затем напишу боту в личку любое сообщение и дёрну эндпоинт getUpdates Telegram Bot API — он вернёт JSON со списком апдейтов, в каждом есть поле chat.id. Это и есть chat_id для отправки:

curl -s "https://api.telegram.org/bot<TOKEN>/getUpdates" | jq '.result[].message.chat.id'

В Pulse — Settings → Notifications → Telegram, вписываю токен и chat_id. Тестовое сообщение — кнопка Send Test.

Технически можно использовать и групповой чат: добавить бота в группу, поднять боту права на отправку сообщений, в chat_id использовать ID группы (отрицательное число). Я оставил приватный чат — в групповом потоке деловой переписки критичные алерты теряются среди обычных сообщений.

Шаг 5. AI-чат (опционально)

Если планируется AI-функционал (чат-ассистент и AI-разбор находок Patrol) — это BYOK. По README проекта, Pulse понимает OpenAI, Anthropic и Ollama. У меня стоит локальная Ollama с моделью среднего размера на отдельной железке — данные не покидают периметр, и это снимает основной вопрос приватности.

AI-функционал — опциональный. Базовая ценность Pulse — дашборд, Patrol на правилах и алерты, и они работают без LLM.

Права доступа: почему read-only — это важно

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

Правило простое: мониторинг должен иметь ровно столько прав, сколько ему нужно для чтения метрик. Ни больше. У многих систем мониторинга в production живут токены с правами уровня администратора — потому что «так быстрее было настроить». Это утечка, которая случается тихо и обнаруживается, когда уже поздно.

Минимальная модель для Pulse + Proxmox:

Если в инфраструктуре несколько кластеров или сегментированные пулы ресурсов — токен лучше разнести на несколько, каждый со своим скоупом.

Чего Pulse делать не должен:

• создавать/удалять ВМ;

• запускать/перезагружать/мигрировать ВМ;

• менять конфигурацию нод;

• управлять backup jobs.

Если в какой-то момент захочется «дать Pulse кнопку рестарта ВМ» — это уже другая категория инструмента, тогда нужна полноценная automation-платформа с собственным RBAC, аудитом и логированием действий.

Правила алертов

Самая частая ошибка с алертами — «давайте включим все, потом отключим лишнее». Не работает: лишние не отключают, на них перестают реагировать, и в итоге игнорируется и важное.

Лучше идти от обратного: какой минимальный набор сигналов нужен, чтобы понять, что происходит. У меня получилось шесть правил. Это не «универсальный набор», а конкретный, который сложился под мою инфраструктуру; для другого окружения список будет другим.

Базовый набор

Как выглядит сообщение в Telegram

Pulse отправляет короткое сообщение: проблема, нода/ресурс, ключевые метрики. По кнопке «Open in Pulse» — переход в дашборд с деталями. Дежурный решает: реагировать сейчас или планово.

Чего сознательно не делаем

• Не настраиваю алерты на CPU/RAM-пороги по нодам. Это шум: загрузка скачет, ложных срабатываний больше, чем полезных событий. Если действительно нужен per-VM CPU monitoring — это уже задача для Prometheus + alertmanager rules с более точной классификацией.

• Не использую Pulse для информационных уведомлений («бэкап успешен», «нода вернулась»). Только проблемы.

Что нашёл Patrol в первую неделю

Patrol — это сканер, который проходит по нодам, бэкапам, ZFS, конфигам и поднимает не «метрика выше порога», а структурные проблемы. Задание остановлено, таймер выключен, конфигурация дрейфит между нодами, версии пакетов расходятся. Это другой класс находок, чем threshold-алерты.

За первую неделю Patrol поднял пять историй, ни одну из которых я заранее не знал. Каждую разбираю в одинаковом формате: сигнал → диагностика → причина → исправление → правило-предохранитель.

PBS backup job в состоянии stopped дольше недели

• Сигнал. Patrol помечает PBS task как stopped, последняя успешная попытка — больше недели назад.

• Диагностика. Открываю PBS UI — да, задание остановлено. В логах PBS — после планового рестарта сервиса задание перешло в stopped и не возобновилось автоматически.

• Причина. Уведомления PBS по email уходили на адрес, у которого фильтр на спам в почтовом сервере отбраковал последние 11 сообщений подряд. Никто этого не видел.

• Исправление. Возобновил задание, проверил его на корректность, добавил правило Pulse «бэкап не выполнен > 24h» — теперь подобное приходит в Telegram, а не в спам.

• Предохранитель. Любые email-уведомления критичных систем дублируются в Telegram через Pulse или отдельный почтовый рилей с проверкой доставки.

ZFS scrub отключён несколько месяцев

• Сигнал. Patrol сообщает, что на двух пулах scrub не запускался дольше 90 дней.

• Диагностика. systemctl list-timers | grep zfs — таймеры zfs-scrub-monthly@<pool>.timer в состоянии disabled.

• Причина. Таймеры выключили во время ручного maintenance несколько месяцев назад и забыли включить обратно. В runbook’е этот шаг не зафиксирован.

• Исправление. Включил таймеры, запустил scrub вручную для синхронизации. Добавил правило Pulse «scrub не запускался > 30 дней».

• Предохранитель. Список stateful-таймеров и их ожидаемое расписание зафиксированы в Ansible-роли. Любое отключение требует комментария в коммите и запись в runbook.

Дрейф конфигурации репозиториев после мажорного апгрейда

• Сигнал. Patrol поднимает расхождение версий пакетов между нодами кластера.

• Диагностика. На двух нодах в /etc/apt/sources.list.d/ остался устаревший URL pve-no-subscription от предыдущей мажорной версии PVE. apt update ругался на 404, но не падал, а на новые пакеты молча не подписывался.

• Причина. При апгрейде кластера со старой мажорной версии на новую pve7to8 или аналог не перезаписал sources.list.d на этих двух нодах — возможно, потому что они были недоступны в момент prepare-фазы.

• Исправление. Поправил URL вручную, apt update, apt full-upgrade, проверил версии ядра и pve-manager.

• Предохранитель. В Ansible-плейбуке пост-апгрейд-валидации добавил apt-get -o APT::Update::Error-Mode=any update (доступно с apt 2.0): команда возвращает ненулевой код, если хоть один репозиторий ответил 404. Без этого флага apt update молча игнорирует ошибочные строки в sources.list.d/ и плейбук считает шаг успешным.

Отложенные обновления ядра на одной ноде

• Сигнал. На одной из нод pending kernel updates висят несколько месяцев. На остальных пяти ситуация типовая: ноды обновляются в окна обслуживания.

• Диагностика. Эта нода — в исключении из Ansible-плейбука апдейтов, потому что на ней когда-то жила ВМ с особыми требованиями к downtime.

• Причина. ВМ давно переехала с этой ноды, исключение в playbook’е осталось. История миграции в коммитах есть, но никто не вычистил исключение.

• Исправление. Накатил обновления в ближайшее окно обслуживания, убрал исключение из плейбука.

• Предохранитель. Исключения в Ansible-инвентаре получили срок жизни и владельца в комментарии. Раз в квартал — ревизия списка исключений.

NVMe выходит за температурный порог под нагрузкой бэкапа

• Сигнал. На одной ноде Pulse рапортует температуру NVMe выше 65 °C во время окна резервного копирования.

• Диагностика. Открываю BMC: fan profile в BIOS стоит на Low (30% оборотов). Под обычной нагрузкой этого достаточно, но окно бэкапа создаёт устойчивую I/O-нагрузку на NVMe, и температура уходит к 70 °C.

• Причина. Fan profile был выставлен на Low при пуско-наладке для снижения шума в стойке. Кейс с длительной I/O-нагрузкой тогда не рассматривался.

• Исправление. Переключил fan profile на Optimal. При той же нагрузке температура падает ниже 60 °C.

• Предохранитель. В чеклист при вводе новой ноды добавил правило: для нод с NVMe в hot-path fan profile должен быть не ниже Optimal. Pulse-алерт «NVMe > 65 °C» остаётся как backup.

Что важно про этот список

Я не утверждаю, что «Pulse уникален и нашёл то, что никто бы не нашёл». Все эти проблемы можно было поймать вручную, при дисциплинированных ручных обходах. На практике в любой инфраструктуре есть слой накапливающегося операционного долга — отключённые таймеры, исключения в плейбуках, забытые fan-profiles. Patrol его подсвечивает, потому что проходится по структурным признакам, а не по «метрика вышла за порог». Это специфика подхода: Patrol смотрит на конфигурацию, а не только на метрики.

Подводные камни и ограничения

Здесь — то, что в маркетинговом обзоре обычно опускают.

Метрики ВМ периодически некорректны (открытый баг)

Pulse у некоторых пользователей показывает неправильные значения RAM ВМ и периодически теряет метрики дисков и сети гостевых ВМ. Это Issue #1319, открытый в марте 2026 и на момент написания статьи не закрытый. На моём кластере я видел это эпизодически — обычно после перезапуска guest agent в ВМ.

Что это значит на практике:

• threshold-алерты по RAM ВМ давать не стоит, пока баг не закрыт — будут ложные срабатывания;

• алерты «storage free < 15%» и «backup not run > 24h» бага не касаются — там агрегация на уровне datastores и заданий, не per-VM.

Cluster degraded false-positive в старых версиях

В версиях ветки 5.0.x был ложный сигнал «Pulse declare Proxmox Cluster as degraded» — Issue #1085, закрыт в январе 2026. В 5.1.x это устранено. Если разворачиваетесь сейчас, проблема неактуальна, но если у вас стоит ранняя версия — повод обновиться.

Cluster network detection требует ручной настройки

Pulse предполагает, что кластерная сеть Proxmox совпадает с API-сетью. На инфраструктурах с разнесёнными VLAN это не так, и API-endpoint каждой ноды надо указывать руками. Сценарий обсуждается в Discussion #781. Если у вас сеть «как из учебника» — проблемы не увидите. Если разнесено — заложите час на наладку.

Pulse работает в одной копии и сам становится единой точкой отказа

Pulse живёт в одном LXC. Если контейнер падает или его хост перезагружается — мониторинг отсутствует. У Pulse Community нет встроенной HA-схемы, нескольких реплик и кворума. Минимальная страховка — регулярный бэкап LXC (PBS справится) и быстрый restore. Для важных продакшнов имеет смысл вынести Pulse-LXC на отдельный хост, не входящий в основной production-кластер: иначе при падении кластера, который вы и хотели мониторить, пропадает и мониторинг.

Что проверять после обновления Pulse или Proxmox

Релизы Pulse выходят часто. Регрессии случаются. Минимальный чек-лист после апдейта:

• открыть дашборд, проверить, что все ноды и PBS на месте;

• проверить, что Patrol-сканы прошли и не залипли в running;

• послать тестовый Telegram-алерт через Send Test;

• сравнить число активных правил алертов с тем, что было до апдейта.

После апгрейда Proxmox VE — то же самое: смотрим, что Pulse корректно видит все ноды и PBS, особенно если меняется major-версия.

Когда Pulse подходит

Если коротко: когда нужен быстрый первый экран с минимальной обвязкой. Чек-лист, когда Pulse — обоснованный выбор:

• небольшой или средний Proxmox-кластер (десятки нод, сотни ВМ/контейнеров);

• несколько разнотипных кластеров под одной точкой обзора;

• задача — быстро увидеть состояние и поймать очевидные эксплуатационные проблемы;

• Telegram уже используется как канал уведомлений;

• нет жёстких требований к ролевому доступу, журналу аудита, интеграции с SIEM и формальному compliance;

• нет ресурса поддерживать отдельный observability-стэк.

В этих сценариях Pulse Community закрывает основную потребность. Relay становится оправдан, когда нужен удалённый доступ к UI и мобильное приложение для дежурного.

Когда Pulse не подходит

Перечисляю без смягчений, потому что выбор инструмента — это честная оценка границ.

• Enterprise-окружение с обязательным RBAC. Несколько групп администраторов с разными правами на разные кластеры — это уже Pro или другой инструмент с зрелой моделью доступа.

• Формальный аудит и compliance (ФЗ-152, ISO 27001, PCI DSS): нужен централизованный журнал действий, выгрузка событий в SIEM, сроки хранения. Pulse Pro отдаёт события через audit webhooks, но это не замена SIEM.

• Долгосрочное хранение метрик. Если нужны метрики за год для планирования ёмкостей — сюда подходит Prometheus + remote write в долговременную time-series базу (Mimir, Thanos, VictoriaMetrics).

• Сложная маршрутизация алертов. Эскалации, дежурные смены (on-call rotation), дедупликация, заглушки на окна обслуживания (silencing) — здесь нужен Alertmanager или PagerDuty/Opsgenie.

• SLO/SLA-отчётность. Если у вас договоры с SLA и нужны формальные отчёты — это про Grafana с дашбордами или специализированные инструменты.

• SIEM-интеграция. Pulse не SIEM. Если у вас есть SIEM, мониторинг должен в него поставлять события, а не быть их единственным держателем.

Альтернативы под эти сценарии: Zabbix (универсальный), Prometheus + Alertmanager + Grafana (метрики и алерты), Wazuh/Elastic (security и compliance), специализированные log-стэки под аудит.

Итог

Pulse в моём сценарии закрыл задачу первого экрана видимости для Proxmox-кластера. Он не заменяет полноценный мониторинг, но закрывает базовый набор: состояние нод, бэкапов, ZFS и storage; простой набор алертов в Telegram; авто-диагностика структурных проблем через Patrol.

Когда в кластере накоплен операционный долг — отключённые таймеры, забытые конфиги, дрейф репозиториев, — Patrol это подсвечивает в первые дни эксплуатации. Это не магия инструмента, а свойство того, что он смотрит на конфигурацию, а не только на метрики.

Когда требования вырастают до ролевого доступа, аудита, отчётов по SLO и интеграции с SIEM, разумный путь — наращивать наблюдаемость на классических инструментах: Zabbix, Prometheus + Alertmanager + Grafana, SIEM. Pulse в этом сценарии остаётся оперативным дашбордом, но перестаёт быть единственным мониторингом.

Если у вас тоже Proxmox-кластер после миграции с проприетарного гипервизора — расскажите в комментариях, как вы решаете задачу первого экрана. И если есть опыт эксплуатации Pulse в продакшне больше нескольких месяцев — особенно интересны истории, где он не сработал: что именно не закрыл, какой инструмент пришлось ставить рядом.

Ссылки и материалы

• Pulse — GitHub repo

• Proxmox VE — официальная wiki по API-токенам

• Issue #1319 — incorrect VM RAM and intermittent metric loss

• Issue #1085 — cluster degraded false-positive

• Discussion #781 — cluster network detection