Pulse для Proxmox: установка мониторинга за 15 минут

Поднял кластер Proxmox. Три ноды, десяток VM, бэкапы на PBS. И ноль видимости — что происходит внутри, узнаёшь только когда пользователи пишут «у нас всё лежит». Знакомо? Мониторинг Proxmox через Pulse закрывает эту дыру одной командой в терминале, без Zabbix, без агентов на каждой ноде, без недели настройки.

Эта статья написана как рабочий рецепт, а не как обзор функций с сайта разработчика. Разберём три способа установки, создание безопасного read-only токена, подключение алертов и реальные ошибки, с которыми сталкиваются при первом запуске — включая ту самую 401, из-за которой половина issue-трекера проекта на GitHub.

1. Диагноз: почему штатных средств Proxmox не хватает

Веб-интерфейс Proxmox показывает состояние ноды, на которой ты сейчас сидишь. Хочешь глянуть кластер целиком — открывай пять вкладок. Хочешь узнать, что бэкап на PBS не отработал третью ночь подряд — иди и смотри логи руками. Никаких алертов из коробки, никакой истории метрик дольше суток, никакого единого экрана на все ноды.

Штатный график RRD в Proxmox хранит точки с шагом в минуту только за последний час, дальше идёт усреднение, и разовый скачок нагрузки в 3 часа ночи ты просто не увидишь на графике за неделю. А именно ночные скачки и роняют продакшн — днём кто-то что-то поменял, ночью оно выстрелило, и виноватого искать по памяти.

Тут в игру входит поведенческий момент, который касается не только SEO, но и реальной эксплуатации: чем позже ты узнал о проблеме, тем дороже её решение. Алерт в Telegram за 20 минут до полного отказа диска — это плановая замена. Тот же диск, найденный постфактум по жалобам пользователей — это восстановление из бэкапа и разбор полётов с начальством.

Из практики: кластер на три ноды, ZFS-пул на одной из них незаметно уходил в DEGRADED почти неделю. Никто не смотрел — зачем, всё же работает. Работало ровно до момента, пока не отвалился второй диск в зеркале, и тогда работать перестало резко и полностью. Пять минут настройки алерта на статус пула сэкономили бы сутки восстановления из бэкапа. Такие истории и есть причина, почему мониторинг ставят не «когда будет время», а сразу после установки гипервизора.

Дальше в статье:

• что Pulse умеет и чем отличается от Zabbix и Checkmk
• три способа установки — LXC-скрипт, Docker, ручной install.sh
• настройка мониторинг-пользователя и API-токена в Proxmox без лишних прав
• подключение алертов и push-режима для изолированного PBS
• разбор реальных ошибок 401/403 при подключении токена
• чем закрыть мониторинг Docker и Kubernetes рядом с Proxmox

Время на установку — 15 минут. Время на полную настройку с алертами и бэкапом конфига — час, если не отвлекаться на кофе. Хотя кофе всё равно налей, разговор долгий.

2. Причины взяться за Pulse, а не городить Zabbix ради трёх нод

Есть нюанс. Pulse — это соло-проект одного разработчика (Richard Courtman), MIT-лицензия, бесплатный self-hosted тир полнофункционален для базового мониторинга. Платный Pulse Pro добавляет AI-патрули и авто-фиксы — для домашнего кластера или небольшого прода это не обязательно.

По цифрам из практики пользователей проекта: инстанс Pulse в LXC на 2 ядрах и полсотни отслеживаемых устройств держится в единицах процентов CPU в простое, рост нагрузки заметен только при большом количестве одновременно открытых вкладок дашборда у разных людей. Для сравнения, Zabbix-сервер с СУБД под капотом на том же количестве хостов обычно требует отдельную VM с 2+ ГБ RAM только под сам сервер, не считая агентов.

Как это устроено изнутри

Бэкенд написан на Go, фронтенд — на SolidJS. Это не праздное любопытство: связка даёт низкое потребление памяти и быстрый холодный старт контейнера — секунды, а не десятки секунд как у стека на Java. Каждая нода Proxmox опрашивается в своей горутине через штатный REST API, без блокировки друг друга: упала связь с одной нодой — остальные продолжают опрашиваться штатно.

