Часть 5. Мониторинг мульти-нод: от простого к продвинутому

[donald]

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

---

Базовые способы проверки​

Если нода работает как systemd-сервис:

• systemctl status <название> — покажет, активен ли сервис;
• journalctl -u <название> -f — выведет логи ноды в реальном времени.

Если нода запущена в Docker:

• docker ps — список запущенных контейнеров;
• docker logs <контейнер> — посмотреть, что пишет нода;
• docker restart <контейнер> — перезапуск в случае сбоя.

Такие проверки можно сделать вручную или встроить в скрипты, которые опрашивают ноды каждые N минут.

---

Скрипты и алерты​

Для автоматизации мониторинга удобно использовать простые bash-скрипты.
Пример — скрипт, который раз в 5 минут пингует порт RPC:
if ! curl -s http://localhost:26657/status > /dev/null; then
echo "NODE IS DOWN" | mail -s "Alert" you@example.com
fi

Скрипт можно запустить по cron, и он будет сигналить, если нода не отвечает.
Вместо email можно отправлять сообщение в Telegram, Slack или Discord через API.

Если нод много, удобно написать скрипт, который обходит их все и проверяет статус:
for port in 26657 27657 28657; do
if ! curl -s http://localhost:$port/status > /dev/null; then
echo "Node on port $port is down"
fi
done

---

Боты и уведомления​

Следующий уровень — уведомления в мессенджеры.
Многие команды запускают Telegram-ботов, которые отслеживают:

• пропуски блоков,
• отключение от сети,
• несинхронизированное состояние.

Настроить такой бот несложно: достаточно скрипта, который проверяет /status, /health или /syncing и отправляет данные в Telegram Bot API.

Можно также использовать внешние сервисы или ботов, которые отслеживают публичные RPC. В случае проблем они сообщают в группу или личные сообщения.

---

Диагностика и типичные проблемы​

Вот что стоит проверять при сбоях:

• Логи — ищите panic, error, out of memory, timeout, too many open files;
• Порты — убедитесь, что они слушаются (ss -tulpn или netstat);
• Процессы — проверьте, запущен ли процесс (ps aux или docker ps);
• Синхронизация — curl http://localhost:26657/status | jq .result.sync_info;
• Нагрузка — htop, iotop, df -h, free -m покажут, хватает ли ресурсов.

Типичные причины падения:

• нехватка RAM или места на диске;
• перепутанные конфиги (одинаковые порты);
• обновление с ошибкой (несовместимость версий);
• перегрузка сервера слишком большим числом нод.

---

Вывод​

Хороший мониторинг — это не роскошь, а необходимость. Сначала достаточно docker ps, curl и логов.
Потом подключаете Telegram-ботов, метрики и графики.
Важно — реагировать на сбои сразу, чтобы не упустить слэшинг или сбой. И чем раньше вы выстроите автоматизацию и алерты, тем спокойнее будете спать.​