Задержка по времени в триггере

[vital8111]

Добрый день.
Есть Триггер
{zclient:log[tmp/test].regexp("created")}=1
Мониторятся логи и соответсвенно если в строке прилетает created то срабатывает триггер.
Не получается сделать, чтобы срабатывал не сразу а по прошествии времени(хочу сделать макросом), если не пришло другое значение(sent) - по этому значению сделан recovery expression
Как так сделать?
Заранее спасибо

P.S. присутствуют тэги по которым разбираются события

[Kos]

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

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

• каждый раз, когда приходит новое значение для любого из перечисленных в триггерной формуле элементов данных;
• дополнительно к этому: раз в 30 секунд по таймеру, но лишь при наличии в триггерной формуле какой-либо из временнЫх функций (date/time/now/nodata/etc.).

Для решения задачи "в лоб" нужно было бы вместо исходного выражения:

{zclient:log[tmp/test].regexp("created")}=1

(которое проверяет лишь последнее полученное значение) использовать что-то другое; например:

{zclient:log[tmp/test].count(30s,"created","like",2m)}>0

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

{zclient:log[tmp/test].count(30s,"created","like",2m)}>0 and {zclient:log[tmp/test].time()}>=0

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

Только я потому и написал "в лоб", что такое решение, скорее всего, работать не будет - как минимум, по двум причинам:

• при таком условии в течение тех же 30 секунд в лог может попасть несколько записей "created", относящихся к разным процессам (с разными UUID-ами);
• в любом случае, тег, который формируется на базе макроса {ITEM.VALUE}, будет содержать значение UUID-а последней поступившей записи из лога, а не той, которая была там две минуты назад.

Таким образом, я бы пошёл по другому пути: я бы задержку добавлял не в сам триггер, а в оповещение. Т.е. сделал бы отдельный Action для таких событий, и в этом действии отсылку уведомлений ставил бы не первым шагом (как это обычно делается), а вторым, выставив продолжительность шагов по умолчанию в нужное для задержки значение (скажем, те же две минуты). Тут, правда, есть свои недостатки: проблема в любом случае будет "светиться" на экране проблем (Monitoring -> Problems), но этот эффект можно уменьшить выставлением уровня критичности для триггера (например, в "Not classified").

К сожалению, идеального варианта я придумать не могу – возможно, у кого-нибудь ещё будут идеи...

[vital8111]

Смысл понял.
Тут как раз такой вариант с задержкой оповещений не пройдет.
Оповещений ка ктаковых не будет а смотрим именно в дашборд.
Поэтому и стоит задача именно алерт выкидывать с задержкой

[Kos]

Да, похоже, что единственный вариант - массово голосовать за ZBXNEXT-4659, в котором как раз аналогичная ситуация описывается.