Для Docker, Kubernetes и TrueNAS в версии 6 добавили отдельный механизм — лёгкие агенты сами отправляют метрики на Pulse POST-запросом, а не ждут, пока их опросят. Для Proxmox это не нужно: штатного API достаточно, агент на гипервизор ставить не придётся вообще.

Сравнение с ближайшими конкурентами

Ну и запросы у вас — сказала бы база данных Zabbix, если бы её пытались поднять ради мониторинга трёх нод в домашней лаборатории. Для этого масштаба — явный перебор.

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

3. Рецепт: разворачиваем Pulse и подключаем Proxmox

3.1. Что нужно до старта

На момент публикации актуальна версия Pulse v6.1.2. Перед установкой проверь свежие релизы на странице GitHub — проект обновляется часто, и в v6 добавили унифицированный мониторинг Docker, Kubernetes и TrueNAS в одном окне.

Таблица портов

3.2. Способ A — LXC-контейнер (самый быстрый)

Если у тебя уже есть Proxmox-хост и не хочется поднимать отдельную VM — запускай прямо из консоли Proxmox. Скрипт из community-scripts создаст LXC, поставит Pulse и сразу подскажет следующий шаг.

bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/pulse.sh)"

Результат: новая LXC-контейнер с работающим Pulse на порту 7655. Скрипт спросит про диск, RAM и CPU — для мониторинга 3-10 нод хватит 1 vCPU и 512 МБ RAM.

3.3. Способ B — Docker (если уже есть Docker-хост)

Не перепутай образ — официальный называется rcourtman/pulse, без кириллицы и лишних форков.

docker run -d \
  --name pulse \
  -p 7655:7655 \
  -v pulse_data:/data \
  --restart unless-stopped \
  rcourtman/pulse:latest

Хочешь сразу задать логин и пароль без экрана первичной настройки — добавь переменные окружения:

docker run -d \
  --name pulse \
  -p 7655:7655 \
  -v pulse_data:/data \
  -e PULSE_AUTH_USER="admin" \
  -e PULSE_AUTH_PASS="СложныйПароль123" \
  --restart unless-stopped \
  rcourtman/pulse:latest

Результат: контейнер поднят, docker ps показывает статус Up, порт 7655 слушает.

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

services:
  pulse:
    image: rcourtman/pulse:latest
    container_name: pulse
    restart: unless-stopped
    ports:
      - "7655:7655"
    volumes:
      - pulse_data:/data
    environment:
      - PULSE_AUTH_USER=admin
      - PULSE_AUTH_PASS=СложныйПароль123

volumes:
  pulse_data:

docker compose up -d

Результат: та же одна строка в логах при старте, но обновление теперь — это docker compose pull && docker compose up -d, без переписывания флагов вручную.

3.4. Способ C — ручная установка (для существующей VM/LXC)

curl -fsSL https://raw.githubusercontent.com/rcourtman/Pulse/main/install.sh | sudo bash

Скрипт сам определит систему, поставит systemd-юнит и запустит сервис. Дальше открывай http://IP-сервера:7655 в браузере — увидишь мастер первичной настройки.

Этот способ выбирай, если у тебя уже есть выделенная VM или LXC под служебные сервисы и не хочется тащить туда Docker ради одного контейнера. Из минусов — обновления придётся гонять тем же install.sh вручную, Docker в этом смысле немного удобнее для CI/CD-подхода к апдейтам.

Какой из трёх способов выбрать? Если Proxmox один и мониторинг нужен «здесь и сейчас» — LXC-скрипт из способа A. Если уже есть Docker-хост под другие сервисы — способ B, туда же в Compose. Способ C — для тех, кто принципиально не любит контейнеры и держит всё голыми systemd-юнитами.

3.5. Создаём отдельного пользователя для мониторинга в Proxmox

Вот тут важно не полениться. Root-токен с полным доступом — это удобно ровно до первого инцидента с утечкой конфига. Заводи отдельного read-only пользователя.

