Типовой мониторинг валидатора устроен так: алерт на «процесс упал», алерт на CPU, алерт на диск, и дежурный тонет в нотификациях, половина которых ничего не значит. При этом то, что реально теряет деньги, проходит мимо: нода зелёная, а reward или стейк утекают. Мы держим observability для клиентских валидаторов, и главная работа здесь не «добавить метрик», а выбрать, на что НЕ алертить. Дальше про эту дисциплину.
Алертим на симптом, а не на причину
Классическая ошибка это алерты на причины: высокий CPU, заполнение диска, рестарт процесса. Причин бесконечно много, большинство сами по себе безобидны, и каждый такой алерт это ложная тревога чаще, чем настоящая. Дежурный быстро учится их игнорировать, и тогда они бесполезны.
Мы алертим на симптомы, то есть на то, что напрямую бьёт по клиенту: валидатор пропускает attestation, latency ответа уехала в хвост, доля пройденных проверок упала. Симптом не врёт: если он сработал, клиенту уже плохо или вот-вот станет. Высокий CPU при этом живёт в дашборде для диагностики, но сам по себе никого ночью не будит. Причину дежурный найдёт по симптому, а не наоборот.
Какие SLI реально важны
Набор сигналов у валидатора короткий, и он не про железо:
- Доля и своевременность attestation. Базовый показатель полезной работы: делает ли валидатор то, за что ему платят, и вовремя ли.
- p99 latency на attestation и на ответы, не среднее. Почему именно хвост, разобрано в посте про то, что slashing это не про uptime.
- Признаки equivocation и конфликта ключа. Высший приоритет, немедленная эскалация: это та категория, что стоит стейка.
- Diversity и blast radius. Разнообразие провайдеров, ASN, версий клиента: коррелированный риск надо видеть до инцидента, а не после.
«Uptime в процентах» здесь не primary-сигнал, а производная. Он есть в отчёте, но дежурного будит не он.
Алерт без раннбука это не алерт
Алерт, на который дежурный не знает, что делать, это просто паника в три ночи. Поэтому у нас правило: каждый алерт, который будит человека, ссылается на раннбук, где написано, что проверить и какие шаги предпринять. Если на симптом нельзя написать раннбук, значит либо симптом выбран плохо, либо мы не понимаем систему, и то и другое надо чинить до того, как алерт уйдёт в прод.
Это и держит число будящих алертов маленьким: чтобы завести новый, надо написать к нему раннбук, и это естественный фильтр против алертов «на всякий случай».
Шум убивает дежурного
Alert fatigue это не про комфорт, это про безопасность. Дежурный, которого за ночь десять раз дёрнули по пустякам, к одиннадцатому, настоящему, реагирует медленно или отмахивается. Поэтому шум это не косметическая проблема, а прямой риск пропустить equivocation.
Мы держим сигнал к шуму высоким сознательно: каждый ложный ночной алерт это баг в мониторинге, который чинится, а не терпится. Лучше десять точных алертов в месяц, на каждый из которых дежурный реагирует всерьёз, чем сто, на которые он перестал смотреть.
Как это у клиента
На полигоне мы настраиваем стек на Prometheus, Grafana и Alertmanager так, чтобы будящие алерты были симптомными и каждый имел раннбук, и специально гоняем сценарии, проверяя, что важное срабатывает, а шум молчит. На клиентском контракте это превращается в его набор SLI, его алерты с раннбуками и его дашборды для диагностики, заточенные под конкретную сеть.
Если вам нужен мониторинг, который будит по делу и не топит в шуме, это часть того, что мы закрываем через operate. Хотите, чтобы мы посмотрели на ваш текущий алертинг на предмет шума и слепых зон: напишите нам.