Як налаштувати alerts та сповіщення для валідатора

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

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

Чому alerts критичні для валідатора

Валідатор Solana не прощає простоїв. Пропущений перехід у статус delinquent означає втрату голосів, зниження stake-attraction і прямі фінансові втрати делегаторів. Моніторинг без alerts — це просто дашборд, який ніхто не дивиться о третій ночі. Алерти перетворюють пасивне спостереження на проактивну реакцію: ви дізнаєтесь про проблему до того, як вона вплине на репутацію ноди.

Ключове правило: кожен alert має вести до конкретної дії. Якщо ви отримуєте сповіщення, але не знаєте, що з ним робити — це не alert, а шум.

Ключові події для сповіщення

Середовище: клієнт Agave (колишній agave-validator), mainnet-beta, Ubuntu 24.04 LTS. Метрики надходять від вбудованого Prometheus-експортера валідатора та node_exporter. Перевірте актуальність назв метрик у вашій версії клієнта перед застосуванням конфігурації.

Delinquent status

Валідатор стає delinquent, коли пропускає занадто багато епох без голосування. Це критичний стан, який вимагає негайного втручання. Метрика: solana_delinquent (значення 1 означає проблеми). Поріг: будь-яке значення, відмінне від 0.

Skip rate перевищення

Skip rate показує частку пропущених слотів. Різкий стрибок сигналізує про проблеми з мережею, дисковою підсистемою або навантаженням на CPU. Метрика: solana_vote_skip_rate. Рекомендований поріг попередження: 0.03 (3%), критичний: 0.08 (8%). Встановлюйте пороги на основі базової лінії вашої ноди — деякі інстанси стабільно працюють з skip rate 0.01, інші — з 0.04.

Диск > 90% заповнений

Валідатор постійно пише snapshot-и та ledger-дані. Заповнений диск призводить до зупинки процесу без можливості відновлення без ручного втручання. Метрика від node_exporter: node_filesystem_avail_bytes з фільтром по точці монтування ledger-розділу. Обчислюйте відсоток: (1 - available / total) * 100. Поріг: 90% для попередження, 95% для критичного alert.

Валідатор зупинився

Процес agave-validator впав або був зупинений. Метрика: up з міткою job, що відповідає вашому валідатору (значення 0 означає, що таргет недоступний). Цей alert має мати найвищий пріоритет — нода не голосує взагалі.

Невдале оновлення

Автоматичне оновлення через systemd-timer або кастомний скрипт може завершитися помилкою. Моніторте exit code процесу оновлення або наявність файлу-маркера невдалого оновлення. Альтернатива: відстежуйте розрив між очікуваною та фактичною версією через метрику solana_version, якщо ваш експортер її надає.

Канали сповіщень: Telegram, email, Slack

Кожен канал має своє місце в операційному ланцюзі. Не обирайте один — комбінуйте залежно від критичності.

• Telegram — найкращий канал для критичних alerts. Миттєва доставка, підтримка markdown, можливість пінгу конкретних осіб через @mention. Підходить для мобільної реакції о будь-якій порі.
• Email — резервний канал та архів. Корисний для некритичних попереджень та пост-інцидентного аналізу. Налаштуйте окрему папку або фільтр, щоб alerts не загубилися серед іншої пошти.
• Slack — основний канал для командної роботи. Підходить для alerts, що вимагають координації: обговорення, призначення відповідального, прив'язка runbook-ів. Інтегрується з PagerDuty або Opsgenie для ескалації.

Практична рекомендація: критичні події (delinquent, зупинка процесу) надсилайте одночасно в Telegram та Slack. Попередження (skip rate, диск) — лише в Slack з відповідним тегом severity.

Налаштування через Prometheus Alertmanager

Передумови: працюючий Prometheus із налаштованим scrape валідатора та node_exporter; встановлений Alertmanager (версію перевірте у вашому середовищі); бот Telegram з токеном та chat_id.

Очікуваний результат: Alertmanager обробляє правила з Prometheus і надсилає сповіщення у вказані канали з правильним severity та анотаціями.

Ризики: помилка в YAML-синтаксисі призведе до непрацездатності всього Alertmanager. Завжди перевіряйте конфігурацію перед перезапуском.

Відкат: збережіть поточний робочий файл alertmanager.yml перед зміною:

cp /etc/alertmanager/alertmanager.yml /etc/alertmanager/alertmanager.yml.bak.$(date +%Y%m%d%H%M)

Файл правил Prometheus (solana_alerts.yml):

