NetXMS Support Forum

Thank you for report, it's corrected now.

Best regards,
Victor

Hello!

Status DCI returns current status of a node. Meanings are following:

0 - Normal
1 - Warning
2 - Minor
3 - Major
4 - Critical
5 - Unknown
6 - Unmanaged

Node status is calculated based on status of child objects (usually interfaces) according to status calculation rules set for this node (default is "most critical"), and active alarms related to this node.

Best regards,
Victor

0.2.20-RC4 actually fix only one bug in console (random crash when changing object properties). No other bugs was reported so far, so I will build final 0.2.20 tonight.

Best regards,
Victor

Hello!

Brief description of common parameters provided by NetXMS agent can be found here: https://www.netxms.org/documentation/common_parameters.html. For Disk.FreePerc() parameter argument is a mount point. For example, on Windows in can be

Disk.FreePerc(C:)

and on UNIX

Disk.FreePerc(/usr)

(assuming that /usr is a mount point).

Unfortunatelly there are no step-by-step example for configuring SNMP DCI, but it should not differ much from configuring agent DCI - you just choose "SNMP Agent" as origin in DCI configuration dialog, and press Select button - you will see MIB browser instead of agent parameters list. Select required entry from MIB browser, and OID will be automatically put into Name field. All other configuration are completely the same as for agent DCI.

Best regards,
Victor

Hello!

%i is a unique identifier of the event's source object (usually node). If you plan to monitor only one service per node with these events, then using just %i is ok, but if you monitor more then one service running on same node and generate same events for diferent services, than you have to distinguish alarms nnot only by node id, but also by service. %3 and %5 is event-specific parameters, number 3 and 5 respectively. For events generated when threshold condition becomes true, parameters are following:

1) Parameter name
2) Item description
3) Threshold value
4) Actual value
5) Data collection item ID
6) Instance

For events generated when threshold condition returns to false, parameters are following:

1) Parameter name
2) Item description
3) Data collection item ID
4) Instance

So in my example I construct alarm key from node id and DCI id.

You can find list of parameters for any predefined event by opening Control Panel -> Events -> Edit appropriate event record and looking at the description field.
All possible macros for event processing policy can be found in NetXMS user manual or here: https://www.netxms.org/documentation/macros.shtml

Best regards,
Victor

I suggest the following scheme:

condition	event when true	event when false
equal 1	COP_SERVICE_STARTING	COP_SERVICE_OK
not equal 0	COP_SERVICE_DOWN	COP_SERVICE_OK

Uncheck "always process all thresholds". Threshold order is important.

Then you will get COP_SERVICE_STARTING if service is in starting state, COP_SERVICE_DOWN if service in state other than running or starting, and COP_SERVICE_OK when it returns to running state.

If you wish to create and terminate appropriate alarms accordingly, you can add the following rules to event processing policy:

Rule 1
Event: COP_SERVICE_STARTING, COP_SERVICE_DOWN
Alarm: Generate alarm, text: %m, key: SERVICE_PROBLEM_%i_%5

Rule 2
Event: COP_SERVICE_OK
Alarm: terminate alarm with key SERVICE_PROBLEM_%i_%3


Then you will have active alarm with appropriate text when service is not running, and it will be automatically terminated when service goes back online. If service will go from starting to, for example, stopped state, text of alarm generated by previous COP_SERVICE_STARTING event will be replaced by message text of COP_SERVICE_DOWN event, so you will have actual information in your alarm browser.

Hope this helps!

Best regards,
Victor

P.S. Also there is a description of threshold checking algorithm in NetXMS user manual, in section 5.2.3.3.

Hello!

If you wish to distinguish between different states, you can create multiple thresholds and events - for example, create separate event SERVICE_PAUSED and for service status DCI create additional threshold "when equal 1" and generate event SERVICE_PAUSED from it. It depends on your environment and requirements - there are no universal tips. From my experience, in most cases considering service as down if it's not running is ok, because it cannot process requests anyway, in whatever state it is, and it's the most important information - actual state is not so important.