# Пользователь в realm pve (не pam - чтобы не плодить системных юзеров)
pveum user add pulse-monitor@pve --comment "Read-only monitoring for Pulse"

# Роль на основе PVEAuditor - Pulse хватает только чтения
pveum aclmod / -user pulse-monitor@pve -role PVEAuditor

# Токен БЕЗ privilege separation - иначе токен получит пустые права
pveum user token add pulse-monitor@pve pulse-token --privsep 0

Результат последней команды — вывод с полем value, это и есть секрет токена. Скопируй сразу, второй раз Proxmox его не покажет.

Почему именно PVEAuditor, а не что-то шире? Роль даёт доступ на чтение ко всему, что нужно мониторингу: статусы нод, VM, контейнеров, хранилищ, задач бэкапа. Прав на запуск, остановку или изменение конфигурации у неё нет физически — даже если токен утечёт, максимум что получит атакующий это список твоей инфраструктуры, а не рычаг для её поломки. Для мониторинга это ровно тот минимум привилегий, который нужен и не больше.

3.6. Подключаем ноду Proxmox в веб-интерфейсе Pulse

Открывай Pulse → Settings → Add Node → Proxmox VE и заполняй поля: адрес хоста с портом 8006, имя пользователя в формате pulse-monitor@pve!pulse-token, и значение токена. Отдельно — если ноды в кластере, Pulse обнаружит остальные автоматически после подключения первой.

Для изолированного PBS без входящих соединений есть push-режим: PBS сам присылает метрики на Pulse по расписанию, входящий доступ на 8007 не нужен вообще. Настраивается отдельным ключом в разделе PBS → Push Mode документации проекта.

Вот как выглядит цикл опроса на уровне протокола — полезно держать в голове, когда разбираешь логи и не понимаешь, откуда взялась задержка в дашборде:

Что появится на дашборде после подключения

Сразу после первого успешного опроса на главном экране Pulse появляются карточки по каждой ноде: загрузка CPU, использование RAM, состояние дисков и уже смонтированных хранилищ. Отдельная вкладка сводит все VM и LXC-контейнеры кластера в один список с фильтром по статусу — running, stopped, paused — и по ноде, на которой они крутятся.

Вкладка Storage показывает не только процент заполнения, но и тип хранилища — ZFS, LVM-thin, директория — с отдельным индикатором для ZFS-пулов: ONLINE, DEGRADED, FAULTED. Именно этот индикатор и не даст повторить историю про неделю в DEGRADED из раздела диагноза выше.

Вкладка Backups подтягивает задачи из PBS или встроенного vzdump и показывает время последнего успешного запуска по каждой VM отдельно. Если бэкап конкретной машины не отрабатывал дольше заданного порога — карточка подсвечивается, и по ней же настраивается алерт из раздела про уведомления ниже.

3.7. HTTPS через reverse proxy

Штатный веб-интерфейс Pulse отдаёт HTTP на 7655. Если планируешь заходить не только из локальной сети — повесь nginx с сертификатом впереди, не открывай 7655 напрямую наружу.

