Мониторинг блокчейн-нод — это не «поставить Prometheus и успокоиться». Blockchain-специфичные метрики принципиально отличаются от стандартных серверных: нода может быть полностью жива с точки зрения процесса, но отстать на 10000 блоков от чейна и тихо отдавать устаревшие данные клиентам. Стандартный uptime-монитор этого не увидит. Разработка системы мониторинга множества блокчейн-нод требует учёта особенностей каждой сети: EVM, Solana, Cosmos — у каждой своя телеметрия и критические метрики. Без специализированной системы вы рискуете потерять стейкинг из-за пропущенных аттестаций или нанести ущерб пользователям RPC-сервиса устаревшими данными. Наша команда имеет 10+ лет опыта в блокчейн-разработке и более 50 реализованных проектов мониторинга. Средняя экономия от внедрения — от 5000$ в месяц на 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-нод
- Создание дашбордов и документация
- Обучение вашей команды
Свяжитесь с нами для оценки вашего проекта. Получите консультацию по вашей конфигурации.