Правила оповещений, которые не кричат «волки»

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

Обновлено 2026-08-26

Основная часть усталости от оповещений происходит из одной ошибки проектирования: срабатывания по мгновенному порогу. CPU коснулся 95% на одном отсчёте во время ночного бэкапа - и у кого-то звонит телефон. Правила в Servers Sentinel принимают длительность рядом с порогом, и одно это убирает большинство ложных срабатываний.

Из чего состоит правило

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

ПолеПримерПримечание
Метрикаcpu.usageЛюбая собираемая метрика, включая пользовательские через API
Оператор>>, >=, <, <=, ==
Порог90Проценты, байты или собственная единица метрики
Держится10mУсловие должно выполняться непрерывно столько времени
Важностьwarning / criticalОпределяет маршрутизацию по каналам и эскалацию
ОбластьГлобально или группа серверовПравило может охватывать весь парк или одну группу

Группировка инцидентов

Когда стойка теряет питание, сорок хостов перестают отвечать в течение нескольких секунд. Сорок оповещений не говорят ничего сверх того, что сказало бы одно. Связанные срабатывания сворачиваются в один инцидент со списком затронутых хостов, поэтому приходит сообщение *упал датацентр*, а не сорок раз *упал server-17*.

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

Подавление

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

Каналы

Сработавшее правило доставляется на почту, в Telegram, Slack или произвольный вебхук. Маршрутизация идёт по важности, поэтому предупреждение может уйти в командный чат, а критичное - ещё и разбудить дежурного. В теле вебхука есть идентификатор инцидента, по которому удобно связывать события в системе дежурств.

Health score

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

Score - это сводка, а не триггер. Оповещайте по конкретным условиям, а score используйте, чтобы решить, на какой хост смотреть первым.