Моніторинг роботи блокчейн-ноди
Нода впала о 3 ночі — ваше dApp почало повертати помилки, користувачі не можуть завершити транзакції. Дізналися ви про це о 9 ранку від першого клієнта, який поскаржився. Знайома картина? Ми стикалися з цим десятки разів: без автоматичного моніторингу простої розтягуються на години. Наші інженери за багато років (понад 5 років досвіду, більше 50 реалізованих проектів) налаштували сотні нод для 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.
Крок 1: Запускаємо збір метрик. 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 за розкладом — опущено для стислості Крок 2: Конфігуруємо правила алертів. Приклад 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 Крок 3: Налаштовуємо канал сповіщень. Для невеликих команд достатньо Telegram: бот надсилає повідомлення з коротким описом проблеми. Алерти спрацьовують після 1–2 хвилин затримки.
Чому зовнішній моніторинг необхідний?
Prometheus моніторить зсередини — якщо впав сервер або мережа, алерт не прийде. Зовнішні перевірки вирішують цю проблему. Зовнішній моніторинг виявляє недоступність в 2 рази швидше, ніж внутрішній, завдяки окремому серверу в іншій локації. Оптимальний вибір залежить від ваших завдань — зв'яжіться з нами, ми допоможемо підібрати рішення.
Для зовнішнього моніторингу є кілька рішень. Порівняємо їх:
| Інструмент | Тип | Переваги | Недоліки |
|---|---|---|---|
| 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".
Що входить у роботу під ключ
- Розгортання Prometheus + Grafana на вашому сервері або хмарі.
- Написання експортера метрик для вашої ноди (go-ethereum, Bor, Bitcoin Core, Solana).
- Налаштування алертів в Telegram/Slack на lag, RPC недоступність, низький диск.
- Встановлення зовнішнього uptime-монітора (Uptime Kuma або Better Stack).
- Створення дашборда з історією метрик та станом в реальному часі.
- Документація з підтримки та доступів.
- Навчання вашої команди роботі з дашбордом та алертами.
Чому обирають нас
- Понад 5 років досвіду в блокчейн-інфраструктурі.
- Більше 50 реалізованих проектів різної складності.
- Команда з 10 сертифікованих інженерів.
- Гарантія швидкого реагування: алерт за 2 хвилини.
Ми гарантуємо, що після налаштування ви дізнаєтеся про проблеми за 2 хвилини, а не вранці. Досвід — понад 50 успішних проектів. Замовте налаштування моніторингу під ключ — отримайте консультацію та оцінку вашої інфраструктури. Вартість — від $1500, економія на простоях до $500/міс. Пишіть нам!