Оповещения по метрикам

Правило оповещения по метрике следит за агрегатом метрики (avg/max/p95 и т. п.) на скользящем окне времени и открывает инцидент, когда значение пробивает заданный порог. Открытие и закрытие инцидента каждое шлёт ровно одно уведомление в каналы доставки проекта — те же email/webhook/Telegram, что и у алертов по проблемам (см. Оповещения).

Где находится

Значок графика в левой рельсе → «Метрики» → в под-меню раздела «Оповещения по метрикам» (или напрямую /projects/{id}/metrics/alerts). Управлять правилами могут владелец и администратор проекта.

Создание правила

Кнопка «Новое правило» открывает форму:

ПолеЧто указать
МетрикаТочное имя метрики, как оно приходит по OTLP (например, http.server.duration) — регистр и написание должны совпадать буква в букву
Агрегацияavg, max, min, sum, p50, p95, p99
Условие> (больше) или < (меньше)
ПорогЧисло, с которым сравнивается агрегат. Должно быть конечным — NaN/Infinity отклоняются с ошибкой «порог должен быть конечным числом»
Окно (с)Ширина скользящего окна в секундах, положительное целое (например, 300 — 5 минут)
ОкружениеНеобязательно; точное совпадение. Пусто = любое окружение
Ключ лейбла / Значение лейблаНеобязательный доп. фильтр по одному лейблу метрики (точное совпадение); заполнять либо оба поля, либо ни одного

Доступные агрегации

АгрегацияСмысл
avgСреднее значение за окно
maxМаксимум за окно
minМинимум за окно
sumСумма значений за окно
p50 / p95 / p99Перцентиль (только для метрик типа histogram; для остальных типов агрегация не сработает содержательно)

Условия

УсловиеСимволПробитиеВосстановление (закрытие инцидента)
gt>текущее значение > порогатекущее значение порога × 0.95
lt<текущее значение < порогатекущее значение порога × 1.05

Восстановление намеренно требует отойти от порога на 5% в безопасную сторону (гистерезис) — иначе значение, колеблющееся ровно на границе, открывало и закрывало бы инцидент на каждой проверке.

Как это оценивается

Фоновый оценщик проходит по всем включённым правилам раз в минуту. На каждом проходе для правила берётся агрегат метрики за окно [сейчас − окно, сейчас) — тем же запросом, что рисует график на детальной странице метрики. Если данных за окно нет вовсе — решение не принимается (инцидент не открывается и не закрывается, ждём следующего прохода).

Дальше:

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

На один rule одновременно может быть только один открытый инцидент.

Инциденты

Ниже таблицы правил на той же странице — список инцидентов проекта (до 100 последних): статус (Открыт / Решён), пиковое и текущее значение агрегата, время начала. Пустое состояние подсказывает, что инцидент появится здесь, как только метрика пробьёт порог правила.

Уведомления и каналы

Уведомления об открытии/закрытии инцидента ставятся в очередь на все включённые каналы доставки проекта — те же, что настроены в Оповещениях (email/webhook/Telegram), отдельных каналов для метрик заводить не нужно. Email пропускается с предупреждением в логе, если SMTP не настроен (см. Конфигурацию). Для внешних каналов (webhook/Telegram) действует та же настройка приватности GOTCHA_EXTERNAL_CHANNEL_DETAILS, что и для алертов по проблемам: при выключенной — наружу уходит только ссылка на страницу правил и вид события, без имени метрики и значений.

Порог на графике

Если на детальной странице метрики (/projects/{id}/metrics/{name}) выбрана та же агрегация, что и в правиле, и правило включено, — его порог рисуется горизонтальной пунктирной линией с подписью условия (например, p95 > 500). Подробнее о самом графике — в Метриках.

Пример: алерт по p95 latency > 500 мс за 5 минут

Допустим, приложение шлёт histogram-метрику http.server.duration (юнит ms) — см. Метрики, как её отправить по OTLP.

  1. Откройте /projects/{id}/metrics/http.server.duration, чтобы убедиться, что точки приходят, и свериться с точным именем/юнитом метрики.
  2. Перейдите в «Метрики → Оповещения по метрикам» и нажмите «Новое правило».
  3. Заполните форму:
    • Метрика: http.server.duration
    • Агрегация: p95
    • Условие: >
    • Порог: 500
    • Окно (с): 300 (это и есть 5 минут)
    • Окружение: production (необязательно, но полезно — иначе окно смешает прод и локальную разработку)
    • Ключ/значение лейбла — оставить пустыми
  4. Нажмите «Создать правило». В таблице появится строка http.server.duration | p95 > 500 | 300s | production | Включено.
  5. Как только p95 за последние 5 минут превысит 500 (в тех же единицах, что несёт метрика — Gotcha не конвертирует юниты), откроется инцидент, и уведомление уйдёт во включённые каналы проекта. На графике метрики с агрегацией p95 появится пунктирная линия на отметке 500.
  6. Когда p95 опустится ниже 475 (500 × 0.95), инцидент закроется, и придёт второе уведомление — «решено».

Удаление правила

Кнопка «Удалить» в строке таблицы правил удаляет его сразу (без отдельного подтверждения). Открытые/прошлые инциденты правила из истории не пропадают.

Смотрите также

  • Метрики — что такое метрика, как её отправлять, детальный график.
  • Оповещения — каналы доставки, алерты по проблемам, лог неудачных доставок.