Руководство пользователя Event Orchestration#

Event Orchestration позволяет IncidentRelay принять последовательность решений о входящем событии мониторинга до завершения его обработки обычным жизненным циклом алерта.

Система мониторинга обычно передаёт факты, например:

• что вышло из строя;
• какой хост или сервис затронут;
• насколько серьёзно событие;
• находится событие в состоянии firing или resolved;
• метки и данные payload, специфичные для интеграции.

На основе этих фактов Event Orchestration может решить:

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

Для создания распространённых правил не нужно быть программистом. Builder на странице Event Orchestration предоставляет элементы управления условиями и действиями. Для сложных определений и рабочих процессов под управлением API также доступно представление JSON.

Когда полезен Event Orchestration#

Используйте Event Orchestration, когда одно или несколько решений нужно принимать на основе содержимого события, а не одной фиксированной конфигурации маршрута.

Типичные случаи:

Event Orchestration не заменяет хранилище алертов IncidentRelay, инциденты, выполнение эскалаций, уведомления, корреляцию или расчёт влияния. Он подготавливает событие и выбирает, как существующий жизненный цикл должен его обработать.

Когда его не стоит использовать#

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

Сохраняйте существующую конфигурацию, если:

• все события одного входящего маршрута всегда принадлежат одной команде и сервису;
• достаточно общей для сервиса политики эскалации по умолчанию;
• обычное подавление или окно обслуживания уже описывает временное рабочее условие;
• изменение относится к личным настройкам уведомлений, а не к обработке событий;
• требуется выполнение произвольного shell-кода, Python, SSH или контейнеров. Такие действия намеренно не поддерживаются.

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

Где найти#

• Войдите в IncidentRelay.
• Выберите нужную группу с помощью глобального переключателя групп.
• Откройте Event Orchestration в меню навигации.
• В списке показаны оркестрации выбранной группы.

Сводные карточки показывают:

• общее количество определений оркестрации;
• активные оркестрации;
• оркестрации в теневом режиме;
• определения с неопубликованным черновиком.

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

Разрешения#

Доступ вычисляется внутри выбранной группы IncidentRelay.

Редактор группы может публиковать изменения, но удалить оркестрацию или управлять переиспользуемыми webhook-действиями может только глобальный администратор.

История версий при необходимости сохраняет трёх разных авторов:

• Created by — кто создал строку версии;
• Changed by — кто последним изменил определение черновика;
• Published by — кто опубликовал неизменяемую версию.

Так можно отличить человека, изменившего правило, от человека, который его проверил и опубликовал.

Основные термины#

Место оркестрации в потоке алерта#

Упрощённый поток:

КопироватьВходящий payload интеграции
        ↓
Аутентификация и нормализация интеграции
        ↓
Глобальная оркестрация группы
        ↓
Оркестрация выбранного сервиса, когда сервис известен
        ↓
Существующий жизненный цикл IncidentRelay
        ↓
Группа алертов, дочерний алерт, эскалация и уведомления

Глобальная оркестрация может выбрать сервис. Затем IncidentRelay вычисляет оркестрацию, привязанную к этому сервису. Оркестрация сервиса также может выбрать другой сервис; передача между сервисами защищена от циклов и слишком длинных цепочек.

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

Пример:

КопироватьПравило 1 задаёт labels.environment = production
        ↓
Правило 2 проверяет labels.environment
        ↓
Теперь правило 2 видит production

Поэтому порядок имеет значение.

Область действия: глобальная или сервис#

Глобальная область действия#

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

Используйте её для:

• выбора команды, маршрута или сервиса;
• нормализации серьёзности и меток разных интеграций;
• применения общих для группы правил suppress или drop;
• установки общих правил группировки;
• распределения событий из одной общей точки интеграции.

Пример:

КопироватьЕСЛИ labels.application равно billing
ТО выбрать сервис Billing API

Область действия сервиса#

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

Используйте её для:

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

Пример:

КопироватьДля сервиса Database:
ЕСЛИ labels.operation равно backup
И event.severity равно warning
ТО подавить уведомления

Выбор области действия#

Придерживайтесь простого правила:

• выбирайте global, когда правило помогает определить владельца или применяется к нескольким сервисам;
• выбирайте service, когда владелец уже известен, а поведение специфично для одного сервиса.

Режим выполнения#

Режим выполнения определяет, влияет ли опубликованное определение на реальные события.

Перед выбором shadow или active необходимо опубликовать версию.

Рекомендуемая последовательность:

Копироватьdisabled → публикация → shadow → проверка выполнений → active

Режим совместимости#

Режим совместимости определяет, как Event Orchestration работает с существующими маршрутами, сопоставлением сервисов и политиками.

legacy#

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

