Операційні вимоги для «Моніторинг валідатора Solana: метрики, інструменти, дашборди» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.

Цей матеріал — операційний посібник із побудови моніторингу валідатора Solana. Тут зібрано конкретні метрики, які треба відстежувати, інструменти для збору даних, порядок налаштування Grafana-дашборду та правила алертингу. Мета — дати вам готову схему, яку можна застосувати до працюючого вузла без переробки під кожен кластер окремо.

Ключові метрики валідатора

Усе різноманіття стану валідатора зводиться до кількох груп метрик. Якщо ви збираєте їх усі — у вас є повна картина. Якщо хочете мінімуму — зосередьтеся на перших двох групах.

Root slot та slot height

Root slot — це останній слот, який ваш валідатор визнав фінальним (rooted). Slot height — це найвищий слот, відомий вашому вузлу нині. Різниця між ними показує, наскільки швидко ваш вузол фіналізує слоти.

Що перевіряти:

  • Чи зростає root slot монотонно (без відкатів).
  • Яка відстань між slot height і root slot — стабільна чи розширюється.
  • Чи не відстає ваш root slot від кореневого слоту кластера (дані беруться з RPC-методу getSlot з параметром commitment: finalized на довіреній ноді).

Якщо root slot зупинився — вузол не голосує і не отримує винагороди. Це критична подія, яка потребує негайного втручання.

Skip rate та delinquent status

Skip rate — частка слотів, у яких валідатор не взяв участі (пропустив голосування). Delinquent status — офіційний статус вузла в кластері, який присвоюється, коли валідатор перестає голосувати тривалий час.

Глибокий аналіз причин високого skip rate розглянуто в окремому матеріалі Як аналізувати skip rate валідатора. Тут зосередимося на тому, що саме моніторити:

  • Поточний skip rate за останні 100 епох (доступно через solana validators або RPC).
  • Чи змінився статус на delinquent — це можна перевірити командою solana validators --output json і фільтрацією за вашою identity.

Delinquent-статус означає, що вузол виключено з активного набору валідаторів. Відновлення вимагає синхронізації та перезапуску, що описано в розділі Аварійне відновлення валідатора: стратегії та кроки.

Використання CPU, RAM, диска

Апаратні ресурси — це базовий шар моніторингу. Solana-валідатор навантажує систему нерівномірно: сплески під час обробки слотів чергуються з відносно спокійними інтервалами.

  • CPU: середнє навантаження та пікове використання ядер. Якщо CPU стабільно вище 80–90% — вузол не встигає обробляти слоти, що прямо впливає на skip rate.
  • RAM: обсяг вільної памʼяті. Solana-клієнт кешує дані в оперативній памʼяті. Якщо free RAM падає близько до нуля, система починає активно використовувати swap, що різко уповільнює обробку.
  • Диск: використаний обсяг на розділі з леджером та акаунт-сторем (account-store), а також IOPS і latency дискових операцій. NVMe-диск має забезпечувати стабільні IOPS на рівні, який відповідає навантаженню вашого кластера. Зростання disk latency — ранній сигнал проблеми.

Мережевий трафік

Solana-валідатор обмінюється великими обсягами даних з сусідніми вузлами (gossip-протокол) та обробляє RPC-запити, якщо цю службу активовано.

  • Inbound/Outbound трафік: раптове зниження може свідчити про проблеми з мережею або ізоляцію вузла від gossip-кластера.
  • Кількість зʼєднань: різке падіння peer-зʼєднань означає, що вузол втрачає звʼязок з мережею.
  • Packet loss та jitter: якщо доступні з інструментів на рівні хоста — ці метрики допомагають виявити мережеві проблеми до того, як вони вплинуть на skip rate.

Інструменти моніторингу

Prometheus + Grafana

Стандартний стек для моніторингу інфраструктури. Solana-валідатор експонує метрики у форматі, сумісному з Prometheus, через вбудований endpoint (за замовчуванням на порту, що вказується при запуску через прапорець --metrics-config).

Передумови:

  • Запущений Prometheus із налаштованим scrape-цілею на ваш валідатор.
  • Розгорнута Grafana з підключеним джерелом даних Prometheus.

Перевірка того, що метрики доступні:

curl http://<validator-ip>:<metrics-port>/metrics

Очікуваний результат — текстовий вивід у форматі Prometheus з метриками, що починаються з префікса solana_. Якщо відповіді немає — перевірте, чи передано прапорець --metrics-config при запуску валідатора, та чи не блокує порт фаєрвол.

Solana CLI команди

CLI — найшвидший спосіб отримати поточний стан без додаткової інфраструктури. Корисні команди для оперативної діагностики:

  • solana slot — поточний слот вузла.
  • solana catchup — статус наздоганяння кластера (чи не відстає вузол).
  • solana validators --output json-compact — список валідаторів із їхнім skip rate та статусом.
  • solana gossip — інформація про gossip-мережу та кількість peer-зʼєднань.
  • solana block-production --url <trusted-rpc> — статистика виробництва блоків за останні епохи.

Обмеження: CLI дає зріз стану на момент виклику, але не зберігає історію. Для трендів потрібен Prometheus або аналогічна система.

Сторонні дашборди

Існують публічні дашборди (SolanaFM, Validators.app тощо), які відображають статус валідаторів у кластері. Вони корисні для швидкої перевірки, але мають обмеження:

  • Дані оновлюються з затримкою (зазвичай кілька хвилин).
  • Ви не контролюєте якість та частоту збору метрик.
  • Деякі деталі (навантаження CPU, стан диска) недоступні, оскільки вони не публічні.

Рекомендація: використовуйте сторонні дашборди для крос-перевірки, але не як основне джерело моніторингу вашого вузла.

