Банальный мониторинг лога

[friis]

Добрый день!

Читаю интернет - не совсем догоняю, а в офиц. документации обрывается на элементе данных - примера настройки триггера уже нет.

Подскажите пожалуйста - задача стоит простенькая.
Нужно мониторить лог файл Линукса на предмет error в нем.


Поставил агента на целевой линукс, дал права на чтение лог файла всем пользователям.
Настроил Элемент - пинг для целевой системы - пинг есть - т.е. связность есть

Настроил Элемент данных для мониторинга лога:
как на скриншоте

Подскажите как сделать триггер на сработку по ERROR in app, с откатом в состояние ОК после 5 минут отсутствия новых error


------------------
Заранее благодарен

[friis]

Что то не могу 2 фотки залить

[friis]

Сделал такой триггер но что то не идет

[friis]

Наверно все уже на рождественских каникулах - с праздником !

[pzabortsev]

Да нет, видимо все ждут, когда вы дочитаете доку до раздела Эскалация ))

Например вот: https://www.zabbix.com/documentation...on/escalations

[friis]

Спасибо что откликнулись. С экскалацией знаком - до этого штук 10 действий настроил


Проблема была в том чтобы - возращать в триггер в состояние ОК после отсутствия новых ошибок, но похоже что {linux-:log[/var/log/uwsgi/driva.log,ERROR in app].str(ERROR in app,300)}=1
сам возвращает в "ок", если в течение пяти минут не было ошибки

Вообщем сейчас базовый функционал мониторинга работает.

Не сталкивался ли кто то с более мощным анализом лога? - например на предмет если ошибка идет таже (errors в логе)- то уже не реагировать на однотипные ?

[friis]

Поторпился я сказать что все ОК

Триггер с выражением {linux:log[/var/log/uwsgi/driva.log,ERROR in app].str(ERROR in app,1200)}=1

не отстреливает обратно в ОК спустя 1200 секунд

Помогите пожалуйста переписать данное выражение чтобы при отстутствии error в течении 1200 секунд он отстреливался обратно в ОК ...

[friis]

С новым годом всех!

Неужели никто не делал столь банального мониторинга логов ?

[Kos]

Ваше выражение триггера пересчитывается каждый раз при поступлении новых данных.

В Вашем случае выражение триггера

{Хост:ЭлементДанных.str(ERROR in app,1200)}=1

отрабатывало бы нормально в случае, если бы в элемент данных регулярно попадали различные значения: тогда на строку "ERROR in app" триггер бы открывался, а на любую другую (если при этом "ERROR in app" не было за последние 20 минут) - закрывался.
Но у Вас сам ЭлементДанных сформулирован так, что он отфильтровывает только "проблемную" строку; никакие другие туда не попадут. Т.е. если "всё хорошо", то новые данные на сервер Zabbix не поступают, и у него просто нет повода пересчитывать состояние такого триггера.

Как вариант, можно предложить добавить в выражение триггера временнУю функцию, тогда его состояние будет дополнительно пересчитываться каждые 30 секунд отдельным серверым процессом timer. Самое простое - это использовать функцию nodata():

{linux:log[/var/log/uwsgi/driva.log,ERROR in app].nodata(1200)}=0

Только при этом надо иметь в виду, что такие функции не вполне совместимы с режимом триггера "generate multiple problems", он должен быть выключен (если интересно - можете поискать по форуму, я об этом писал несколько раз).

[friis]

Обсуждение ушло в https://www.zabbix.com/forum/showthr...611#post193611
т.к. тут неясно сформулирована суть проблемы

КОС - спасибо за помощь !