Как настроить пороги оповещений, которые не игнорируют?

Порог сам по себе не спасает от шума. Если оповещение не связано с действием, его будут игнорировать при любом числе в условии. Хорошее правило сообщает о ситуации, которая уже влияет на сервис или скоро сделает это, приходит к человеку с полномочиями исправить ее и содержит достаточно контекста для первого решения.

Я видел, как команды пытались лечить сотни ночных сообщений одним движением: поднять CPU с 80 до 90 процентов, увеличить окно с пяти минут до десяти или отключить самый разговорчивый канал. Через месяц шум возвращался, только инциденты обнаруживались позже. Причина проста: порог, устойчивость сигнала, маршрутизация, группировка и подавление решают разные задачи. Настраивать их надо раздельно.

Оповещение должно заслужить право разбудить человека

У оповещения есть право существовать только тогда, когда получатель может назвать конкретное действие и допустимое время реакции. Если после сообщения инженер лишь открывает график и наблюдает, это панель мониторинга, а не повод для вызова.

Google SRE в главе Monitoring Distributed Systems проводит полезную границу между симптомом и причиной. Симптом отвечает на вопрос «что сломалось для пользователя», причина помогает понять «почему». Для срочного вызова симптом обычно сильнее: рост доли неуспешных запросов уже говорит о нарушении сервиса, а загрузка CPU в 92 процента может быть нормальной работой или причиной, которая пока никому не мешает. Метрика ресурса все равно нужна, но часто ей место в диагностике или заявке рабочего времени.

Перед созданием правила заполните пять полей:

1. Наблюдаемый ущерб: какая функция сервиса нарушена.
2. Получатель: какая команда владеет исправлением.
3. Действие: что инженер проверит или изменит первым.
4. Срок: сколько можно ждать без роста ущерба.
5. Условие закрытия: когда инцидент действительно закончился.

Если одно поле остается пустым, не включайте отправку. Сначала исправьте владение, телеметрию или инструкцию. Особенно опасна формулировка «пусть дежурный посмотрит»: она превращает внимание инженера в фильтр, который должен был быть реализован в запросе.

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

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

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

Источник шума виден в истории состояний

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

Разделите шумные срабатывания по происхождению. Обычно встречаются четыре разных класса:

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

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

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

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

Еще один класс часто скрывается под словом «повтор»: новое уведомление после краткого закрытия. Для человека это тот же инцидент, но система видит новую последовательность состояний. Сопоставляйте сообщения не только по техническому идентификатору, но и по временному окну, сервису и принятому инциденту. Так станет видно, что проблема находится в условии восстановления, а не в частоте повторной доставки.

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

Порог выбирают по последствию и запасу времени

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

Для заполнения диска простое условие «использовано больше 80 процентов» плохо переносится между томами. На диске 100 ГБ остаток 20 ГБ может исчезнуть за минуты, на диске 20 ТБ тот же процент оставляет 4 ТБ. Сигнал по прогнозируемому времени до заполнения отвечает на операционный вопрос точнее. При этом внезапный скачок скорости записи требует отдельной защиты, потому что линейный прогноз опирается на недавнее поведение.

Для задержки и ошибок выбирайте окно, которое соответствует пользовательскому потоку. Среднее скрывает хвост распределения, а слишком узкий процентиль на малом трафике прыгает из-за нескольких запросов. Полезно требовать и плохое качество, и достаточный объем наблюдений. Иначе ночью одна ошибка из двух запросов создаст «50 процентов ошибок», хотя срочная реакция может ничего не изменить.

Статический порог остается хорошим выбором, когда существует жесткий предел: срок действия сертификата, запас адресов, длина очереди перед известным отказом, температура оборудования по спецификации. «Умный» динамический порог не должен переопределять физическую или договорную границу. Он помогает искать отклонение от сезонного поведения, но также обучается на плохих периодах и может принять постепенную деградацию за новую норму.

Для каждого правила запишите основание числа обычным текстом: «при этой скорости место закончится менее чем через четыре часа, а безопасное расширение занимает два». Если основание нельзя восстановить, число станет магическим и переживет изменение нагрузки, архитектуры и времени восстановления.

Для сервиса с SLO полезнее скорость расходования бюджета ошибок, чем один порог ошибок на все случаи. Короткое окно ловит быстрый пожар, длинное подтверждает, что расход устойчив. Одновременное нарушение двух окон уменьшает реакцию на случайный всплеск и сохраняет раннее обнаружение сильной аварии. Но такой сигнал имеет смысл только при определенном SLO и корректном учете успешных событий.

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

Ожидание и гистерезис убирают разные повторы

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

В Prometheus поле for требует, чтобы выражение оставалось истинным непрерывно до перехода из pending в firing. Поле keep_firing_for удерживает активное состояние некоторое время после исчезновения условия. В официальной документации Prometheus второе поле прямо предложено для уменьшения дрожания и ложных закрытий при пропаже данных.

Рабочее правило может выглядеть так:

