Выложил версию 0.2.23-rc3 в https://www.netxms.org/download/rc (https://www.netxms.org/download/rc) для желающих потестировать мониторинг логов.
Добавлена возможность:
1. проверять сообщения, принимаемые встроенным syslog сервером на соответствия шаблонам и создавать события при соответствии;
2. через агента проверять записи в текстовых логах на соответствия шаблонам и создавать события при соответствии;
3. на Windows - то-же самое для Windows Event Log.
Для 1. надо обновить сервер, для 2 и 3 достаточно поставить новых агентов.
Как настраивать монтторинг логов через агента:
1. Создать необходимые события (через Control Panel -> Events);
2. В конфиге агента добавить загрузку субагента logwatch.nsm (libnsm_logwatch.so на UNIX);
3. Для каждого лога добавить запись вида Parser = config_file в секции LogWatch. Например так:
*LogWatch
Parser = /opt/netxms/etc/log_1.xml
Parser = /opt/netxms/etc/log_2.xml
4. Создать конфиги парсеров. Каждый конфиг - это отдельный XML файл следующего формата:
<parser>
<file>file_name</file>
<rules>
<rule>
<match>regexp</match>
<event params="n">event_code</event>
</rule>
...
</rules>
</parser>
Таг <rule> можно повторять сколько необходимо. Аттрибут params в таге event указывает, сколько подстрок (обозначенных в regexp'e скобками) надо передать как параметры события (их потом можно использовать через макросы %1, %2, ...). Если параметров нет, то фттрибут events можно не указывать.
Для мониторинга Windows event logs вместо имени файла надо указывать *log_name, например *System
Примеры:
1. Послать событие с кодом 1000 если в строке лога найдено слово "error":
<rule>
<match>error</match>
<event>1000</event>
</rule>
2. Послать событие с кодом 2000 если строка начинается со слова "warning:", при этом текст после "warning:" передать как параметр:
<rule>
<match>^warning: (.*)</match>
<event params="1">2000</event>
</rule>
отличная новость!! мы очень этого ждали! спасибо!
о проблемах: не разлистывается каталог - https://www.netxms.org/download/rc
а точное имя файла не известно... как ж его скачать? =)
+ вопрос: нельзя ли коротЕнько обрисовать, как именно работает (алгоритм) модуль парсинга логов?
я имею в виду что меня интересует следующее:
1) SysLog - мы ловим все поступающие на порт сообщения от лог-демонов, сравниваем с нашим шаблоном (условием) и если получаем именно то что ищем, то можно запускать процессинг...
т.е. в данном случае (при условии что мы ждём сообщение, указывающее на сбой\превышение\понижение) спокойно реализуема стандартная политика типа "получили совпадающее с шаблоном сообщение от удалённого syslog = есть проблема -> нода помечается как сбойная -> запомнили, что с конкретного сервера (устройства) приходило сообщение о проблеме -> ждём, когда придёт сообщение не совпадающее с шаблоном -> сообщение пришло (проблема рассосалась), сбойный статус ноды очищается". так, я правильно мыслю?
2) Windows Event Logs - мы парсим логи на серверах и при обнаружении искомых комбинаций, подходящих под наши шаблоны, запускаем процессинг эвентов.
вот тут возникает вопрос: будет ли сервер мониторинг запоминать, в какое время в Event log'е Windows было сгенерировано найденное сообщение об ошибке? нужно для того, что бы чётко понимать, что следующее по времени сообщение, относящееся к тому же сервису\программе но уже с пометкой Info, указывает на то что проблема была решена.
так же крайне важно, что бы парсер ставил где-то у себя отметку о ДАТЕ\ВРЕМЕНИ последней обнаруженной АБСОЛЮТНО ЛЮБОЙ записи в логе, для того, что бы при следующем цикле не производилось сканирование системного лога РАНЕЕ этой обнаруженной записи. т.е. делается ли сейчас такой timestamp? логи не сканируются с начала?
и если на сервере в процессе парсинга EL (Event Log) парсер натыкается сначала на одно сообщение об ошибке (нода помечается сбойной), потом на другое, потом на третье (и т.д.), будут ли эти обнаруженные ошибки добавляться к текущему набору проблем ноды?
т.е. если например будут обнаружены (последовательно, но в разные по времени циклы опроса)...
а) сбой или появление проблемы в работе нужного сервиса, причём что ВАЖНО: мы обнаруживаем не просто остановку, падение или проблему сервиса, а можем (должны мочь) определять, что конкретно с сервисом произошло.
б) проблема с аппаратной частью сервера, например сбой какого-то из контроллеров или HDD
в) системные сообщения о проблемах (возникших на уровне самой ОС)
... то будут ли эти обнаруженные проблемы добавлены в список проблем ноды? точнее сказать, будет ли в этом случае список проблем ноды содержать все эти записи?
ещё вопрос: как происходит обработка логов Windows? Используется regexp? можно ли привести более подробный пример именно для обработки логов Windows?
по сути нас интересует большинство полей, причём в совокупности:
Date - удобное поля для фиксации таймштампа возникновение проблемы. ведь проблема возникла не тогда когда её нашёл парсер, а именно тогда, когда она была зафиксирована в системном логе.
Time - относится к Date.
Source - источник возникшей проблемы (программа\служба\система)
Type - отличное поле для определения статуса события
Event ID - ОЧЕНЬ важное поле. позволяет нам различать, ЧТО ЖЕ ИМЕННО произошло со службой\системой\etc.
Я не знаю, в курсе ли народ, но всё равно хочу порекомендовать: www.eventid.net - прекрасный ресурс по ошибкам, генерируемым Windows и способам их решений. ОЧЕНЬ рекомендую. зачастую помогает значительно быстрее (больше вариантов решений), нежли родной мелкомягкий http://support.microsoft.com/.
Виктор, обратите внимание на сайтик =). Авось да пригодится... Было бы прикольно добавить в мониторинг возможность автоматически выдавать ссылки на методы решения обнаруженных проблем.
Вот типичная ссылка:
http://www.eventid.net/display.asp?eventid=X&source=Y
где можно автоматом подставлять вместо X - Event ID, вместо Y - Source.
Пример: если ищем Source: Application Error и EventID: 1000
Строка: http://www.eventid.net/display.asp?eventid=1000&source=Application+error
В полученной форме нужно открыть пункт Details (Comments and links for event id 1000 from source Application Error).
И не просто выдавать отдельной строкой, мол "возможное здесь (ссылка) Вы найдёте решение этой проблемы" (интерактивно, при просмотре NetXMS Alarm Browser'а), а дать возможность вставлять такие готовые ссылки в письма-извещения, с той же припиской).
это размышления в слух... прошу не бить... =)
Description - отличное поле для regexp-поиска конкретных деталей пришествия.
Так вот, к чему я...
Нельзя ли создать формализованную форму для поиска данных (шаблон сравнения) в логах Windows? Для заполнения через графический интерфейс? Т.е. форму, в целом полностью повторяющую внешний вид окна "Event Properties" Windows? Каждое из полей формы можно было бы заполнять данными, которые бы В СУММЕ участвовали в regexp-запросе... Если нет (возможности или желания) - ну и ладно, не важно, это был просто вопрос.... =)
Кстати, Виктор, вопрос, нельзя ли как-то разграничить Windows Event Logs и NetXMS Event Logs более конкретными названиями? а то чем дальше, тем больше будет путаницы (имхо) если употреблять короткое "Event Logs". если раньше проблем не было только в силу того, что NXMS не работал с логами Windows, то теперь придётся постоянно уточнять ЧТО имеется в виду в каждом конкретном контексте. Может быть имеет смысл логи NetXMS переименовать в просто "NetXMS Logs"? это тоже, так, мысли вслух...
И ЕЩЁ РАЗ ОГРОМНОЕ СПАСИБО Вам за вашу работу!
Quote from: Anth0ny on October 07, 2008, 02:10:11 PM
о проблемах: не разлистывается каталог - https://www.netxms.org/download/rc
а точное имя файла не известно... как ж его скачать? =)
ispravil
Quote from: Anth0ny on October 07, 2008, 02:10:11 PM
+ вопрос: нельзя ли коротЕнько обрисовать, как именно работает (алгоритм) модуль парсинга логов?
я имею в виду что меня интересует следующее:
1) SysLog - мы ловим все поступающие на порт сообщения от лог-демонов, сравниваем с нашим шаблоном (условием) и если получаем именно то что ищем, то можно запускать процессинг...
т.е. в данном случае (при условии что мы ждём сообщение, указывающее на сбой\превышение\понижение) спокойно реализуема стандартная политика типа "получили совпадающее с шаблоном сообщение от удалённого syslog = есть проблема -> нода помечается как сбойная -> запомнили, что с конкретного сервера (устройства) приходило сообщение о проблеме -> ждём, когда придёт сообщение не совпадающее с шаблоном -> сообщение пришло (проблема рассосалась), сбойный статус ноды очищается". так, я правильно мыслю?
Pochti tak. Esli ja hochu pomechat' nodu kak sbojnuju pri problemah i ubirat' otmetku kogda problema ischezla, eto budet vigljadet' tak:
1. sozadt' shablon 1 dlja soobschenija ob oshibke, vibrat' sobitie kotoroe budet generitsja (EVENT_ERROR naprimer)
2. sozdat' shablon dlja soobschenija o tom, chto problemi bol'she net, vibrat' sobitie kotoroe budet generitsja (EVENT_OK naprimer)
3. dal'she kak obichno dlja threshold sobitij: delaem dva pravila v event policy, na EVENT_ERROR sozdaem alarm s kljuchom, na EVENT_OK terminiruem alarm s takim kljuchom.
ostal'nie otveti zavtra :)
Виктор, я всё ещё тут =)
Очень жду продолжения марлезонского балета =))
Sorry, получилось "послезавтра"... :(
Quote from: Anth0ny on October 07, 2008, 02:10:11 PM
2) Windows Event Logs - мы парсим логи на серверах и при обнаружении искомых комбинаций, подходящих под наши шаблоны, запускаем процессинг эвентов.
вот тут возникает вопрос: будет ли сервер мониторинг запоминать, в какое время в Event log'е Windows было сгенерировано найденное сообщение об ошибке? нужно для того, что бы чётко понимать, что следующее по времени сообщение, относящееся к тому же сервису\программе но уже с пометкой Info, указывает на то что проблема была решена.
см. объяснение про syslog - работает так-же.
Quote from: Anth0ny on October 07, 2008, 02:10:11 PM
так же крайне важно, что бы парсер ставил где-то у себя отметку о ДАТЕ\ВРЕМЕНИ последней обнаруженной АБСОЛЮТНО ЛЮБОЙ записи в логе, для того, что бы при следующем цикле не производилось сканирование системного лога РАНЕЕ этой обнаруженной записи. т.е. делается ли сейчас такой timestamp? логи не сканируются с начала?
Сейчас парсер просто ждет появления новых сообщений, то, что было на момент запуска - не сканируется. В будущем я планирую это сделать, хотя спорный вопрос - надо ли это делать всегда. Ведь если запись в логе была оставлена задолго до запуска парсера, то возможно что она уже не актуальна.
Quote from: Anth0ny on October 07, 2008, 02:10:11 PM
и если на сервере в процессе парсинга EL (Event Log) парсер натыкается сначала на одно сообщение об ошибке (нода помечается сбойной), потом на другое, потом на третье (и т.д.), будут ли эти обнаруженные ошибки добавляться к текущему набору проблем ноды?
т.е. если например будут обнаружены (последовательно, но в разные по времени циклы опроса)...
а) сбой или появление проблемы в работе нужного сервиса, причём что ВАЖНО: мы обнаруживаем не просто остановку, падение или проблему сервиса, а можем (должны мочь) определять, что конкретно с сервисом произошло.
б) проблема с аппаратной частью сервера, например сбой какого-то из контроллеров или HDD
в) системные сообщения о проблемах (возникших на уровне самой ОС)
... то будут ли эти обнаруженные проблемы добавлены в список проблем ноды? точнее сказать, будет ли в этом случае список проблем ноды содержать все эти записи?
каждая запись, которая соответствует шаблону, вызывает создание события - а дальше все зависит от event processing policy - как напишете, так и будет.
Quote from: Anth0ny on October 07, 2008, 02:10:11 PM
ещё вопрос: как происходит обработка логов Windows? Используется regexp? можно ли привести более подробный пример именно для обработки логов Windows?
да, regexp.
Quote from: Anth0ny on October 07, 2008, 02:10:11 PM
по сути нас интересует большинство полей, причём в совокупности:
Date - удобное поля для фиксации таймштампа возникновение проблемы. ведь проблема возникла не тогда когда её нашёл парсер, а именно тогда, когда она была зафиксирована в системном логе.
Time - относится к Date.
Source - источник возникшей проблемы (программа\служба\система)
Type - отличное поле для определения статуса события
Event ID - ОЧЕНЬ важное поле. позволяет нам различать, ЧТО ЖЕ ИМЕННО произошло со службой\системой\etc.
Я не знаю, в курсе ли народ, но всё равно хочу порекомендовать: www.eventid.net - прекрасный ресурс по ошибкам, генерируемым Windows и способам их решений. ОЧЕНЬ рекомендую. зачастую помогает значительно быстрее (больше вариантов решений), нежли родной мелкомягкий http://support.microsoft.com/.
Виктор, обратите внимание на сайтик =). Авось да пригодится... Было бы прикольно добавить в мониторинг возможность автоматически выдавать ссылки на методы решения обнаруженных проблем.
Вот типичная ссылка:
http://www.eventid.net/display.asp?eventid=X&source=Y
где можно автоматом подставлять вместо X - Event ID, вместо Y - Source.
Пример: если ищем Source: Application Error и EventID: 1000
Строка: http://www.eventid.net/display.asp?eventid=1000&source=Application+error
В полученной форме нужно открыть пункт Details (Comments and links for event id 1000 from source Application Error).
И не просто выдавать отдельной строкой, мол "возможное здесь (ссылка) Вы найдёте решение этой проблемы" (интерактивно, при просмотре NetXMS Alarm Browser'а), а дать возможность вставлять такие готовые ссылки в письма-извещения, с той же припиской).
это размышления в слух... прошу не бить... =)
Description - отличное поле для regexp-поиска конкретных деталей пришествия.
пока-что это только regexp на description - потом добавлю и остальные поля.
Quote from: Anth0ny on October 07, 2008, 02:10:11 PM
Так вот, к чему я...
Нельзя ли создать формализованную форму для поиска данных (шаблон сравнения) в логах Windows? Для заполнения через графический интерфейс? Т.е. форму, в целом полностью повторяющую внешний вид окна "Event Properties" Windows? Каждое из полей формы можно было бы заполнять данными, которые бы В СУММЕ участвовали в regexp-запросе... Если нет (возможности или желания) - ну и ладно, не важно, это был просто вопрос.... =)
GUI для настройки мониторинга логов обязательно будет, но не сразу и скорее всего уже в новой консоли.
Quote from: Anth0ny on October 07, 2008, 02:10:11 PM
Кстати, Виктор, вопрос, нельзя ли как-то разграничить Windows Event Logs и NetXMS Event Logs более конкретными названиями? а то чем дальше, тем больше будет путаницы (имхо) если употреблять короткое "Event Logs". если раньше проблем не было только в силу того, что NXMS не работал с логами Windows, то теперь придётся постоянно уточнять ЧТО имеется в виду в каждом конкретном контексте. Может быть имеет смысл логи NetXMS переименовать в просто "NetXMS Logs"? это тоже, так, мысли вслух...
В NetXMS много разных логов - event log, snmp trap log, syslog, audit log - так-что просто NetXMS Logs не подходит...
Quote from: Victor Kirhenshtein
см. объяснение про syslog - работает так-же.
секундочку... не совсем понял... Вы имеете в виду, что агент не просто смотрит Windows Event Log'и и сам сравнивает с заданнымы шаблонами, а транслирует записи из логов по мере появления на сервер мониторинга, который уже непосредственно занимается разбором полученного и сравнением, на подобии syslogd...? в реальном времени? я что-то уже запутался... разъясните технический момент плиз...
Quote from: Victor Kirhenshtein
Сейчас парсер просто ждет появления новых сообщений, то, что было на момент запуска - не сканируется. В будущем я планирую это сделать, хотя спорный вопрос - надо ли это делать всегда. Ведь если запись в логе была оставлена задолго до запуска парсера, то возможно что она уже не актуальна.
это опять же отсылает меня к предыдущему ответу... каков механизм работы парсера windows-логов?
Quote from: Victor Kirhenshtein
каждая запись, которая соответствует шаблону, вызывает создание события - а дальше все зависит от event processing policy - как напишете, так и будет.
да-да, это понятно =)
Quote from: Victor Kirhenshtein
да, regexp.
стандартный regexp? можно ссылочку на документацию, если Вас не затруднит =)
Quote from: Victor Kirhenshtein
пока-что это только regexp на description - потом добавлю и остальные поля.
опа... это означает, что мы сейчас не можем искать данные (в проверяемых логах) в полях Date, Time, Source, Type и Event ID? только в поле описания, Description? Если да, то это сильно сужает возможности парсера... :-\
Quote from: Victor Kirhenshtein
GUI для настройки мониторинга логов обязательно будет, но не сразу и скорее всего уже в новой консоли.
чтож, это не так важно сейчас, но будет замечательно потом =)
Quote from: Victor Kirhenshtein
В NetXMS много разных логов - event log, snmp trap log, syslog, audit log - так-что просто NetXMS Logs не подходит...
ну... тогда даже и не знаю. значит придётся всегда указывать полные названия.. =)
Quote from: Anth0ny on October 10, 2008, 02:13:50 PM
Quote from: Victor Kirhenshtein
см. объяснение про syslog - работает так-же.
секундочку... не совсем понял... Вы имеете в виду, что агент не просто смотрит Windows Event Log'и и сам сравнивает с заданнымы шаблонами, а транслирует записи из логов по мере появления на сервер мониторинга, который уже непосредственно занимается разбором полученного и сравнением, на подобии syslogd...? в реальном времени? я что-то уже запутался... разъясните технический момент плиз...
Я имел ввиду что принцип тот-же - проверяем каждую новую запись на соответствие шаблону, и если соответствует - генерируем новое событие. Обработка логов производится агентом, на сервер отсылаются события.
Quote from: Anth0ny on October 10, 2008, 02:13:50 PM
Quote from: Victor Kirhenshtein
да, regexp.
стандартный regexp? можно ссылочку на документацию, если Вас не затруднит =)
http://en.wikipedia.org/wiki/Regular_expression (http://en.wikipedia.org/wiki/Regular_expression)
NetXMS использует POSIX extended regular expressions.
Quote from: Anth0ny on October 10, 2008, 02:13:50 PM
Quote from: Victor Kirhenshtein
пока-что это только regexp на description - потом добавлю и остальные поля.
опа... это означает, что мы сейчас не можем искать данные (в проверяемых логах) в полях Date, Time, Source, Type и Event ID? только в поле описания, Description? Если да, то это сильно сужает возможности парсера... :-\
не все сразу :) это пока-что бета-код, я его выложил чтобы народ его тестировал параллельно с дальнейшей разработкой.
Виктор, приветствую =)
Как там насчёт релиза?
Quote from: Anth0ny on November 17, 2008, 12:45:01 PM
Виктор, приветствую =)
Как там насчёт релиза?
Доделываю log parsing и еще разные мелочи.
Виктор, приветствую =)
Как там, планируется улучшать модуль парсинга windows-и файловых логов?
Меня лично весьма и весьма заботит и интересует именно парсинг windows-логов (всех полей: Date\Time\Source\Type\Event ID).
Ещё раз спасибо Вам за вашу работу!
=)
Конечно планируется :) Я думаю что в следующем релизе уже будет.