Событийные триггеры для Workflows

Событийные триггеры для Workflows

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

Выбор типа триггера

Тип триггера	Когда использовать	Источник событий
Триггер проблемы	Запускается, когда проблема открывается или разрешается, и при необходимости когда определённые поля проблемы изменяются. Используйте, когда нужно реагировать один раз на всю проблему, а не на каждое отдельное оповещение.	Проблемы ИИ. Требуемые разрешения: storage:events:read.
Триггер события ИИ	Запускается на отдельных оповещениях при обнаружении аномалий. Используйте, когда нужно реагировать на каждое оповещение индивидуально, а не на сгруппированное событие проблемы.	События ИИ. Требуемые разрешения: storage:events:read.
Триггер события	Запускается на любом типе события, соответствующем пользовательскому фильтру DQL. Используйте, когда ни один встроенный тип триггера не покрывает ваш источник событий или когда нужен полностью настраиваемый фильтр.	События, события безопасности, dt.system.events. Требуемые разрешения зависят от типа события.

Перед настройкой

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

Триггер проблемы

Проблемы создаются ИИ Ключ-АСТРОМ путём корреляции аномалий и их первопричин в вашей среде. Триггер проблемы запускает Workflow, когда проблема открывается, изменяется или разрешается. Источник событий — проблемы ИИ.

Чтобы просмотреть прошлые события, изучить доступные поля и протестировать условия фильтра перед настройкой триггера, выполните этот запрос в Блокнотах:

fetch dt.davis.problems

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

fetch events
| filter event.kind == "DAVIS_PROBLEM"

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

• Состояние проблемы:
  • active: запускается при открытии проблемы. По умолчанию.
  • active or closed: запускается при открытии проблемы и снова при её закрытии.
  • closed: запускается только при закрытии проблемы.
• Категория события: определения см. в разделе «Категории событий».
• Серьёзность: уровень серьёзности, при котором проблемы должны запускать Workflow.
• Затронутые сущности: фильтрация по тегам сущностей:
  • Включить все сущности.
  • Включить сущности со всеми указанными ниже тегами.
  • Включить сущности с любым из указанных ниже тегов.

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

В разделе Дополнительные параметры:

• Минимальная длительность: откладывает запуск триггера до тех пор, пока проблема не будет открыта в течение как минимум настроенной длительности. Подробности см. в разделе «Задержка триггера».
• Обновления: повторно запускает Workflow при изменении определённых полей проблемы в течение её жизненного цикла. См. раздел «Повторный запуск при изменении полей».
• Дождаться анализа первопричин: если включено, триггер запускается только после завершения анализа первопричин. Рекомендуется: включите, чтобы избежать запуска на неполных данных проблемы.
• Дополнительный пользовательский фильтр запроса: добавьте выражение сопоставления DQL, чтобы дополнительно уточнить, какие проблемы запускают триггер. Это поле входит в общее выражение сопоставления, которое ограничено 1 000 символов для всех полей триггера.

Задержка триггера

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

Допустимые значения (в минутах):

• 5
• 10
• 15
• 30
• 60 (один час)
• 120 (два часа)
• 240 (четыре часа)
• 1440 (один день)
• 10080 (одна неделя)

Задержка основана на dt.duration_marker — поле, устанавливаемом ИИ Ключ-АСТРОМ, которое накапливается с момента первого создания проблемы. Триггер срабатывает один раз при пересечении порога на активной фазе. Если вы настроили фильтр триггера на обнаружение также и закрытой фазы, триггер дополнительно сработает один раз при закрытии проблемы, независимо от того, была ли она закрыта вручную или автоматически. Проблема, закрытая до достижения настроенного порога, не создаёт триггер.

Изменения полей до порога: изменения отслеживаемых полей проблемы, произошедшие до пересечения порога задержки, не учитываются в Workflows. Проблема становится видимой только когда dt.duration_marker достигает настроенного значения. Изменения полей после порога отслеживаются нормально. Подробности см. в разделе «Повторный запуск при изменении полей».

Повторный запуск при изменении полей

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

Например, если вы выбрали серьёзность для Обновлений, триггер запускается, когда серьёзность меняется с MEDIUM на HIGH. Если серьёзность возрастает до CRITICAL, триггер запускается снова, поскольку значение поля изменилось на новую комбинацию.

Поле затронутых сущностей отслеживает объединение affected_entity_ids и smartscape.affected_entities. Изменение любого из этих базовых полей считается изменением затронутых сущностей.

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

Триггер события ИИ

ИИ Ключ-АСТРОМ генерирует оповещения, хранящиеся как события ИИ в хранилище данных, во время обнаружения и анализа аномалий. События ИИ более детальны, чем проблемы: одна проблема может группировать несколько событий ИИ по мере развития условий (например, событие насыщения ресурса, за которым следует событие деградации сервиса). Триггер события ИИ позволяет реагировать на конкретное событие ИИ, а не на проблему в целом. Источник событий — события ИИ.

Чтобы просмотреть прошлые события, изучить доступные поля и протестировать условия фильтра перед настройкой триггера, выполните этот запрос в Блокнотах:

fetch dt.davis.events

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

fetch events
| filter event.kind == "DAVIS_EVENT"

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

• Состояние проблемы:
  • active: запускается при открытии события ИИ. По умолчанию.
  • active or closed: запускается при открытии события ИИ и снова при его закрытии.
  • closed: запускается только при закрытии события ИИ.
• Имя события ИИ:
  • equals: запускается, когда имя события ИИ точно совпадает со строкой.
  • contains: запускается, когда имя события ИИ содержит строку.
