Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Victor Kirhenshtein

#7351
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
#7352
I suggest the following scheme:


conditionevent when trueevent when false
equal 1COP_SERVICE_STARTINGCOP_SERVICE_OK
not equal 0COP_SERVICE_DOWNCOP_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.
#7353
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
#7354
Общие вопросы / Re: NetXMS-0.2.20-RC4
March 12, 2008, 07:20:29 PM
Консоль версии RC3 иногда падала в core после изменения properties объекта.
#7355
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
#7356
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
#7357
Общие вопросы / Re: NetXMS-0.2.20-RC3
March 11, 2008, 10:54:40 AM
Можно ничего не писать, какие-то правила для корреляции событий при 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 повесить на эти события.
#7358
Общие вопросы / Re: NetXMS-0.2.20-RC3
March 11, 2008, 09:38:27 AM
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 и восстанавливается нормальная обработка событий.
#7359
Общие вопросы / Re: NetXMS-0.2.20-RC3
March 10, 2008, 07:04:02 PM
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.
#7360
General Support / Re: Condition
March 10, 2008, 04:40:40 PM
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
#7361
Общие вопросы / Re: NetXMS-0.2.20-RC3
March 10, 2008, 09:04:06 AM
Da, etoj ikonki tam ne dolzno bilo bit' :) Zabil strochku v kode zakommentirovat'...
#7362
General Support / Re: Condition
March 07, 2008, 12:40:40 PM
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
#7363
Announcements / NetXMS 0.2.20-RC3 is available
March 07, 2008, 12:38:56 PM
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
#7364
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
#7365
General / Re: Is development still happening?
March 07, 2008, 09:37:10 AM
I will roll out 0.2.20-RC3 today, and if nobody found any bugs, final 0.2.20 release will come out Monday or Tuesday.

Best regards,
Victor