Оркестрация с настройкой active + legacy не применяется к production-событиям. Используйте симуляцию или переключитесь на hybrid, когда будете готовы применять решения.

hybrid#

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

Примеры:

КопироватьОркестрация явно задаёт приоритет P1
→ существующая политика приоритетов не заменяет это явное значение

Оркестрация не выбирает политику уведомлений
→ обычный выбор политики уведомлений продолжается

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

Это рекомендуемый режим для большинства первых production-внедрений.

orchestration#

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

Используйте этот режим только после проверки результатов в теневом и гибридном режимах.

Безопасный первый запуск#

Для первого правила соблюдайте такую последовательность:

• Создайте оркестрацию с режимом выполнения disabled.
• Используйте режим совместимости hybrid.
• Добавьте одно узконаправленное правило.
• Сохраните черновик.
• Проверьте его.
• Выполните симуляцию как совпадающего, так и несовпадающего события.
• Опубликуйте версию.
• Переключите режим выполнения на shadow.
• Проверьте реальные трассировки выполнений и теневые метрики.
• Переключайте режим выполнения на active, только когда наблюдаемые решения верны.
• Во время первого запуска сохраняйте существующие маршруты и политики.
• Если опубликованное изменение неверно, используйте откат.

Обзор страницы и вкладок#

Откройте оркестрацию, чтобы увидеть её рабочую область.

Rules#

Создавайте и упорядочивайте условия и действия. Карточка правила содержит сводку:

• WHEN — условие;
• THEN — настроенные действия;
• AFTER — что произойдёт после совпадения.

Правила можно перемещать вверх и вниз, редактировать, дублировать и удалять.

Simulator#

Проверяйте черновик без создания алертов и отправки webhook-действий. Можно напрямую проверить нормализованное событие или передать необработанный payload через нормализатор поддерживаемой интеграции.

Versions#

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

Executions#

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

Webhook Actions#

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

Settings#

Позволяет изменить имя, описание, область действия и сервис. Настройки выполнения определяют режим работы и режим совместимости.

Создание первой оркестрации#

В этом примере критические production-алерты направляются выбранной команде и сервису и помечаются как P1.

1. Создайте определение#

Нажмите New orchestration и заполните:

Новая оркестрация изначально отключена и содержит начальный черновик.

2. Добавьте правило#

Откройте Rules и нажмите Add rule.

Используйте:

stop прекращает вычисление последующих правил этой оркестрации. Он не отбрасывает событие и не останавливает обычный жизненный цикл алерта.

3. Добавьте условия#

Оставьте корневую группу ALL и добавьте два условия:

Для in и not_in введите JSON-массив. Builder может принять значение через запятую, но JSON-массив понятнее и исключает неоднозначность.

Условие означает:

Копироватьenvironment должно быть production
И
severity должно быть critical или fatal

4. Добавьте действия#

Добавьте следующие действия:

• set_team — выберите нужную команду.
• set_service — выберите нужный сервис.
• set_priority — введите P1.
• set_label — имя orchestrated, значение true.

Сохраните правило, затем нажмите Save draft.

5. Выполните проверку#

Нажмите Validate.

Среди прочего проверяются:

• структура условий и операторы;
• синтаксис ссылок на поля;
• безопасность регулярных выражений;
• параметры действий;
• ссылки на выбранные маршрут, команду, сервис и политики;
• шаблоны;
• опасные catch-all-правила с drop.

Исправьте все ошибки перед публикацией. Предупреждения тоже следует рассмотреть, даже если технически черновик допустим.

6. Выполните симуляцию совпадающего события#

Откройте Simulator, выберите Normalized event и используйте:

Копировать{
  "source": "webhook",
  "title": "Checkout API unavailable",
  "message": "Health check failed for checkout-api-2",
  "severity": "critical",
  "status": "firing",
  "dedup_key": "checkout-api-2:unavailable",
  "labels": {
    "environment": "production",
    "service": "checkout-api",
    "instance": "checkout-api-2"
  }
}

Нажмите Run simulation.

Убедитесь, что:

• правило совпало;
• выбраны правильные идентификаторы команды и сервиса;
• приоритет стал P1;
• добавлена метка orchestrated=true;
• итоговый disposition — process, а не suppress, pause или drop;
• не совпало никакое неожиданное правило.

7. Выполните симуляцию несовпадающего события#

Измените environment на staging и повторите симуляцию. Правило не должно совпасть, а событие не должно быть изменено этим правилом.

Проверять несовпадения так же важно, как совпадения.

8. Опубликуйте и включите теневой режим#

Нажмите Publish. При публикации создаётся неизменяемая версия.

Откройте Settings и переключите режим выполнения на shadow. Оставьте режим совместимости hybrid.

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

Условия#

Условие решает, следует ли выполнять действия одного правила.

Листовое условие состоит из трёх частей:

Копироватьполе + оператор + ожидаемое значение

Пример:

Копироватьlabels.environment equals production

Ссылки на поля#

Поля используют безопасные пути с точками. IncidentRelay читает только JSON-объекты и индексы массивов; он не может выполнять методы или произвольные выражения.

Простое поле без корня, например severity, нормализуется в event.severity, однако явные корни проще понимать и сопровождать.

Распространённые нормализованные поля:

Копироватьevent.source
event.title
event.message
event.description
event.severity
event.status
event.dedup_key
event.group_key
labels.alertname
labels.environment
labels.service
labels.instance
labels.job

Точный набор меток зависит от входящей интеграции.

Операторы#

Числовые сравнения принимают конечные числа и строки с числами. Логические операторы распознают логические значения, 0/1 и распространённые строки: true, false, yes, no, on и off.

Группы AND, OR и NOT#

Builder предоставляет три типа логических групп:

• ALL — должны совпасть все дочерние элементы; логика AND;
• ANY — должен совпасть хотя бы один дочерний элемент; логика OR;
• NONE — не должен совпасть ни один дочерний элемент; логика NOT.

Пример:

КопироватьALL
├── labels.environment equals production
└── ANY
    ├── event.severity equals critical
    └── labels.priority equals p1

Это означает:

Копироватьproduction AND (critical OR p1)

Пример NONE:

КопироватьALL
├── labels.environment equals production
└── NONE
    ├── labels.namespace starts_with dev-
    └── labels.namespace starts_with test-

Такое условие совпадает с production-событиями, namespace которых не относится ни к разработке, ни к тестированию.

Catch-all-правила#

Правило с пустым условием совпадает с каждым достигшим его событием.

Catch-all-правила полезны в конце определения для значений по умолчанию, например:

КопироватьЕсли ни одно предыдущее правило не остановило обработку,
добавить метку orchestration_result=default

Они опасны в сочетании с drop, suppress, pause или обязательной маршрутизацией. Для публикации catch-all-правила с drop требуется явное подтверждение.

Рекомендации по регулярным выражениям#

Используйте regex, только если требование нельзя выразить равенством, префиксом, суффиксом или принадлежностью.

Хорошо:

Копировать^rabbitmq(-[a-z0-9-]+)?$

Избегайте широких выражений вроде:

Копировать.*

Широкое регулярное выражение часто скрывает catch-all-правило и усложняет проверку. IncidentRelay проверяет безопасность regex и ограничивает размер обрабатываемого ввода, но точное выражение всё равно проще эксплуатировать.

Действия#

Действия выполняются в порядке отображения внутри совпавшего правила. Раннее действие может предоставить данные последующему.

Изменение полей события#

set_trace_level управляет объёмом Alert Explain Trace до того, как alert lifecycle начнёт записывать trace. compact сохраняет упорядоченные шаги без подробных JSON-данных payload, а disabled не создаёт строки Alert Explain Trace. Service-scoped orchestration не может использовать это действие, потому что она может выполниться уже после начала lifecycle.

set_alert_event_history управляет только history-записями входящих событий дочернего алерта. full сохраняет created, updated и resolved; initial — только первое created; disabled не сохраняет ни один из этих трёх типов входящих событий. Operational timeline инцидента сохраняется во всех режимах. Значение можно задавать и в global, и в service orchestration; если совпало несколько actions, применяется последнее.

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

Метки и пользовательские поля#

Пример:

Копироватьset_label
name: owner
value: platform

Выбор владельца и политик#

Builder загружает разрешённые объекты текущей группы. Во время выполнения проверяется, что выбранные маршрут, команда, сервис и политики образуют согласованную комбинацию.

Примеры недопустимых комбинаций:

• маршрут принадлежит другой группе;
• источник маршрута — sentry, а источник события — alertmanager;
• выбранный сервис принадлежит другой команде, чем выбранный маршрут;
• выбранная политика принадлежит другой команде;
• выбранный объект отключили или удалили после публикации.

В гибридном режиме такой вариант отклоняется, и может продолжиться устаревшая обработка. В режиме совместимости orchestration ошибка может заблокировать обработку.

Настройка группировки#

set_grouping может определить:

• group_key;
• dedup_key;
• window_seconds.

Пример:

Копироватьgroup_key: {{ labels.alertname }}:{{ labels.environment }}
dedup_key: {{ labels.alertname }}:{{ labels.instance }}
window_seconds: 900

Так создаётся по одному инциденту для каждого имени алерта и окружения, а для каждого экземпляра сохраняется один дочерний алерт в пределах 15-минутного окна группировки.

Прежде чем менять группировку в production, прочитайте раздел Алерты и группы алертов.

Suppress, pause и drop#

У этих трёх действий очень разные последствия.

suppress#