Best regards,
Victor

Консоль версии RC3 иногда падала в core после изменения properties объекта.

Hello!

Looks like typo or bug in MIB file if you select trap OID from MIB browser: in the trap log, trap OID is .1.3.6.1.4.1.674.10892.1.0.1354 while in trap configuration window it is .1.3.6.1.4.1.674.10982.1.0.1354.

Best regards,
Victor

Hello!

From the description looks like you have correctly configured everything. Could you please post screenshots of your trap configuration and actual traps from trap log (you can wipe out IP addresses if needed - I don't think they are important in this case)?

Best regards,
Victor

Можно ничего не писать, какие-то правила для корреляции событий при event storm не нужны.

Если есть желание узнавать о наступлении такой ситуации, то генерируем аларм из события SYS_EVENT_STORM_DETECTED, а по событию SYS_EVENT_STORM_ENDED убираем его.
Например так:

Rule 1:
Source: any
Event: SYS_EVENT_STORM_DETECTED
Alarm: %m key EVENT_STORM

Rule 2:
Source: any
Event: SYS_EVENT_STORM_ENDED
Alarm: terminated with key EVENT_STORM

Естественно можно и какие-то actions повесить на эти события.

Quote from: Alex on March 10, 2008, 07:35:42 PM
Victor
Можно еще и примеры, в виде картинки хотя бы, для SYS_EVENT_STORM_DETECTED и SYS_EVENT_STORM_ENDED?
Спасибо заранее.

Система постоянно мониторит количество событий в секунду. Если в течении определенного количества секунд (параметр EventStormDuration) происходит больше событий чем задано параметром EventStormEventsPerSecond, то генерируется событие SYS_EVENT_STORM_DETECTED. Все последующие события отмечаются как correlated и не пропускаются через event processing policy. Когда событий становится меньше чем EventStormEventsPerSecond в течении EventStormDuration, то генерируется событие SYS_EVENT_STORM_ENDED и восстанавливается нормальная обработка событий.

Quote from: Alex on March 10, 2008, 11:33:40 AM
Хех, но значит есть в проекте это. И это хорошо В 0.2.21 будет?

Это уже есть, можно делать разные интересные вещи при помощи ситуаций и скриптов. Сейчас нет времени, а вечером напишу подробно как этим пользоваться.

Quote from: Alex on March 10, 2008, 11:33:40 AM
Еще вопросы.
1. Нашелся новый таб в свойствах нода: Trusted Nodes. Что это и с чем его едят?

Это контроль использования proxy node в DCI. Теперь если я определяю для ноды А DCI и указываю ему proxy node B, то нода А должна быть в списке Trusted Nodes у ноды В. Иначе возникает ситуация когда имея доступ только к ноде А, я могу получать параметры ноды В. Если этот механизм не нужен, то его можно отключить, выставив параметр сервера CheckTrustedNodes в 0.

Quote from: Alex on March 10, 2008, 11:33:40 AM
2. Что такое Retain Customer Interface Names?

Остатки работы над поддержкой interface descriptions. Ни на что не влияет. В релизе уберу.

Quote from: Alex on March 10, 2008, 11:33:40 AM
3. Enable Event Storm Detection?

Включает отслеживание слишком большого количества событий в секунду. Если порог превышен, то генерируется событие SYS_EVENT_STORM_DETECTED, и все остальные коррелируются с ним.

Quote from: Alex on March 10, 2008, 11:33:40 AM
4. Status Shift?

Значение по умолчанию для алгоритма "relative" status propagation.

Hello!

Thanks for your post. I forgot to mention this upgrade problem The really needed steps is 2 and 3, and -c option is needed. This is because in 0.2.20 changes syntax of netxmsd.exe command line, to be in common style with agent and other tools.

Best regards,
Victor

Da, etoj ikonki tam ne dolzno bilo bit' Zabil strochku v kode zakommentirovat'...