groups:
- name: api-slo
  rules:
  - alert: ApiHighErrorRate
    expr: |
      (
        sum(rate(http_requests_total{status=~"5.."}[5m]))
        /
        sum(rate(http_requests_total[5m]))
      ) > 0.05
      and
      sum(rate(http_requests_total[5m])) > 1
    for: 10m
    keep_firing_for: 5m
    labels:
      severity: page
      service: api
      team: platform
    annotations:
      summary: "API returns more than 5% server errors"
      action: "Check recent deployment and upstream availability"

Здесь порог качества отделен от минимального трафика, десять минут защищают от короткого всплеска, а пять минут удержания не дают сообщению закрыться и снова открыться из-за одного хорошего измерения. Эти числа нельзя копировать вслепую. Период for должен быть короче доступного времени реакции, но длиннее обычного безопасного выброса.

Настоящий гистерезис требует разных условий входа и выхода, например открывать состояние при заполнении выше 85 процентов, а считать восстановление устойчивым только ниже 80. Не каждая система правил выражает это одним условием. Иногда проще записать состояние отдельной метрикой или использовать два порога в обработчике. Главное, чтобы закрытие означало запас, а не случайное касание границы.

Согласуйте for с частотой вычисления. При интервале одна минута ожидание в десять минут дает около десяти последовательных подтверждений, а при интервале пять минут всего два. Также проверьте, что происходит при перезапуске сервера правил и временной пропаже ряда: непрерывность состояния может сброситься, хотя пользовательская проблема никуда не исчезла.

Не ставьте длинный for на сигнал, который уже означает завершившийся необратимый ущерб. Потеря реплики еще может ждать подтверждения, если резервирование работает. Подтвержденная порча данных, истечение сертификата или недоступность единственного входа требуют другой логики. Защиту от ложных вызовов тогда переносят в качество самого измерения и независимое подтверждение, а не в ожидание.

Группировать надо по инциденту, а не по источнику

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

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

Конфигурация маршрута показывает сам принцип:

route:
  receiver: operations
  group_by: [cluster, service, alertname]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
  - matchers:
    - severity="page"
    receiver: oncall
    repeat_interval: 30m

group_wait дает связанным событиям короткое время собраться в первую доставку. group_interval определяет, как часто отправлять изменения внутри уже существующей группы. repeat_interval отвечает за напоминание, если состояние продолжается. Последнее нельзя ставить одинаково для всех классов: получасовое напоминание уместно для непрерывной критической аварии, но превращает рабочую заявку в спам.

Не группируйте только по team. Тогда независимые аварии разных сервисов сольются в одно сообщение, а закрытие части экземпляров будет трудно прочитать. Не включайте instance по умолчанию. Отдельный вызов на экземпляр оправдан лишь тогда, когда каждый экземпляр требует отдельного действия и команда способна выполнять их параллельно.

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

Дедупликация зависит от стабильности меток. Если аннотацию со значением метрики случайно превратили в метку, каждый расчет получает новый отпечаток и обходит дедупликацию. Зафиксируйте контракт меток в шаблоне правил и проверяйте изменения автоматически. Это дешевле, чем потом искать, почему одно условие создало сотни «уникальных» событий.

Подавление должно отражать зависимость

Когда известная первичная авария объясняет дочерние симптомы, отправляйте первичный сигнал и подавляйте последствия. Alertmanager называет это inhibition: целевое оповещение не доставляется, пока активно исходное с совпадающими метками из списка equal.

Если кластер недоступен, сообщения о каждом сервисе и узле редко добавляют действие. Правило подавления может оставить вызов ClusterUnreachable, скрыв InstanceDown в том же кластере:

inhibit_rules:
- source_matchers:
  - alertname="ClusterUnreachable"
  - severity="page"
  target_matchers:
  - alertname="InstanceDown"
  equal: [cluster]

Совпадение по cluster здесь защищает соседние кластеры от случайного подавления. Официальная конфигурация Alertmanager предупреждает о тонкости: отсутствующая метка и метка с пустым значением считаются равными. Поэтому поля из equal должны присутствовать и проверяться в обоих правилах. Иначе источник без метки может заглушить цели, которые вы не собирались связывать.

Подавление отличается от временной тишины. Тишина, или silence, задается оператором на период работ и совпадает по меткам. Inhibition постоянно кодирует зависимость между сигналами. Не используйте длинную тишину вместо исправления шумного правила: срок закончится, лавина вернется, а причина останется неизвестной.

Автоматическое подавление допустимо только при надежном первичном сигнале. Если ClusterUnreachable зависит от той же сломанной системы сбора, дочерние сообщения могут оказаться единственным свидетельством. Проверьте правило на архивном инциденте и на исчезновении источника данных, затем убедитесь, что подавленные события остаются видимыми в интерфейсе для диагностики.

Плановое окно обслуживания решает третью задачу. Оно временно меняет ожидаемое поведение известного объекта, но не доказывает зависимость сигналов. Делайте окно узким по сервису, кластеру и времени, назначайте автора и причину. Глобальное отключение канала на ночь скрывает соседние аварии и оставляет после работ неясное состояние.

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

