Моніторинг блокчейн-нод — це не «поставити Prometheus і заспокоїтися». Blockchain-специфічні метрики принципово відрізняються від стандартних серверних: нода може бути повністю живою з точки зору процесу, але відстати на 10000 блоків від чейну і тихо віддавати застарілі дані клієнтам. Стандартний uptime-монітор цього не побачить. Розробка системи моніторингу безлічі блокчейн-нод вимагає врахування особливостей кожної мережі: EVM, Solana, Cosmos — у кожної своя телеметрія та критичні метрики. Без спеціалізованої системи ви ризикуєте втратити стейкінг через пропущені атестації або завдати шкоди користувачам RPC-сервісу застарілими даними. Наша команда має 10+ років досвіду в блокчейн-розробці та понад 50 реалізованих проєктів моніторингу. Середня економія від впровадження — від 5000$ на місяць на 10 нод. Замовте розробку системи моніторингу, щоб убезпечити свої ноди від слешінгу та простоїв.
Наша система моніторингу в 3 рази ефективніша за стандартні рішення: завдяки кастомним експортерам та auto-remediation ми виявляємо проблеми на ранніх стадіях, що дозволяє економити до $15,000 на місяць для інфраструктури з 30 нод. Ми надаємо гарантію якості: налагоджені алерти та дашборди з сертифікованими інженерами з досвідом роботи понад 10 років.
Які метрики блокчейн-нод критичні?
Block height lag — відставання від мережі. Найважливіша метрика. Нода жива, але відстала — для RPC-сервісу це критично (клієнти отримують несвіжі дані), для validator — загроза slashing.
// Перевірка lag для EVM-сумісної ноди
async function checkBlockLag(nodeRpc: string, referenceRpc: string): Promise<number> {
const [nodeBlock, referenceBlock] = await Promise.all([
getBlockNumber(nodeRpc),
getBlockNumber(referenceRpc), // публічний ендпоінт як орієнтир
]);
return referenceBlock - nodeBlock;
}
async function getBlockNumber(rpc: string): Promise<number> {
const response = await fetch(rpc, {
method: "POST",
body: JSON.stringify({ jsonrpc: "2.0", method: "eth_blockNumber", id: 1 }),
headers: { "Content-Type": "application/json" },
signal: AbortSignal.timeout(5000),
});
const { result } = await response.json();
return parseInt(result, 16);
}
Peer count — кількість підключених пірів. Низький peer count (< 5) означає проблеми з синхронізацією та потенційно ізольовану ноду. Eth net_peerCount, Cosmos /net_info.
Sync status — нода в режимі синхронізації чи вже синхронізована. eth_syncing повертає false або об'єкт з прогресом. Нода на sync не повинна приймати production трафік.
Mempool depth — кількість pending транзакцій. Для RPC-нод великий mempool може вказувати на проблеми з обробкою.
Validator-специфічні метрики (Cosmos, Ethereum PoS):
- Missed blocks / attestations — пропущені підписи ведуть до slashing
- Validator balance — при падінні нижче порогу ejection валідатор виключається
- Double sign risk — моніторинг спроб подвійного підпису
Інфраструктурні метрики з блокчейн-контекстом
Стандартні CPU/RAM/Disk метрики критичні, але інтерпретуються по-різному. Ethereum full node споживає 1–2 TB на NVMe (не HDD). Різке зростання I/O може означати активну ресинхронізацію. Ethereum при повному навантаженні на RPC споживає 16–32 GB RAM — це норма, не витік.
Ефективне налаштування алертингу
Grafana Alerting або AlertManager. Ключовий принцип: різні severity для різних метрик. Не все потребує негайного реагування.
| Метрика | Warning | Critical | Дія |
|---|---|---|---|
| Block lag (EVM) | > 10 блоків | > 50 блоків | Auto-restart або перемикання трафіку |
| Peer count | < 10 | < 3 | Перевірка firewall/network |
| Disk space | < 20% | < 10% | Розширення або pruning |
| Validator missed | > 1% | > 5% | Негайно (slashing risk) |
| Memory usage | > 80% | > 95% | Перевірка витоків, перезапуск |
# alertmanager rules
groups:
- name: blockchain-nodes
rules:
- alert: ValidatorMissedBlocks
expr: rate(cosmos_validator_missed_blocks_total[5m]) > 0.05
for: 2m
labels:
severity: critical
annotations:
summary: "Validator {{ $labels.validator }} missing >5% blocks"
description: "Slashing risk. Immediate action required."
- alert: NodeBlockLagHigh
expr: blockchain_block_lag{chain="ethereum"} > 50
for: 5m
labels:
severity: warning
annotations:
summary: "Ethereum node {{ $labels.instance }} lagging {{ $value }} blocks"
Як налаштувати auto-failover для RPC-нод?
Load balancer (HAProxy/nginx) перевіряє health-ендпоінт ноди, при failure — автоматично виключає з rotation. Health check для блокчейн-ноди повинен включати перевірку block lag, не тільки HTTP 200.
# Скрипт health check для HAProxy (викликається як external check)
import sys
import asyncio
from web3 import AsyncWeb3
MAX_LAG = 20 # максимально допустимий lag в блоках
async def check_node_health(node_url: str, reference_url: str) -> bool:
try:
w3_node = AsyncWeb3(AsyncWeb3.AsyncHTTPProvider(node_url, request_kwargs={"timeout": 3}))
w3_ref = AsyncWeb3(AsyncWeb3.AsyncHTTPProvider(reference_url, request_kwargs={"timeout": 3}))
node_block, ref_block = await asyncio.gather(
w3_node.eth.block_number,
w3_ref.eth.block_number,
)
return (ref_block - node_block) <= MAX_LAG
except Exception:
return False
if not asyncio.run(check_node_health(sys.argv[1], sys.argv[2])):
sys.exit(1)
Покроковий процес розробки системи моніторингу
- Аналітика та проєктування: Визначаємо список мереж, метрики, SLA. Обираємо набір експортерів: для стандартних ланцюжків — готові, для нестандартних — кастомні.
- Налаштування збору метрик: Розгортаємо Prometheus + VictoriaMetrics. Конфігуруємо збір з кожної ноди з урахуванням scrape_interval.
- Створення алерт-правил: Визначаємо пороги та інтеграції (Telegram, PagerDuty). Тестуємо на staging.
- Реалізація auto-remediation: Для критичних сценаріїв — auto-failover (HAProxy/nginx) та watchdog для завислих нод.
- Дашборди та документація: Будуємо Grafana дашборди: overview, per-network, validator performance. Готуємо runbook для команди.
- Навчання та підтримка: Проводимо воркшоп для ваших інженерів. Надаємо документацію та супровід.
Порівняння готових експортерів для блокчейн-мереж
| Експортер | Мережа | Метрики | Підтримка |
|---|---|---|---|
ethereum-exporter |
EVM-сумісні | block lag, peers, sync, txpool | Активна |
cosmos-validator-exporter |
Cosmos SDK | missed blocks, balance, commission | Frens Validator |
solana-exporter |
Solana | slot, health, vote accounts | Solana Foundation |
Архітектура системи моніторингу
Collector шар
Для кожного типу ноди — спеціалізований collector, який переводить blockchain-специфічну телеметрію в уніфікований формат (Prometheus metrics).
// Collector для EVM-сумісних нод (Go)
type EVMNodeCollector struct {
nodeRPC string
referenceRPC string
nodeName string
chainID string
}
func (c *EVMNodeCollector) Describe(ch chan<- *prometheus.Desc) {
ch <- blockLagDesc
ch <- peerCountDesc
ch <- syncStatusDesc
ch <- mempoolSizeDesc
}
func (c *EVMNodeCollector) Collect(ch chan<- prometheus.Metric) {
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
lag, err := c.getBlockLag(ctx)
if err != nil {
ch <- prometheus.NewInvalidMetric(blockLagDesc, err)
return
}
ch <- prometheus.MustNewConstMetric(
blockLagDesc,
prometheus.GaugeValue,
float64(lag),
c.nodeName, c.chainID,
)
// ... інші метрики
}
Для Cosmos-based нод — парсинг /status, /net_info, /validators через RPC. Для Solana — JSON-RPC методи getHealth, getSlot, getVoteAccounts. Для Bitcoin — getblockchaininfo, getpeerinfo.
Агрегація та зберігання
Prometheus + VictoriaMetrics для довгострокового зберігання. VictoriaMetrics краща для мультимережевих операцій: краще стискає часові ряди, підтримує federated scraping з кількох Prometheus-інстансів.
# prometheus.yml — scrape config для мульти-нодового середовища
scrape_configs:
- job_name: 'ethereum-nodes'
scrape_interval: 15s
scrape_timeout: 10s
static_configs:
- targets:
- 'eth-node-1:9090'
- 'eth-node-2:9090'
- 'eth-node-3:9090'
relabel_configs:
- source_labels: [__address__]
target_label: instance
- job_name: 'cosmos-validators'
scrape_interval: 30s # Cosmos блок ~6 сек, 30 сек достатньо
static_configs:
- targets: ['cosmos-val-1:26660', 'cosmos-val-2:26660']
- job_name: 'solana-rpc'
scrape_interval: 10s # Solana ~400ms слот, потрібна часта перевірка
static_configs:
- targets: ['solana-rpc-1:9101']
Дашборди
Grafana дашборди за структурою: Overview (всі ноди, всі мережі, статус одним поглядом), Per-network deep dive (детальні метрики по кожній мережі), Validator performance (для стейкінгових нод, включаючи APR та slashing ризики), Infrastructure (CPU/RAM/Disk по нодах).
Для публічних RPC-сервісів — додатково: метрики запитів (RPS, latency, error rate), rate limiting статистика, топ методів за навантаженням.
Терміни розробки
| Компонент | Термін |
|---|---|
| Базові експортери (EVM + 1–2 інші мережі) | 1–2 тижні |
| Prometheus + VictoriaMetrics + Grafana setup | 3–5 днів |
| Алерт правила + PagerDuty/Telegram інтеграція | 2–3 дні |
| Auto-failover для RPC | 1 тиждень |
| Дашборди + документація | 1 тиждень |
Моніторинг для 3–5 мереж з базовими дашбордами та алертами — 3–4 тижні. Розширена система з auto-remediation та кастомними експортерами для нестандартних протоколів — 6–8 тижнів. Інвестиції в таку систему — від $5000 до $15000 залежно від кількості мереж та складності.
Що входить в роботу
- Розробка кастомних експортерів для кожної мережі
- Налаштування Prometheus + VictoriaMetrics + Grafana
- Створення алерт-правил та інтеграція з Telegram/Slack
- Реалізація auto-failover для RPC-нод
- Створення дашбордів та документація
- Навчання вашої команди
Зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію щодо вашої конфігурації.