Алерт, на который никто не идёт

Признак, по которому видно состояние мониторинга: спросите у дежурного, сколько уведомлений пришло за прошлую неделю и на сколько он отреагировал.

Разрыв между числами и есть проблема. Если пришло сорок, а отреагировал на три — тридцать семь правил работают против вас.

Почему это хуже, чем ничего

Мониторинг, который шумит, не просто бесполезен. Он вреден, и по трём механизмам.

Порог реакции растёт. Человек, разбудённый пять раз за неделю без причины, на шестой раз посмотрит утром. Шестой окажется настоящим. Это не разгильдяйство, а нормальная адаптация: он научился, что уведомление обычно ничего не значит.

Настоящее теряется в потоке. Сорок уведомлений в канале — это стена, которую не читают. Важное приходит туда же и выглядит так же.

Уходит доверие. Когда «сработал алерт» перестаёт означать «что-то случилось», система перестаёт быть источником правды. Дальше инциденты обнаруживают по жалобам, а мониторинг существует для отчётности.

Правило, которое я применяю

У каждого правила должно быть записано действие. Одна строка: что сделать человеку, который это получил.

Не «проверить систему». Конкретное: посмотреть глубину очереди и, если растёт, добавить обработчиков. Или: переключить на резервного провайдера.

Если действие сформулировать не получается, вариантов два, и оба хорошие. Либо действие есть, но его никто не сформулировал — тогда это надо сделать, и правило станет полезным. Либо действия нет — тогда правило надо удалить.

Понижение до «предупреждения» — не решение. Предупреждение, на которое никто не смотрит, — это то же самое, только с самообманом: формально мы следим.

На что стоит алертить

Здесь я не согласен с распространённой практикой, и скажу прямо.

Не на ресурсы. Процессор на восьмидесяти процентах — не авария. Это, возможно, эффективное использование железа. Память под завязку у JVM — нормальное поведение сборщика мусора. Диск на девяноста процентах — авария, но только если он растёт; если он такой третий год, это норма.

Алерт на ресурс срабатывает, когда системе плохо, и когда ей хорошо, и различить одно от другого он не помогает.

На симптомы, которые видит пользователь. Доля ошибок выросла. Задержка на девяносто девятом перцентиле превысила обещанную. Заказы перестали создаваться. Очередь растёт быстрее, чем разбирается.

Разница принципиальная: симптом означает, что кому-то уже плохо. Ресурс означает, что может стать плохо, а может и не стать.

На выгорание бюджета ошибок. Если сформулирована цель по надёжности — скажем, 99,9% успешных запросов в месяц, — то бюджет ошибок за месяц известен. Алерт на скорость его расходования гораздо полезнее порога на мгновенное значение: он ловит и резкий всплеск, и медленную деградацию, и при этом молчит на единичном сбое, который в бюджет укладывается.

Это, на мой взгляд, единственный способ отличить «сломалось» от «поморгало», не занимаясь подбором порогов вручную.

Три технические причины шума

Помимо плохо выбранных условий, есть три механические причины, по которым правильное правило шумит.

Нет выдержки. Условие «доля ошибок больше процента» без указания длительности срабатывает на одном всплеске в тридцать секунд. Почти любое правило нуждается в требовании «держится N минут», и подбор этой длительности важнее подбора порога.

Нет подавления зависимых. База недоступна — уведомляют все двенадцать сервисов, которые в неё ходят. Двенадцать уведомлений об одной аварии. Нужна иерархия: если сработала корневая причина, зависимые молчат.

Нет группировки. Двадцать экземпляров одного сервиса при общем сбое дают двадцать одинаковых сообщений. Группировка по метке сервиса превращает их в одно со счётчиком.

Все три настраиваются в любой современной системе уведомлений и все три обычно оставлены по умолчанию.

Что делать с накопленным

Правил обычно уже много, и удалять страшно: вдруг именно оно поймает.

Порядок, который работает:

1. Выгрузить срабатывания за месяц с числом по каждому правилу.
2. Отсортировать по убыванию. Верхние пять — это девяносто процентов шума.
3. По каждому из пяти ответить: было ли хоть одно срабатывание, после которого что-то сделали. Нет — удалить. Да — понять, чем те срабатывания отличались от остальных, и переписать условие под них.
4. Повторять раз в месяц.

Четвёртый пункт важнее первых трёх. Шум накапливается непрерывно: каждое правило добавляют после инцидента, и каждое кажется оправданным в тот момент. Без регулярной прополки система приходит в то же состояние за полгода.

Когда всё это можно не делать. Если дежурства нет и уведомления приходят в чат, который читают в рабочее время, — цена шума низкая, и заниматься прополкой незачем. Разговор начинается там, где кого-то будят ночью. Тогда каждое лишнее правило имеет цену, измеряемую в человеке.