Триггер с сложным условием

[teddy]

Коллеги! что-то я запутался с такой проблемой.
/host/ITEM - берет с хоста строку из лог файла. Через функцию log( filename.log, *pattern* ) По pattern находим строку с ошибкой в логе. и потом эту строку разбираем через regexp
ITEM.A, ITEM.B, ITEM.C - это разобраные кусочки условно IP, hostname, description взятые из строки лога с ошибкой.
Важно что сама строка очень большая чтоб брать ее целиком.
Теперь строим триггер по этой ошибке. было б достаточно указатть что last(/host/ITEM) <> "-" для срабатывания триггера, но тогда мы не сможем вывести ни в письмо ни в текст ошики IP, hostname, description.
Поэтому делаем триггер таким
Типа last(/host/ITEM.A) <> last(/host/ITEM.B = 8) and last(/host/ITEM.C) <> "-" чтоб через {HOST.VALUE1}, {HOST.VALUE2}, {HOST.VALUE3} вывести данные.
Т.к такой триггер не закрывается сам - ну нет тут условия закрытия - то делаем его не Single а Multiple. и тут становится проблема: три елемента в условии, которые меняются одновременно т.к они зависимые от одного общего родителя.
И в итоге повяляется три одинаковых алерта по каждому из item.
Если сделать Single то при появлении двух разных строк с ошибками - по первой алерт появится. по второй появится только если кто-то закроет первый руками.
Как вы решаете подобную проблему с парсингом логов?

[Kos]

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

2) в Zabbix-е нет функции log() (если я что-то упустил, то киньте в меня ссылку на документацию). Но зато у стандартного агента Zabbix есть ключ элемент данных log[...] (ссылка) - возможно, имелась в виду эта возможность. Если так, то при помощи параметров <регулярное выражение> и <вывод> можно найденную строку переформатировать таким образом, чтобы передаваемая на сервер строка имела более удобный вид и содержала меньше мусора (см. последний пример по приведённой ссылке).

[teddy]

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

Я понимаю почему так работает сейчас. Вопрос как сделать чтоб работало как надо. Если это возможно.
Например обратится в триггере в поле Operation data или Description к значения item этого же хоста, но которого нет в условии?

2) в Zabbix-е нет функции log() (если я что-то упустил, то киньте в меня ссылку на документацию). Но зато у стандартного агента Zabbix есть ключ элемент данных log[...] (ссылка) - возможно, имелась в виду эта возможность. Если так, то при помощи параметров <регулярное выражение> и <вывод> можно найденную строку переформатировать таким образом, чтобы передаваемая на сервер строка имела более удобный вид и содержала меньше мусора (см. последний пример по приведённой ссылке).

Да я ошися со скобочками. но я не понял про "можно найденную строку переформатировать таким образом, чтобы передаваемая на сервер строка имела более удобный вид". Через regexp и комбинировать \1 \2 \3 ?
Этот не подходит т.к я алертам проставляю тег {HOST.VALUE1} и потом могу делать анализ по тегам точнее по алертам по IP. а в Description пишу {HOST.VALUE1} on {HOST.VALUE2} для описания события.
Т.е мне нужно раздробить строку на несколько item.

[Kos]

я не понял про "можно найденную строку переформатировать таким образом, чтобы передаваемая на сервер строка имела более удобный вид". Через regexp и комбинировать \1 \2 \3 ?

Да, именно.

Я понимаю почему так работает сейчас. Вопрос как сделать чтоб работало как надо.

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

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

• вынести пороговое значение "свежести" в пользовательский макрос, к примеру:

{$MAX_PERIOD}

1m

• сформулировать условие триггера таким образом:

count(/host/ITEM.A,{$MAX_PERIOD})>0 and count(/host/ITEM.B,{$MAX_PERIOD})>0 and count(/host/ITEM.C,{$MAX_PERIOD})>0

В первом же случае можно, переформатировав полученное значение в одно (но в котором легко определить, что есть IP, а что есть hostname), оставить в условии триггера только один элемент данных. А в теги и Description уже извлекать из него нужные подстроки с помощью макрофункций.

[teddy]

Благодарю. именно макрофункции и решили вопрос. Неакуратно выглядит в тексте триггера, но зато на дашборде и в сообщении - супер !
я как то упустил из виду такую возможность!