Как я и обещал - это мой третий серьезный пост по поводу работы Zabbix  агента с журналами событий Windows.
Здесь речь пойдет о том, как агент начинает работу (после старта) и завершает работу (останавливается, перезапускается).
Также будут даны предложения по улучшению  принципов работы  при первом добавлении в систему Элементов с  ключом  eventlog[ХХХХХХ]. 
Мне известно о добавлении в версии 2.0 для ключ eventlog  новой возможности: 
режим - один из all (по умолчанию), skip (пропуск обработки старых данных).
mode - one of all (default), skip (skipping processing of older data)

Но этот параметр безусловно указывает агенту обрабатывать только те записи журналов, которые возникли после запуска агента.  А я не хочу пропускать событий, которые возникали в период, когда Агент не работал. Для меня это принципиально и  я эту возможность использовать не буду, хотя для других она может оказаться очень полезной.

Как и в предыдущих своих сообщениях ZBX-2614 and  ZBX-2651  я обращу внимание на работу агента при фильтрации сообщений на стороне агента. В качестве примера беру абсолютно реальные задачи:

Пример №1. Нужно отлавливать редкостные сообщения с журнала Безопасность - события блокировки учетных записей на контроллере домена.
Это вот такой ключ: 
eventlog[Security,,"Success Audit",,644] 
Здесь громаднейший поток событий - вплоть до миллиона событий в день а событие блокировки акаунта может возникать например один раз в несколько дней.
Примечание - мой друг на работе имеет журналы Безопасности по 2 Гбайта - около 6 миллионов записей событий.

Пример №2. Нужно отлавливать события результатов работы Проверки диска при загрузке системы (chkdsk - Checking file system)
eventlog[Application,,, Winlogon,1001] 
Здесь поток событий значительно меньше чем в журнале Безопасности, но и события могут появляться очень-очень редко - например один раз в год (но это очень важные события !!!). 

Особенность обеих примеров в том, что события возникают через очень большие промежутки между другими событиями.
Что же происходит когда агент нашел последнее совпадение – он отправляет сообщение серверу а сервер отмечает в базе данных в таблице “items”  в поле  “lastlogsize”  специальный номер последнего пришедшего события. Этот номер - специальный маркер номера события в журнале, который визуально нигде не увидишь.
Далее проходит несколько дней, а за это время в журнал Безопасность  внесено несколько миллионов записей и у нас возникает необходимость перезагрузить сервер или перезапустить Zabbix агента.
При запуске агент получит список активных проверок и начнет обрабатывать  несколько миллионов событий для ключа с примера №1 - и это очень плохо. Это и потеря вычислительных ресурсов и большое время пока агент доберется до конца журнала, а самое главное - работа агента в таком случае совсем непрогнозируемая - это может влиять на работу других проверок. Кстати о этой проблеме в форуме встречаются обсуждения.

То же самое с примером №2. Например это рабочая станция, которая  загружается каждый день. Так что каждое утро агент будет пересматривать весь журнал Системы  например за несколько лет? Зачем это нужно? А если проверок несколько?

Короче к чему я веду - предлагаю внести некоторые изменения в работу агента:
Когда агент останавливается, то он обязательно должен послать серверу сообщения от каждого Элемента с типом активных проверок (может быть только от log, logrt, eventlog), в котором есть значение lastlogsize . Для этого агенту нужно всего несколько миллисекунд перед  окончательным завершением работы.
Будет ли это специальное сообщение, которое не попадет в историю событий базы данных, или это будет  обычное (запрограммированное)  сообщение, которое будет видно в истории событий - решать вам. Мне в принципе другой вариант нравиться - будет видно когда агент остановился - это может быть полезным. Фактически для всех Элементов значение lastlogsize будет одинаковым в пределах одного журнала и соответствовать последней записи.
В результате при следующем запуске агент будет продолжать с  того места - где остановился. То есть агент не будет проверять то что уже проверял раньше.

Другое нововведение, которое я предлагаю (опять же возможность  mode ->  skip нам не подходит !!!):
Задать принудительно при создании Элемента  и дать возможность пользователю указать в любой момент, что в следующий раз, когда агент получит список активных проверок - пусть продолжает  с конца  журнала, а не отправляет все существующие записи.
Почему я это предлагаю: в форуме есть множество сообщений о том, как пользователи испытывают мучение  в недоумении  от того что агент начинает пересылаться весь громаднейший журнал событий.
 Я почти на 100% уверен что никому этого не нужно. Лучше чтобы при первом  !!!!   добавлении Элемента - журнал весь  не пересылался. 
Мне кажется это можно сделать без изменения схемы базы данных. Например при создании нового Элемента задавать  lastlogsize=99999999999 для примера - очень большим. Агент со своей стороны должен обрабатывать такой случай так же как и mode ->  skip. Вот и все. Больше ничего не нужно. И это все можно сделать еще и в ветке 1.8.
Можно сделать еще лучше - при настройке Элемента дать возможность пользователю  самостоятельно принудительно установить это атрибут (lastlogsize=99999999999) в любой момент времени. Например – если агент долго не обрабатывал журнал событий (Элемент был долгое время отключен) и чтобы в следующий раз  при получении активных проверок  агент не перечитывал журнал. Полезно же? Конечно!
Все сказанное, наверное,  актуально и для ключей  log[] и  logrt[].

Ну вот и все друзья мои. Это было третье и последнее  мое сообщение. Следующее будет уже о работе триггеров с журналами событий :)
Извините что без картинок - в следующий раз.