NetXMS Support Forum

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? Если да, то это сильно сужает возможности парсера... 

не все сразу это пока-что бета-код, я его выложил чтобы народ его тестировал параллельно с дальнейшей разработкой.

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 не подходит...

Hello!

Yes, "Communication failure" means that NetXMS server was unable to connect to SMTP server. You cannot change connect timeout, it's a system wide setting.
However, I can implement mail resending in case of failures. I'll put it onto feature request list.

Best regards,
Victor

Quote from: isherim on October 08, 2008, 12:07:24 PM
За время работы в режиме дебага(сутки) данное сообщение не появлялось. Может поискать что-то конкретное в логе-он очень объемный?

Если таких сообщений не было, то и искать нечего - меня интересуют сообщения за период начиная с 5-10 минут перед появлением сообщений "thread not responding...".
Старые логи можно смело стирать.

Quote from: Anth0ny on October 08, 2008, 12:41:56 PM
1 - боюсь, что увеличение MaxSessions не приведёт к желаемому результату, ведь если я рассуждаю правильно, все сессии на таком проблемном сервере будут заняты зомби-запросами... которые будут висеть в незаконченном состоянии вплоть до того момента, пока не перезагрузят проблемный сервис. или он окончательно обделается... на что мало надежды...

Не совсем так плохо. Тайм-аут на подключение все-таки есть, просто он большой. Постепенно эти зомби-сессии будут завершаться. Ну и в любом случае это временное решение.

Quote from: Anth0ny on October 08, 2008, 12:41:56 PM
2 - имеется в виду Condition типа "Data collection error"?
т.е. если я выставлю Data collection error = 2 consecutive samples, то при двух ушедших и не вернувших значения запросах я получу срабатывание трешолда?

Да.

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

Quote from: Anth0ny on October 07, 2008, 02:10:11 PM
о проблемах: не разлистывается каталог - https://www.netxms.org/download/rc
а точное имя файла не известно... как ж его скачать? =)

ispravil

Teper' ponjatno. Pohoze chto na connect timeout dovol'no bol'shoj, poetomu soedinenija visjat, t.e. s tochki zrenija agenta zapros na znachenie parametra do konca ne obrabotan. Po umolchaniju agent prinimaet ne bolee 32 odnovremennih zaprosov. Ja k sledujuschemu relizu razberus' s timeout'ami pri proverke servisov, poka chto v kachestve workaround mozno sdelat' dve veschi:

1. Na agente, gde zagruzen portCheck.nsm, dobavit' parametr MaxSessions = 256 (ili drugoe bol'shoe chislo vplot' do 1024).
2. Dobavit' esche odin threshold na parametr ServiceCheck.HTTP na oshibku sbora dannih - togda mozno budet uznavat' o takih problemah. Ponjatno chto oshibka sbora DCI ne oznachaet chto service ne rabotaet, mogut bit' i drugie prichini, no po krajnej mere budet vidno chto kakie-to problemi est'.

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

Понятно. Проблема в том, что на Windows вместо аббревиатуры подставляется название зоны, которое потом никто не может распознать. Исправим.

Буду сегодня вечером все это анализировать. Очень жду логи...

Looks like a bug in WMI subagent. I'll check it today.

Quote from: Anth0ny on October 06, 2008, 11:37:40 AM
запускать на сервере мониторинга?

да

Само по себе большое количество объектов блокировки вызывать не должно. А вот несколько недоступных узлов могут. Я просматривал код, связанный с этими блокировками - еще одна возможная причина - медленная работа базы данных одновременно с наличием большого количества измененных объектов (напримет после изменений в топологии сети, добавления новых узлов, изменения в шаблонах).

There are not too much information about WMI support in NetXMS unfortunately. Brief discussion are here: https://www.netxms.org/forum/index.php/topic,389.0.html.

Best regards,
Victor