Мониторинг вновь создаваемого лог файла.

[Whols]

Сделал пока так, но полностью не отрабатывает.
logrt["/tmp/logs/etl2.log","FAILED| \d{4}-\d{2}-\d{2}-\d{2}-\d{2}",,,skip,\0]

Если хотите логические операции внутри регулярных выражений, то надо экранировать ():

(FAILED|\d{4}-\d{2}-\d{2}-\d{2}-\d{2})

Конкретно в этом случае не скажу точно, будет ли работать.

[Whols]

Но вам "или" не нужно. Сравнивайте со строкой "FAILED \d{4}-\d{2}-\d{2}-\d{2}-\d{2}". Тогда получаете эту строку как ITEMVALUE.

[Whols]

Например, искать в ней заведомо присуствующую строку "FAILED":

Подождите, зачем проверку еще и в тригере устраивать? У вас элемент активной проверки (т.е. на стороне агента) ищет строку "FALED" и отправляет на сервер в случае совпадения. Вам надо всего лишь nodata()=0 для триггера.

[Kos]

Подождите, зачем проверку еще и в тригере устраивать? У вас элемент активной проверки (т.е. на стороне агента) ищет строку "FAILED" и отправляет на сервер в случае совпадения. Вам надо всего лишь nodata()=0 для триггера.

Как я писал выше, у нас фильтр на "проблемную" строку указан прямо в ключе элемента данных, т.е. любое новое значение, пересылаемое агентом Zabbix, заведомо будет содержать строку "FAILED" и являться индикатором проблемы.
Триггер требует какого-то условия, чтобы срабатывать при поступлении нового значения. В данном случае, поскольку нужно реагировать на любое новое значение, то можно прописать самое простое условие. Я предложил сравнивать длину значения - она явно будет ненулевой, поскольку значение содержит, как минимум, подстроку "FAILED". Но с таким же успехом можно прописать и любое другое условие, которое в расках данной задачи будет выполняться всегда. Я упомянул str("FAILED")=1, но с ткаим же успехом можно указать, например, count(#1)>0 или какую-нибудь ещё тавтологию.

Автор темы хотел бы ручного закрытия проблемы (закрывает дежурный оператор, когда разберётся).
Триггерная функция nodata() требует обязательного параметра (длина периода для проверки). Для данной задачи она плоха тем, что:

• по истечении этого периода проблема закроется автоматически, что противоречит поставленной задаче (закрывать вручную);
• создаёт совершенно ненужную дополнительную нагрузку (поскольку триггер с временнЫми функциями пересчитывается каждые 30 секунд, что для данной задачи не нужно);
• не совместима с опцией "Multiple event generation".

[Narkolog]

Всем спасибо, все заработало так как надо! Большая благодарность всем кто откликнулся.
Но вот шеф немного усложнил задачу)), теперь необходим триггер на зависший job допустим выполнение задания начинается с 1 ночи до 7 утра, и если нет данных в логе "COMPLETED" слать сообщение на емаил
Написал следующий код: {HOST:log["/tmp/logs/etl2.log","COMPLETED",,,skip].nodata(21600)}=1, но действие идет постоянно как только закрываю руками проблему, он заново отсылает сообщение, подскажите пожалуйста правильный код?

[Kos]

Всем спасибо, все заработало так как надо! Большая благодарность всем кто откликнулся.
Но вот шеф немного усложнил задачу)), теперь необходим триггер на зависший job допустим выполнение задания начинается с 1 ночи до 7 утра, и если нет данных в логе "COMPLETED" слать сообщение на емаил

При такой постановке задачи проверять наличие (вернее, отсутствие) записи в логе надо раз в сутки - в тот момент, когда уже пора бить тревогу.
Пусть это будет, скажем 07:15 утра. Тогда я бы сформулировал условие, например, так:

{HOST:log["/tmp/logs/etl2.log","COMPLETED",,,skip].time()}>=071500
and
{HOST:log["/tmp/logs/etl2.log","COMPLETED",,,skip].time()}<071600
and
{HOST:log["/tmp/logs/etl2.log","COMPLETED",,,skip].count(7h)}=0

И выражение восстановления:

{HOST:log["/tmp/logs/etl2.log","COMPLETED",,,skip].count(1h)}>0

Комментарии:
Поскольку триггер содержит временнУю триггерную функцию time(), то вне зависимости от поступающих данных он будет пересчитываться каждые 30 секунд (чтобы отследить момент, когда сработает условие по времени).
Таким образом, реальная проверка будет выполняться в период с 07:15 до 07:16: если за последние 7 часов количество поступивших в лог-файл записей со строкой "COMPLETED" окажется нулевым, то триггер сработает. И останется в состоянии "Проблема" до тех пор, пока либо не появится такая свежая строка в логе (для этого нужно выражение восстановления), либо не будет закрыт вручную. Кроме того, выражения восстановления не даёт триггеру закрыться автоматически после 07:16, а ограничения по времени не позволят сработать триггеру заново после ручного закрытия.

[Narkolog]

Огромное спасибо! Записал код на триггер, но пока событие не произошло, тфью три раза, узнать результат не смогу)))

[Narkolog]

Запустил на тестовом сервере, отработки не было))), потому что прошло событие FAILED))) ждем дальше.

[Narkolog]

Не работает триггер, пробовал изменять условия выражения time() и count() на ближайщее время, сообщений от забикса не приходило и на Dashboard нет ничего.

Код такой:

JOB Hovering "COMPLETED"

{host:log["/tmp/logs/etl2.log","COMPLETED",,,skip].time()}=065900 and {host:log["/tmp/logs/etl2.log","COMPLETED",,,skip].time()}=070000 and {host:log["/tmp/logs/etl2.log","COMPLETED",,,skip].count(6h)}=0

[Semiadmin]

Чтобы этот триггер сработал, на часах должно быть 6.59 и 7.00 одновременно. Ситуация маловероятная, но наркологам виднее. Впрочем, даже если оставить одно условие time()=070000, намного лучше не станет. Триггер будет пересчитываться раз в 30 секунд, так что вероятность того, что он пересчитается ровно в 7 часов 0 минут 0 секунд, 1/30.

[Narkolog]

Тогда какие предложения?

[Semiadmin]

Так коллега Kos написал вам правильный триггер. Он плохого не посоветует.

[Kos]

Тогда какие предложения?

Делать нестрогое сравнение, прверяя время не на точное совпадение, а на интервал (от и до). Пример я приводил в своей предыдущей реплике. Не работает? Тогда давайте разбираться, почему не работает: покажите свой триггер, что высвечивает Latest data по данному айтему за последние сутки, и историю проблем по данному хосту за последние сутки.

[Whols]

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

[Narkolog]

Спасибо за подсказку, извиняюсь за невнимательность. В моем коде триггеров было точное указание, а не >= изменил триггер и сообщение пошло.