Мониторинг работы блокчейн-ноды
Нода упала в 3 ночи, ваше приложение начало возвращать ошибки, пользователи не могут совершать транзакции. Узнали вы об этом в 9 утра от первого пожаловавшегося пользователя. Это типичная ситуация без мониторинга. Правильный мониторинг — это алерт через 2 минуты после начала проблемы, а не через 6 часов.
Что мониторить
Для любой ноды (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 GB в день, без мониторинга через несколько месяцев он заканчивается, нода останавливается.
Стек мониторинга: Prometheus + Grafana
Стандартный подход для production:
go-ethereum экспортирует метрики в Prometheus формате из коробки:
geth --metrics --metrics.addr 127.0.0.1 --metrics.port 6060
Доступны: chain_head_block, p2p_peers, rpc_calls, timing метрики.
Для нод без нативного Prometheus — экспортер:
# Простой экспортер для любой EVM-ноды
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)
Grafana dashboards — готовые дашборды есть на Grafana.com для большинства нод (Ethereum, Polygon, BSC). Импортируются по ID, адаптируются под конкретный стек.
Alerting
Alertmanager (часть Prometheus стека) — настройка алертов:
# 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, Slack, PagerDuty — через Alertmanager receivers. Для небольших команд — Telegram достаточно.
Uptime checks: внешний мониторинг
Prometheus мониторит изнутри. Нужен также внешний мониторинг — на случай если упал сам сервер или сеть:
- Uptime Kuma (self-hosted) — простой, поддерживает HTTP, TCP, JSON-query проверки
- Better Uptime / BetterStack — SaaS, удобно для небольших команд
- Healthchecks.io — для cron-подобных проверок, которые должны выполняться регулярно
Для ноды: HTTP check на POST / с телом {"method":"eth_blockNumber","id":1} — если 200 вернулся, нода живая на базовом уровне.
Логи
Централизованные логи — отдельная тема, но минимум: journald с ротацией и grep по уровням ошибок. Для нескольких нод — Loki + Grafana.
Критические паттерны в логах geth которые нужно алертить: "database corruption", "fatal error", "peer discovery disabled".
Что настраивается за 2–3 дня
Prometheus + Grafana на вашем сервере или облаке, экспортер метрик для вашей ноды (go-ethereum, Bor, Bitcoin Core или другой), алерты в Telegram/Slack на lag, RPC недоступность, системные метрики, внешний uptime monitoring, дашборд с историей метрик и текущим состоянием.







