Алерты без шума помогают реагировать вовремя: как выбрать пороги, окна и дедупликацию, чтобы тревога всегда вела к действию.
Шум в алертах появляется, когда мониторинг сообщает не о проблеме, а о колебаниях. Метрика чуть дернулась, задача перезапустилась, сеть мигнула на секунду, и уже прилетает тревога. Если таких сообщений десятки в день, команда быстро перестает отличать важное от второстепенного.
Самая опасная часть шума - привыкание. Когда алерты часто оказываются ложными или «ни о чем», люди начинают откладывать реакцию, отключать уведомления или смотреть их раз в несколько часов. В итоге реальная авария теряется среди мелких всплесков, а время восстановления растет.
Плохо настроенные алерты обычно видно сразу:
Представьте ситуацию. Ночью у API на 2 минуты выросли ошибки 500 из-за короткого сбоя у внешнего провайдера. Система отправляет 30 уведомлений по каждому инстансу. Дежурный тратит время на чтение, но уже не уверен, что это важно, потому что «такое часто бывает». Если через час начнется настоящий перегруз базы, шанс пропустить его становится заметно выше.
Подход «Алерты без шума» сводится к простой цели: получать меньше сигналов, но таких, по которым можно сразу сделать конкретное действие. Для этого нужны понятные пороги, разумные окна и правила дедупликации, а не бесконечный поток тревог.
Хороший алерт означает одно: кто-то должен сделать конкретный шаг прямо сейчас. Если после уведомления нечего делать (или непонятно, что делать), это не алерт, а наблюдение. Наблюдению место на дашборде.
Проверьте правило простой формулой: «Если это случилось, какие 1-2 действия мы делаем в ближайшие 10 минут?» Если ответа нет, алерт нужно переписать.
Часто в шум уходят метрики, которые полезно видеть, но не нужно «лечить руками»: небольшие колебания нагрузки, единичные 5xx, разовые пики задержки, медленные запросы без влияния на пользователей.
У каждого алерта должен быть владелец и понятная ответственность: кто получает, в каком канале, за сколько минут обязан отреагировать. Иначе уведомление быстро превращается в фон, потому что все думают, что «кто-то другой разберется».
Мини-ранбук удобно уместить в один абзац прямо в описании алерта: что проверить и что делать. Например: «Если 5xx растут 5 минут: 1) открыть последние деплои и откатить, если совпало по времени; 2) посмотреть логи API по trace-id; 3) проверить базу на рост ошибок и пул соединений; 4) если есть явный источник, отключить проблемную фичу; 5) если неясно - эскалировать дежурному бэкенда». Такой текст снижает панику и ускоряет первые шаги.
Когда принцип соблюден, алертов становится меньше, но каждый из них реально помогает, а не тренирует команду игнорировать уведомления.
Чтобы построить алерты без шума, сначала договоритесь, какие типы сигналов вы собираете и для чего.
Метрики - это числа во времени: процент ошибок, задержка, загрузка CPU, длина очереди. Они хорошо подходят для порогов, окон и сравнения с нормой.
Логи - это отдельные события с текстом и полями: «пользователь не найден», «таймаут в запросе». Они незаменимы для поиска причин, но плохо подходят для алерта по каждому событию.
Трассировки - это путь одного запроса через сервисы. Они показывают, где теряется время, и помогают понять, какая часть системы виновата.
Для алертов чаще всего подходят сигналы, которые прямо показывают ухудшение сервиса и требуют реакции:
Алерт «по одному логу» почти всегда превращается в шум. Один и тот же текст может появляться сотни раз из-за ретраев, сканеров, кривого клиента или короткого сетевого сбоя. В итоге тревога означает не проблему, а то, что «кто-то что-то написал в лог». Практичнее превращать логи в метрики: считать частоту, долю от всех запросов, число уникальных пользователей, которых это задело.
Главная идея - связывать техническую метрику с влиянием на пользователя. Тогда при срабатывании понятно, что делать и насколько срочно. Например, если вы выкатываете API для приложения (хоть написанного вручную, хоть собранного на TakProsto), формулируйте алерт так, чтобы он отвечал на вопрос «пользователь сейчас страдает?»:
Если связь с пользователем не получается описать одной фразой, это кандидат не для алерта, а для дашборда и разборов по запросу.
Порог «выше/ниже» хорошо работает там, где есть понятная граница нормы. Например: свободное место на диске меньше 10% или пул соединений к базе заполнен больше 90%. В таких метриках смысл прямой: пересекли линию - делаем конкретное действие.
Где абсолюты часто врут - это метрики, зависящие от трафика. 200 ошибок в час может быть катастрофой для маленького сервиса и почти незаметным фоном для большого. Поэтому вместо «сколько» часто полезнее смотреть «как быстро» и «какая доля»: rate (ошибок в минуту), процент 5xx от всех запросов, рост задержки относительно базового уровня.
Помогает сразу закладывать два уровня: warning и critical. Warning дает время разобраться без ночного подъема. Critical означает, что вы реально идете чинить прямо сейчас.
Например:
Сезонность и пики нагрузки лучше учитывать не «плавающими» порогами, а нормальными окнами и относительными сравнениями. Для API на TakProsto, где пользователи часто запускают сборки вечером, имеет смысл не алертить на сам рост RPS, а ловить ошибки и задержки на фоне роста нагрузки. Еще один прием - сравнивать с «обычным» значением за прошлую неделю в тот же час. Тогда пороги не дергаются от ежедневных всплесков, но ловят то, что действительно пошло не так.
Короткие всплески бывают у любого сервиса: перезапуск подов, краткий сетевой сбой, прогрев кеша. Если алерт реагирует на каждую секунду, он превращается в шум и ломает принцип «алерт только на действие». Окно и сглаживание нужны как раз для того, чтобы тревога срабатывала только на проблему, которая держится.
Представьте API: за 30 секунд прилетело 40 ошибок 500 из-за временного сбоя у зависимости, а потом все само восстановилось. При проверке «за последнюю минуту» вы, скорее всего, получите тревогу. При проверке «процент ошибок за 5 минут» тот же пик может раствориться, если дальше ошибки не повторялись. В итоге окно 5 минут будет срабатывать тогда, когда пользователи действительно страдают, а не когда «моргнуло».
Есть и обратная сторона: большое окно замедляет реакцию. Если у вас строгий SLO по доступности, а команда реально может вмешаться за 10-15 минут, то окно 10 минут плюс задержка доставки алерта - уже риск.
Отдельная боль - «горит - погасло - горит». Это флаппинг. Его лечат простыми правилами:
Окно выбирайте от времени реакции и цели метрики. Чем быстрее вы можете исправить, тем короче окно. И наоборот: если вы все равно не успеете за 2 минуты, нет смысла получать алерт каждые 60 секунд.
Дедупликация решает простую боль: один инцидент - одно уведомление. Если у вас 20 инстансов API и у всех упал один и тот же upstream, команда не должна получить 20 сообщений. Достаточно одного алерта с понятным счетчиком (сколько инстансов затронуто) и ясным действием.
Группировка отвечает на вопрос: по какому признаку алерт считается «одним». Обычно хватает 1-2 измерений: сервис и окружение (prod/stage). Регион или кластер добавляйте только если это меняет действие (например, можно выключить трафик в одном регионе). Группировка по клиенту или tenant полезна, когда у вас действительно разные SLA и отдельная поддержка, иначе это быстрый путь к шуму.
С повторами важно не переборщить. Напоминания нужны, если инцидент не закрыт, но не каждые 2 минуты. Как правило, хватает редких повторов (раз в 30-60 минут) или уведомления при изменении масштаба (например, было 2 инстанса, стало 10). Если метрика «чуть-чуть» колеблется вокруг порога, лучше молчать.
Ингибирование (подавление) спасает от каскада вторичных тревог. Пример: если база недоступна, то алерты «API 500», «очередь растет», «таймауты» стоит приглушить и оставить один главный сигнал: «DB down». Дежурный видит причину, а не последствия.
Маршрутизация делает алерт полезным по времени. Ночью должны приходить только события, требующие немедленного действия. Днем часть сигналов можно отправлять в рабочий чат или в очередь на разбор. Простое правило: если нет владельца и сценария реакции, алерт не должен будить.
Хорошее правило начинается не с графика, а с понятного симптома. Сформулируйте его так, как его почувствует пользователь, и сразу добавьте ожидаемое действие. Например: «пользователь не может войти, дежурный проверяет статус авторизации и откатывает последний релиз, если рост ошибок совпал по времени».
Дальше выберите метрику и контекст, где именно вы ее считаете. Одна и та же «ошибка 500» в одном эндпойнте может быть критичной, а в другом - редкой мелочью. Добавьте фильтры, которые меняют смысл: сервис, метод, регион, окружение, важный клиент.
Если вы делаете сервисы в TakProsto и у вас есть снапшоты и откат, фиксируйте это как возможное действие прямо в алерте: «при совпадении по времени с релизом - откатиться на предыдущий снапшот».
После этого задайте порог и окно и обязательно прогоните идею по истории. Порог должен ловить реальную проблему, а окно - отсеивать короткие всплески. Если на прошлой неделе алерт бы сработал 20 раз без последствий, это не алерт на действие.
Чтобы правило стало операционным, доведите его до понятного стандарта:
Сигнал должен быть привязан к действию. Если алерт сработал, дежурный должен понимать, что проверить за 5 минут и что можно сделать безопасно прямо сейчас.
Ошибки удобно ловить двумя способами. Доля 5xx (например, 2%+) хороша, когда трафик стабильный и важно качество для пользователей. Абсолютное число 5xx (например, 200 за 5 минут) полезнее при низком трафике: 50% от двух запросов ничего не значит, а 200 ошибок подряд - уже инцидент. Часто ставят оба условия, чтобы не пропустить ни «тихий» сбой, ни массовый.
Задержку лучше смотреть по p95 или p99. Среднее легко прячет проблему: 90% ответов быстрые, а 10% очень медленные, и пользователи жалуются, хотя «среднее норм». Для p95 можно задать порог, например 800 мс, а для p99 - 1500 мс, но всегда сверяйтесь с вашим SLO.
Насыщение показывает, что сервис упирается в лимиты: растет очередь, заканчивается пул соединений, участились таймауты клиента. Здесь алерт важен до того, как посыпятся 5xx.
Пример набора правил: предупреждение по доле 5xx 1% за 10 минут, критичный - 3% за 2 минуты. Для задержки аналогично: p95 выше порога 15 минут (warn), p99 выше порога 3 минуты (crit). Разные окна помогают отличить краткий пик от устойчивого ухудшения.
В ранбуке для API полезно держать короткий план:
Хороший алерт по базе отвечает на один вопрос: что мы можем сделать прямо сейчас. Это самый надежный способ не утонуть в шуме.
Пик соединений сам по себе часто нормален (утренний старт, деплой, прогрев). А вот рост, который не откатывается, обычно значит утечку или неправильный пул.
Практичное правило: алертить не абсолютное число, а сочетание «близко к лимиту и держится долго». Например: активные соединения больше 80% от max_connections в течение 10 минут, и при этом растет доля idle in transaction. Действия обычно простые: ограничить новый трафик, проверить пул в сервисах, найти зависшие транзакции.
Если реплика используется для чтения, лаг важен только когда он портит данные для пользователя (устаревшие списки, пропавшие заказы). Хороший триггер: lag больше 30-60 секунд 5 минут подряд, плюс рост очереди WAL или падение apply rate. Действие: временно убрать чтение с реплики или переключить критичные запросы на мастер.
Медленные запросы лучше алертить не по факту «какой-то запрос был долгим», а по симптомам, которые влияют на пользователей и устойчивость:
Для диска и I/O почти всегда нужны окна: 1-2 минуты всплеска могут быть вакуумом или бэкапом. Смотрите 10-15 минут и проверяйте, коррелирует ли это с ростом latency запросов.
Если один сбой вызывает десяток вторичных метрик, дедуплицируйте по корню: «DB недоступна/не отвечает». Остальные алерты (ошибки приложений, таймауты, рост ретраев) стоит подавлять, пока активен главный инцидент.
02:13 ночи. Мониторинг показывает рост 5xx на API с 0.2% до 6% за последние 10 минут. При этом CPU на серверах в норме, память тоже. Похоже на сбой не от нагрузки, а от зависимости: база, внешнее API, очереди или лимиты.
Первыми должны сработать не «CPU высокий», а алерты, которые ведут к действию: процент 5xx по окну и рост задержки по p95. Если есть отдельный алерт на ошибки подключения к базе или рост таймаутов, он помогает сразу сузить поиск. В этом и смысл алертов без шума: тревога говорит, что делать, а не просто «что-то не так».
Дедупликация спасает от массового пробуждения. Вместо 200 сообщений по каждому эндпоинту приходит одно: «API 5xx > 5% 10 мин, затронуты 12 маршрутов». Группировка по сервису и подавление вторичных алертов (например, на 4xx от клиентов) не дают расползтись панике.
Первые 10 минут обычно выглядят так:
После стабилизации правила обычно упрощают, а не усложняют: один главный алерт на пользовательский эффект (5xx и p95) плюс один диагностический (например, таймауты к базе). Порог и окно корректируют по факту: если разбудило зря, увеличивают окно или добавляют устойчивость «держится 2 из 3 проверок», но оставляют логику прозрачной.
Самая частая причина алерт-фатига простая: тревоги срабатывают чаще, чем команда успевает что-то сделать. Через пару недель мозг начинает считать любой пинг «фоном», и реальная авария тонет в шуме.
Если порог близко к норме, а окно короткое, алерт будет дергаться на каждый пик. Типичный пример: «ошибки 5xx > 1% за 1 минуту» при трафике, который гуляет. Лучше считать на более длинном окне и требовать устойчивости, а не одного всплеска.
Алерт без владельца превращается в «кто-нибудь разберитесь». Алерт без действия звучит как «что-то не так», и на него перестают реагировать. В тексте уведомления должно быть ясно: что проверить первым (лог, дашборд, зависимость), где граница «ждем» vs «эскалируем», и кто принимает решение.
Когда одно событие бьет и по метрике, и по логу, и по отдельному сервису, вы получаете три сообщения вместо одного. Дедупликация и группировка по сервису, окружению и типу ошибки заметно снижают шум.
Если есть только «API медленное», вы не понимаете, что именно чинить. Если есть только «закончились подключения к базе», продуктовая команда узнает поздно. Нужна связка: один алерт на пользовательскую боль и один-два технических, которые помогают быстро найти источник.
Когда «предупреждение» приходит в тот же канал, что и «падение продакшена», важное перестает отличаться от неважного. Разделяйте уровни: предупреждения для дневной работы, критичные - только для тех, кто реально может и должен реагировать прямо сейчас.
Перед тем как включать алерты в бою, прогоните быстрый контроль. Он занимает 10 минут, но экономит ночные дежурства и помогает не выработать привычку игнорировать тревоги.
Алерт должен читаться как задача. У него есть владелец (команда или роль) и понятный следующий шаг.
Порог и окно должны быть проверены на истории, иначе вы получите флаппинг и потерю доверия. Хорошее правило редко тревожит, но почти всегда означает проблему.
Отдельно договоритесь о severity и маршрутизации: что идет в чат, что будит дежурного ночью, а что просто фиксируется. И внесите в календарь ежемесячный пересмотр: какие алерты помогли, какие были шумом, какие можно удалить или переписать.
Чтобы алерты без шума стали нормой, не пытайтесь чинить все сразу. Начните с 5-10 самых важных тревог, где цена пропуска реально высокая: падение доступности, массовые 5xx, переполнение очереди, критичный лаг репликации. Остальное временно переведите в наблюдение (дашборды, отчеты, weekly review), чтобы не будить людей по мелочам.
Дальше соберите обратную связь от тех, кто дежурит. После каждой недели задавайте три вопроса: какие алерты мешали, каких не хватило, и где правило сработало поздно. Важно не спорить, а фиксировать факты: сколько было ложных срабатываний и сколько раз алерт не привел к действию.
Полезно вести простую «карточку алерта», чтобы правила не превращались в магию:
Чтобы небольшой команде не утонуть в ручных правках, договоритесь о минимальном процессе изменений: любое изменение правила проходит короткий review и имеет заметку «почему поменяли». Если вы часто правите пороги, заведите шаблоны (например, «API latency», «DB connections») и переиспользуйте их, а не копируйте руками.
Если хочется чуть меньше ручной рутины, можно собрать внутренний сервис, где правила алертов и шаблоны ранбуков живут в одном месте, а изменения фиксируются как версии. На TakProsto (takprosto.ai) такой сервис можно быстро сделать через чат-интерфейс, а затем так же быстро откатываться к предыдущему состоянию, если правка порогов неожиданно «разбудила» всю команду.
Шум появляется, когда мониторинг реагирует на краткие колебания, а не на устойчивую проблему. Если уведомления часто оказываются «ложными» или не требуют действий, команда привыкает и начинает игнорировать даже важные сигналы.
Оставляйте алерт только там, где после срабатывания понятно, что сделать в ближайшие 10 минут. Если ответ звучит как «просто посмотреть на график» или «непонятно, что делать», это лучше перенести в дашборд или отчет.
Сначала формулируйте симптом на языке пользователя: что именно ухудшилось для клиента, и насколько срочно. Затем подбирайте метрику, которая это отражает, и сразу добавляйте краткий сценарий первых проверок, чтобы алерт был «на действие», а не «на тревогу».
Метрики удобны для порогов, окон и долей, потому что их можно устойчиво измерять во времени. Логи полезнее для диагностики причин, а не для алерта на каждое событие; чаще их стоит агрегировать в метрику (частота, доля, число затронутых пользователей), иначе уведомления быстро станут шумом.
Ставьте пороги там, где есть понятная «граница нормы» (например, место на диске или заполнение пула соединений). Для метрик, зависящих от трафика, чаще работают доли и скорости изменений: процент 5xx, rate ошибок, рост p95/p99 относительно обычного уровня.
Окно должно отфильтровывать краткие всплески, но не делать реакцию слишком медленной. Практичное правило: окно выбирают от реального времени вмешательства команды и от того, насколько метрика «шумная» сама по себе; если вы все равно не успеете исправить за 2 минуты, нет смысла алертить каждую минуту.
Это флаппинг: метрика болтается вокруг порога и постоянно дергает алерт. Обычно помогают гистерезис (разные пороги на включение и выключение), требование устойчивости условия и «пауза» на повторы, чтобы не получать одно и то же каждые пару минут.
Дедупликация нужна, чтобы один инцидент давал одно уведомление, даже если затронуто много инстансов. Группировка отвечает за то, по каким признакам вы считаете событие «одним» (обычно сервис и окружение), а подавление убирает вторичные алерты, когда уже есть главный сигнал о первопричине.
Держите в описании алерта короткий «мини-ранбук» одним абзацем: что проверить первым и какие безопасные действия можно сделать сразу. Также важно указать владельца и ожидания по реакции, иначе уведомление быстро превращается в «кто-нибудь разберитесь».
Используйте это как конкретное действие: «если рост ошибок совпал с релизом — откатиться на предыдущий снапшот» и проверьте, что этот шаг безопасен и понятен дежурному. В TakProsto это особенно удобно, потому что откат и снимки состояния можно встроить в стандартный сценарий реакции, уменьшая время на первые решения.
