Ревизия алертов раз в полгода: какие удалить, а какие ужесточить

MAATRIX

Откройте список правил в Alertmanager или Zabbix, который вы настраивали год назад, и посчитайте, сколько из них вы вообще вспомните без подсказки названия. Скорее всего половина — это алерты под сервисы, которых уже нет, пороги, скопированные из чужого мануала «на всякий случай», и правила, которые не срабатывали ни разу за всё время существования. Другая половина — наоборот, шумит каждый день по мелочам, и её тоже никто не открывает. Мониторинг без ревизии не улучшается сам по себе — он медленно превращается в свалку, где полезный сигнал тонет в собственном балласте. Разбираем, как раз в полгода провести ревизию всего набора правил и по каждому решить: оставить, ужесточить или удалить.

Почему алерты нужно ревизовать регулярно, а не один раз настроить

Настройка мониторинга — это не разовая задача, а процесс без финальной точки. Инфраструктура вокруг алертов меняется быстрее, чем сами алерты. Полгода назад вы держали один сервис приложения и одну базу — сейчас добавился воркер очередей, реплика для чтения и кэш-слой, а правила, написанные под старую топологию, продолжают жить нетронутыми. Кто-то скопировал CPU > 80% из старого проекта в новый, не проверив, какая нагрузка на новом сервере считается нормальной. Разработчик выкатил фичу, из-за которой типичная нагрузка на диск выросла вдвое, а порог остался прежним — алерт, который раньше срабатывал раз в квартал по делу, теперь орёт три раза в неделю на штатное поведение.

Ключевая мысль: набор алертов — это не конфигурация, которую можно «настроить и забыть». Это живой артефакт, который нужно ревизовать с той же регулярностью, с какой вы обновляете зависимости или проверяете бэкапы. Разница между командой, которая доверяет своему мониторингу, и командой, которая читает алерты через раз, часто сводится именно к тому, ревизуют ли они правила системно или только реагируют на отдельные жалобы «опять спамит».

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

Две болезни накопленного набора алертов

За полгода-год эксплуатации набор алертов почти неизбежно расслаивается на две проблемные категории, и лечатся они по-разному.

Мёртвые алерты. Правило существует, канал подключён, но срабатываний нет — ни одного за квартал, а иногда и за год. Причины разные: сценарий устарел (сервис вывели из эксплуатации, изменили архитектуру); порог выставлен настолько консервативно, что практически недостижим (диск > 98%, когда ротация логов чистит его при 90%); метрика перестала собираться из-за изменений в экспортере, а alert-rule продолжает существовать вхолостую. Опасность мёртвого алерта не в том, что он шумит — он молчит, создавая ложное чувство защищённости: в дашборде числится «алертов настроено: 40», по факту работает 25, а остальные 15 — иллюзия покрытия.

Шумные алерты. Обратная проблема — правило срабатывает часто, но подавляющее большинство срабатываний не требует действия: временный всплеск, флап метрики около порога, дубли из нескольких источников на одно событие. Каждое такое срабатывание по отдельности безобидно, но накопительный эффект серьёзнее — команда перестаёт открывать уведомления вообще; этот механизм привыкания мы разбирали в статье про усталость от алертов. Шумный алерт вреднее мёртвого именно потому, что активно тренирует людей игнорировать канал, в котором рано или поздно придёт что-то настоящее.

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

Периодичность: почему полгода, а не квартал и не раз в год

Полгода — практический компромисс, а не магическое число. Раз в месяц ревизовать весь набор избыточно: статистики за месяц мало для выводов, а сама ревизия отнимает время, которое можно потратить на что-то срочнее. Раз в год — слишком редко: за год инфраструктура успевает поменяться настолько, что ревизия превращается не в «подкрутить пороги», а в «переписать половину правил с нуля», а команда за это время успевает накопить усталость от шума, которую потом лечить сложнее, чем предотвратить.

