Отключение Триггера

[Максим]

Ребята помогите пожалуйста.
Ситуация такая: отслеживаю я в логах определенную ошибку.
Триггер {***:logrt["\**\***\l\log_info","Проблемы с ключом","UTF-8",100].str(Проблемы с RSA ключом)}=1
Когда проблемы с ключом, то ошибки сыплются за подряд, естественно триггер на каждую срабатывает и засыпает почту сообщениями по каждой ошибке.
Как сделать чтобы он срабатывал на первую ошибку на дальнейшие не реагировал?
Я думаю как вариант, сделать чтоб при срабатывании Триггера, он отключался на 30 минут, как это можно реализовать?

[Kos]

Я думаю как вариант, сделать чтоб при срабатывании Триггера, он отключался на 30 минут, как это можно реализовать?

Убрать из свойств триггера "галочку" "Multiple PROBLEM events generation", а в условие триггера добавить конструкцию

and {***:logrt["\**\***\l\log_info","Проблемы с ключом","UTF-8",100].nodata(30m)}=0

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

[Максим]

Убрать из свойств триггера "галочку" "Multiple PROBLEM events generation", а в условие триггера добавить конструкцию

and {***:logrt["\**\***\l\log_info","Проблемы с ключом","UTF-8",100].nodata(30m)}=0

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

Галочка снята и так. А если я поставлю nodata(30m). То когда появится ошибка "Проблемы с ключом" то он же оповестит меня лишь через 30 минут после появления ошибки, а не сразу?

[Kos]

Галочка снята и так. А если я поставлю nodata(30m). То когда появится ошибка "Проблемы с ключом" то он же оповестит меня лишь через 30 минут после появления ошибки, а не сразу?

Смысл этой конструкции: условие триггера выполняется только в случае, когда данные пришли недавно. Через 30 минут nodata(30m) будет возвращать единицу, что приведёт к невыполнению условия триггера ("равно нулю") и, соответственно, его закрытию.

А отсутствие указанной "галочки" должно приводить к тому, что если триггер уже находится в состоянии "PROBLEM", то новые события генерироваться не должны (пока триггер не вернётся в "OK").

Если же эта "галочка" у вас НЕ выставлена, а почтовые уведомления всё равно "сыпятся", то надо смотреть подробнее последовательность событий - что именно происходит. В первую очередь, экран Monitoring -> Events (отфильтровать по данному хосту и триггеру), и смотреть, действительно ли в таком количестве генерируются события "переход триггера в состояние PROBLEM". Там же можно нажать на дату/время и посмотреть подробности этого события - будут видны действия (Actions) на него, в частности - что и кому отсылалось.
Например, как вариант, может быть некорректно настроенное действие (когда на одно событие отсылается множество уведомлений).

Ещё вариант - под указанный в ключе элемента данных фильтр ("Проблемы с ключом") подходит большее количество строк, нежели искомая строка в триггере ("Проблемы с RSA ключом"), в результате чего при возникновении реальной проблемы в элемент данных попадает множество строк, часть из которых приводит к срабатыванию триггера, а часть - к тому, что он тут же закрывается. Тогда надо либо корректировать эти строки в ключе элемента данных, либо использовать в триггере другую функцию (например, {***:logrt["\**\***\l\log_info","Проблемы с ключом","UTF-8",100].count(30m,"Проблемы с RSA ключом")}>0).

[Максим]

Смысл этой конструкции: условие триггера выполняется только в случае, когда данные пришли недавно. Через 30 минут nodata(30m) будет возвращать единицу, что приведёт к невыполнению условия триггера ("равно нулю") и, соответственно, его закрытию.

А отсутствие указанной "галочки" должно приводить к тому, что если триггер уже находится в состоянии "problem", то новые события генерироваться не должны (пока триггер не вернётся в "ok").

Если же эта "галочка" у вас НЕ выставлена, а почтовые уведомления всё равно "сыпятся", то надо смотреть подробнее последовательность событий - что именно происходит. В первую очередь, экран monitoring -> events (отфильтровать по данному хосту и триггеру), и смотреть, действительно ли в таком количестве генерируются события "переход триггера в состояние problem". Там же можно нажать на дату/время и посмотреть подробности этого события - будут видны действия (actions) на него, в частности - что и кому отсылалось.
Например, как вариант, может быть некорректно настроенное действие (когда на одно событие отсылается множество уведомлений).

Ещё вариант - под указанный в ключе элемента данных фильтр ("Проблемы с ключом") подходит большее количество строк, нежели искомая строка в триггере ("Проблемы с rsa ключом"), в результате чего при возникновении реальной проблемы в элемент данных попадает множество строк, часть из которых приводит к срабатыванию триггера, а часть - к тому, что он тут же закрывается. Тогда надо либо корректировать эти строки в ключе элемента данных, либо использовать в триггере другую функцию (например, {***:logrt["\**\***\l\log_info","Проблемы с ключом","utf-8",100].count(30m,"Проблемы с rsa ключом")}>0).

Огромное спасибо за пояснения, тестирую)