groups:
- name: agave-validator
  rules:
  - alert: SolanaValidatorDown
    expr: up{job="agave-validator"} == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Валідатор недоступний"
      description: "Процес валідатора не відповідає понад 1 хвилину"
      runbook: "Перевірте статус systemd: systemctl status agave-validator"

  - alert: SolanaDelinquent
    expr: solana_delinquent > 0
    for: 0m
    labels:
      severity: critical
    annotations:
      summary: "Валідатор у статусі delinquent"
      description: "Валідатор пропускає голосування та позначений як delinquent"

  - alert: SolanaHighSkipRate
    expr: solana_vote_skip_rate > 0.05
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Skip rate перевищує 5%"
      description: "Поточне значення: {{ $value | printf \"%.4f\" }}"

  - alert: SolanaDiskFull
    expr: (1 - node_filesystem_avail_bytes{mountpoint="/mnt/ledger"} / node_filesystem_size_bytes{mountpoint="/mnt/ledger"}) * 100 > 90
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "Ledger-диск заповнений на {{ $value | printf \"%.1f\" }}%"
      description: "Залишиться місця для snapshot-ів обмежено"

Заменіть /mnt/ledger на фактичну точку монтування вашого ledger-розділу. Заменіть job="agave-validator" на ваш фактичний job name із конфігурації Prometheus scrape.

Файл alertmanager.yml з Telegram-каналом:

global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'telegram-critical'
  routes:
  - match:
    severity: critical
    receiver: 'telegram-critical'
  - match:
    severity: warning
    receiver: 'slack-warnings'

receivers:
- name: 'telegram-critical'
  telegram_configs:
  - bot_token: 'ВАШ_ТОКЕН_БОТА'
    chat_id: 'ВАШ_CHAT_ID'
    send_resolved: true
    parse_mode: 'HTML'

- name: 'slack-warnings'
  slack_configs:
  - api_url: 'ВАШ_SLACK_WEBHOOK_URL'
    send_resolved: true
    channel: '#validator-alerts'

Перевірка конфігурації перед застосуванням:

amtool check-config /etc/alertmanager/alertmanager.yml
promtool check rules /etc/prometheus/solana_alerts.yml

Обидві команди мають завершитися без помилок. Тільки після цього перезапускайте сервіси.

Застосування змін:

systemctl reload alertmanager
systemctl reload prometheus

Перевірте, що правила завантажено: відкрийте інтерфейс Prometheus (зазвичай http://ваш-сервер:9090/alerts) і переконайтеся, що всі правила з групи agave-validator відображаються зі станом INACTIVE.

Тестування alerts

Налаштовані alerts необхідно перевірити до того, як реальна проблема застане вас зненацька.

Тест SolanaValidatorDown: зупиніть процес валідатора на 2 хвилини:

sudo systemctl stop agave-validator

Попередження: ця дія зупиняє вашу ноду. Виконуйте лише в тестовому середовищі або за наявності резервного плану. Після отримання alert негайно запустіть:

sudo systemctl start agave-validator

Тест SolanaHighSkipRate: тимчасово знизьте поріг у правилі до значення, яке поточний skip rate гарантовано перевищує (наприклад, 0.001). Зачекайте 5 хвилин (значення for). Після отримання сповіщення поверніть оригінальний поріг і виконайте reload.

Тест через Alertmanager API: найбезпечніший спосіб, що не впливає на валідатор:

curl -X POST http://localhost:9093/api/v1/alerts -H "Content-Type: application/json" -d '[{"labels":{"alertname":"TestAlert","severity":"warning"},"annotations":{"summary":"Тестове сповіщення"}}]'

Це надішле штучний alert без залучення Prometheus чи валідатора. Якщо сповіщення прийшло у всі канали — інтеграція працює.

Тихі години та пріоритети

Не всі alerts однаково термінові. Якщо ви налаштуєте всі сповіщення з однаковим пріоритетом, виникне втома від alert-ів і пропущені критичні події.

Рекомендована матриця пріоритетів:

Для налаштування тихих годин (mute intervals) додайте секцію mute_time_intervals в alertmanager.yml. Наприклад, щоб заглушити warning-и з 23:00 до 07:00 за київським часом:

mute_time_intervals:
- name: night-warnings
  time_intervals:
  - times:
    - start_time: 23:00
      end_time: 07:00

route:
  ...
  routes:
  - match:
    severity: warning
    receiver: 'slack-warnings'
    mute_time_intervals:
    - night-warnings

Критичні alerts ніколи не mute-яться. Тихі години застосовуються лише до non-critical подій, щоб уникнути безсонних ночей через попередження про skip rate, які ви все одно не зможете оперативно вирішити до ранку.

Після налаштування всіх alerts наступний логічний крок — перевірка стабільності збору даних та діагностика проблем із snapshot-ами. Дивіться детальніше у матеріалі Як діагностувати snapshot failures.

Джерела

• Anza: Agave Validator Requirements
• Anza: Setup an Agave Validator
• Anza: Validator Security Best Practices
• Anza Agave: Releases
• Anza: Install the Solana CLI
• Solana Documentation: Staking
• Solana Documentation: Stake Accounts