Монитортно лога

[aleksey.ishchenko]

Нужно мониторить файл лога на наличие строки Ошибка записи файла
сделал элемент данных llog[C:\exchange\in\TBPPv620\log\cmsrec.log,,,,skip,] и триггер ffind(/S019/log["C:\exchange\in\TBPPv620\log\cmsrec.log","^.*Ошибк а записи файла.*.в каталог <\\F01FS\CMS_IMP\IN\TBPP\>.*$"],,,"Ошибка")=1
Выражение восстановления
find(/W31271589/log[C:\exchange\in\TBPPv620\log\cmsrec.log,,,,skip,],,,"сохранен в каталог")=1
Но данных нет в истории. В чем ошибка?
Zabbix 6.4.15

[Kos]

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

[Kos]

Но данных нет в истории. В чем ошибка?

Причинами могут быть, например:

• тип элемента данных выставлен не "Zabbix agent (active)", а другой (например, просто "Zabbix agent");
• данные в исходном файле не в UTF-8, а в другой кодировке (тогда её надо явно указать третьим параметром ключа элемента данных);
• вторым параметром ключа элемента данных задано не совсем подходящее регулярное выражение. Собственно, это уже очевидно (если это не ошибка копипаста на форум):

  /S019/log["C:\exchange\in\TBPPv620\log\cmsrec.log","^.*Ошибка записи файла.*.в каталог <\\F01FS\CMS_IMP\IN\TBPP\>.*$"]

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

Кроме того, есть ещё возможная ошибка в определении триггера.
Во-первых, в выражении триггера ссылка на несуществующий элемент данных (который имеет в ключе второй параметр, но не имеет параметра "skip"). Наверное, такой элемент данных у вас тоже есть, иначе не удалось бы сохранить триггер с таким выражением.
Во-вторых, если используется действительно элемент данных с таким регулярным выражением во втором параметре ключа, в качестве значений для такого элемента данных будут собираться только строки, соответствующие этому регулярному выражению (т.е. заведомо содержащие слово "Ошибка") - соответственно, условие триггера будет выполняться для каждого входящего значения. Но такой триггер, сработав один раз, никогда не закроется - поскольку для этого нужно, чтобы перестало выполняться условие срабатывания триггера (а при наличии выражения восстановления - дополнительно к этому, ещё и выполнилось условие восстановления).

[aleksey.ishchenko]

Стоит агент активный, кодировка UTF-8 в файле
Что-то неправильно в элементе данных? В параметре

Ошибк а записи файла

так скопировалось.
Изменил на log[C:\exchange\in\TBPPv620\log\cmsrec.log,,,,skip,]
Но триггер не срабатывает

[Kos]

Изменил на log[C:\exchange\in\TBPPv620\log\cmsrec.log,,,,skip,]
Но триггер не срабатывает

А данные от агента поступают? В Latest data их видно?

[aleksey.ishchenko]

Данные от агента поступают, в последниъх данных видно

[Kos]

Данные от агента поступают, в последниъх данных видно

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

[aleksey.ishchenko]

Запись выглядит вот так
024-05-14 22:18:43,048 ERROR - Ошибка записи файла <MKB_PP_2405142203.uamp> в каталог <\\F01FS\CMS_IMP\IN\TBPP\>.
Код ошибки: 53 - The network path was not found.
2024-05-14 22:19:39,835 INFO - Прием файлов из очереди <vrsap00\private$\cmstbpp>
2024-05-14 22:19:39,850 INFO - Принят файл - <MKB_PP_2405142215.uamp>, дата - <2024-05-14 22:15:11,824>, размер - 5972 байт
2024-05-14 22:19:39,866 INFO - Файл - <MKB_PP_2405142215.uamp> успешно распакован. Новый размер - 39199 байт
2024-05-14 22:19:39,897 INFO - Файл <MKB_PP_2405142215.uamp> сохранен в каталог <\\F01FS\CMS_IMP\IN\TBPP\> (Записано 39199 байт).
2024-05-14 22:19:40,914 INFO - Прием файлов завершен (Принято 1 файлов).
Если создать шаблон, то триггер срабатывает
элемент данных
log[C:\exchange\in\TBPPv620\log\cmsrec.log,Ошибка записи файла]
триггер find(/Monitoring Log CMS/log[C:\exchange\in\TBPPv620\log\cmsrec.log,Ошибка записи файла],,"like","Ошибка записи файла")=1
сейчас почему-то не срабатывает восстановление

find(/Monitoring Log CMS/log[C:\exchange\in\TBPPv620\log\cmsrec.log,Ошибка записи файла],,"like","сохранен в каталог <\\F01FS\CMS_IMP\IN\TBPP\>")=1

если по условию появилась запись

сохранен в каталог

[Kos]

Запись выглядит вот так

Т.е. "ошибка записи" одного файла, а "сохранён в каталог" другой, но это ОК и вы хотите в такой ситуации проблему закрывать?

сейчас почему-то не срабатывает восстановление

Я же объяснял выше, почему так будет происходить.
Чтобы сработало восстановление, должно выполниться два условия: 1) перестать выполняться основное условие триггера; 2) дополнительно к этому - выполниться условие восстановления. Но основное условие триггера (в таком виде, как у вас сформулировано) будет выполняться всегда, как только придёт первое же значение.

[aleksey.ishchenko]

Т.е. "ошибка записи" одного файла, а "сохранён в каталог" другой, но это ОК и вы хотите в такой ситуации проблему закрывать?

Перекладыванем файл занимается очередь msmq, при отправке файла копия помещается в папку архива и копия в папку назначения, в случае ошибки, файл появляется только в папке архива на исчточнике \\S019\exchange\in\TBPPv620\ARCH. Видимо только руками закрывать триггер.

[Kos]

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