Алерт и группа алертов создаются или обновляются. Они помечаются как подавленные оркестрацией, запланированные уведомления очищаются, а эскалация не планируется, пока действует подавление.

Используйте действие, если операторам может понадобиться найти, проверить или сопоставить событие.

Пример:

КопироватьЕСЛИ labels.environment равно development
И event.severity равно warning
ТО suppress с причиной "Development warning"

pause#

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

Если совпадающее событие resolve поступит до активации, ожидающее событие разрешится без создания алерта.

retrigger управляет повторными firing-событиями:

• preserve сохраняет исходное время активации;
• reset заново запускает задержку после каждого повторного firing-события.

Пример:

Копироватьpause 300 seconds
retrigger preserve
reason "Wait five minutes for transient recovery"

Используйте preserve, если алерт должен появиться через пять минут после первого сбоя. Используйте reset, если алерт должен появиться только спустя пять минут без восстановления после самого последнего сигнала о сбое.

drop#

Обработка останавливается, алерт и группа алертов не создаются.

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

Постановка webhook в очередь#

enqueue_webhook выбирает одно переиспользуемое webhook-действие. HTTP-запрос не выполняется внутри запроса алерта. IncidentRelay ставит асинхронное выполнение в очередь после успешного применения результата оркестрации.

При симуляции и теневом вычислении webhooks не отправляются.

Режим обработки после совпадения#

Режим обработки определяет, что произойдёт с последующими правилами после совпадения текущего.

Визуальный Builder сейчас ориентирован на правила верхнего уровня и вложенные группы условий. Расширенными деревьями с дочерними правилами при необходимости можно управлять через JSON или API.

Используйте stop для взаимоисключающих решений о маршрутизации:

КопироватьПравило 1: production-база данных → команда Database → stop
Правило 2: production-frontend → команда Frontend → stop
Правило 3: catch-all → Platform intake → stop

Используйте continue, если нужно применить несколько независимых обогащений:

КопироватьПравило 1 добавляет метку окружения
Правило 2 нормализует серьёзность
Правило 3 выбирает приоритет

Поведение при ошибке действия#

У каждого действия есть настройка on_failure:

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

Для действий маршрутизации и disposition предпочитайте stop_rule или stop_orchestration, если продолжение создаст вводящий в заблуждение частичный результат. Для необязательного обогащения часто допустим continue.

Шаблоны#

Текстовые действия могут использовать безопасные шаблоны в {{ и }}.

Пример:

КопироватьDatabase alert on {{ labels.instance }} in {{ labels.environment }}

Шаблоны могут ссылаться на те же безопасные корни полей, что и условия.

Поддерживаемые фильтры:

Фильтры можно объединять в цепочки:

Копировать{{ labels.service | default("unknown") | trim | lower }}

Шаблоны намеренно ограничены. Они не могут выполнять Python, вызывать методы, обращаться к атрибутам объектов или запускать произвольный код.

Отсутствующие поля шаблона#

Этот шаблон завершится ошибкой, если labels.cluster отсутствует:

КопироватьCluster {{ labels.cluster }} is unavailable

Этот вариант безопаснее:

КопироватьCluster {{ labels.cluster | default("unknown") }} is unavailable

Используйте Simulator для проверки событий без необязательных меток.

Практические примеры#

Следующие примеры показывают полные рабочие намерения. Идентификаторы команд, сервисов и политик выбираются в Builder, поэтому в описаниях они не прописаны жёстко.

Пример 1: маршрутизация алертов RabbitMQ по меткам#

Цель: одна общая интеграция Alertmanager получает много алертов, но события RabbitMQ должны отправляться команде и сервису messaging.

Условия:

КопироватьALL
├── labels.job equals RabbitMQ
└── labels.rabbitmq regex ^rabbitmq(-[a-z0-9-]+)?$

Действия:

Копироватьset_team       → Messaging team
set_service    → RabbitMQ service
set_label      → name=component, value=rabbitmq
set_grouping   → group_key={{ labels.alertname }}:{{ labels.rabbitmq }}
stop

Зачем здесь regex: метка rabbitmq может содержать имена вроде rabbitmq-cloud, rabbitmq-production или rabbitmq-eu1, при этом префикс остаётся стабильным.

Пример 2: нормализация названий серьёзности#

Цель: один источник отправляет disaster, а правила IncidentRelay ожидают critical.

Правило:

КопироватьIF event.severity equals disaster
THEN set_severity critical
AFTER continue

Теперь последующее правило может единообразно проверять event.severity equals critical.

Пример 3: создание полезного заголовка#

Цель: заменить общий заголовок алерта информацией о сервисе и экземпляре.

Условие:

Копироватьlabels.service exists

Действие:

Копироватьset_title
{{ labels.service | upper }}: {{ event.title | trim }} on {{ labels.instance | default("unknown instance") }}

