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

[Narkolog]

Всем привет, помогите пожалуйста новичку.
Необходимо настроить забикс на чтение самого свежего лога и высылать результат на почту. есть папка куда Crontab будет сохранять лог по событию, путь следующий /tmp/logs/xxxx.log. По настройкам Crontab каждый день будет создаваться лог на событие, etl_2020-10-30-10-45.log и так далее.
Пробовал создавать item на лог, но там требуется абсолютный путь до файла, а он будет меняться каждый день
Подскажите пожалуйста как решить эту задачу?

[Kos]

Если путь к файлу (т.е. папка) фиксированный, а меняется только имя файла, то логично использовать метрику logrt[...]. Или надо искать в логе не отдельную строку, а пересылать всё содержимое целиком?

[Narkolog]

Есть путь /tmp/logs, фаил создается с такими датами etl_2020-10-30-10-45.log, etl_2020-11-02-10-45.log
Подскажите пожалуйста полностью метрику logrt?
Zabbix item должен после прочтения лога отправлять на емаил либо "COMPLETED", либо "FAILED"

[Hamardaban]

https://www.zabbix.com/documentation/current/ru/manual/config/items/itemtypes/zabbix_agent

выражение для поля файл_regexp примерно такое “ ^/tmp/logs/etl_\d{4}-\d{2}-\d{2}-\d{2}-\d{2}\.log$”

[Hamardaban]

К стати не совсем понятно что именно вы хотите «мониторить»?

Если содержимое лог файлов с именем которого меняется - тогда logrt
Если наличие или количество определенных файлов - тогда vfs.dir.count

Если что-то иное - читайте о возможностях в документации и выбирайте наиболее подходящее.

[Narkolog]

В каждом новом лог файле хочу мониторить значения "COMPLETED", либо "FAILED"
и к нему прикрутить уже триггер, Получается новый день, новый лог фаил и в нем значения "COMPLETED", либо "FAILED"
Спасибо всем большое, толкаете меня в нужном направлении!!

Отказывается высылать данные лога
142956:20201102:203348.537 In need_meta_update() key:logrt["/tmp/logs/etl_\d{4}-\d{2}-\d{2}-\d{2}-\d{2}\.log$"]
142956:20201102:203348.537 End of need_meta_update():SUCCEED
142956:20201102:203348.537 In process_value() key:'Test-wildfly:logrt["/tmp/logs/etl_\d{4}-\d{2}-\d{2}-\d{2}-\d{2}\.log$"]' lastlogsize:0 value:'(null)'
142956:20201102:203348.537 buffer: new element 0
142956:20201102:203348.537 End of process_value():SUCCEED
142956:20201102:203348.537 In send_buffer() host:'10.231.3.70' port:10051 entries:1/100
142956:20201102:203348.537 send_buffer() now:1604327628 lastsent:1604327628 now-lastsent:0 BufferSend:5; will not send now
142956:20201102:203348.537 End of send_buffer():SUCCEED
142956:20201102:203348.537 End of process_active_checks()

[Narkolog]

Создал итем с таким ключом logrt["/tmp/logs/etl_\d{4}-\d{2}-\d{2}-\d{2}-\d{2}\.log$"], и почему то никакой реакции от забикса. В веб интерфейсе пишет активировано и все.

[Whols]

Последний слэш перед расширением зачем?

logrt["/tmp/logs/^etl_\d{4}-\d{2}-\d{2}-\d{2}-\d{2}.log$"]

[Hamardaban]

чтобы отличать
. matches any character (except for line terminators)
и
\. matches the character . literally (case sensitive)


конечно и без слеша сработает ибо первое включает в себя и второе

[Whols]

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

logrt["/tmp/logs/^etl_\d{4}-\d{2}-\d{2}-\d{2}-\d{2}.log$","COMPLETED",,,skip,\0]

Тогда на выходе вы получаете ITEMVALUE в виде совпадения, а не всей строки. Ну и ведете поиск только по вновь созданным файлам (как я понимаю, первая проверка будет до первого совпадения).
-
На FAILED надо создать отдельный элемент.

[Narkolog]

Спасибо за подсказку, попробовал ваш код в итемсе, пока результатов нет.

Заметил одну странность, при создании лога в ручную с другим размером в килобайтах, триггер срабатывает и емаил улетает на почту.

Складывается впечатление, что файлы одного размера не подходят под код итемса и он ничего не отправляет.

Вот данные из лога агента:

In need_meta_update() key:logrt["/tmp/logs/etl2_\d{4}-\d{2}-\d{2}-\d{2}-\d{2}\.log$","FAILED",,,skip,\0]
151802:20201104:083748.826 End of need_meta_update():FAIL