Критичность определяет договор доставки

Метка критичности должна задавать срок реакции, канал и полномочия получателя, а не эмоциональную оценку автора правила. Слова critical, warning и info бесполезны, пока команда не договорилась, что происходит с каждым классом.

Практичная схема начинается с последствий:

• page: ущерб идет сейчас или наступит до следующего рабочего окна, требуется немедленное действие;
• ticket: запас времени позволяет назначить владельца и исправить в рабочие часы;
• info: событие сохраняется для поиска и анализа, человеку его не отправляют;
• security: отдельный маршрут по установленной процедуре, если доступ или данные могут быть затронуты.

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

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

У каждого класса должен быть предел повторов. Для page нужны подтверждение и эскалация, если владелец не отвечает. Для ticket достаточно одного открытия и обновлений при существенном изменении. info не должно незаметно попадать в почту: переполненная папка также приучает людей не читать системные сообщения.

Одинаковое правило может иметь разную критичность в разных средах, но различие надо объяснить. Отказ узла в тестовой среде обычно создает заявку, а отказ единственного узла производственного сервиса вызывает дежурного. Не кодируйте среду в названии правила. Используйте стабильную метку и явную политику маршрута, иначе копии постепенно разойдутся по логике.

Проверьте, может ли получатель выполнить действие. Служба поддержки способна зарегистрировать влияние пользователя, но не всегда имеет доступ к кластеру. Инженер платформы видит инфраструктуру, но не принимает решение об остановке финансовой операции. При сложной аварии один маршрут назначает руководителя инцидента, а остальные команды подключаются по процедуре, вместо того чтобы получать одинаковые независимые вызовы.

Пропавшие данные не равны нормальному состоянию

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

Grafana различает No Data, Error и пропажу отдельного ряда. No Data возникает, когда запрос выполнился, но не вернул ни одной точки. Error означает сбой или тайм-аут запроса. При пропаже ряда часть данных остается, поэтому общее правило может продолжить вычисляться и молчать о конкретном регионе или экземпляре.

Политику задают по смыслу метрики. Для периодической пакетной задачи отсутствие точек между запусками нормально. Для сердцебиения платежного шлюза оно само является симптомом. В Prometheus функция absent_over_time(metric[5m]) обнаруживает полное отсутствие ряда в окне, но не всегда сохраняет набор меток, нужный для указания исчезнувшего экземпляра. В динамической среде жесткий список экземпляров быстро устаревает.

Не направляйте каждый DatasourceError владельцу приложения. Ошибка общего источника данных может породить копию для каждого правила. Сгруппируйте такие события по идентификатору источника и отправьте команде мониторинга, а состояние пользовательского сервиса проверяйте независимым внешним сигналом. Режим «сохранить последнее состояние» полезен при коротком разрыве, но длительное молчание источника требует отдельного оповещения.

Мониторинг также нуждается в проверке доставки. Официальная практика Prometheus рекомендует сквозной тест пути, например периодический сигнал от источника через Prometheus и Alertmanager до получателя, вместо отдельных сообщений о каждом звене. Такой тест отвечает на главный вопрос: способен ли канал позвать человека сейчас.

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

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

Правила меняют через наблюдаемый эксперимент

Изменение порога считается завершенным только после проверки на исторических данных и ограниченного периода наблюдения. Сравните старое и новое выражение на одних интервалах: сколько реальных инцидентов каждое поймало, сколько раз вызвало действие, как быстро сработало и сколько создало отдельных доставок.

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

Для нового правила сначала включите вычисление без срочной доставки. Пусть оно пишет состояние в журнал или тестовый приемник. Проведите через него известный плохой интервал, обычный пик нагрузки, развертывание и пропажу данных. Затем включите рабочий маршрут и назначьте дату проверки. Это не бессрочный «теневой режим»: без даты правило может годами ничего не защищать.

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

Храните изменение правила рядом с причиной: идентификатор инцидента, ожидаемое уменьшение шума, риск пропуска и способ отката. Через квартал число 10m уже никто не вспомнит, а запись покажет, какой безопасный всплеск оно должно было отсеять. Если профиль нагрузки изменился, решение можно пересчитать, а не обсуждать заново по памяти.

Оценка после запуска должна отвечать на два вопроса. Снизилось ли число доставок на один инцидент, и сохранилось ли время обнаружения значимых аварий? Уменьшение шума при росте пропущенных событий не считается улучшением. Хорошая настройка сокращает ненужные прерывания, не покупая тишину за счет невидимого ущерба.

В инфраструктурных проектах GSE мы связываем схему мониторинга с реальными компонентами ЦОД, зонами ответственности и режимом поддержки, а не оставляем ее набором заводских порогов. Это особенно важно для смешанных сред, где один инцидент проходит через оборудование, платформу и прикладной сервис.

Оставьте в срочном канале только правила, для которых можно закончить фразу: «Если это сработало, дежурный до указанного срока делает вот это». Остальные сигналы не надо терять. Им надо назначить честное место: заявка, панель, журнал или условие, которое автоматика исправляет без человека.