Результат:

КопироватьPAYMENTS: High error rate on payments-api-3

Пример 4: подавление предупреждений development#

Цель: оставить предупреждения development видимыми, не уведомляя дежурных.

Условия:

КопироватьALL
├── labels.environment equals development
└── event.severity in ["info", "warning"]

Действия:

Копироватьset_label name=suppression_source value=orchestration
suppress reason="Non-production informational event"
stop

Используйте suppress, а не drop, поскольку разработчикам может понадобиться найти событие позднее.

Пример 5: задержка временных сбоев#

Цель: создать алерт, только если endpoint остаётся нездоровым пять минут.

Условия:

КопироватьALL
├── labels.alertname equals EndpointUnavailable
└── labels.environment equals production

Действие:

Копироватьpause
seconds: 300
retrigger: preserve
reason: "Wait for transient endpoint recovery"

Событие resolve с теми же источником и ключом дедупликации, поступившее до активации, предотвратит создание алерта.

Пример 6: отбрасывание тестового события интеграции#

Цель: система мониторинга отправляет известный тестовый сигнал, который не должен становиться алертом.

Условия:

КопироватьALL
├── labels.alertname equals IncidentRelayIntegrationTest
├── labels.environment equals test
└── labels.intent equals connectivity-check

Действие:

Копироватьdrop reason="Expected integration connectivity test"

Используйте несколько точных условий. Не ограничивайтесь event.title contains test, потому что это слово может встречаться и в реальных инцидентах.

Пример 7: выбор политик для инцидентов с влиянием на клиентов#

Цель: критические события, влияющие на клиентов, должны использовать самую быструю эскалацию и отдельную политику уведомлений.

Условия:

КопироватьALL
├── labels.customer_impacting is_true
└── event.severity equals critical

Действия:

Копироватьset_priority              P1
set_escalation_policy     Customer Critical escalation
set_notification_policy   Customer Incident notifications
set_label                  name=customer_impacting, value=true
stop

Выбранные политики должны принадлежать выбранной команде.

Пример 8: группировка множества хостов в один инцидент#

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

Действия:

Копироватьset_grouping
group_key: {{ labels.alertname }}:{{ labels.cluster }}
dedup_key: {{ labels.alertname }}:{{ labels.instance }}
window_seconds: 1800

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

Пример 9: постановка диагностического webhook в очередь#

Цель: при поступлении критического события базы данных асинхронно запросить диагностику у внутреннего сервиса автоматизации.

• Глобальный администратор создаёт webhook-действие Collect database diagnostics.
• Правило оркестрации сопоставляет сервис базы данных и критическую серьёзность.
• Правило выбирает enqueue_webhook → Collect database diagnostics.
• IncidentRelay применяет оркестрацию и создаёт алерт.
• Планировщик асинхронно доставляет webhook с повторными попытками.

Шаблон тела может содержать:

Копировать{
  "service": "{{ labels.service }}",
  "instance": "{{ labels.instance }}",
  "alert": "{{ event.title }}",
  "severity": "{{ event.severity }}"
}

Webhook не отправляется во время симуляции или в теневом режиме.

Simulator#

Simulator вычисляет текущий черновик изолированно. Он не:

• создаёт и не обновляет алерты;
• меняет режим выполнения;
• публикует версию;
• отправляет уведомления;
• выполняет исходящие webhooks;
• изменяет production-данные.

Результат симуляции разделён на четыре представления:

• Итог показывает итоговое событие, выбранные маршрут/команду/сервис и результат выполнения;
• Правила объясняют сработавшие и пропущенные правила, включая фактические значения условий и значения до/после для действий;
• Изменения показывают детерминированный diff вход → результат и, если включено сравнение, активная версия → черновик;
• Raw JSON сохраняет полный ответ API для диагностики.

Ввод нормализованного события#

Выберите Normalized event, если уже знаете поля, которые используют ваши правила.

Минимальный полезный пример:

Копировать{
  "source": "webhook",
  "title": "Example alert",
  "severity": "warning",
  "status": "firing",
  "dedup_key": "example-1",
  "labels": {
    "environment": "staging"
  }
}

Необработанный payload интеграции#

Выберите источник интеграции, чтобы пропустить payload через тот же зарегистрированный нормализатор, который используется при production-приёме.

В этом релизе поддерживаются источники:

Копироватьalertmanager
aws_sns
datadog
grafana
librenms
rmon
sentry
webhook
zabbix

Это полезно, если вы не знаете точно, как необработанный payload преобразуется в нормализованные метки и поля события.

Сравнение с активной версией#

Включите Compare with active version, если у оркестрации уже есть опубликованная версия.

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

Проверьте изменения в:

