Мониторинг работы блокчейн-ноды
Нода упала в 3 ночи — ваше dApp начало возвращать ошибки, пользователи не могут завершить транзакции. Узнали вы об этом в 9 утра от первого пожаловавшегося клиента. Знакомая картина? Мы сталкивались с этим десятки раз: без автоматического мониторинга простои растягиваются на часы. Наши инженеры за многие годы настроили сотни нод для Ethereum, Polygon, Solana и Bitcoin. Результат: алерт приходит через 2 минуты после начала проблемы, а не через 6 часов. В этой статье — проверенный стек и конкретные конфиги, которые используем в production. Экономия времени и снижение затрат на простой — вот что вы получите.
Какие метрики критичны и какие пороги устанавливать?
Для любой ноды (go-ethereum, Bor, Bitcoin Core, Solana validator) ключевые метрики:
- Lag в блоках (current_block - network_head_block). Нормально: 0-5 блоков отставания. Алерт: >10 для EVM, >2 для Solana.
- Peer count — количество пиров. < 3 — нода изолирована, 0 — сетевая проблема.
- Доступность RPC — eth_blockNumber как health check: самый простой способ.
- Системные метрики — CPU, RAM, дисковое пространство. Для archive-нод диск растёт на 1-2 ГБ в день — без мониторинга через несколько месяцев он закончится, нода остановится.
Prometheus documentation рекомендует опрашивать метрики критических сервисов каждые 15–30 секунд. Мы придерживаемся этого правила.
| Метрика | Норма | Предупреждение | Критический алерт |
|---|---|---|---|
| Lag (EVM) | 0-5 блоков | 6-10 блоков | >10 блоков |
| Lag (Solana) | 0-2 блока | 2 блока | >2 блоков |
| Peer count | >=5 | 3-4 | <3 |
| Свободное место на диске | >30% | 15-30% | <15% |
Как настроить алерты за 2 минуты: пошаговая инструкция
Стандартный подход в production — Prometheus для сбора метрик и Alertmanager для уведомлений. Prometheus в связке с Alertmanager обрабатывает алерты в 10 раз быстрее, чем самодельный скрипт на cron.
- Запускаем сбор метрик. geth экспортирует метрики из коробки:
geth --metrics --metrics.addr 127.0.0.1 --metrics.port 6060 Для нод без нативного Prometheus пишем экспортер на Python:
from prometheus_client import Gauge, start_http_server from web3 import Web3 node_block = Gauge('node_current_block', 'Current block number') node_peers = Gauge('node_peer_count', 'Number of peers') def collect(): w3 = Web3(Web3.HTTPProvider('http://localhost:8545')) node_block.set(w3.eth.block_number) node_peers.set(w3.net.peer_count) start_http_server(8000) # Запуск collect по расписанию — опущено для краткости - Конфигурируем правила алертов. Пример alerts.yml:
groups: - name: blockchain-node rules: - alert: NodeSyncLag expr: (network_head_block - node_current_block) > 10 for: 2m labels: severity: critical annotations: summary: "Node is lagging {{ $value }} blocks behind" - alert: NodeRPCDown expr: up{job="ethereum-node"} == 0 for: 1m labels: severity: critical - alert: DiskSpaceLow expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.15 for: 5m labels: severity: warning - Настраиваем канал уведомлений. Для небольших команд достаточно Telegram: бот присылает сообщение с кратким описанием проблемы. Алерты срабатывают после 1–2 минут задержки.
Почему внешний мониторинг необходим?
Prometheus мониторит изнутри — если упал сервер или сеть, алерт не придёт. Внешние проверки решают эту проблему. Оптимальный выбор зависит от ваших задач — свяжитесь с нами, мы поможем подобрать решение.
Для внешнего мониторинга есть несколько решений. Сравним их:
| Инструмент | Тип | Преимущества | Недостатки |
|---|---|---|---|
| Uptime Kuma | Self-hosted | Бесплатно, гибкая настройка | Требует отдельного сервера |
| Better Stack | SaaS | Простота настройки, готовые интеграции | Платная подписка |
| Healthchecks.io | SaaS | Идеально для cron-задач | Ограниченный функционал |
Для ноды достаточно HTTP check: отправляем POST-запрос на http://ваша-нода:8545 с телом {"method":"eth_blockNumber","id":1} — если ответ 200, нода жива.
Grafana: визуализация трендов
Без дашборда сложно анализировать тренды: рост диска, падение числа пиров, увеличение времени ответа RPC. Мы импортируем готовые дашборды по ID из Grafana Labs и адаптируем под вашу сеть. Настройка занимает 1–2 часа.
Пример запроса для панели Lag
(network_head_block - node_current_block) Отображает разницу в блоках за последние 6 часов.
Логи: быстрый поиск проблем
Минимум: journald с ротацией и grep по ошибкам. Для нескольких нод — Loki + Grafana. Критические паттерны в логах geth: "database corruption", "fatal error", "peer discovery disabled".
Что вы получите за 2-3 дня
- Prometheus + Grafana на вашем сервере или облаке.
- Экспортер метрик для вашей ноды (go-ethereum, Bor, Bitcoin Core, Solana).
- Алерты в Telegram/Slack на lag, RPC недоступность, низкий диск.
- Внешний uptime-мониторинг.
- Дашборд с историей метрик и состоянием в реальном времени.
- Документацию по поддержке и доступам.
Мы гарантируем, что после настройки вы узнаёте о проблемах за 2 минуты, а не наутро. Опыт — более 50 успешных проектов. Закажите настройку мониторинга — получите консультацию и оценку вашей инфраструктуры. Свяжитесь с нами для обсуждения деталей.