Проблема с многократной расслыкой опове&

[airosa]

Добрый день, уважаемые форумчане!
Есть Zabbix версии 2.4.5
Возникла проблема при мониторинге лога на определенные фразы.
Вроде все просто, но при срабатывании триггера по жабберу отправляются сразу несколько сообщений. Условия такие:
сам итем:

log[/var/log/cisco/vpn_anyconnect.log]

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

Далее несколько однотипных триггеров. по идее он должен смотреть в лог и если при изменении файла в нем появляется подстрока "Invalid password",то жаббером рассылается сообщение, а триггер переключается в состояние PROBLEM. Через 30 секунд (меньше как я понял нельзя) триггер переключается в состояние ОК без отсылки алерта.

{Template Syslog:log[/var/log/cisco/vpn_anyconnect.log].str(Invalid password)} and {Template Syslog:log[/var/log/cisco/vpn_anyconnect.log].nodata(30)}=0

На деле же при появлении подстроки выскакивает алерт, через ~13 секунд снова выскакивает алерт о проблеме, и потом через 30 секунд снова выскакивает алерт триггера и триггер переходит в состояние ОК.

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

[Kos]

В свойствах триггера выставлена ли "галочка" "Multiple PROBLEM events generation"?

[airosa]

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

[Kos]

При выставленной "галке" и использовании в триггере временнЫх функций (в частности, nodata())оповещение может рассылаться каждые 30 секунд. Подробности я публиковал тут ещё полтора года назад, но, к сожалению, в списке приоритетов эта проблема где-то глубоко внизу. Проголосовавших мало, а объяснить серьёзность проблемы мне удалось только инженеру техподдержки, с которым я общался, но не тем, от кого зависит принятие решений об архитектуре

[airosa]

Когда искал решение находил эту страницу...
То есть решения нет? даже костыльного?
Сами каким образом вышли из положения?

[Kos]

Когда искал решение находил эту страницу...
То есть решения нет? даже костыльного?
Сами каким образом вышли из положения?

Увы, пока что решения нет.
Сами выходим из положения именно что при помощи "костыля": в качестве параметра функции nodata() указывается 7 секунд (вместо документированных 30-ти). Дело в том, что обработка события Zabbix-ом тоже занимает какое-то время: прибывшие данные сначала помещаются в кэш, из которого с периодичностью в 5 секунд они сбрасываются в базу одним из процессов DBSyncer. Этот процесс, собственно, в этот момент и производит вычисление триггеров, которые должны сработать при получении новых данных. И если указать 5 секунд или меньше, то с довольно большой вероятностью событие может не сгенерироваться (между получением данных и их обработкой уже прошло 5 секунд, nodata(5) вернёт единицу). Сколько к этим 5 секундам добавить - зависит от производительности и загруженности системы (у нас сервер довольно мощный, так что +2 секунды вполне хватает).
Соответственно, вероятность того, что в это же время успеет сработать ещё и вычисление триггера процессом timer существенно снижается. Процесс timer активизируется каждые 30 секунд (в :00 и :30 секунд каждой минуты), он пересчитывает все триггеры, которые содержат временнЫе функции (nodata(), date(), time() и т.п.).

[airosa]

Спасибо за помощь и подробные разъяснения!