• маршруте, команде и сервисе;
• заголовке, серьёзности и приоритете;
• группировке и дедупликации;
• политиках;
• disposition;
• поставленных в очередь webhooks.

Чтение результата симуляции#

Важные области результата:

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

Replay#

Replay вычисляет сохранённые алерты или предыдущие выполнения оркестрации относительно выбранной версии. Изменения не применяются к production.

Replay полезен при:

• изменении широкого правила;
• добавлении условия drop или suppress;
• изменении группировки;
• замене выбора маршрута;
• проверке поведения черновика на реальных исторических данных.

Replay сообщает количества, ошибки, disposition и отличия от активной версии. Он также предупреждает, если черновик отбросит большую долю воспроизведённых событий.

Текущая веб-страница ориентирована на симуляцию одного события. Replay доступен через API оркестрации и может быть добавлен в рабочие процессы проверки.

Проверка, публикация и версии#

Сохранение черновика#

Save draft сохраняет редактируемое определение и записывает текущего пользователя как последнего редактора.

Сохранение не изменяет опубликованную production-версию.

Проверка#

Validate сохраняет текущее состояние builder и выполняет статические проверки и проверки сущностей.

Проверка не доказывает правильность бизнес-логики. По-прежнему требуются симуляция, теневой режим и ревью.

Публикация#

Publish создаёт неизменяемую версию и делает её активной для определения оркестрации.

Публикация не меняет режим выполнения автоматически. Отключённая оркестрация после публикации остаётся отключённой.

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

Неизменяемая история#

Опубликованные версии не редактируются на месте. Это обеспечивает:

• точный хеш определения;
• надёжную связь выполнения с версией;
• понятное авторство;
• безопасное сравнение;
• воспроизводимый откат.

Откат#

Откат не переписывает историю. IncidentRelay копирует выбранное историческое определение в новую версию и публикует эту копию.

После отката:

• старые версии остаются неизменными;
• новая версия получает собственный номер и автора публикации;
• последующие выполнения ссылаются на новую версию.

Теневой режим и выполнения#

Теневой режим — самый безопасный способ наблюдать за опубликованным определением на реальном трафике.

В теневом режиме:

• опубликованные правила вычисляются;
• записи выполнений и трассировки сохраняются;
• возможные решения можно сравнить с фактическими результатами жизненного цикла;
• production-поведение событий не меняется;
• webhook-действия не доставляются.

Список выполнений#

На вкладке Executions показаны:

• источник интеграции;
• итоговый disposition;
• количество совпавших правил;
• длительность вычисления;
• время создания;
• кнопка трассировки.

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

Что проверить перед активацией#

Проверьте репрезентативную выборку каждого важного источника и типа событий.

Ищите:

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

Теневые метрики#

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

Метрики — сигнал, а не механизм одобрения. Даже небольшое количество отличий может содержать одну критическую ошибку маршрутизации.

Webhook-действия#

Webhook-действия — принадлежащие группе переиспользуемые определения исходящих HTTP-запросов. Они отделены от определений правил, чтобы секретами и настройками доставки можно было управлять централизованно.

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

Создание webhook-действия#

Откройте Webhook Actions и нажмите Add webhook.

Настройте:

Пример секретных заголовков:

Копировать{
  "Authorization": "Bearer secret-token",
  "X-Source": "IncidentRelay"
}

При редактировании существующего действия интерфейс намеренно показывает {} вместо расшифровки сохранённых заголовков. Если оставить заголовки пустыми, существующие зашифрованные заголовки сохранятся. Новый непустой объект заменит их.

Безопасность#

Доставка webhook включает защиту от подделки серверных запросов и раскрытия секретов:

• URL должен использовать HTTP или HTTPS и не может содержать встроенные учётные данные;
• по умолчанию требуется HTTPS;
• частные и специальные сетевые адреса запрещены, если явно не добавлены в список разрешённых;
• перенаправления ограничены и проверяются повторно;
• опасные hop-by-hop-заголовки отклоняются;
• секретные заголовки шифруются;
• ответы API никогда не возвращают значения заголовков;
• ошибки и фрагменты ответов в журналах редактируются и ограничиваются по размеру;
• запросы получают ключ идемпотентности;
• применяются ограничения параллелизма и частоты для группы.

Требование к планировщику#

Исходящие webhook-запросы выполняются асинхронно. Чтобы ожидающие выполнения автоматизации и повторные попытки доставлялись, процесс планировщика IncidentRelay должен быть запущен.

Расширенное представление JSON#

Builder охватывает распространённые типы условий и действий. JSON view показывает полное детерминированное определение и полезен для:

• копирования определения на ревью;
• массовых изменений;
• расширенного извлечения переменных;
• деревьев дочерних правил;
• конфигураций, создаваемых через API.

