NetXMS Support Forum

Выложил версию 0.2.23-rc3 в 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

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).

Ещё раз спасибо Вам за вашу работу!
=)

Конечно планируется Я думаю что в следующем релизе уже будет.