Парсинг лога Zabbix-агентом

[LeoZepp]

Настроил парсинг лог-файлов, заббих их видит, данные идут.
Ключ элемента данных указан на каждый из файлов лога:

log[/var/log/windows/1-xxx.log]
log[/var/log/windows/2-xxx.log]
log[/var/log/windows/3-xxx.log]

Хочу что бы при появлении в логах новой строки со значением к примеру "4722:" отрабатывал триггер и отправлял сообщение. Отправка отрабатывает, но очевидно триггер неправильно написан:

{********:log[/var/log/windows/1-xxx.log].str("4722:")}=1
{********:log[/var/log/windows/2-xxx.log].str("4722:")}=1
{********:log[/var/log/windows/3-xxx.log].str("4722:")}=1

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

[Kos]

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

[LeoZepp]

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

Да, пожалуйста. Ссылка на картинки

[LeoZepp]

И если как я понимаю парсинг настроен по упоминанию в строке события 4724


То приходит сообщение

[Kos]

То есть уведомления доставляются через Телеграмовский скрипт... Ну ладно.
1) То сообщение, которое доходит, действительно ли есть в указанном логе? Если да - то далеко ли оно от искомого сообщения (с кодом "4724")? Если смотреть Monitoring -> Latest data, то эти сообщения попадали в Zabbix с большим интервалом (разница между Zabbix-ными таймстэмпами)?
2) А что видно в логе действий? Monitoring -> Triggers, найти нужное срабатывание триггера (возможно, через фильтр, выставив статус "Any", если триггер уже закрылся), нажать на дату, чтобы выбрать событие, ещё раз нажать на дату, чтобы посмотреть подробности -- в первую очередь, Message Actions справа?
3) Реально триггер срабатывал один раз, или же было несколько срабатываний подряд?
4) На триггере взведён ли флажок "Multiple PROBLEM events generation"?

[LeoZepp]

То есть уведомления доставляются через Телеграмовский скрипт... Ну ладно.
1) То сообщение, которое доходит, действительно ли есть в указанном логе? Если да - то далеко ли оно от искомого сообщения (с кодом "4724")? Если смотреть Monitoring -> Latest data, то эти сообщения попадали в Zabbix с большим интервалом (разница между Zabbix-ными таймстэмпами)?
2) А что видно в логе действий? Monitoring -> Triggers, найти нужное срабатывание триггера (возможно, через фильтр, выставив статус "Any", если триггер уже закрылся), нажать на дату, чтобы выбрать событие, ещё раз нажать на дату, чтобы посмотреть подробности -- в первую очередь, Message Actions справа?
3) Реально триггер срабатывал один раз, или же было несколько срабатываний подряд?
4) На триггере взведён ли флажок "Multiple PROBLEM events generation"?

1) Да, есть. Достаточно далеко (каждый раз дальность рандомная). Если смотреть в Monitoring -> Latest data, то интервал так же рандомный
2) Видно что событие было отправлено (оно и было отправлено) с тем же текстом ошибки, что и в телеграм прилетело.
3) Бывает срабатывает 1 раз, бывает и несколько раз подряд.
4) Флажок не стоит.

[Kos]

Действительно, странно.
У меня было нечто подобное, когда из лога Windows-машины в Zabbix приходило несколько значений подряд, и пока отрабатывалась вся цепочка (вычисление триггера -> его срабатывание -> запись в соответствующие таблицы о срабатывании триггера, о необходимости действий -> вычисление необходимых операций эскалации -> выполнение эскалаций) на одно из этих значений (реально вызвавшее проблему), то на момент раскрытия макроса (у меня использовался {ITEM.VALUE1}) выбиралось уже следующее пришедшее значение, а не то, на которое сработал триггер.

А какая у Вас версия Zabbix-сервера?

И ещё вопрос: обычно, одно значение log[...] - это одна строка из лог-файла. В Вашем случае так и есть? Т.е. всё, что приходит в уведомлении (начиная с "<29>1" и заканчивая "Parameter 2:") - это всё одна строка?

[LeoZepp]

Действительно, странно.
У меня было нечто подобное, когда из лога Windows-машины в Zabbix приходило несколько значений подряд, и пока отрабатывалась вся цепочка (вычисление триггера -> его срабатывание -> запись в соответствующие таблицы о срабатывании триггера, о необходимости действий -> вычисление необходимых операций эскалации -> выполнение эскалаций) на одно из этих значений (реально вызвавшее проблему), то на момент раскрытия макроса (у меня использовался {ITEM.VALUE1}) выбиралось уже следующее пришедшее значение, а не то, на которое сработал триггер.

