NetXMS Support Forum

In the script, you have access to all event attributes via $event variable, which is an object of class NetXMS_Event with the following attributes:
code - event code
id - event id
severity - event severity (as number)
timestamp - event timestamp (as UNIX timestamp)
message - event message text
userTag - user tag associated with event
parameters[] - array with event parameters

So, to access event's parameter 6, you should use


$event->parameters[6]


Best regards,
Victor

Hi!

To authenticate NetXMS users via RADIUS, you should do the following:

1. Add NetXMS server's IP address to the list of RADIUS server clients

2. Set NetXMS server configuration parameters (via Control Panel -> Server Configuration):
RADIUSServer - IP address of your RADIUS server;
RADIUSPort - port used by RADIUS server (usually 1645 or 1812);
RADIUSSecret - secret you have set when added NetXMS server as RADIS client.

3. Create users with same login names as in Active Directory, and set authentication method in user's properties to "RADIUS".

And then RADIUS authentication should work

Best regards,
Victor

Tut sluchajno net opechatki?

@echo off
@sc stop spooler
@cs start spooler
@sc query spooler >>query.log

Execute action on management server means that given command will be executed on a machine where NetXMS server runs. In this case, parent process for a command will be netxmsd itself.

Execute action on remote agent means that given command will be executed on a (remote) machine where NetXMS agent runs. In this case, parent process for a command will be nxagentd.

Best regards,
Victor

Parsing logov (vkljuchaja vstroennij syslog) realizovan v 0.2.23.

Realizovano v 0.2.23.

You mean that agent version 0.2.21 was working with WMI without problems? This information can help me a lot with debugging. Could you please confirm that by installing older agent version on a host?

About eta - I'll try to fix it as fast as possible, but unfortunately I still cannot reproduce this problem in my environment.

Best regards,
Victor

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