Правила уведомлений

Правило уведомлений решает, когда Наблюдатель считает, что что-то случилось: сайт упал, контейнер завершился по нехватке памяти, диск сервера заполнен больше чем на 90 %, очередь задач растёт. Сработавшее правило пишет событие в ленту стека или сервера, а каналы уведомлений решают, отправить ли его в Telegram, MAX или на почту.

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

#Где найти правила

Откройте проект, нажмите «Управление» и перейдите на вкладку «Правила». Её видят владелец и участники с ролью «Редактор».

Правила сгруппированы по объектам: «Проверки сайтов», «Контейнеры и поды», «Серверы», «S3-хранилища», «Метрики приложения», «Сервисы (по трассам)», «События и логи». У каждого правила есть переключатель, кнопки «Редактировать» и «Удалить». Сверху — поиск по названию, условию и сервису и фильтры: включённые или выключенные, уровень. Объекты, для которых правил ещё нет, собраны в блоке «Ещё можно отслеживать».

#Какие правила уже есть в проекте

При создании проекта Наблюдатель заводит типовые правила. Названия в таблице — как в кабинете; переименовать правило можно через «Редактировать».

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

Позже правила появляются сами:

• «Источник метрик не отвечает» — когда в проекте появляется первый источник метрик приложения. Уровень «Ошибка», включено, окно 5 минут.
• Аномалия потока — когда приложение впервые присылает новый поток событий и логов. Правило ловит, что записей в потоке стало заметно больше или меньше обычного. Таких правил создаётся не больше 100 на проект.

Удалённое типовое правило само не возвращается — его можно создать заново через «Добавить правило».

Важно. В проектах, созданных до ноября 2026 года, выключенные пороги могли сохраниться включёнными. Проверьте переключатели на вкладке «Правила».

#События без правил

Часть событий записывается всегда, и правил для них нет. В каналы они уходят по уровню:

• сертификат сайта скоро истекает: за 14 дней — предупреждение, за 3 дня — ошибка; истёк — ошибка; обновлён — успех;
• устаревшая версия TLS и «HTTP больше не ведёт на HTTPS» — предупреждение; сменился IP-адрес сайта — инфо;
• новая ошибка приложения и её повтор после «решено» — ошибка;
• сбой агента и OOM на сервере — ошибка, перезагрузка сервера — предупреждение.

Пороги замедления сайта задаются не в правиле, а в самой проверке сайта.

#Как создать правило

1. На вкладке «Правила» нажмите «Добавить правило». Добавить правило в конкретную группу можно и кнопкой «+» в её заголовке.
2. Выберите «Объект»: проверки сайтов, контейнеры и поды, серверы, S3-хранилища, метрики приложения, сервисы по трассам или события и логи.
3. Выберите «Условие»:
   • «Смена состояния» — например, проверка перешла в «Недоступен» или контейнер стал «Нездоров»;
   • «Инцидент завершения» — контейнер завершился по OOM или с ошибкой;
   • «Порог по метрике» — значение выше или ниже порога;
   • «Аномалия (авто)» — значение заметно отличается от обычного, порог считается сам;
   • «Цель сервиса (SLO)» — для сервисов по трассам: сервис быстро выходит за свою цель по времени ответа и ошибкам;
   • «Источник не отвечает» — приложение перестало отдавать метрики.
4. Заполните параметры условия: «Метрика», «Агрегация», «Оператор», «Порог», «Окно, минут» или «Чувствительность».
5. При необходимости сузьте правило (см. ниже).
6. Выберите «Уровень в ленте»: «Ошибка», «Предупреждение», «Инфо» или «Успех». От уровня зависит, в какие каналы уйдёт уведомление.
7. Задайте «Название (необязательно)» — иначе оно соберётся из условия. В блоке «Предпросмотр» видно условие целиком.
8. Нажмите «Добавить».

Что можно отслеживать по порогу:

Для S3 есть готовые правила — их добавляет кнопка «Алерты» на вкладке «S3» стека. Подробнее — в статье про бекапы в S3.

#Как сузить правило до сервиса, контейнера или сервера

По умолчанию правило действует на все стеки и серверы проекта. Сузить можно так:

• Контейнеры и поды — поле «Сервис (workload)»: имя сервиса из compose или Kubernetes, например api. Поле «Инстанс» — один конкретный контейнер или под. Пусто — все сервисы.
• Серверы — поле «Сервер»: один сервер или «все серверы проекта». Правило действует только на серверы, подключённые к проекту на вкладке «Серверы».
• Сервисы (по трассам) — имя сервиса из трассировки. Пусто — все сервисы. Порог цели для отдельного сервиса меняется не в правиле, а на странице сервиса — см. аномалии и поиск причины.
• Метрики приложения — метрика, её «Метки» (например, только очередь emails) и «Источник».
• S3 — «Хранилище» и «Префикс».
• События и логи — «Поток».

