Триггер по журналу событий

[Foboss360]

Большое спасибо за подсказку

[Foboss360]

Логично, что
триггер должен срабатывать если
eventlog[Application,,Error,,111].last = 1
А восстанавливаться если
eventlog[System,,Information,,107].last = 1

Спасибо.
Но как же будет выглядеть итоговое выражение для триггера?

Верно ли это это выражение, между ними должно быть условие AND ?
{Windows:eventlog[Application,,Error,,111].last() = 1 and {Windows:eventlog[System,,Information,,107].last ()}= 1

[Semiadmin]

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

[Alex_UUU]

Спасибо.
Но как же будет выглядеть итоговое выражение для триггера?

Верно ли это это выражение, между ними должно быть условие AND ?
{Windows:eventlog[Application,,Error,,111].last() = 1 and {Windows:eventlog[System,,Information,,107].last ()}= 1

В триггере есть два поля: условие срабатывания и условие выключения. и, как отметил Semiadmin, в доках все прописано, и в самой поставке куча примеров.

[Semiadmin]

Ну если все же решать задачу, как она поставлена, используя идею коллеги Alex_UUU, то мысли такие.
Во-первых, eventlog винды может ротироваться 2 способами - перезатирать старые записи при достижении заданного объема лога или архивировать лог.
Видимо, первый способ не гарантирует, что при ротации лога будет удалена данная конкретная запись, так что должен быть выбран второй.
После этого возникает задача по сравнению 2 независимых событий из разных логов - какое из них произошло раньше, искомая ошибка или ротация лога.
В силу ряда причин точную последовательность можно установить в триггере только в том случае, если интервал между событиями не меньше полминуты.
Если лог сротировался сразу после сообщения об ошибке - возможны нюансы.
В качестве обходного решения можно в препроцессинге айтемов получать через JS текущий таймстемп в unixtime и или писать его в зависимые айтемы, или прямо в основные, сделав их тип не логом, а числовым.
Тогда условие триггера будет last(error.time) > last(rotation.time)

[Kos]

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

Точно, у меня тоже такое ощущение. Причём, это относится не только к автору темы.

Насчёт конструкций вроде "count(#1)" и "nodata(1)" я уже писал, но, видимо, мне не верят и желают набить собственные шишки. Ну что ж, как говорится, флаг в руки.

Далее, кто-то писал:

Имеем
eventlog[System,,Information,,107] - меняет значение, если нашли инфу о ротации.
Значения:
0
0
0
1 - произошла ротация
0
0

Обработка логов так не работает. Значением будет не ноль или единица, а строка из лога, соответствующая заданным условиям (имя лога="System", важность="Information", eventid="107"). Для примера я сделал поиск по этим условиям в своём логе и нашёл единственную запись:

The system has resumed from sleep.

Не знаю, какое это имеет отношение к ротации логов, но готов поверить, что у других людей используется другая версия операционной системы и у них там будет что-то вроде: "Application log has been rotated". Но даже если так, то: а) значением будет строка, а не число (если только не использовать предобработку для каких-то преобразований); б) значение будет лишь тогда, когда эта запись попала в лог и после этого переслана агентом на сервер Zabbix. Т.е. в базе данных Zabbix никаких нулей при отсутствии ротации не будет, а будут лишь редкие записи о том, что ротация была. В случае метрики eventlog и типа данных "Log" в базу попадут ещё некоторые метаданные, доступные при помощи триггерных функций logeventid(), logseverity() и logsource(), но в данном случае они не очень работают, т.к. соответствующий фильтр уже выставлен на уровне ключа элемента данных, и других eventid и severity там просто не будет.

[Alex_UUU]

2Kos , я - ленивый, поэтому мне легче написать 0 и 1, чем фразы :-) На и просто даю наводку (удочку), а не рыбу :-)
По временным задержкам правильно отписал Semiadmin И это постоянно наводит на мысль: если срок реагирования на проблему установлен регламентом в сутки, есть ли смысл делать проверку ежесекундно и реагировать на каждый чих :-).