Налаштування Grafana-дашборду

Нижче наведено порядок створення дашборду з нуля. Припущення: Prometheus вже збирає метрики з вашого валідатора.

Крок 1. Створіть новий дашборд у Grafana та додайте панелі за такими групами:

  1. Стан синхронізації: root slot (метрика solana_root_slot), slot height (solana_slot_height), різниця між ними.
  2. Продуктивність голосування: skip rate (solana_vote_skipped_slots_ratio або розрахунок з лічильників пропущених/загальних слотів).
  3. Апаратні ресурси: CPU, RAM, disk I/O — беруться з node_exporter, а не з Solana-метрик.
  4. Мережа: трафік та кількість зʼєднань (також з node_exporter).

Крок 2. Налаштуйте часові вікна. Для більшості панелей використовуйте останні 1–6 годин з автоматичним оновленням кожні 15–30 секунд. Для трендів skip rate — останні 24 години або 7 днів.

Крок 3. Додайте рядок верхнього рівня з ключовими індикаторами (stat panels): поточний root slot, skip rate за останню епоху, статус delinquent (так/ні), вільне місце на диску. Це дозволяє оцінити стан за кілька секунд.

Крок 4. Збережіть дашборд і, за можливості, експортуйте його у формат JSON для резервного копіювання конфігурації.

Типова помилка: створення панелей з надто багатьма метриками на одному графіку. Краще розділити CPU system, CPU user та CPU iowait на окремі панелі — це полегшує читання під час інциденту.

Alerts: які метрики відстежувати

Алертинг — це те, що перетворює моніторинг із інструменту перегляду на інструмент реагування. Нижче наведено перелік алертів із рекомендованими порогами. Усі пороги потребують калібрування під ваше обладнання та кластер — почніть із цих значень і коригуйте за результатами перших тижнів роботи.

Метрика Умова алерту Серйозність Пояснення
Root slot Не зростає понад 2 хвилини Critical Вузол зупинив голосування. Можлива причина — крах процесу, проблема з мережею, відсутність місця на диску.
Skip rate Вище 5% за останні 100 епох Warning Вузол пропускає голосування. Причини різні — від навантаження CPU до мережевих затримок. Детальний аналіз — у відповідному розділі.
Delinquent статус Статус змінено на delinquent Critical Вузол виключено з активного набору. Вимагає аварійного відновлення.
Вільне місце на диску (леджер) Менше 10% від загального обсягу Warning При досягненні 0% валідатор зупиниться. Час на реакцію залежить від швидкості зростання леджера.
Вільне місце на диску (леджер) Менше 3% від загального обсягу Critical Негайна загроза зупинки.
CPU використання Середнє вище 90% понад 5 хвилин Warning Вузол працює на межі. Може призвести до зростання skip rate.
RAM (free) Менше 2 ГБ вільної памʼяті Warning Ризик активного swap, що різко уповільнює валідатор.
Disk I/O latency Вище 5 мс (для NVMe) понад 2 хвилини Warning Може свідчити про деградацію диска або навантаження від інших процесів.
Gossip peer count Менше 20 peer-зʼєднань Warning Вузол може втратити звʼязок з кластером. Перевірте мережу та фаєрвол.

Рекомендація: налаштуйте канали сповіщень так, щоб critical-алерти надходили миттєво (SMS, дзвінок), а warning — через агрегований канал (Telegram, Slack) з розумним групуванням, щоб уникнути втоми від алертів.

Чеклист моніторингу для нового валідатора

Перелік кроків, які варто виконати одразу після розгортання валідатора, до того, як він почне обробляти реальний трафік кластера.

  1. Увімкніть експорт метрик. Переконайтеся, що при запуску валідатора передано прапорець --metrics-config і endpoint доступний для Prometheus.
  2. Розгорніть node_exporter на тому ж сервері для збору апаратних метрик (CPU, RAM, диск, мережа).
  3. Налаштуйте scrape у Prometheus з інтервалом 10–15 секунд для Solana-метрик і 15–30 секунд для node_exporter.
  4. Створіть мінімальний дашборд у Grafana: root slot, skip rate, CPU, RAM, вільне місце на диску, кількість peer-зʼєднань.
  5. Налаштуйте критичні алерти: зупинка root slot, delinquent статус, вільне місце на диску менше 5%.
  6. Налаштуйте warning-алерти: skip rate вище 5%, CPU вище 90%, RAM менше 2 ГБ, peer count менше 20.
  7. Перевірте канали сповіщень: надішліть тестовий алерт і переконайтеся, що він доходить до вас у прийнятний час.
  8. Зробіть резервну копію конфігурації дашборду (експорт JSON) і зберігайте її поза сервером моніторингу.
  9. Верифікуйте метрики на живому вузлі: порівняйте значення root slot у Grafana з результатом команди solana slot — вони мають збігатися.
  10. Зафіксуйте базові значення (baseline) для вашого обладнання: типове CPU, RAM, disk IOPS у спокійному стані. Це стане орієнтиром для майбутньої діагностики.

Після виконання цього чеклиста ваш валідатор має повний контур моніторингу: збір метрик, візуалізація, сповіщення та резервування конфігурації. Наступний крок — переконатися, що ви готові до сценаріїв, коли моніторинг фіксує критичну подію. Про це детально в матеріалі Аварійне відновлення валідатора: стратегії та кроки.

Версія ресурсу

Ресурс «Моніторинг валідатора Solana: метрики, інструменти, дашборди»: статична версія 1.0. Сторінка містить готовий практичний матеріал і готова до практичного використання без очікування окремого інтерактивного інструмента. Остання редакційна перевірка: 2 серпня 2026 року.

Джерела