После редактирования JSON всегда нажимайте Apply JSON, затем Save draft и выполняйте проверку.

Полный пример:

Копировать{
  "schema_version": 1,
  "rules": [
    {
      "name": "Critical production database",
      "description": "Route and enrich critical database events.",
      "enabled": true,
      "condition_tree": {
        "all": [
          {
            "field": "labels.environment",
            "operator": "equals",
            "value": "production"
          },
          {
            "field": "labels.component",
            "operator": "equals",
            "value": "database"
          },
          {
            "field": "event.severity",
            "operator": "in",
            "value": ["critical", "fatal"]
          }
        ]
      },
      "actions": [
        {
          "type": "set_title",
          "template": "DB: {{ event.title | trim }} on {{ labels.instance | default(\"unknown\") }}"
        },
        {
          "type": "set_priority",
          "value": "P1"
        },
        {
          "type": "set_label",
          "name": "orchestrated",
          "value": "true"
        },
        {
          "type": "set_grouping",
          "group_key": "{{ labels.alertname }}:{{ labels.cluster | default(\"default\") }}",
          "dedup_key": "{{ labels.alertname }}:{{ labels.instance }}",
          "window_seconds": 1800
        }
      ],
      "processing_mode": "stop",
      "children": []
    }
  ]
}

Для действий с командами, маршрутами, сервисами и политиками требуются числовые идентификаторы. Предпочтительно выбирать их в Builder, чтобы каталог предоставил допустимые для группы объекты.

Расширенные действия с переменными#

Движок также поддерживает детерминированные действия извлечения переменных через JSON и API:

Копироватьextract_regex
copy_field
copy_to_variable
json_path
split
set_variable
static
lowercase
uppercase
trim

Переменные сохраняются в variables.<name> для последующих условий и шаблонов.

Пример:

Копировать{
  "type": "extract_regex",
  "source": "labels.instance",
  "pattern": "^(?P<service>[a-z0-9-]+)-[0-9]+$"
}

После успешного извлечения последующее действие может использовать:

Копировать{{ variables.service }}

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

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

Оркестрация никогда не запускается#

Проверьте:

• Версия опубликована.
• Режим выполнения — shadow или active.
• Событие принадлежит той же группе.
• У глобальной оркестрации ожидаемый контекст группы.
• Оркестрация сервиса привязана к сервису, действительно выбранному для события.
• Не используется active + legacy, когда ожидается применение к production.
• Оркестрация и выбранный сервис включены.

Правило никогда не совпадает#

Используйте Simulator и изучите трассировку условия.

Распространённые причины:

• используется event.environment, хотя значение находится в labels.environment;
• неверный регистр;
• строка неправильно сравнивается с JSON-массивом;
• путь исходного payload отличается от нормализованного события;
• необязательная метка отсутствует;
• неверны якоря или экранирование регулярного выражения;
• предыдущее правило изменило поле;
• правило отключено.

in или not_in не проходит проверку#

Введите JSON-коллекцию:

Копировать["critical", "fatal"]

Не вводите только:

Копироватьcritical

Ошибка шаблона#

Вероятно, указанное поле отсутствует или содержит нескалярный объект.

Используйте default для необязательных полей:

Копировать{{ labels.cluster | default("unknown") }}

Проверьте событие без необязательной метки.

Выбранный маршрут отклонён#

Убедитесь, что:

• маршрут включён;
• маршрут принадлежит группе оркестрации;
• источник маршрута совпадает с источником события;
• команда маршрута активна;
• выбранные сервис и политики при необходимости принадлежат той же команде.

Событие видно, но никто не получил уведомление#

Проверьте, равен ли disposition выполнения suppress, совпало ли подавление или окно обслуживания и нашла ли политика уведомлений получателя.

Подавленное оркестрацией событие намеренно сохраняется, а уведомления и эскалация отключаются.

Событие отсутствует в Alerts#

Проверьте disposition выполнения:

• drop означает, что алерт не создан;
• pause означает, что событие ожидает и может активироваться позднее;
• resolve мог поступить до активации задержанного события.

Задержанное событие не активируется#

Проверьте:

• запущен ли процесс планировщика;
• не было ли ожидающее событие уже разрешено;
• прошло ли время активации;
• не продлевают ли повторные события с retrigger=reset задержку постоянно;
• журналы планировщика и ожидающих событий на наличие безопасных типов ошибок.

Webhook не отправляется#

Проверьте:

• режим выполнения — active, а не shadow;
• выполнение оркестрации успешно применено;
• webhook-действие включено;
• планировщик запущен;
• URL использует HTTPS, если HTTP явно не разрешён;
• цели с частными адресами разрешены конфигурацией;
• доставка не задерживается ограничениями частоты или параллелизма;
• статус выполнения webhook и безопасное сообщение об ошибке.