Полгода даёт достаточно данных для статистики (сезонность нагрузки за такой период уже видна — например, летний спад трафика или пиковые дни распродаж) и не даёт правилам уйти слишком далеко от реальной топологии. При высоком темпе изменений — часто добавляются сервисы, команда быстро растёт — цикл стоит сократить до квартала; при стабильной инфраструктуре можно растянуть до трёх кварталов. Но если дата следующей ревизии нигде не зафиксирована, скорее всего её не будет никогда — «когда-нибудь потом» превращается в «через два года, после третьего пропущенного инцидента». Практический совет: заводите повторяющееся событие в календаре или тикет с датой следующей ревизии сразу после того, как закончили текущую — не полагайтесь на память.

Шаг 1: собрать статистику срабатываний за период

Ревизия начинается не с интуиции («кажется, этот алерт бесполезный»), а с цифр. Без статистики за спиной решение об удалении или ужесточении — это гадание, и через полгода вы рискуете либо удалить редкий, но важный алерт, либо оставить шумный просто потому, что «вроде привыкли».

Как собрать данные, зависит от стека:

Alertmanager (Prometheus). История срабатываний доступна через API:

# Активные и разрешённые алерты за текущее окно хранения
curl -s http://alertmanager:9093/api/v2/alerts | jq -r '.[] | [.labels.alertname, .status.state, .startsAt] | @tsv'

# Группировка по имени правила — сколько раз встречается за выгрузку
curl -s http://alertmanager:9093/api/v2/alerts | jq -r '.[].labels.alertname' | sort | uniq -c | sort -rn

Ограничение: сам Alertmanager хранит историю недолго (обычно часы-дни, зависит от retention), поэтому для полугодовой статистики нужен либо отдельный лог отправленных уведомлений (например, через webhook-receiver, который пишет каждое срабатывание в файл или таблицу), либо запрос к самому Prometheus по метрике ALERTS за нужный диапазон времени — она хранится столько, сколько настроен retention TSDB.

Zabbix. Штатная история событий доступна в веб-интерфейсе (Reports → Top 100 triggers) — готовый рейтинг самых часто срабатывающих триггеров за выбранный период, ровно то, что нужно для ревизии, без написания скриптов. Для гибкой выгрузки — API-метод trigger.get с фильтром по времени и event.get для подсчёта событий на триггер.

Самописный скрипт в Telegram. Если алерты уходят через собственный bash/python-скрипт (частый случай на небольших VPS), скорее всего истории нет вообще — скрипт шлёт сообщение и забывает о нём. Это стоит починить в первую очередь: добавить строку логирования перед каждой отправкой —

echo "$(date -Iseconds)|${ALERT_NAME}|${ALERT_VALUE}" >> /var/log/alerts-history.log

и раз в полгода поднять лог через awk: awk -F'|' '{print $2}' /var/log/alerts-history.log | sort | uniq -c | sort -rn. Без этой минимальной инвестиции ревизия каждый раз будет опираться на память дежурных, а память избирательна — хорошо помнит один особенно раздражающий алерт и забывает десяток тихих, которые не срабатывали никогда.

SaaS-платформы (Datadog, PagerDuty, Opsgenie). У них статистика срабатываний и время до реакции (time to acknowledge) обычно уже встроены в интерфейс отдельным отчётом — нужно только убедиться, что дашборд настроен на нужный диапазон.

Шаг 2: свести данные в таблицу ревизии

Собранную статистику удобно свести в одну таблицу — по одной строке на каждый alert-rule. Формат простой, не нужен специальный инструмент:

Колонка «требовали действия» заполняется не по ощущению, а по факту: приводило ли срабатывание к реальному вмешательству (перезапуск, эскалация, ручное исправление), или всё разрешилось само за то время, пока человек шёл проверять. Если журнала таких решений нет — заведите его на следующий цикл: короткая пометка «ложное» / «реальное» рядом с каждым уведомлением экономит часы на следующей ревизии. Час-полтора на такую таблицу для набора из 30-50 правил — реалистичная оценка, если статистика уже собрана скриптом или API-запросом заранее, а не выгружается вручную построчно.

Шаг 3: критерии удаления мёртвого алерта

Ноль срабатываний за полгода — повод разобраться, но не автоматическая команда «удалить». Прежде чем убрать правило, пройдите короткий чек-лист:

• Метрика вообще собирается? Проверьте в Prometheus/Grafana, что ряд данных не пустой за весь период. Если метрика пропала (изменили лейбл, перекатили экспортер, поменяли конфиг) — алерт молчит не потому, что всё хорошо, а потому что он сломан. Это самый опасный случай, и его нужно чинить, а не удалять.
• Сценарий ещё актуален? Если алерт написан под сервис, который вывели из эксплуатации или мигрировали на другую платформу — удаляйте без риска.
• Порог реалистичен для события, которое и должно быть редким? Истечение сертификата, критическая ошибка бэкапа, отказ диска — ноль срабатываний за полгода для таких алертов хороший знак, не повод для удаления. Ключевой вопрос не «сколько раз сработал», а «если бы событие случилось, сработал бы алерт вовремя» — это стоит явно проверить, а не только смотреть статистику.
• Есть ли дублирующее покрытие? Иногда алерт молчит, потому что событие на практике всегда предваряется другим алертом, который срабатывает раньше и по нему уже принимают меры. Можно оставить оба (резервирование для критичных сценариев — нормально) или решить, что один избыточен.

Если после проверки алерт всё ещё мёртв без уважительной причины — удаляйте без сожаления. Раздутый список правил, где половина никогда не срабатывала, усложняет чтение конфига и создаёт ложное ощущение покрытия там, где его нет.

Шаг 4: критерии ужесточения шумного алерта

Для алертов, где доля «требовали действия» к общему числу срабатываний низкая (условная граница — меньше 20-30%, но универсального числа нет, смотрите по своей терпимости команды к шуму), стандартный набор мер:

• Выдержка по времени (for-clause). Самая частая и самая эффективная правка. Вместо мгновенного срабатывания на пересечение порога — требование удерживать состояние N минут подряд. В Prometheus это буквально одна строка:

- alert: HighCPULoad
  expr: cpu_usage_percent > 90
  for: 10m
  labels:
    severity: warning

Кратковременный всплеск от cron-задачи не переживёт 10 минут ожидания; устойчивая деградация — переживёт и сработает как надо.

• Пересмотр самого порогового значения. Если статистика показывает, что реальные проблемы начинаются на значениях, сильно отличающихся от текущего порога, — меняйте число, опираясь на историю метрики за те же полгода, а не на круглое интуитивное значение вроде «80% звучит разумно». Разбор того, как порог, логичный на бумаге, не совпал с реальной точкой деградации сервиса, — в статье про инцидент с порогом на 90%.
• Дедупликация и группировка. Если один инцидент рождает десяток уведомлений (например, одна ошибка коннекта к базе сыплется от каждого из десяти воркеров) — группируйте по общему лейблу и шлите одно сообщение вместо десяти. В Alertmanager это group_by в конфиге маршрутизации.
• Понижение severity вместо удаления. Не каждый алерт обязан будить дежурного ночью. Часть шумных, но не полностью бесполезных алертов стоит перевести из канала с немедленным уведомлением в канал с отложенным просмотром (дашборд, письмо раз в сутки). Это убирает шум из зоны, где цена ложного срабатывания — прерванный сон.
• Условие на несколько метрик вместо одной. Часто ложное срабатывание — проблема того, что алерт смотрит на один показатель, хотя ситуация определяется сочетанием. Пример: не «очередь выросла», а «очередь выросла и обработка не успевает за приёмом» — сочетание отсекает кратковременные скачки, которые сами рассасываются.

Итоговый критерий: каждое срабатывание должно требовать внимания

Полезный ориентир для всего процесса — простой мысленный тест: если бы прямо сейчас пришло уведомление от этого алерта, вы бы бросили текущую задачу и пошли проверять? Ответ «да, всегда» — правило настроено правильно, вне зависимости от частоты срабатывания. Ответ «скорее всего опять ерунда, но на всякий случай гляну» — кандидат на ужесточение. Ответ «даже открывать не буду» — алерт либо давно пора было ужесточить, либо он не несёт практической ценности и его стоит удалить.

Идеальный набор алертов — не тот, где меньше всего правил, и не тот, где больше всего покрытия на бумаге. Это тот, где частота срабатывания примерно равна частоте реальных проблем, а дежурный, открывая уведомление, знает, что там почти наверняка что-то настоящее. Такое доверие к каналу поддерживается регулярной ревизией — раз в полгода выделить полтора-два часа, свести статистику в таблицу и честно пройтись по каждой строке.

Частые вопросы