• Затронутые сущности: фильтрация по тегам сущностей:
  • Включить все сущности.
  • Включить сущности со всеми указанными ниже тегами.
  • Включить сущности с любым из указанных ниже тегов.
• Окно обслуживания: управляет тем, запускается ли триггер во время окон обслуживания.
  • Всегда: запускается независимо от окон обслуживания. По умолчанию.
  • Только внутри окна обслуживания: запускается только когда активно окно обслуживания.
  • Только вне окна обслуживания: запускается только когда ни одно окно обслуживания не активно.
• Дополнительный пользовательский фильтр запроса: добавьте выражение сопоставления DQL, чтобы дополнительно уточнить, какие события ИИ запускают триггер. Это поле входит в общее выражение сопоставления, которое ограничено 1 000 символов для всех полей триггера.

Триггер события

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

Тип события

Выберите, на какой тип события реагировать:

• events: хранит события наблюдаемости из всей вашей среды, изменения конфигурации, события окон обслуживания и пользовательские события, загруженные через API событий или созданные в OpenPipeline.
• security.events: обнаружения уязвимостей, обнаружения соответствия и обнаружения безопасности от Application Security Ключ-АСТРОМ и сторонних поставщиков, загружаемые через конечную точку v1/security.events или конечные точки custom/security.events/<custom-endpoint-name>. Используйте этот тип для автоматизации исправления или создания заявок при обнаружении новых уязвимостей.
• dt.system.events: события, генерируемые системными сервисами Ключ-АСТРОМ, включая события аудита, уведомления о жизненном цикле приложений, события выполнения Workflow и самоконтроль расширений.

Допустимость системных событий Для dt.system.events только системные события, загруженные через OpenPipeline, могут запускать Workflow. Большинство типов системных событий маршрутизируются через OpenPipeline, но некоторые — нет. Чтобы увидеть, какие события в вашей среде являются допустимыми, выполните этот запрос в Блокнотах:

fetch dt.system.events
| filter isNotNull(dt.openpipeline.pipelines)

Фильтр запроса

В поле Фильтр запроса сузьте, какие события запускают триггер, используя синтаксис сопоставления DQL. Фильтр запроса является частью общего выражения сопоставления, которое ограничено 1 000 символов для всех полей триггера.

Пример 1: сопоставление определённого типа события.

event.type == "com.example.order.completed"

Пример 2: сопоставление событий безопасности с определённым статусом.

event.kind == "SECURITY_EVENT" and vulnerability.resolution.status == "OPEN"

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

Использование данных событий в задачах Workflow

Когда Workflow запускается событием, полная полезная нагрузка события доступна всем последующим задачам. Ссылайтесь на неё с помощью выражения event(). Например, event()["event.type"] возвращает тип запускающего события. Можно использовать любое поле из полезной нагрузки события для передачи контекста действиям, построения условий или персонализации уведомлений. Для ручных запусков во время разработки Workflows предварительно заполняет контекст события из последнего успешного выполнения и позволяет скорректировать его перед запуском.

Ограничения

• Размер выражения фильтра: полное выражение сопоставления, скомпилированное из всех полей триггера (фильтры сущностей, имя события и любой дополнительный пользовательский фильтр запроса), ограничено 1 000 символов. Сохранение триггера, скомпилированное выражение которого превышает этот лимит или содержит некорректный DQL, возвращает ошибку валидации.
• Лимит длины выражения сопоставления DQL: в сложных сценариях конфигурация триггера события ИИ и триггера проблемы может привести к выражению сопоставления DQL, превышающему лимит в 1 000 символов. Рассмотрите следующие варианты:
  • Оставьте конфигурацию формы широкой и используйте опцию Дополнительный пользовательский фильтр для уточнения логики сопоставления. Вы можете изучить полученное выражение сопоставления DQL в Блокнотах, проверив часть фильтра запроса DQL.
  • Определите процессор OpenPipeline, который добавляет вычисляемое свойство на основе ваших критериев к интересующим событиям. Используйте это вычисляемое свойство в качестве критерия фильтра в Дополнительном пользовательском фильтре вашей конфигурации триггера.
• Синтаксис сопоставления DQL: выражения фильтра триггера события используют синтаксис сопоставления DQL. Каждое событие оценивается индивидуально по мере поступления в OpenPipeline; функции агрегации и запросы с несколькими событиями не поддерживаются.
• Скорость выполнения: каждый Workflow ограничен 1 000 запусков по событийному триггеру в час. При превышении этого лимита выполнения ограничиваются (HTTP 429) на срок до одного часа. При трёхкратном превышении в течение семи дней триггер автоматически деактивируется. Как событие ограничения, так и деактивация отмечаются в обзоре Workflows и могут быть отфильтрованы.
  • Повторная активация деактивированного триггера: чтобы повторно активировать триггер, скорректируйте конфигурацию фильтра, чтобы уменьшить объём событий, затем выберите Сохранить. Используйте Запросить прошлые события в конфигурации триггера, чтобы оценить ожидаемый объём событий и избежать достижения лимита до развёртывания.

Разрешения

• Актор Workflow требует доступа на чтение к типу события, на которое реагирует триггер. Предоставляйте разрешения в зависимости от типа триггера и типа события:

Тип триггера	Требуемое разрешение
Триггер проблемы	storage:events:read
Триггер события ИИ	storage:events:read
Триггер события (events)	storage:events:read
Триггер события (security.events)	storage:security.events:read
Триггер события (dt.system.events)	storage:system:read

• Ограничьте storage:buckets:read конкретным бакетом, связанным с событием.
• Для интерактивных пользователей также выберите эти разрешения в их настройках авторизации. Подробности см. в разделе «Безопасность Workflow».