NetXMS Support Forum

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

Hello!

ConditionStatus() DCI is available in 0.2.20-RC3. Please note that to use it you should add node on which you configure this DCI to condition's trusted nodes list, or disable trusted nodes checking by setting global server configuration parameter CheckTrustedNodes to 0.

Best regards,
Victor

Version 0.2.20-RC3 (Release Candidate 3) is available for download from https://www.netxms.org/download/rc. Changes from 0.2.19 are following:

- Implemented advanced event processing using situations
- Added checking of NetXMS server own network connectivity via beacon hosts
- Implemented "proxy node" functionality for DCIs
- Added possibility to use values of other DCIs in transformation scripts
- Added possibility to specify multiple recipients in e-mail or SMS action
- Implemented System.CPU.Usage for individual processors on Linux
- PING subagent: added parameter ICMP.PacketLoss(*)
- Command line options for the server changed to use common style
- Added UNICODE support in client part on Linux/UNIX
- Implemented macros in template DCIs (expanded when template applies to node)
- Added event storm detection
- Added possibility to specify multiple SNMP community strings for discovery
  and configuration polls
- NetXMS server now can understand interface aliases (description in Cisco terms)
- Added optional synchronization of node names with DNS
- New command line tool for managing alarms - nxalarm
- Implemented "stop processing" option for event processing policy rule
- Implemented "move" operation for templates (move between template groups)
- New internal parameter: ConditionStatus(*)
- Fixed issues: #188, #189, #190, #191, #195, #199, #203

If nobody finds serious bugs in this RC, it will become 0.2.20 on Monday or Tuesday.

Best regards,
Victor

Hi!

Problema s kounterom v propushenom dvoetochii. Pravil'no budet

*WinPerf
Counter = NetUtilization:"\Network Interface(Broadcom NetXtreme Gigabit Ethernet)\Current bandwidth":60:A:INT:Average bandwidth utilization for last minute


A postavlennuju zadachu mozno reshit' cherez transformation script - delaetsja DCI na bytes/sec cherez interface, i v transformation script delaetsja pereschet v procenti. V tekuschej versii maximal'nuju skorost' interfeisa pridetsja v scripte zadavat' konstantoj, no nachinaja s 0.2.20-RC3 mozno budet ispol'zovat' znachenie DCI.

Primer transformation sripta (dlja 100Mbps interfeisa):


$1 / 1000000


Best regards,
Victor