Туториал: алерты для пайплайнов

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

Что такое правило алерта#

Правило наблюдает за запусками одного вида, фильтрует их по условиям и, когда запуск подходит, отправляет алерт в один или несколько каналов. Cooldown не даёт тому же правилу сработать повторно какое-то время, так что шаг, падающий в цикле, даёт одно сообщение, а не сотню. Правила живут на странице Alerts и бывают трёх видов:

Lambda function runs — вызовы функций, неважно, вызвали их напрямую, через шлюз или из пайплайна.
Pipeline step runs — каждый шаг пайплайна по мере выполнения, так что можно выбрать пайплайн по имени и реагировать на падение или слишком долгую работу любого его шага.
Human gate — срабатывает, когда запуск останавливается на шаге human-in-the-loop; так согласующие узнают, что нужно их решение.

Куда уходят алерты#

Slack: URL incoming-webhook канала. Сообщение показывает имя правила, пайплайн или функцию, статус и краткое описание.
Webhook: ваш публичный HTTPS-URL с POST или PUT, необязательными заголовками и выбором payload: сам объект алерта, JSON с приложенной трассой или произвольное тело с плейсхолдерами.
Function: вызывает одну из ваших функций с алертом в качестве события. Всё, что умеет функция — перезапустить, эскалировать, завести тикет, — становится реакцией.
Pipeline: запускает пайплайн с алертом на входе — для реакций в несколько шагов со своими согласованиями.

1. Создаём правило для пайплайна#

Откройте Observability → Alerts и нажмите New Alert Rule. Заполняйте сверху вниз:

Rule name: что-то, что коллега поймёт в Slack, например Nightly ETL failed. Enabled оставьте включённым.
Rule kind: Pipeline step runs.
Target pipelines: выберите пайплайн. Пустой список означает все пайплайны воркспейса — хорошее умолчание для правила «на всё».
Conditions: начните с Status equals FAILED. Другие полезные: Duration greater than с числом миллисекунд для зависающих шагов; Error message contains с фразой, чтобы отдельно маршрутизировать один класс ошибок; Repeated failure с количеством и окном, чтобы правило игнорировало единичный флаки-запуск и срабатывало на третьем падении за десять минут; Log pattern matches с регулярным выражением по логам шага.
Channels: добавьте Slack и вставьте URL incoming-webhook канала, куда должен прилетать алерт. Добавьте второй канал, если хотите, чтобы вебхук или функция тоже реагировали.
Cooldown: сколько миллисекунд правило молчит после срабатывания. Пять минут (300000) — разумный старт для правила о падениях.

Сохраните правило. Оно начинает следить за следующим запуском сразу; ничего передеплоивать не нужно.

2. Заставляем сработать#

Самая честная проверка — настоящее падение. Откройте пайплайн, нажмите Run (manual) и передайте payload, от которого один шаг бросит ошибку, например без обязательного поля. Запуск краснеет, и через несколько секунд в Slack-канал приходит сообщение с именем правила, пайплайном, статусом шага и кратким описанием ошибки. Запустите ещё раз внутри cooldown: второго сообщения нет, как и задумано.

Всё, что сработало, лежит на странице Alerts в виде истории: правило, запуск, из которого пришёл алерт, серьёзность и каналы, куда он ушёл. Id запуска ведёт на выполнение с его логами, так что путь от сообщения в Slack до упавшей строки — два клика.

3. Payload вебхука#

Канал webhook отправляет запись алерта как JSON. С шаблоном default тело — сам алерт; шаблон json добавляет объект trace с id запуска, именем функции, статусом и ошибкой. Его форма:

webhook bodyjson

{
  "id": "…",
  "ruleId": "…",
  "ruleName": "Nightly ETL failed",
  "runId": "…",
  "functionId": "…",
  "functionName": "load-warehouse",
  "type": "status",
  "conditionTypes": ["status"],
  "severity": "error",
  "message": "…what matched, in words…",
  "details": { "…": "…" },
  "triggeredAt": "2026-09-05T02:00:03.000Z",
  "channels": ["webhook"]
}

Шаблон custom позволяет написать тело самому с плейсхолдерами вроде {{alert.ruleName}}, {{alert.message}} и {{trace.status}} — так подгоняют формат под то, что уже ожидает инцидент-система или чат-бот. Для аутентификации добавьте заголовки. URL должен быть публичным HTTPS; приватные адреса отклоняются.

4. Автоматизируем реакцию#

Уведомление — это начало. Канал Function вызывает одну из ваших функций с алертом в качестве события: упавший импорт может перезапустить себя с батчем поменьше, а зависший шаг — отмениться и встать в очередь заново. Канал Pipeline запускает из алерта целый пайплайн — правильная форма, когда реакции нужны несколько шагов, собственные ретраи или решение человека перед чем-то разрушительным.

5. Алерты, когда запуск ждёт человека#

Пайплайн с шагом human-in-the-loop стоит, пока кто-то не одобрит, не отклонит или не ответит. Никто не смотрит в инбокс весь день, поэтому создайте второе правило вида Human gate, при желании сузив его до типа гейта, и отправьте его в Slack-канал согласующих. Сообщение несёт запуск и ссылку на инбокс, а запуск продолжается в момент их действия. Как работают гейты и как их собирать — тема следующего туториала.

Хорошие привычки#

Подбирайте cooldown под пайплайн. Расписанию, которое запускается каждую минуту, нужен cooldown длиннее, чем ночной задаче, иначе один сломанный деплой превращается в стену сообщений.
Маршрутизируйте по серьёзности. Алерты несут severity от info до critical. Предупреждения направляйте в вебхук, который только логирует, а critical — в канал, который люди действительно читают.
Одно правило «на всё», немного узких. Правило о падениях на весь воркспейс с щедрым cooldown ловит всё; узкие правила с условием по тексту ошибки добавляйте для случаев, которым нужна другая реакция.
Выключайте, а не удаляйте. Переключатель Enabled глушит правило на время миграции или известного сбоя и сохраняет его историю и настройки до возвращения.