Мониторинг лог файлов

[metalhead]

Всем привет. Есть задача мониторить лог файлы на Windows машине на предмет наличия в них определённой строки. Лог файлы создаются каждый день в полночь с именем в формате YYYYMMDD.log, старые лог файлы не удаляются, они так же остаются в той же папке.
Не могу понять как в Item-е в параметр Key прописать путь к файлу -- log[file,C:\path\to\logs\yyyymmdd.log] и чтобы старые лог файлы не считывались агентом. То есть читаться должен только актуальный на данный момент лог файл, например 20230628.log .

Может кто-то подсказать как это сделать?

[Kos]

Может кто-то подсказать как это сделать?

Использовать предназначенный именно для таких ситуаций ключ logrt[...], а не log[...]. Чтобы при начальном создании элемента данных не обрабатывались все логи, используйте в параметре mode значение skip.
Примерно так:

logrt["C:/path/to/logs/\d{8}\.log","искомая строка",UTF-8,,skip]

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

[metalhead]

Спасибо, Kos, но, к сожалению, триггер почему-то не срабатывает. Вот мой Item и его триггер на примере статичного файла:




Разве не должно работать со значением last(0)=1? Пробовал также со значением <>0, результат тот же.
В лог файле искомый текст "add tick" присутствует и он появился после создания Item-а, если это имеет значение.

[Kos]

Разве не должно работать со значением last(0)=1? Пробовал также со значением <>0, результат тот же.
В лог файле искомый текст "add tick" присутствует и он появился после создания Item-а, если это имеет значение.

Разумеется, не должно.
Значением, которое возвращается метрикой "log[...]" (также как и "logrt[...]") будет вся строка из лог-файла. В вашем случае она будет содержать, как минимум, подстроку "add tick", поэтому сравнивать всю эту строку с единицей - заведомо плохая мысль, равенства не будет никогда.
Теоретически, можно из всей этой строки выкусывать какие-то фрагменты (при помощи регулярного выражения и параметра <output>), но это уже следующий "наворот", который можно обсудить позже.

Тем не менее, раз данные пошли (т.е. вы видите нужные строки на экране последних данных, "Latest data"), то полдела уже сделано: коммуникации с агентом есть, файл мониторится, данные поступают. Осталось разобраться с триггером, но для этого вы сами должны чётко сказать: на что именно этот триггер должен реагировать? По какому набору условий он должен срабатывать (генерировать проблему) и по какому - закрываться? Исходя из этого, можно будет советовать что-то более конкретное.

[Hamardaban]

Ключ logrt возвращает строку. Вы сравнивая ее с 1 в выражении триггера какой результат хотите получить?

пардонте за повтор - пока писал Kos уже написал всё гораздо обстоятельнее! :-)

И позволю себе продолжить: если задачей является просто реакция на появление подстроки в логе проще\лучше использовать ключики log.count \ logrt.count которые возвращают количество строк с которым удобнее работать. Тогда триггер может быть просто logrt.count > 0.

[metalhead]

Значением, которое возвращается метрикой "log[...]" (также как и "logrt[...]") будет вся строка из лог-файла. В вашем случае она будет содержать, как минимум, подстроку "add tick", поэтому сравнивать всю эту строку с единицей - заведомо плохая мысль, равенства не будет никогда.

попробовал такое выражение в триггере и всё равно не срабатывает:

({MT FX Demo:log["C:/MetaTrader4Server/logs/sample.log"].regexp("add tick")}=1)

у Item-а тип данных ставил Log/Text//Character - ничего не помогает.

вы видите нужные строки на экране последних данных, "Latest data"

Нет, данных на экране Latest Data по этому Item-у нету

на что именно этот триггер должен реагировать? По какому набору условий он должен срабатывать (генерировать проблему) и по какому - закрываться

Триггер должен реагировать на появление искомого текста "add tick" в строке и вывести всю эту строку в сгенерированное письмо которое отправляется админам. Насчёт закрытия - наверное будем закрывать проблему вручную (Allow manual close) т.к. условия по которому проблема будет считаться решённой нету (в логе не будет такой записи), но в теории искомый текст после ручного закрытия может снова появиться и триггер снова должен сработать, а мы снова будем фиксить и закрыть проблему =)

[Kos]

Нет, данных на экране Latest Data по этому Item-у нету

Тогда моё предположение о том, что "данные пошли", неверно, и надо разбираться с этим.
Проверьте, что:

• тип элемента данных - "Zabbix agent (active)", а не просто "Zabbix agent" (логи могут мониториться только агентом в активном режиме);
• тип информации для него - "Log";
• интервал обновления - короткий (не больше нескольких секунд);
• имя хоста точно (с учётом регистра букв) совпадает на стороне агента и на стороне сервера Zabbix. На стороне агента - агент пишет его в свой лог-файл при старте агента (первой строкой в квадратных скобках), на стороне сервера - в свойствах хоста (узла сети), в поле "Host name" ("Имя узла сети") - не путать с соседним полем "Visible host name" ("Видимое имя").

Если здесь всё ОК, то можно временно выставить на агенте (в его конфиг-файле) параметр "DebugLevel=4", рестартануть агента, после чего воспроизвести проблемную ситуацию (т.е. добавить в ваш лог-файл нужную запись) и смотреть по логу агента, что там происходило.

Формула триггерного выражения у вас выглядит корректной, с одним замечанием: судя по синтаксису, у вас используется версия Zabbix не выше 5.2 (начиная с 5.4, синтаксис поменялся). А эти версии уже более не поддерживаются (ссылка). Я бы советовал обновиться, как минимум, на текущую версию LTS (на данный момент - 6.0).

[metalhead]

Всё проверил, всё выставил как на скринах ниже, в конфиг файла добавил "DebugLevel=4" и имя хоста, рестартнул заббикс агента, добавлял/удалял искомый текст в sample.log файл, но агент его полностью игнорирует, в лог файле о нём ни слова. Другие Item-ы активно проверяются и логгируются.
Обновить заббикс сервер пока возможности нет..

[Kos]

Всё проверил, всё выставил как на скринах ниже, в конфиг файла добавил "DebugLevel=4" и имя хоста, рестартнул заббикс агента, добавлял/удалял искомый текст в sample.log файл, но агент его полностью игнорирует, в лог файле о нём ни слова. Другие Item-ы активно проверяются и логгируются.

С таким элементом данных любые добавляемые в файл строки должны пересылаться на сервер и отображаться на экране последних данных ("Latest data") при выборе там конкретного хоста. Если этого не происходит - можно с триггером пока вообще не заморачиваться: он не сработает, пока не будут нормально поступать данные.
Я у себя перепроверил - нормально данные собираются, пробовал в ключе элемента данных указывать имя файла и с прямыми слэшам и с обратными, и в двойных кавычках, и без - прекрасно всё собирается. Правда, у меня агент поновее (версии 6.0.4), но в этом плане там изменений не было давно.

В лог-файле в режиме отладки должен быть виден, как минимум, обмен конфигурационными данными между агентом в активном режиме и сервером - должно быть видно, что идёт запрос с параметром "request": "active checks", а на него приходит ответ со списком нужных проверок, который включает элемент даных с нужным ключом. Как альтернатива (если что-то где-то настроено неверно) - возврат пустого списка либо ругань на то, что сервер не может прислать список нужных проверок.

При просмотре через веб-интерфейс Zabbix - элемент данных не переходит ли в неподдерживаемое состояние?
На этом хосте есть ещё какие-либо элементы данных, работающие в активном режиме? Если да - они работают нормально?