Максим Дорохов 
Ложные срабатывания мониторинга: зачем нужны гистерезис и задержка уведомлений
Мониторинг прислал «сайт упал», через тридцать секунд — «сайт восстановлен». И так три раза за час. Через неделю такой практики уведомления начинают игнорировать все, включая тот единственный раз, когда падение было настоящим. Разбираем, какими настройками это лечится.
Откуда берётся «дребезг»
Сеть между мониторингом и сайтом не идеальна: единичный таймаут, кратковременная перегрузка сервера в момент проверки, временная сетевая помеха на конкретном маршруте — всё это может дать один неудачный опрос без реального инцидента на стороне сайта. Если система реагирует на каждый такой одиночный сбой как на полноценное падение, получается «дребезг»: инцидент открывается и тут же закрывается, снова и снова.
Гистерезис: два разных порога вместо одного
Первый защитный механизм — не один порог «недоступности», а два независимых: один процент неудачных проверок, после которого инцидент открывается, и другой, более мягкий, процент восстановления, после которого инцидент закрывается. Из-за этого разрыва между порогами система не мечется туда-обратно на каждом пограничном значении — чтобы закрыть инцидент, нужно устойчивое улучшение, а не одна случайно удавшаяся проверка сразу после серии неудачных.
Это тот же принцип, что в термостате: если бы отопление включалось и выключалось ровно по одной температуре, оно бы щёлкало непрерывно на границе. Зазор между порогом включения и порогом выключения — и есть гистерезис.
Задержка уведомлений: пауза перед тем, как беспокоить человека
Второй механизм работает на следующем уровне — уже после того, как инцидент технически зафиксирован. Уведомление уходит не мгновенно, а с настраиваемой паузой: если за это время сайт успевает восстановиться сам, человека вообще не тревожат. Задержка не влияет на то, что инцидент был зафиксирован во внутренней истории, — она влияет только на то, когда об этом узнает конкретный получатель.
Слишком короткая задержка возвращает тот самый шум, от которого она должна защищать. Слишком длинная — превращается в задержку реакции на реальный инцидент, что для страницы оплаты может стоить продаж. Разумный ориентир — короткая задержка для критичных страниц (оформление заказа, вход в личный кабинет) и более длинная для второстепенных (блог, статичные информационные страницы).
Третий уровень — подтверждение из нескольких точек
Помимо гистерезиса и задержки, есть ещё один встроенный фильтр шума: недоступность засчитывается, когда её подтверждают сразу несколько независимых точек мониторинга, а не одна случайная. Это защищает от ситуации, когда локальная сетевая проблема у одной точки наблюдения выглядит как падение всего сайта, хотя на деле не связана с самим сайтом вовсе.
Условный пример на реальном числе точек Пруфена — 13. Конкретные процентные пороги вы задаёте сами в настройках, ниже просто для наглядности принципа, а не как готовые дефолтные значения:
| Точек сообщают о недоступности | Что происходит |
|---|---|
| 1 из 13 (≈8%) | Инцидент не открывается — похоже на локальный сетевой сбой одной точки |
| 5 из 13 (≈38%) | Ещё не открывается, если порог задан выше — недостаточно подтверждений |
| 8 из 13 (≈62%) | Порог открытия достигнут (в примере) — инцидент фиксируется |
| 12 из 13 (≈92%) | Порог закрытия достигнут (в примере) — инцидент закрывается |
Пример на цифрах: как задержка гасит одиночный сбой
Проверка идёт каждые 2 минуты. В 10:02 один опрос не проходит, в 10:04 сайт снова отвечает штатно — классический одиночный блип без реального инцидента:
| Время | Результат проверки | Без задержки | С задержкой 5 минут |
|---|---|---|---|
| 10:00 | Доступен | — | — |
| 10:02 | Недоступен | Уведомление о падении уходит сразу | Пауза перед отправкой — уведомление ещё не ушло |
| 10:04 | Доступен | Уведомление «восстановлено» уходит следом | Сайт поднялся до истечения паузы — уведомление о падении так и не отправлено |
| Итог | — | 2 уведомления, оба про инцидент, которого фактически не было | 0 уведомлений, шум погашен полностью |
Задержка настраивается слайдером от 0 до 30 минут, по умолчанию — 5. Разумная отправная точка для разных типов страниц:
| Тип страницы | Ориентир по задержке | Почему |
|---|---|---|
| Оформление заказа, оплата | 0–2 минуты | Цена минуты простоя высока — лучше лишнее уведомление, чем пропущенный инцидент |
| Вход в личный кабинет | 2–5 минут | Критично, но чуть менее срочно — значение по умолчанию (5 минут) обычно подходит |
| Блог, статичные страницы | 10–30 минут | Кратковременные сбои некритичны — длинная пауза гасит почти весь шум |
В Пруфене оба уровня настраиваются отдельно: пороги открытия и закрытия инцидента задаются независимо друг от друга, а задержка уведомлений регулируется слайдером по умолчанию на 5 минут — можно выставить своё значение под критичность конкретной проверки.
Частые вопросы
Задержка уведомлений замедляет обнаружение проблемы? Нет — она откладывает именно уведомление конкретному человеку, а не сам факт фиксации инцидента внутри системы. Разница важная: история и статус видны сразу, а тревожат вас — с паузой.
С чего начать, если ещё не настраивали пороги? Значения по умолчанию — разумная стартовая точка для большинства сайтов. Смысл их менять появляется, когда вы уже видите конкретную проблему: слишком много шумных инцидентов или, наоборот, слишком долгую тишину при реальном сбое.
Нужно ли одинаково настраивать все проверки? Нет — страница оплаты и второстепенная статья блога заслуживают разных настроек: там, где цена ошибки выше, задержку и пороги стоит делать более чувствительными.
Может ли дребезг быть признаком реальной проблемы? Иногда да — постоянные короткие сбои на грани порога могут говорить о нестабильности сервера под нагрузкой, а не только о шуме мониторинга. Стоит проверить логи сервера, если дребезг не прекращается после настройки порогов.