Alerts

​

Основные понятия

• Alert — правило. Оно указывает что проверять (триггер), как часто (интервал оценки), когда считать неисправным (составная логика), насколько срочно (серьезность) и кого/куда уведомлять (каналы).
• Incident — что происходит, когда alert срабатывает. Один alert имеет максимум один открытый инцидент одновременно. Повторные нарушения обновляют доказательства того же инцидента. Инциденты разрешаются оператором; автоматическое разрешение при прекращении действия правила планируется, но не включено в настоящее время.
• Channel — место отправки уведомления: email, Slack, generic webhook или внутри панели. Каждый alert может использовать любую комбинацию.

​

Типы триггеров

​

1. metric_threshold

{
  "metric": "p95_latency_ms",
  "filter": { "environment": "production" },
  "window_secs": 900,
  "op": ">",
  "value": 5000
}

​

2. custom_sql

• rows mode (без op/value): alert срабатывает, как только запрос вернет как минимум одну строку.
• value mode: запрос должен давать одному столбцу псевдоним metric_value; диспетчер сравнивает metric_value первой строки с value, используя op.

{
  "sql": "SELECT count() AS metric_value FROM agenteye.events WHERE event_type = 'error' AND ts >= now() - INTERVAL 1 HOUR",
  "op": ">",
  "value": 100
}

​

3. evaluation_score

{
  "score_key": "hallucination",
  "op": ">",
  "value": 0.6,
  "window_secs": 3600,
  "min_count": 5,
  "environment": "production"
}

​

4. eval_compound

{
  "combinator": { "at_least": 2 },
  "conditions": [
    { "score_key": "hallucination", "op": ">", "value": 0.8 },
    { "score_key": "helpfulness",   "op": "<", "value": 0.6 },
    { "score_key": "tone",          "op": "<", "value": 0.5 }
  ],
  "window_secs": 3600,
  "min_count": 5,
  "environment": "production"
}

• combinator: "any", "all", или { "at_least": N }.
• conditions[]: каждый { score_key, op, value }, используя те же операторы, что и другие триггеры (>, >=, <, <=, ==).
• window_secs: общий lookback, применяемый к каждому условию (по умолчанию 3600).
• min_count: минимальное количество оценок на условие перед тем, как это условие может быть нарушено; условие с слишком малым количеством выборок в окне считается нарушенным (по умолчанию 1).
• environment: необязательно; ограничивает каждое условие одной средой.

​

5. per_event

{
  "event_type": "error",
  "lookback_secs": 60,
  "environment": "production",
  "tool_name": "bash",
  "agent_id": "caa",
  "error_type": "TimeoutError",
  "message_contains": "vertex-ai timed out"
}

​

Составная логика (M из N)

• eval_window: количество последних оценок, на которые смотреть (по умолчанию 1)
• min_breaches: сколько из них должны быть нарушены перед срабатыванием alert (по умолчанию 1)

​

Интервал оценки

​

Каналы

​

Email

1. Переопределение recipients[] для каждого канала (когда не пусто).
2. Параметр alerts.email_default_recipients (массив строк email).

​

Slack

• URL по умолчанию: alerts.slack_default_webhook (установлено в /settings).
• Переопределение для каждого alert: установите webhook_setting_key канала на любой другой ключ параметра типа URL, например, alerts.slack_oncall, alerts.slack_costs.

​

Generic webhook

{
  "schema_version": 1,
  "event": "alert.firing",
  "incident": { "id": "uuid", "url": "https://…/incidents/uuid", "opened_at": "2026-…" },
  "alert":    { "id": "uuid", "name": "errors > 50/hr", "severity": "critical" },
  "breach":   { "value": 73.0, "summary": "ErrorCount > 50 (observed 73.000)", "evidence": { … } }
}

​

Внутри панели

​

Жизненный цикл инцидента

firing  ──ack──▶  acknowledged
   │                    │
   └────────────────────┴───── operator resolve ───▶  resolved

• firing — диспетчер только что открыл инцидент или обнаружил другое нарушение. Уведомление о срабатывании разветвляется ровно один раз (контролируется временной меткой notified_firing_at инцидента).
• acknowledged — оператор нажал ack на /incidents/:id. Инцидент по-прежнему считается открытым; последующие нарушения обновят его доказательства без повторного уведомления.
• resolved — оператор нажал resolve. Автоматическое разрешение при прекращении нарушения правила планируется, но в настоящее время не включено, поэтому открытый инцидент остается открытым, пока оператор его не разрешит.

​

Требуемые разрешения

• alerts:read: просмотр alert-правил.
• alerts:write: создание, редактирование, удаление alert-правил и активирование тестового уведомления.
• incidents:read: просмотр инцидентов.
• incidents:write: открытие ручных (ad-hoc) инцидентов, не связанных с alert.
• incidents:ack: подтверждение, назначение, комментирование и разрешение инцидентов.

Устаревший alerts:ack. Ключи и операторы, которым было предоставлено более старое разрешение alerts:ack, продолжают работать: оно принимается как incidents:ack (и подразумевает incidents:read), поэтому существующие дежурные операторы сохраняют свой доступ без переизданий учетных данных. Выпускайте новые разрешения с семейством incidents:*.

Средство выбора получателя Email. Средство выбора получателей редактора alert отображает членов вашей организации, так что вы можете выбрать их по имени. Он загружается для любого оператора, имеющего alerts:read или alerts:write; просмотр каталога вашей команды для этой цели не требует users:read, и средство выбора возвращает только адреса email членов, никогда полные записи пользователей.

​

Конфигурация

• alerts.email_default_recipients (email_list): JSON-массив строк email — получатели по умолчанию для email-каналов.
• alerts.slack_default_webhook (url): URL Slack incoming-webhook по умолчанию.
• alerts.webhook_default_url (url): URL generic-webhook по умолчанию.
• alerts.webhook_signing_secret (secret): ключ HMAC-SHA256. Всегда возвращается как "" в ответе GET; введите новое значение для ротации.
• alerts.enabled_channels (channel_set): набор внешних типов каналов для организации, которые отправляются при срабатывании alert; по умолчанию все три (email, slack, webhook). Удаление типа здесь глобально подавляет этот канал для каждого alert без редактирования каждого правила. Канал внутри панели всегда доставляется и не затрагивается этим параметром.

​

Проверка нового alert

1. Сохраните его как включенный с как минимум одним каналом уведомления.
2. Выберите test на странице деталей alert и подтвердите, что каждое настроенное место назначения получает синтетическое уведомление.
3. После первого реального нарушения подтвердите, что инцидент появляется под Incidents и его измеренное значение соответствует соответствующему запросу панели.

​

Устранение неполадок