Публикация недоступна#

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

Изменения отображаются под именем другого автора#

Список версий различает:

• создателя версии;
• последнего пользователя, изменившего её черновик;
• пользователя, опубликовавшего её.

Если один пользователь редактирует, а другой публикует, значения Changed by и Published by ожидаемо отличаются.

Рекомендации по рабочему проектированию#

Давайте правилам бизнес-имена#

Хорошо:

КопироватьCritical production database routing
Suppress development backup warnings
Delay transient endpoint failures

Менее полезно:

КопироватьRule 1
New rule
Test

Объясняйте почему, а не только что#

Используйте описания и комментарии публикаций для записи рабочей причины.

Пример:

КопироватьSuppress warning-level backup events in development because they are reviewed in the daily report and must not page on-call.

Предпочитайте явные условия#

Предпочтительно:

Копироватьlabels.environment equals production
AND labels.component equals database
AND event.severity equals critical

вместо:

Копироватьevent.title contains DB

Структурированные метки стабильнее человекочитаемого текста.

Упорядочивайте взаимоисключающие правила маршрутизации#

Ставьте самые конкретные правила первыми и останавливайтесь после совпадения маршрута.

Копировать1. Payments production critical
2. Payments other
3. Other production
4. Catch-all

Отделяйте нормализацию от итоговых решений#

Понятное определение часто следует такому порядку:

Копировать1. Нормализовать метки и серьёзность
2. Выбрать владельца
3. Выбрать приоритет и политики
4. Настроить группировку
5. Применить решения suppress/pause/drop
6. Поставить автоматизацию в очередь

Избегайте скрытой связанности#

Если последующее правило зависит от поля, изменённого предыдущим, укажите это в описаниях обоих правил.

Проверяйте в обоих направлениях#

Для каждого важного правила проверьте:

• совпадающее событие;
• близкое событие, которое не должно совпасть;
• отсутствие необязательных полей;
• статус resolved;
• другое окружение;
• другой источник;
• сравнение с существующей активной версией.

Проверяйте разрушительные решения отдельно#

Считайте высокорисковыми:

• drop;
• широкий suppress;
• длительный pause;
• замену маршрута;
• set_event_action resolve;
• изменение ключей группировки;
• режим совместимости orchestration.

Перед активацией используйте replay и наблюдение в теневом режиме.

Часто задаваемые вопросы#

Влияет ли сохранение черновика на production?#

Нет. Production использует опубликованную активную версию с учётом режима выполнения.

Применяются ли правила сразу после публикации?#

Публикация обновляет активную версию, но режим выполнения disabled всё равно предотвращает запуск. В теневом режиме версия вычисляется без изменения production-поведения.

Может ли редактор группы публиковать?#

Да. Редактор группы может изменять, проверять, симулировать, воспроизводить, публиковать и откатывать оркестрации этой группы.

Может ли редактор группы создавать webhook-действия?#

Нет. Управление переиспользуемыми webhook-действиями остаётся доступно только глобальным администраторам.

Означает ли stop, что алерт отбрасывается?#

Нет. Он останавливает последующие правила оркестрации. Событие продолжает обычный жизненный цикл с уже принятыми решениями.

Чем suppress отличается от silence?#

Оба могут предотвратить уведомления. Подавление оркестрацией — это записанное в алерте решение движка правил, которое может зависеть от изменённых полей или порядка правил. Silence — отдельная конфигурация подавления алертов, обычно более понятная для временных или независимо управляемых окон подавления.

Чем pause отличается от длительности for в Alertmanager?#

Длительность for выше по потоку не позволяет Alertmanager отправить алерт, пока выражение не остаётся истинным указанное время. Orchestration pause действует после получения события IncidentRelay, сохраняет ожидающее событие и может отменить его, если до активации поступит совпадающий resolve.

Может ли оркестрация вызывать скрипты?#

Нет. Произвольное выполнение Python, shell, SSH и контейнеров не поддерживается. Используйте защищённый асинхронный webhook к специализированному сервису автоматизации.

Можно ли использовать поля исходного payload?#

Да, через raw.<path>, но нормализованные поля event и labels обычно лучше переносятся между интеграциями и проще тестируются.

Можно ли отменить публикацию?#

Да. Используйте Versions и rollback. IncidentRelay публикует новую копию выбранного исторического определения, а не изменяет старую историю.

Где посмотреть, почему событие обработано определённым образом?#

Откройте вкладку Executions оркестрации и просмотрите трассировку. Трассировка Explain алерта также содержит сведения о выполнении оркестрации, если они доступны.

Связанная документация#

• API Event Orchestration
• Архитектура Event Orchestration
• Алерты и группы алертов
• Группы и RBAC
• Сервисы
• Политики эскалации
• Каналы уведомлений
• Журналирование администрирования