NetXMS Support Forum

Hello!

Short overview of database structure related to data collection:

All collected data stored in tables idata_xx, where xx is a node object id, so each node has it's own table for data. Structure of this table is quite simple:

Field	Type	Description
item_id	integer	DCI id
idata_timestamp	integer	Timestamp in UNIX format (seconds since epoch)
idata_value	varchar(255)	Value

You can get the list of nodes from nodes table, where you probably should be interested only in id and may be primary_ip fields.
Some fileds from "nodes" table:

Field	Type	Description
id	integer	Node object id
primary_ip	varchar(15)	Node's primary IP address
uname	varchar(255)	Node's uname (output of uname -a command)

Node's name, status, and comments can be obtained from "object_properties" table.
Some fileds from "object_properties" table:

Field	Type	Description
id	integer	Object id
name	varchar(63)	Object name
status	integer	Object status
comments	text	Object comments

Some information on database structure can also be obtained from this topic: https://www.netxms.org/forum/index.php/topic,198.0.html

Hope this helps!

Best regards,
Victor

Quote from: lowtek on October 12, 2008, 09:24:57 AM
Thanks Victor. While I'm waiting for this feature to be implemented I think the best thing to do right now is to activate or install SMTP service on the NetXMS server itself.

Yes, this should be a reasonable workaround.

Best regards,
Victor

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
запускать на сервере мониторинга?

да