Мониторинг роботи блокчейн-ноди
Нода упала в 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, дашборд з історією метрик та поточним станом.