А какая у Вас версия Zabbix-сервера?

И ещё вопрос: обычно, одно значение log[...] - это одна строка из лог-файла. В Вашем случае так и есть? Т.е. всё, что приходит в уведомлении (начиная с "<29>1" и заканчивая "Parameter 2:") - это всё одна строка?

Версия: zabbix_server (Zabbix) 3.0.4
Да, у меня это все одна строка начиная с <29>1

[LeoZepp]

Действительно, странно.
У меня было нечто подобное, когда из лога windows-машины в zabbix приходило несколько значений подряд, и пока отрабатывалась вся цепочка (вычисление триггера -> его срабатывание -> запись в соответствующие таблицы о срабатывании триггера, о необходимости действий -> вычисление необходимых операций эскалации -> выполнение эскалаций) на одно из этих значений (реально вызвавшее проблему), то на момент раскрытия макроса (у меня использовался {item.value1}) выбиралось уже следующее пришедшее значение, а не то, на которое сработал триггер.

А как победили эту проблему?

[Kos]

А как победили эту проблему?

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

log[/var/log/windows/1-xxx.log]

ставил бы:

log[/var/log/windows/1-xxx.log,"4722: "]

, а триггер бы ставил с условием

{Host.log[/var/log/windows/1-xxx.log,"4722: "].nodata(30)}=0

(срабатывать только для "свежих" значений, через 30 секунд закрываться).

Тут, правда, есть шанс нарваться на неприятность, которую я описывал раньше и которая, к сожалению, до сих пор не устранена.
Если НЕ ставить галочку "Multiple PROBLEM events generation", то можно пропустить событие, которое идёт вскоре после предыдущего (в логе две искомые строки появились с интервалом <30 секунд, триггер сработает на первое событие и пришлёт уведомление, а второе будет пропущено, т.к. на момент обработки этого значения сервером триггер ещё не вернулся в состояние "OK").

Если же СТАВИТЬ эту "галочку", то, наоборот, могут приходить дубликаты уведомлений (один раз триггер срабатывает по приходу нового значения, другой раз - поскольку настало время пересчитать условие триггера nodata() серверным процессом timer).
По этому поводу мной была открыта проблема ещё два года назад, но, видимо, у разработчиков она далеко не в топе приоритетов. Наверное, слишком мало проголосовавших (зарегистрировавшись, можно нажать на ссылку "Vote for this issue" справа вверху)

[LeoZepp]

Ну, т.е. в Вашем случае я бы вместо

log[/var/log/windows/1-xxx.log]

ставил бы:

log[/var/log/windows/1-xxx.log,"4722: "]

, а триггер бы ставил с условием

{Host.log[/var/log/windows/1-xxx.log,"4722: "].nodata(30)}=0

(срабатывать только для "свежих" значений, через 30 секунд закрываться).

Думал об этом, тогда на каждый из 3х лог-файлов придется вешать по 7 элементов данных с разным значением (4722, 4728, 5136 и т.д.), а это кажется не очень правильным + nodada=0 не могу использовать, иначе сообщения в telegram не будут отправляться вообще.

[LeoZepp]

Интересно, а есть возможность что бы данные с событием 4624 вообще не поступали на сервер Zabbix? Тогда проблема бы ушла.

[Kos]

Думал об этом, тогда на каждый из 3х лог-файлов придется вешать по 7 элементов данных с разным значением (4722, 4728, 5136 и т.д.), а это кажется не очень правильным + nodada=0 не могу использовать, иначе сообщения в telegram не будут отправляться вообще.

Ну, можно попытаться обойтись одним элементом данных:

log[/var/log/windows/1-xxx.log,"(4722|4728|5136|...): "]

а в триггерах проверять str(искомая строка)=1 and nodata(30)=0 (для каждого триггера искомая строка - своя). В любом случае, основная идея - передавать на сервер не всё содержимое лога, а только интересующие записи.

Update:
Это, кстати, ответ и на Ваш последний вопрос :-)

[LeoZepp]

Ну, можно попытаться обойтись одним элементом данных:

log[/var/log/windows/1-xxx.log,"(4722|4728|5136|...): "]

а в триггерах проверять [b]str(искомая строка)=1

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