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

[snaf]

Добрый день дорогие пользователи сего форума.

Мне нужно мониторить лог файл. Если встречается слово Error или CRL больше чем 5-ть раз за последнюю минуту тогда должен сработать тригер.

пример текущей конфигурации:
item:
log[/tmp/sys.log,"([Ee][Rr][Rr][Oo][Rr])|([Cc][Rr][Ll])",100]

trigger:
{Zabbix server:log[/tmp/sys.log,"([Ee][Rr][Rr][Oo][Rr])|([Cc][Rr][Ll])",100].nodata(60)}=0

В данный момент тригер срабатывает если за последнюю минуту слово встречается хотя бы 1 раз. Но меня это не совсем устраивает.

Я так же пробовал через count что то сообразить. Но ничего дельного из этого не вышло. Надеюсь что понятно объяснил. Форумчане, я рассчитываю на вашу помощь.

[Kos]

На мой взгляд, item вполне нормальный (если по нему реально приходит то, что надо). С написанием триггера сложнее, т.к. он должен не только переходить в состояние PROBLEM, но и возвращаться назад в OK.

Вариант 1:

{Zabbix server:log[/tmp/sys.log,"([Ee][Rr][Rr][Oo][Rr])|([Cc][Rr][Ll])",100].count(60)}>5

Решаем "в лоб": используя функцию count(), считаем количество строк за последнюю минуту. Если больше пяти, триггер включается, иначе - выключается.
На первый взгляд всё хорошо: фильтровать в функци count() ничего не надо (поскольку нужные записи отфильтровываются уже на входе, регулярным выражением самого элемента данных), выражение триггера предельно простое. Однако "засада" кроется в том, что выражение такого триггера пересчитывается только по прибытии нового значения элемента данных. Соответственно, если в лог-файле появилась сразу пачка такого рода записей, а потом всё стало хорошо (больше ругани не появляется), то триггер перейдёт в состояние PROBLEM на шестой записи и останется в этом состоянии до тех пор, пока в логе не появится какая-то ругань в следующий раз.

Вариант 2:

{Zabbix server:log[/tmp/sys.log,"([Ee][Rr][Rr][Oo][Rr])|([Cc][Rr][Ll])",100].count(60)}>5
and
{Zabbix server:log[/tmp/sys.log,"([Ee][Rr][Rr][Oo][Rr])|([Cc][Rr][Ll])",100].nodata(60)}=0

Добавляем функцию nodata(), что заставляет этот триггер пересчитываться ещё и каждые 30 секунд. Второе условие приведёт к закрытию триггера (переходу в OK), если новых сообщений об ошибках в логе не появляется.

Тут ещё нужно учесть, что интервал опроса для данного элемента данных не должен превышать минуты (лучше поставить порядка 30 секунд). Потому как если его выставить, скажем, в 5 минут, а ошибки туда пишутся каждые 20 секунд, то тогда каждые 5 минут агент будет присылать очередную накопившуюся за это время порцию записей (15 штук), которые будут приводить к срабатыванию триггера, который через минуту закроется. И так каждые 5 минут :-)

[snaf]

На мой взгляд, item вполне нормальный (если по нему реально приходит то, что надо).

Да. По нему действительно приходит что надо.

С написанием триггера сложнее, т.к. он должен не только переходить в состояние PROBLEM, но и возвращаться назад в OK.

Именно с этим у меня и возникли проблемы когда я использовал count. Тригер срабатывал но обратно своё состояние не менял.

Вариант 2:

{Zabbix server:log[/tmp/sys.log,"([Ee][Rr][Rr][Oo][Rr])|([Cc][Rr][Ll])",100].count(60)}>5
and
{Zabbix server:log[/tmp/sys.log,"([Ee][Rr][Rr][Oo][Rr])|([Cc][Rr][Ll])",100].nodata(60)}=0

То что надо!!! Я не знаю как я упустил такой момент. Я пытался использовать отдельно count и nodata. Но не додумался о комбинировании их.

Спасибо вам большое. Теперь всё работает должным образом.

[Kos]

Рад, что помогло :-)