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

[Foboss360]

Всем привет.
Допустим, в элементе данных есть ключ: eventlog[Application,,Error,,111]
Он собирает все ошибки с ошибкой и кодом 111.
Необходимо создать триггер, который сообщает об этой найденной ошибке в журнале и закрывается при удалении этой ошибки из журнала. Именно триггер закрывается (не по времени), когда ошибка больше не обнаруживается в журнале. Заббикс версии 5.0
Т.е. триггер чтобы закрывался, когда этой- же ошибки в логе больше нет.

{Windows:eventlog[Application,,Error,,111].nodata(20m)}=0 - этот точно не подходит, так как он по времени
({Windows:eventlog[Application,,Error,,111].count(#1)}>0) or ({Windows:eventlog[Application,,Error,,111].count(#1)}=0) - этот срабатывает когда найдена ошибка, но почему-то не закрывается триггер когда ошибки в логах уже нет.

Либо нужно вешать два отдельных триггера, на открытие проблемы и на закрытие проблемы и указывать зависимости? Либо можно все выражение прописать в одном триггере?

Подскажите, есть ли какие-то рабочие варианты?

[Kos]

Увы и ах, но вряд ли такое можно сделать штатными средствами.
Мониторинг логов (как лог-файлов, так и Windows Event logs) отличается от других видов мониторинга тем, что отлавливает лишь события вида "в логе появилась новая запись" (и далее можно эту запись анализировать и предпринимать что-то на основе её содержания), но при этом нет событий "из лога что-то пропало". И я даже не знаю, существуют ли вообще какие-либо системы, которые умеют отлавливать события подобного вида.

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

[kharkov_max]

Напишите скрипт, который парсит лог и кидает в траппер 1 есть ошибка, 0 нет ошибки в файле и nodata ... создайте userParameter - ну как то так.

[Foboss360]

Большое спасибо за ответы. Буду думать, что лучше предпринять.
Вот такое ещё решение нашел. Предпоследний абзац. Есть решение с триггером. Буду пробовать. Но что-то мне подсказывает что не сработает... Версия Zabbix у меня 5.0

[Semiadmin]

Странная у вас задача, если честно. Для вас действительно признаком прекращения проблемы является ротация лога и удаление записи о происшедшем событии?

[Kos]

Вот такое ещё решение нашел. Предпоследний абзац. Есть решение с триггером. Буду пробовать.

Работать будет, несмотря на то, что статья писалась ещё во времена версии Zabbix 2.x. Разве что минимально допустимое значение параметра для nodata (официально поддерживаемое) - 30 секунд (хотя по факту работает и меньше, но "возможны нюансы").
Но это решение описывает именно тот подход, о котором вы изначально высказались:

{Windows:eventlog[Application,,Error,,111].nodata(20m)}=0 - этот точно не подходит, так как он по времени

[Foboss360]

Странная у вас задача, если честно. Для вас действительно признаком прекращения проблемы является ротация лога и удаление записи о происшедшем событии?

Совершенно верно, признаком прекращения проблемы - является удаление записи о прошедшем событии. По крайней мере понимаю это так. В связи с этим задача метрики - сообщить о появлении записи проблемы эвентлоге, и закрыть проблему когда произойдет ротация лога и запись эта удалится.

[Foboss360]

Работать будет, несмотря на то, что статья писалась ещё во времена версии Zabbix 2.x. Разве что минимально допустимое значение параметра для nodata (официально поддерживаемое) - 30 секунд (хотя по факту работает и меньше, но "возможны нюансы").
Но это решение описывает именно тот подход, о котором вы изначально высказались:

Если взять вот такое выражение:
({Windows:eventlog[Applocation,,Error,,111].count(#1)}<>0) and ({Windows:eventlog[Applocation,,Error,,111].nodata(1)}<>1)

.count(#1): Функция count, подсчитывает количество событий.
<>0: Оператор сравнения, означает что триггер срабатывает, если количество ошибок с ID 111 не равно 0
.nodata(1): Функция nodata, проверяет отсутствие данных в течение 1 интервала опроса
<>1: Оператор сравнения, означает, что триггер срабатывает, если нет данных в течение 1 интервала опроса

В связи с этим выражением, полагаю, что триггер должен сработать если есть ошибки с ID 111 и должен закрыться если нет данных в журнале приложений по этой ошибке в течение 1 интервала опроса (единица - это ведь не минуты?). Item у меня 2 минуты.
Не уверен что это будет должным образом работать, но попробую. Либо думать о других вариантах, через скрипт о которых писалось выше. Но это более затратный вариант, хотелось бы конечно стандартными инструментами.

[Kos]

Если взять вот такое выражение:
<чушь убрана>

Ну, вы бы хоть почитали документацию, что ли, а то как-то даже не очень хочется комментировать написанное.

Во-первых, все триггерные функции (кроме временнЫх типа time() или date()) работают с историей элементов данных в базе данных Zabbix.
Не с данными в логе, а с данными, которые агент оттуда извлёк и переслал на сервер Zabbix. Соответственно, если эти данные потом в исходном логе были удалены, то Zabbix об этом не узнает никак - в его базе эти данные останутся в течение срока, заданного для этого элемента данных.

Во-вторых, выражение "count(#1)<>0" будет истинным всегда, пока в истории для этого элемента данных есть хоть что-то. Подчёркиваю: в истории, т.е. в базе данных Zabbix.

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

[Foboss360]

Kos, спасибо за подробные комментарии. Действительно, всё так и есть.
Буду дальше думать как решить свою задачу. И перечитаю документацию ))

[Alex_UUU]

Погодь. Насколько я понял, триггер должен закрываться не когда ошибка ушла, а когда файл логов удалился (сротировался). Может это и отлавливать? Т.е .надо поймать ротацию лога. А выловить ее можно... по логу.
Самый очевидный способ, при ротации логов в лог пишется инфа о ротации.
Поймали эту инфу - закрыли все необходимые триггеры.

[Foboss360]

Погодь. Насколько я понял, триггер должен закрываться не когда ошибка ушла, а когда файл логов удалился (сротировался). Может это и отлавливать? Т.е .надо поймать ротацию лога. А выловить ее можно... по логу.
Самый очевидный способ, при ротации логов в лог пишется инфа о ротации.
Поймали эту инфу - закрыли все необходимые триггеры.

Хмммм. А ведь Вы правы!
Может я неправильно высказался о своей задаче выше. Но подразумевал именно ротацию лога. Именно то - когда файл логов удалился. Т.е произошла ротация лога. Да, совершенно верно, так и есть.
То есть теперь мне необходимо проследить как произойдет ротация логов, и потом протий в сам журнал Windows, и найти эту запись о ротации. Я так понимаю она может быть в журнале Windows Безопасность или в журнале Windows Система.

[Foboss360]

Создал два элемента данных:
Для событий ротации лога - eventlog[System,,Information,,107]
Для событий с уровнем ошибки - eventlog[Application,,Error,,111]


С учётом вышесказанного, подправил триггер:
({Windows:eventlog[System,,Information,,107].count(#1)}>0) and (({Windows:eventlog[Application,,Error,,111].count(#1)}=0) or ({Windows.[Application,,Error,,111].nodata(1)}=1))
p.s. как оказалось, триггер срабатывает только на открытие проблемы. Но снова не закрывается ... Не пойму, где ошибся в выражении триггера? Или его надо как-то упростить?

Прошу подсказать, как будет выглядеть правильно выражение для триггера - чтобы взводился когда есть ошибка в журнале Приложения 111 (eventlog[Application,,Error,,111]), и закрывался когда есть запись в журнале Система 107 (eventlog[System,,Information,,107])

[Foboss360]

Пока не получается создать верное выражение для триггера.

[Alex_UUU]

Стоит помнить, что триггер обрабатывается столько раз, сколько элементов в нем участвует. Т.е. на каждый чих каждого элемента
Тут очень помогает просто вручную посмотреть данные по каждому элементу и найти место, где должен сработать/восстановиться триггер И на асновании этого писать условия.
Имеем
eventlog[System,,Information,,107] - меняет значение, если нашли инфу о ротации.
Значения:
0
0
0
1 - произошла ротация
0
0
eventlog[Application,,Error,,111] - инфа об ошибке
0
0
1 ошибка
0
0
1 ошибка
0
0

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