LLD триггеры, зависимости, корреляция событий.

[Uttar]

Добрый день.
Есть правило обнаружение, в ходе работы которого создаются элементы данных и триггеры. На триггеры навешаны действия по отправке уведомлений\запуске скриптов.
Задача - не вызывать экшен если уже горит другой триггер из этого же правила обнаружения.
Единственный способ, который нашёл, это сделать через корреляцию событий. Но с ней проблема, что правило корреляции закрывает проблему, а при следующей проверке триггер опять срабатывает, в итоге в истории проблем тысячи бесполезных событий, которые мешают.
Как можно решать подобные кейсы?

[teddy]

Добрый день.
Есть правило обнаружение, в ходе работы которого создаются элементы данных и триггеры. На триггеры навешаны действия по отправке уведомлений\запуске скриптов.
Задача - не вызывать экшен если уже горит другой триггер из этого же правила обнаружения.
Единственный способ, который нашёл, это сделать через корреляцию событий. Но с ней проблема, что правило корреляции закрывает проблему, а при следующей проверке триггер опять срабатывает, в итоге в истории проблем тысячи бесполезных событий, которые мешают.
Как можно решать подобные кейсы?

В протипе триггера указать что он зависит от другого триггера. тогда если один - проблема - то второй не срабатывает.
тут есть один маленький нюанс. поскольку прототипами генерится ( может генереится ) много однотипных триггеров то вы не сможете указать что то типа триггер1-1 зависит от триггера2-5 если триггер1-1 генерит одно правило обнаружения а триггер2-5 генерит другое правило. такой расклад надо прописывать руками после генерации правил на хосте.

[Uttar]

В протипе триггера указать что он зависит от другого триггера. тогда если один - проблема - то второй не срабатывает.
тут есть один маленький нюанс. поскольку прототипами генерится ( может генереится ) много однотипных триггеров то вы не сможете указать что то типа триггер1-1 зависит от триггера2-5 если триггер1-1 генерит одно правило обнаружения а триггер2-5 генерит другое правило. такой расклад надо прописывать руками после генерации правил на хосте.

В том-то и дело, что нужна зависимость между однотипными триггерами из одного прототипа.
И после генерации нельзя менять выражеиня\зависимости триггеров, т.к. они из шаблона унаследованы.

[teddy]

В том-то и дело, что нужна зависимость между однотипными триггерами из одного прототипа.
И после генерации нельзя менять выражеиня\зависимости триггеров, т.к. они из шаблона унаследованы.

есть варианты:
1. создавать триггеры в состоянии Disable. после создания руками делать клоны и создавать зависимости. решает задачу чтоб ничего не пропустить, но очень неудобно и конечно много мусора в описании хоста.
2. продумать такое создание триггеров чтоб было два или более прототипа триггеров в рамках одного обнаружения, прописываем заивисмость одноих ПРОТОТИПОВ от других ПРОТОТИПОВ. Даже если они одинаковые по сути их можно на уровне LLD создавать нужными парами или тройками ну и т.д. Тогда они создадутся с нужными связями. Плюсы подхода - все красиво и ничего лишнего. Минус один - надо много думать при написании функции LLD и не всегда это возможно вообще.
3. Реализовывать аналог "корелляции событий" по отношению к триггерам самостоятельно чере API. Плюс- свободное поле деятельности. делай что нужно. Минус - очень высокий порог вхождения в реализацию.

Лично у меня в нескольких несложных случаях реализован путь 1. В одном более тяжелом - второй. До третьего пути я еще не созрел, хотя и есть где это очень просится ))