Сузить правило до одного стека нельзя. Если стенды должны жить по разным правилам, разнесите их по разным проектам.

#Агрегация и окно: как не будить из-за всплеска

У порогового правила два параметра времени:

• «Окно, минут» — за какой период оценивается значение. 0 — по последнему значению, без окна. Окно не бывает короче двух интервалов сбора данных.
• «Агрегация» — как значение сводится за окно:
  • «в среднем за окно» — сглаживает всплески;
  • «максимум за окно» — превысило хоть раз;
  • «минимум за окно» — держалось за порогом всё окно, самый спокойный вариант;
  • «последнее значение»;
  • «прирост за окно» — только для счётчиков: «упало больше 10 задач за 15 минут».

Для метрик приложения есть флажок «Алерт и тогда, когда метрика не поступает»: пустое окно тоже считается срабатыванием.

Совет. Порог ставьте чуть выше обычного пика за неделю, окно — 5–15 минут, агрегацию — «минимум за окно» или «в среднем за окно». Тогда одиночный всплеск не разбудит вас ночью.

#Как подобрать порог по истории

Не ставьте порог наугад. Откройте график метрики за неделю и посмотрите на обычные пики:

• диск и память сервера — на странице сервера, вкладки «Диск» и «Память» (мониторинг серверов);
• CPU и память контейнера — на странице контейнера (мониторинг контейнеров);
• метрики приложения — на странице метрики: там же видны правила, пороги и срабатывания прямо на графике (метрики приложения).

Ещё проще поручить это ИИ-ассистенту: он посмотрит историю и предложит порог, при котором правило сработало бы за неделю только по делу.

#Повторы и восстановление

• Одно срабатывание — одно событие. Пока условие держится, повторных уведомлений нет. Напоминаний и эскалаций тоже нет.
• Восстановление. Когда условие уходит, пишется событие возврата. «Сайт снова доступен», «Контейнер восстановлен», «Под вышел из CrashLoopBackOff», «Источник метрик снова отвечает» и «Сервис снова в цели» приходят с уровнем «Успех». «Порог в норме», «Метрика вернулась к норме», «Аномалия устранена» и «Сервис вернулся к норме» — с уровнем «Инфо», и по умолчанию в каналы не уходят. Чтобы получать и их, включите уровень «Инфо» в канале.
• Сводки. Если следом за первым уведомлением в том же стеке случается ещё что-то, это приходит одним сообщением «Ещё события». Подробнее — в статье уведомления в Telegram, MAX и на почту.
• Частая аномалия — норма. Если одна и та же аномалия за сутки началась 5 раз, пятое уведомление предупредит, что дальше это считается обычным поведением, и следующие не придут, пока она не станет реже. Подробнее — в статье аномалии и поиск причины.

Тихих часов и расписаний у правил нет. Если ночью нужны только аварии, оставьте в ночном канале уровень «Ошибка».

#Как понять, что правило шумит

Каждое лишнее уведомление приучает команду игнорировать остальные. Признаки шума:

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

Что делать с шумным правилом: поднять порог, удлинить окно, сменить агрегацию на «минимум за окно» или понизить уровень до «Предупреждения» или «Инфо».

ИИ-ассистент видит, сколько раз каждое правило сработало за последние 7 дней и когда сработало в последний раз. Спросите его: «Какие правила шумят чаще всего? Подбери им пороги» — он найдёт шумные правила и предложит, что поменять.

#Чего правила не умеют

• Порог относительно другой метрики, например «пул занят на 90 % от максимума» или «доля упавших платежей больше 5 %». Порог задаётся только абсолютным значением одной метрики. Обход: пусть приложение само отдаёт долю отдельной метрикой.
• Расписания, тихие часы, повторные напоминания и эскалации.
• Сужение до одного стека.

#Настройка через ИИ-ассистента

Правила удобнее всего настраивать словами: «Предупреди, если диск на любом сервере заполнится больше чем на 90 %» или «Пиши в Telegram, когда сайт недоступен, а о замедлениях не надо». Ассистент знает каталог правил, подберёт пороги по истории, проверит, не дублирует ли новое правило включённое, и скажет, куда придёт уведомление. Подробнее — в статье ИИ-ассистент по MCP.

#Что дальше

• Уведомления в Telegram, MAX и на почту — куда отправлять сработавшие правила.
• Аномалии и поиск причины — правила без порога и причина сбоя в уведомлении.
• Метрики приложения — очереди, задачи и бизнес-показатели для своих правил.
• События и инциденты — где видны срабатывания правил.