Eventlog processing on Agent side. Serious experiments about performance and sequence sending Я провел несколько очень точных и серьезных экспериментов с обработкой виндовс евентлога. Может быть кому-то это покажется безумием, но мне это было интересными и полезным. Опишу как я это делал - может быть это будет кому-то полезно. А потом выскажу свое мнение и пожелания. Я создал кастомный журнал событий "Alarm" и наполнил их событиями по определенному алгоритму. Для создания журнала нужно в реестре добавить ветку с именем журнала на пути [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\ Alarm] "Retention"=dword:00000000 "MaxSize"=dword:07ff0000 Два дополнительных ключа определяют размер и режим ротации журнала. Кастомный журнал был создан для устранения влияния возможных других факторов и для тестирования в будущем. После этого с помощью бат-файла я наполнил журнал событиями. В результате журнале есть 100200 событий в четкой последовательности по определенному алгоритму. (журнал наполнялся 18 минут :) Вот структура журнала, где видно как он образован: 2010.Jun.28 22:26:20 FireSRC Information 555 100000 range END. Text for ALARM with ID 555 2010.Jun.28 22:26:20 FireSRC Error 333 1000 - in 100000 range. Text for ALARM with ID 333 2010.Jun.28 22:26:20 FireSRC Error 333 999 - in 100000 range. Text for ALARM with ID 333 2010.Jun.28 22:26:20 FireSRC Error 333 998 - in 100000 range. Text for ALARM with ID 333 ………………………………………………………… 2010.Jun.28 22:08:16 FireSRC Error 333 2 - in 2000 range. Text for ALARM with ID 333 2010.Jun.28 22:08:16 FireSRC Error 333 1 - in 2000 range. Text for ALARM with ID 333 2010.Jun.28 22:08:16 FireSRC Warning 444 2000 range START. Text for ALARM with ID 444 2010.Jun.28 22:08:16 FireSRC Information 555 1000 range END. Text for ALARM with ID 555 2010.Jun.28 22:08:16 FireSRC Error 333 1000 - in 1000 range. Text for ALARM with ID 333 2010.Jun.28 22:08:15 FireSRC Error 333 999 - in 1000 range. Text for ALARM with ID 333 ........................................................... 2010.Jun.28 22:08:02 FireSRC Error 333 2 - in 1000 range. Text for ALARM with ID 333 2010.Jun.28 22:08:02 FireSRC Error 333 1 - in 1000 range. Text for ALARM with ID 333 2010.Jun.28 22:08:02 FireSRC Warning 444 1000 range START. Text for ALARM with ID 444 Основной принцип - через каждую тысячу обычных событий (EventID 333) повторяются несколько отличительных событий (EventID 444,555) которые мы будем фильтровать на стороне агента. Бат-файлы и рег-файл вы можете взять из приложенного архива. Думаю этот маленький Хау-Ту может быть полезен тем, кому нужно проверить корректность работы Ключей и сложных триггеров в реальных условиях принудительно создавая произвольные события в журналах событий и наблюдая правильно ли ведет себя Zabbix. После этого я создал несколько разных ключей и сделал эксперименты. Итак: Первый аспект - производительность (скорость) чтения журнала с помощью нескольких Итемов с фильтрацией на стороне агента по EventID. Сразу отмечу, что если на агенте включить DebugLevel=4 то скорость обработки журнала катастрофически падает, поэтому на скорость проверять нужно без уровня отладки !!! Все параметры агента, которые могут влиять на производительность - дефолтные, кроме одного MaxLinesPerSecond=1000. Это сделано для лучшего выражения разницы в скорости работы агента. Во всех Элементах данных свойство Update interval (in sec)=1. Итак первый эксперимент: два Элемента данных с ключами: eventlog[Alarm,,,,444] eventlog[Alarm,,,, 555] Агентом обработано 100200 событий и серверу отправлено 200 событий за 1 мин. 30 сек. картинка "Two_Item_ID444+555.png" Второй эксперимент: один Элемент данных с ключом: eventlog[Alarm,,,,444|555] Агентом обработано 100200 событий и серверу отправлено 200 событий за 1 мин. 10 сек. картинка "One_Item_ID444_or_555.png" То есть ощутимо быстрее, чем в предыдущем примере. При этом процессор Core2Duo 3.0Ghz загружен заметно меньше (см. картинку "processor_load_differenses.png") Другой аспект - последовательность построения и отправки событий. Как видите на рисунке Two_Item_ID444+555 события были сформированы и переданы на сервер не в той последовательности как они были созданы на узле. Они сформированы так как агент их читал (два разных Элемента) и переслал серверу. Это не совсем хорошо. Исходя из этого предлагаю идею: сделать так что когда агент спрашивает и получает от сервера список активных проверок он группирует вс е Элементы по каждому журналу в отдельные группы и при опросе журнала будет пропускать новое событие через элементы в этой группе за один проход. Таким образом будет соблюдено реальную последовательность событий в со стороны агента в пределах каждого уникального журнала !!!. Также по идее будет улучшена производительность. Например реальные элементы данных для одного узла сети Виндовс: eventlog[System,,,,26|6009] eventlog[System,,,Warning,1007|3019|24] eventlog[System,,,Error] должны быть сформированы в одну группу. Единственное нужно решить что делать с параметрами Элементов Update interval (in sec). Наверно его нужно также брать как критерий формирования групп. В таком случае в документации должна давать рекомендацию - при использовании нескольких Элементов для одного журнала - задать одинаковый Update interval (in sec). Хочу также доказать что в реальном окружении могут возникать ситуации, где описанное мной замечание есть актуальным. Например заббикс Агент был значительное время без связи с Сервером и не мог отправлять события. После восстановления связи он начнет обрабатывать журнал и слать события с большой скоростью. Или, например хост был значительное время был в режиме Без наблюдения в интерфейсе, а потом снова был включен и т.д.. Если Zabbix администратор захочет вывести список событий за с нескольких Элементов - он не получит достоверного журнала с правильной очередностью возникновения событий. Другими словами Администратор не должен задумываться над тем, что события могли прийти в неправильной последовательности даже в очень редкостных ситуациях, он должен быть всегда уверен что события пришли правильно!!! О работе триггеров при таких обстаятельствах я лучше промолчу - это отдельная история. Хотя эксперимент проводился для ключа Элемента данных eventlog[] но все сказанное, наверное, актуально и для ключей log[] и logrt[]. Спасибо за внимание.