[Narkolog]

Задачу упростили, теперь файл будет один, в нем будут значения "FAILED" 2020-11-04-15-03, дата будет меняться
как мне в коде ключа вывести эти два значения.
Сделал пока так, но полностью не отрабатывает.
logrt["/tmp/logs/etl2.log","FAILED| \d{4}-\d{2}-\d{2}-\d{2}-\d{2}",,,skip,\0]

[Kos]

А зачем вам два значения? Если хотите срабатываний только на строку "FAILED", то можно выводить лишь таймстэмп заданий, завершившихся с ошибкой.

И ещё.
Отсылка уведомлений в Zabbix-е - это действие, которое выполняется в качестве реакции на срабатывание триггера.
Предвидя дальнейшие телодвижения, сразу спрошу: а как и каким образом вы собираетесь закрывать этот триггер?
Например:

• автоматически сразу после срабатывания (отослали уведомление, и ладно);
• вручную, пока не закроет соответствующий сотрудник;
• при следующем успешном выполнении cron-задания (т.е. минимум на следующий день, если задание запускается раз в сутки).

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

[Narkolog]

Закрывать будет дежурник
Уведомлений не нужно о восстановлении, достаточно того, что дежурник увидел и закрыл.
Может я немного путанно обьяснил, но надо письме выводить полную строку события: FAILED" 2020-11-04-15-03, с каждой новой датой.

[Kos]

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

Закрывать будет дежурник
Уведомлений не нужно о восстановлении, достаточно того, что дежурник увидел и закрыл.
Может я немного путанно обьяснил, но надо письме выводить полную строку события: FAILED" 2020-11-04-15-03, с каждой новой датой.

Тогда, раз имя файла фиксировано, то нет смысла использовать logrt, можно обойтись более простой метрикой log.
Если строка FAILED всегда содержит дату/время, и выводить надо всю строку целиком, то нет смысла искать там таймстэмп отдельным регулярным выражением.
В итоге, метрика существенно упрощается:

log["/tmp/logs/etl2.log","FAILED",,,skip]

- будут пересылаться любые строки, содержащие подстроку "FAILED".

Если это работает, то далее уже можно извращаться с триггером.
Поскольку поступать будут только строки, содержащие подстроку "FAILED", то реагировать надо на любое новое значение.
Например, искать в ней заведомо присуствующую строку "FAILED":

{HOST:log["/tmp/logs/etl2.log","FAILED",,,skip].str("FAILED")}=1

Или просто проверять, что она непустая:

{HOST:log["/tmp/logs/etl2.log","FAILED",,,skip].strlen()}>0

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

И уже на уровне триггера можно при желании вытягивать таймстэмп, скажем, в имя проблемы, если использовать macro functions.
Например, так:

{{ITEM.VALUE}.regsub("FAILED\s+(\d{4}-\d{2}-\d{2}-\d{2}-\d{2})","\1")}

И в случае, когда задание завершается ошибкой несколько раз подряд - надо ли присылать уведомления по каждому сбою?

Если надо получать уведомления на новое срабатывание, когда ещё не закрыта предыдущая проблема, то добавить ещё настроку "Multiple problem generation".

[Narkolog]

Благодарю! Самое то решение. Запустил такой код на тригеррах

{host:log["/tmp/logs/etl2.log","FAILED",,,skip].logeventid(""FAILED"")}=0 and {host:log["/tmp/logs/etl2.log","FAILED",,,skip].logeventid(\d{4}-\d{2}-\d{2}-\d{2}-\d{2})}=0

Запустил кронтаб жду результата))

[Kos]

Ну, строго говоря, триггерная функция logeventid() (так же как и logseverity() и logsource()) имеет смысл только для элементов данных с ключом eventlog[...] (сообщения из Windows Event Log-а, где для них собираются соответствующие метаданные). Что она будет возвращать в остальных случаях - фиг его знает. Скорее всего, нули (поскольку не найдёт совпадений), в результате чего Ваша конструкция будет работать как ожидается, но как-то это контринтуитивно (особенно с вызовом этой функции дважды, да ещё и с учётом передаваемых этой функции параметров, которые нигде не играют роли).

[Narkolog]

В общем оно работает, но я переделаю по вашему совету. Подскажите пожалуйста, какое значение использовать в триггере?

[Kos]

В общем оно работает, но я переделаю по вашему совету. Подскажите пожалуйста, какое значение использовать в триггере?

Ну я ж писал выше.
Я бы сам остановился на варианте

{HOST:log["/tmp/logs/etl2.log","FAILED",,,skip].strlen()}>0

как одном из самых наглядных (не нужно долго думать, что означает это триггерное выражение).