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

[vreis]

Надо мониторить лог фаил, с названием c:\logs\YYYYMMDD.log хочу следить за ошибкой, например "No such file or directory", незнаю, как правилно описать item,чтобы всегда проверялся сегодняшний лог файл.

Подскажите пожалуйста zabbix 2.0.6

[readmy]

Добрый день.
Таже ситуация, как мониторить лог файлы с меняющиеся датой в названии файла?

[readmy]

пример:
путь до лога
C:\Program Files (x86)\Digispot II\DJin2\DjinRRVL\DBG_LOG\rrvl_2020-02-10__00_00_00.0003.txt
Пишу:
logrt["C:\Program Files (x86)\Digispot II\DJin2\DjinRRVL\DBG_LOG\rrvl_[0-9]{4}-[0-9]{2}-[0-9]{2}__[0-9]{2}_[0-9]{2}_[0-9]{2}.[0-9]{4}.txt","REASON=SetLockRemote",UTF-8,100,skip]
НЕ РАБОТАЕТ!!!
КАК ПРАВИЛЬНО НАПИСАТЬ?

[Kos]

Реально работающий пример:

logrt["C:\Dealing\PrimeFIXLoader\logs\^[0-9]{4}-[01][0-9]-[0-3][0-9].log$",,,,skip]

Контролирует лог-файлы, имена которых имеют формат C:\Dealing\PrimeFIXLoader\logs\YYYY-MM-DD.log.

Другой пример:

logrt["C:\RemoteSW\^Javalog20[0-9]{6}.log$"," \[FATAL\] ",,,skip]

Контролирует файлы (логи Java-приложения), имена которых имеют формат C:\RemoteSW\JavalogYYYYMMDD.log, на предмет строк, содержащих подстроку "[FATAL]", окружённую пробелами.

В обоих случаях используются агенты v4.0.x.

Я не вижу явных причин, почему может не работать в Вашем случае. Могу только предполагать:
1) Используется старая версия агентов. Прежние версии не поддерживали регулярные выражения PCRE, в частности - конструкцию "[0-9]{2}" (но вполне справлялись с аналогичной по смыслу конструкцией "[0-9][0-9]").
2) Возможно, что реально используется не та кодировка, которая указана (в данном случае - UTF-8). Перепроверить!
3) Если в настройках элемента данных нужно поменять кодировку, то лучше сам элемент данных при этом пересоздать (чтобы он имел другой ID). Т.е. вместо редактирования этого элемента данных делаем клон, в котором указываем другую кодировку, после чего исходный элемент данных удаляем. Потому как при смене кодировки (особенно с разным количеством байт на символ - скажем, UTF-8 на UTF-16, или Windows-1251 на UTF-8) иногда возникают совершенно непонятные эффекты; проще пересоздать сам элемент данных, чем в них разбираться.

Если же ничего не помогает, то в конфиге агента можно выставить DebugLevel=4 и пытаться разбираться по его логам, как он себя ведёт.

[readmy]

Реально работающий пример:

logrt["C:\Dealing\PrimeFIXLoader\logs\^[0-9]{4}-[01][0-9]-[0-3][0-9].log$",,,,skip]

Контролирует лог-файлы, имена которых имеют формат C:\Dealing\PrimeFIXLoader\logs\YYYY-MM-DD.log.

Другой пример:

logrt["C:\RemoteSW\^Javalog20[0-9]{6}.log$"," \[FATAL\] ",,,skip]

Контролирует файлы (логи Java-приложения), имена которых имеют формат C:\RemoteSW\JavalogYYYYMMDD.log, на предмет строк, содержащих подстроку "[FATAL]", окружённую пробелами.

В обоих случаях используются агенты v4.0.x.

Я не вижу явных причин, почему может не работать в Вашем случае. Могу только предполагать:
1) Используется старая версия агентов. Прежние версии не поддерживали регулярные выражения PCRE, в частности - конструкцию "[0-9]{2}" (но вполне справлялись с аналогичной по смыслу конструкцией "[0-9][0-9]").
2) Возможно, что реально используется не та кодировка, которая указана (в данном случае - UTF-8). Перепроверить!
3) Если в настройках элемента данных нужно поменять кодировку, то лучше сам элемент данных при этом пересоздать (чтобы он имел другой ID). Т.е. вместо редактирования этого элемента данных делаем клон, в котором указываем другую кодировку, после чего исходный элемент данных удаляем. Потому как при смене кодировки (особенно с разным количеством байт на символ - скажем, UTF-8 на UTF-16, или Windows-1251 на UTF-8) иногда возникают совершенно непонятные эффекты; проще пересоздать сам элемент данных, чем в них разбираться.

Если же ничего не помогает, то в конфиге агента можно выставить DebugLevel=4 и пытаться разбираться по его логам, как он себя ведёт.

Спасибо! Это прям то что НАДО!
буду экспериментировать.