server {
    listen 443 ssl;
    server_name pulse.example.local;

    ssl_certificate     /etc/letsencrypt/live/pulse.example.local/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/pulse.example.local/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:7655;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Заголовки Upgrade и Connection нужны обязательно — дашборд Pulse держит вебсокет для живого обновления метрик, без них графики будут замирать и обновляться только по F5.

3.8. Тюнинг интервала опроса и хранения истории

По умолчанию Pulse опрашивает ноды каждые несколько секунд, пока открыт хотя бы один клиент дашборда. Для трёх-пяти нод это ни на что не влияет. Для кластера в 20+ нод с сотнями VM разумно увеличить интервал и ограничить глубину хранения истории — иначе диск под /data начнёт расти быстрее, чем ты успеешь настроить ротацию.

# Settings -> General -> Polling & Storage
polling_interval_seconds: 15
metrics_retention_days: 30

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

3.9. Настройка алертов

Settings → Notifications → добавляешь канал. Поддерживаются Telegram, Discord, Slack, email и вебхуки. Порог по CPU/RAM/диску задаётся в процентах, порог по бэкапам — в часах с момента последнего успешного job.

# Пример настройки алерта в конфиге Pulse (Settings -> Alerts)
threshold_cpu_percent: 90
threshold_memory_percent: 85
threshold_disk_percent: 90
backup_stale_hours: 26
notify_channels: [telegram, email]

4. Проверка: убеждаемся что мониторинг реально работает

# Статус сервиса при ручной установке
systemctl status pulse

# Статус контейнера при установке через Docker
docker ps --filter name=pulse

# Логи, если что-то не так
docker logs -f pulse
# или
journalctl -u pulse -f

# Проверка что API Proxmox отвечает на токен
curl -k -H "Authorization: PVEAPIToken=pulse-monitor@pve!pulse-token=ТВОЙ-СЕКРЕТ" \
  https://IP-ноды:8006/api2/json/nodes

Если последняя команда вернула JSON со списком нод, а не ошибку — токен рабочий, дальше проблема если что уже на стороне Pulse, не Proxmox. Открой дашборд, нода должна появиться в списке за 10-30 секунд после первого опроса.

5. Осложнения: разбор реальных ошибок

Восстановление после сбоя

Если хост с Pulse умер целиком — подними новый контейнер или LXC той же версии, разверни туда volume/каталог /data из бэкапа и запусти сервис. Настройки нод, токены и история алертов восстановятся, повторно вводить токены Proxmox не придётся.

# Восстановление volume из архива для Docker-инсталляции
docker volume create pulse_data
docker run --rm -v pulse_data:/data -v $(pwd):/backup alpine \
  tar xzf /backup/pulse-backup-2026-07-30.tar.gz -C /data
docker compose up -d

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

Для домашней лаборатории есть отдельный вариант установки — аддон Home Assistant. Если у тебя уже крутится Home Assistant рядом с Proxmox, Pulse Server и Pulse Agent можно поднять как его аддоны, без отдельной VM или LXC под мониторинг. Для прод-окружения такой вариант не рекомендую — изоляция и обновления аддонов Home Assistant устроены не так строго, как у отдельного сервиса.

Всё не так плохо как кажется по этой таблице. На практике 90% проблем — это privsep у токена. Один флаг чинит почти всё.

6. Альтернативы: когда Pulse — не твой вариант

• Zabbix — тяжелее в настройке, зато мониторит вообще всё в инфраструктуре, не только Proxmox. Бери, если у тебя уже есть Zabbix-сервер и нужно добавить пару нод, а не разворачивать отдельный стек.
• Checkmk — похожая история: избыточен для трёх нод, но силён если нужен единый мониторинг на сотни хостов вперемешку с сетевым оборудованием.
• Grafana + Prometheus + pve-exporter — гибче по визуализации и хранению истории, но собирать стек из трёх компонентов ради красивых графиков оправдано только если Grafana у тебя и так стоит под другие задачи.
• Proxmox Datacenter Manager (PDM) — официальный инструмент от самого Proxmox для управления несколькими кластерами. Хорош как замена веб-интерфейса и умеет удалённо управлять нодами разных кластеров из одной точки, но алертов и глубины метрик как в Pulse там пока меньше — это скорее панель управления, чем система наблюдения.
• Netdata — если хочется мониторить не только Proxmox, а метрики ОС на глубоком уровне на каждой ноде: контекст-свитчи, интерапты, детальную разбивку по процессам. Но это агент на каждый хост, а не read-only через API, и придётся ставить его на каждую ноду отдельно, включая гипервизор.

Ничто не мешает совмещать инструменты: Pulse — как быстрый обзорный дашборд и источник алертов по инфраструктуре Proxmox, а Zabbix или Grafana — как единая точка мониторинга для всей компании, куда Pulse при желании прокидывает метрики через вебхук. Так делают, когда мониторинг уже был построен под другие системы, а Proxmox добавился в инфраструктуру позже.

Если кластер маленький, а API Proxmox — твой единственный источник данных, Pulse выигрывает по соотношению «сколько времени потратил — сколько пользы получил». Для энтерпрайза с сотней хостов разного типа — смотри в сторону Zabbix или Checkmk.

Отдельно скажу про встроенный Proxmox Backup Server. Он и сам умеет слать уведомления о неудачных задачах — но только про себя, и только по email. Если тебе нужен единый экран с состоянием нод, VM и бэкапов одновременно, штатных писем PBS недостаточно — придётся всё равно смотреть в отдельный дашборд.

Free-тир Pulse против Pulse Pro

Для домашней лаборатории или небольшого прода бесплатного тира хватает с запасом. Pro имеет смысл там, где мониторинг превращается в отдельную задачу с SLA и нужен автоматический разбор инцидентов без участия человека.

7. Профилактика: чтобы не чинить это в 3 ночи

Мониторинг самого Pulse

Да, тому кто мониторит — тоже нужен мониторинг. Добавь Pulse в проверку через cron или внешний uptime-сервис: пинг на порт 7655 раз в 5 минут.

# Простая проверка доступности, кидай в cron
curl -sf http://127.0.0.1:7655/api/health || echo "Pulse недоступен" | mail -s "ALERT: Pulse down" ты@почта.ru

Резервное копирование конфига

# Бэкап volume для Docker-инсталляции
docker run --rm -v pulse_data:/data -v $(pwd):/backup alpine \
  tar czf /backup/pulse-backup-$(date +%F).tar.gz -C /data .

Автозапуск

При Docker — флаг --restart unless-stopped уже в команде установки выше, этого достаточно. При ручной установке через install.sh проверь что юнит включён:

systemctl enable pulse
systemctl is-enabled pulse

Безопасность

Мониторинг сам по себе — привлекательная цель для атаки: он видит всю инфраструктуру сразу, и токен от него потенциально открывает read-доступ ко всему кластеру. Относись к хосту с Pulse так же серьёзно, как к самим гипервизорам.

• UFW — открывай 7655 только для доверенной подсети, наружу не публикуй без VPN или reverse-proxy с аутентификацией
• fail2ban — если веб-интерфейс всё же смотрит наружу, повесь jail на форму логина, чтобы перебор пароля упирался в бан по IP после нескольких попыток
• SSH hardening на хосте с Pulse — отключи пароль-логин, оставь только ключи, поменяй порт если это единственная линия обороны от automated-сканеров
• Отдельный read-only пользователь в Proxmox для каждого источника мониторинга, никогда не root-токен — роль PVEAuditor физически не может ничего сломать, даже если токен утечёт
• Резервные копии токенов и конфига — вынесены за пределы самого хоста Pulse, иначе потеряешь и данные, и способ их восстановить одним и тем же инцидентом
• Ограничение по IP на уровне файрвола Proxmox для порта 8006, если Pulse сидит на статическом адресе — лишний барьер даже при утечке валидного токена

# Пример правила UFW: пускать 7655 только из локальной подсети
ufw allow from 192.168.1.0/24 to any port 7655 proto tcp
ufw deny 7655

Капля никотина убивает лошадь. Один открытый наружу дашборд мониторинга без пароля — весь периметр компании.

Обновление

# Docker
docker pull rcourtman/pulse:latest
docker stop pulse && docker rm pulse
# дальше повторяешь docker run с теми же volume и переменными

# Ручная установка / LXC
curl -fsSL https://raw.githubusercontent.com/rcourtman/Pulse/main/install.sh | bash

Перед обновлением — бэкап volume/данных, описанный выше. Откатиться при неудаче: для Docker поднять контейнер со старым тегом версии из Releases, для ручной установки — переустановить конкретную версию флагом --version у install.sh.

8. FAQ

Почему Pulse не подключается к Proxmox после настройки?

В девяти случаях из десяти дело в токене — либо включена privilege separation и у токена пустые права, либо роль назначена не на корневой путь /. Проверь оба пункта командой pveum acl list и пересоздай токен с —privsep 0.

Как проверить что мониторинг Proxmox через Pulse работает правильно?

Открой дашборд Pulse — нода должна показывать актуальные CPU, RAM и статус за последние 30 секунд. Дополнительно проверь через curl с ручным запросом к API Proxmox с тем же токеном — если JSON приходит, проблема не в правах, а в самом Pulse.

Что делать если Pulse грузит CPU на слабом сервере?

Увеличь интервал опроса в настройках, закрой лишние открытые вкладки дашборда — Pulse снижает частоту polling, когда нет активных клиентов, но при постоянно открытых вкладках в нескольких браузерах нагрузка растёт пропорционально.

Чем Pulse отличается от Zabbix для мониторинга Proxmox?

Pulse заточен именно под Proxmox-экосистему — понимает Ceph, ZFS, статус бэкапов PBS из коробки и разворачивается за одну команду. Zabbix универсальнее и мониторит любую инфраструктуру, но требует отдельного сервера, базы данных и куда больше настройки под задачу с нуля.

Можно ли мониторить несколько кластеров Proxmox одним Pulse?

Да, добавляй ноды каждого кластера отдельно через Settings → Add Node, у каждого независимого кластера свой токен. Внутри одного кластера достаточно подключить одну ноду — остальные Pulse обнаружит сам через членство в кластере.

Нужен ли агент на нодах Proxmox для работы Pulse?

Нет, для мониторинга самого Proxmox VE и PBS агент не требуется — Pulse ходит через штатный REST API по токену. Агенты нужны только если дополнительно подключаешь Docker-хосты, Kubernetes или хочешь снять данные SMART/температуры изнутри гостевых систем.

Можно ли использовать Pulse бесплатно для коммерческого проекта?

Да, self-hosted версия распространяется по лицензии MIT и полнофункциональна для базового мониторинга без ограничений по количеству нод. Платный Pulse Pro — это отдельный слой AI-функций и расширенной аналитики, а не условие для коммерческого использования базовой версии.

Как перенести настройки Pulse на новый сервер?

Забэкапь каталог /data (или Docker volume pulse_data) как описано в разделе профилактики, разверни Pulse той же версии на новом хосте, распакуй архив в volume и запусти сервис — токены нод и конфиг алертов подтянутся автоматически, повторно вводить ничего не придётся.

Как часто выходят обновления Pulse и обязательно ли их ставить сразу?

Проект развивается активно, патч-релизы выходят с интервалом в недели. Ставить в день релиза не обязательно, но раз в месяц-два проверять changelog стоит — там же закрывают проблемы вроде избыточного спама в syslog нод и уточняют работу с API-токенами, о которых шла речь в разделе про ошибки.

8.1. Отдельно про Proxmox Mail Gateway

Если в инфраструктуре крутится ещё и PMG — Pulse подключает его тем же способом, что и PVE: read-only пользователь, токен без privilege separation, добавление ноды через тот же мастер в Settings. На дашборде PMG появится отдельной вкладкой с очередью писем, статистикой спам-фильтра и статусом самого сервиса — не нужно заводить для почтового шлюза отдельный инструмент мониторинга только потому, что это не гипервизор.

9. Прогноз

После установки у тебя есть живой дашборд по всем нодам Proxmox, алерты в Telegram при падении бэкапа или переполнении диска, и история метрик вместо разовых снимков. Больше не нужно открывать пять вкладок веб-интерфейса, чтобы понять что происходит в кластере целиком.

Дальше — дело техники: подключи PBS через push-режим если он изолирован, настрой пороги под свою нагрузку и не забывай про бэкап конфига перед каждым апдейтом. Кластер вырастет с трёх нод до тридцати — Pulse тот же самый, меняется только интервал опроса и глубина хранения истории, архитектуру переделывать не придётся.

Если рядом с Proxmox крутится ещё и Docker-хост или кластер Kubernetes — не плоди отдельные системы мониторинга под каждый тип инфраструктуры, версия 6 сводит всё в один дашборд. Меньше вкладок в браузере — меньше шанс пропустить алерт среди вкладок с котиками.

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