Мониторинг и автоматическая остановка моста

Верификатор, контрольная проверка (canary) и сторожевой процесс (watchdog) публикуют состояние моста для Prometheus. Canary и watchdog повышают уровень остановки только своего узла. Для остановки нескольких узлов нужны отдельно настроенные административные вызовы либо процедура управления; оператор может связать её с оповещениями Alertmanager.

Получение метрик

GET /admin/metrics

Ответ использует текстовый формат Prometheus: text/plain; version=0.0.4. Маршрут должен быть доступен только из закрытой сети — через ACL балансировщика, Kubernetes NetworkPolicy или правила VPC. Prometheus обращается к нему из той же сети.

Обработчик читает снимок из памяти через :persistent_term.get/2, без запросов к БД и синхронных обращений к другим процессам. Он не ждёт ответа компонентов моста. Это не гарантирует время HTTP-ответа при перегрузке самого узла или сети.

Шесть групп метрик

1. Операции bridge_lock

Успешное исполнение bridge_lock увеличивает bridge_refill_mints_total. Счётчик показывает число обработанных операций с момента запуска узла:

bridge_refill_mints_total 12734

Если при ожидаемой активности счётчик не растёт, проверьте остановку моста, сетевую связность и исполнение прекомпайла.

2. Отказы верификатора

Отказ межсетевой проверки увеличивает bridge_unbacked_bridge_mints_total{reason="…"}. Метка reason принимает значения из ограниченного списка: отсутствующее событие, несовпадение суммы, контракта, сигнатуры или сети, недостаточная финальность, нарушение привязки HTLC или получателя, возврат Ethereum-блокировки, запрещённый claimer и ошибки RPC.

Любое приращение требует расследования: верификатор не смог подтвердить операцию через Ethereum. Это может быть как нарушение данных, так и недоступность RPC. До возобновления определите причину и проверьте все источники остановки.

3. Давность контрольной проверки

Canary периодически проверяет известное корректное событие bridge_lock через рабочий Ethereum RPC. При отказе проверки Chain.Bridge.Canary повышает локальный уровень остановки до red через CircuitState. Это не изменяет состояние консенсуса и не останавливает другие узлы.

Метрика показывает число секунд с последней успешной проверки:

bridge_canary_last_success_seconds 47.3

До первой успешной проверки публикуется большое конечное значение — примерно 31 год. Так правило metric > threshold сработает и при полном отсутствии успешных проверок, вместо того чтобы пропустить отсутствующий ряд метрик.

4. Работа сторожевого процесса

Watchdog работает в отдельном дереве супервизоров и следит за сигналами активности canary. Пропуск настроенного числа сигналов повышает локальный уровень остановки этого узла. Для остановки нескольких узлов нужны отдельные административные вызовы либо процедура управления, описанная ниже.

bridge_watchdog_consecutive_failures 0
bridge_watchdog_tripped 0
bridge_watchdog_last_canary_heartbeat_seconds 47.3
bridge_watchdog_last_tick_seconds 12.1

bridge_watchdog_last_tick_seconds показывает давность работы watchdog, а bridge_watchdog_last_canary_heartbeat_seconds — давность сигнала от canary. Отображайте оба значения: работающий watchdog не означает, что canary выполняет проверки. До первого сигнала также используется большое конечное значение.

5. Уровень остановки

bridge_circuit_state{tier} показывает уровень остановки: один ряд равен 1, остальные — 0.

bridge_circuit_state{tier="none"} 0
bridge_circuit_state{tier="yellow"} 1
bridge_circuit_state{tier="red"} 0
bridge_circuit_state{tier="black"} 0

Выражение bridge_circuit_state{tier!="none"} == 1 обнаруживает любой активный уровень остановки.

6. Автоматизация ввода через мост

Серии bridge_intent_watcher_* и bridge_intent_eth_claim_* показывают продвижение курсора Ethereum-событий, расхождения с планом и ошибки автоматических claim. Пороги и порядок расследования задаются для конкретного развёртывания во внутренней инструкции оператора, поставляемой с релизом.

Объём за 24 часа

bridge_inflow_24h_usdc суммирует суммы записей моста, а bridge_outflow_24h_usdc — успешно исполненные HTLC, отмеченные как мостовые. Название метрики не означает, что публичный вывод POA → Ethereum включён: он остаётся отключённым.

Агрегация выполняется каждые 30 секунд по таблицам состояния. Это метрики наблюдения, а не правила консенсуса. Настройте пороги отклонения объёма по ожидаемой нагрузке; при достаточной истории можно использовать статистическую модель.

Контроль сборщика метрик

Две метрики проверяют сам сборщик:

• bridge_metrics_collector_last_success_unix_seconds — Unix-время последнего полностью успешного сбора. Проверка: time() - metric > threshold; порог можно начать с четырёх интервалов опроса и уточнить по условиям развёртывания.
• bridge_metrics_collector_failures_total{collector} — число ошибок каждого источника данных: БД, уровня остановки, canary или watchdog.

Счётчики выявляют отдельные ошибки, а время последнего успеха — полную остановку сборщика. Без них сохранённые старые значения могут выглядеть как действующие показатели.

Автоматическая остановка

Адаптер уведомлений Alertmanager вызывает POST /admin/bridge/halt с заголовком x-admin-api-token и HMAC-подписью. HaltAdmin проверяет подпись, время, уникальность nonce и привязку к целевому узлу и маршруту. Это административная операция остановки одного узла; она не записывает общесетевое состояние консенсуса. Для остановки нескольких узлов нужны отдельные обращения либо предусмотренная протоколом процедура управления.

Уровень yellow запрещает новые bridge_lock. Уровни red и black также блокируют затронутые правилами моста операции claim; возвраты и обычные HTLC имеют отдельные правила. Не описывайте эти уровни как запрет всех операций сети.

В журнале сохраняется источник остановки, например reason="alert:<RuleName>". Перед возобновлением согласуйте все активные причины остановки и следуйте процедуре оператора.

Граница доверия

У /admin/metrics нет аутентификации на уровне приложения. Закройте его сетевыми правилами. Доступ к внутренней сети или SSRF может раскрыть агрегированные операционные данные; ограничьте пути доступа и исходящие HTTP-запросы приложения.

До включения автоматической остановки проверьте доступ Prometheus, актуальность метрик, правила оповещения, адрес узла и аутентификацию адаптера. Контрольное срабатывание и последующее возобновление выполняйте по согласованной операторской процедуре. Наличие метрик само по себе не подтверждает, что Alertmanager настроен и остановит нужный узел.

Какие данные не публикуются

Ответ содержит агрегаты. Идентификаторы событий bridge_lock, хеши HTLC и транзакций, адреса получателей и другие данные отдельных операций в него не включаются. Журнал моста читается отдельно через операторские средства доступа к БД. Метка reason ограничена фиксированным словарём и не содержит данные отклонённого события.

Настройка Prometheus

- job_name: bridge_node
  scrape_interval: 15s
  scrape_timeout: 10s
  metrics_path: /admin/metrics
  static_configs:
    - targets: ["bridge.internal:4000"]

При интервале сбора 30 секунд и опросе Prometheus каждые 15 секунд одно значение обычно считывается дважды. Более частый опрос не ускоряет обновление снимка, но может уменьшить задержку его обнаружения.

Шаблон адаптера Alertmanager, пороги и порядок действий по каждому оповещению хранятся во внутренней документации оператора для соответствующего релиза. Секреты в конфигурационные примеры не включаются.