Закрытие триггеров по сложным условиям

[teddy]

Коллеги!
есть два триггера.

Первый:
sum(/Template App/log.count[/var/log/server.log,"Cannot lock terminal by params: TerminalInfo{processingId=",,1000,,,],3m)>0
второй:
Problem: sum(/Template App/log.count[/var/log/server.log,"Cannot lock terminal by params: TerminalInfo{processingId=",,1000,,,],30m)>30
Recovery: sum(/Template App/log.count[/var/log/server.log,"Cannot lock terminal by params: TerminalInfo{processingId=",,1000,,,],3m)=0

Логика. если за 3 миниты в логе есть ошибки - алерт. Если ошибки повторяются дольше чем 30мин - то алерт более высокого уровня. Ошибки ушли - алерты закрылись оба, т,к ошибки ушли.

Таким образом условия срабатывания разные. Условия закрытия как бы одинаковые, но так не работает.
Я понимаю почему несмотря на закрытие первого триггера - второй остается открытым.

вопрос как сделать правильно мою логику?
идеально если б можно было сделать триггер по значению, что время активности другого триггера больше 30мин. но я не нашел как такое реализовать без привлечения АПИ ( это уже оверхед явно для такой задачи)

[Kos]

Когда в настройках триггера есть отдельно условие срабатывания и условие восстановления, то условие восстановления проверяется только после того, как перестало выполняться условие срабатывания (т.е. условие восстановления является дополнительным).

Предположим, что данные собираются с интервалом раз в минуту.
Рассмотрим сценарий: событий в логах долгое время нет (log.count[...] возвращает нули), затем - в течение нескольких минут события есть, причём довольно много (допустим, в течение 5 минут приходят не нули, а каждый раз по десятке), а затем - всё рассосалось, и снова приходят одни нули.

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

Второй триггер среагирует чуть позже, когда таких десяток наберётся больше 3 штук, чтобы их сумма превысила 30. Однако и закроется тоже позже, т.к., например, через 25 минут после того как проблема "рассосалась", при вычислениях "за последние полчаса" всё еще будут фигурировать пять десяток, дающих в сумме значение, большее 30.

Я бы рекомендовал для вашего сценария вместо триггерной функции sum() использовать функцию min():

• для первого триггера:

min(/Template App/log.count[/var/log/server.log,"Cannot lock terminal by params: TerminalInfo{processingId=",,1000,,,],3m)>0

• для второго триггера:

min(/Template App/log.count[/var/log/server.log,"Cannot lock terminal by params: TerminalInfo{processingId=",,1000,,,],30m)>0

Выражение восстановления в таком случае не нужно.
Логика: если в течение трёх минут (или 30 минут) подряд идут ошибки в логе, то триггер срабатывает; как только прекратились (пришёл первый ноль) - закрывается.

Правда, такой триггер не будет срабатывать в случае, если ошибки появляются с интервалом, бОльшим, чем период опроса. В нашем примере - если опрашиваем раз в минуту, а ошибки возникают каждые 2 минуты (причём "пачками" по 10 штук), то с таким условием триггер на это не отреагирует.
Но для таких ситуаций можно использовать функции avg() или count().

[teddy]

Спасибо. Я понял вашу логику. Нужно переопределить условия.