One kind of trap that covers dozens of alarms - how to configure

[victor]

Hi!

There are few different ways to achieve required functionality. First is to create alarm message texts and keys based on subcomponent. Let's assume that you have mapped subcomponend identifier to parameter number 2 of your event. Then you can create alarms with key like DEVICETRAP_%i_%2 . With such key, events related to different subcomponents will create separate alarms, and events related to subcomponent with already active alarm will replace existing alarm's text, severity, etc. and update repeat count. Creating alarms of different severity is abit more tricky - you will need separate rule for each severity. Rules have to be identical except filtering script which should check severity in the trap. For example, if you have mapped severity to event's parameter number 3, and it is text string like "minor", "major", etc., you can use filtering scripts like this:

return $3 == "minor";

or simply

$3 == "minor"

(note the absence of the semicolon in last case).

Another possible way is to create single rule in event processing policy that will call NXSL script for trap-based event and stop processing, and in that script create different new event based on trap parameters (using PostEvent function).

And the hardcore way is to create server module that will process traps and do whatever needed - generate events, update object attributes, etc.

Best regards,
Victor

[Yarda]

That's promising. Thank you for the cookbook, I'll try your suggestions from the top. Hoping not to reach the hard-core...

Just a confirmation of my understanding. Every configured Event has a severity, this one will play no role in my scenario, won't it? I am going to set my Event as Normal, to have a lot of relaxing green color in the Event Monitor.

[victor]

Alarm severity may or may not be of same severity as originating event. When you create alarm from event in event processing policy, you have an option to set same severity as in event or any other fixed severity.

Best regards,
Victor

[Yarda]

Yes, that's what I meant; in my case where I am gonna generate multiple Alarms out of one Event, I will decide manually what would be their statuses. So that my Event's status is nothing else but only color label in the Event Monitor.

[victor]

Yes, exactly.

[Yarda]

I was successful with my configuration of multiple event policies. I've got good feelings. Tho' there is one extension to my situation. Imagine that for some of my numeric trap parameters I need to see a written description in alert's message.

ID parameter is a good example in my case. We have around 100 possible ids... It would be nice to be able to map numbers to some hardcoded/configured string values.

So, I need to go for the hard-core way, at least partially, anyway, don't I...?

What approach would you recommend? I am thinking of tweaking (somehow :)) every relevant trap and adding some special parameter that I can refer to as $(X+1) (where X is the number of properly mapped parameters in my SNMP trap mapping config)...

Thank you for your opinion.

Yarda.

[Yarda]

Also, I noted, and cannot explain it myself (yet), that when I generate my alarms, I have CRITICAL, MAJOR, MINOR and NORMAL all triggered by one "NORMAL" event, only sometimes I get change of the node's status.

Only sporadically (but not rarely :)) I see the following events in the Event Monitor:

Major SYS_NODE_MAJOR Node status changed to MAJOR
Critical SYS_NODE_CRITICAL Node status changed to CRITICAL
Warning SYS_NODE_WARNING Node status changed to WARNING
Normal SYS_NODE_NORMAL Node status changed to NORMAL

[victor]

Hi!

For showing text instead of code in events and alarms, you can use script in script library and macro like %[script_name]. For example, if you have some code as parameter number 5 in trap-generated event, you can create script called CodeToText in library:

switch($5)
{
   case 1: return "CODE 1";
   case 2: return "CODE 2";
   // and so on...
   default: return "Unknown code " . $5;
}

and then use

%[CodeToText]

in event and alarm message template.

Best regards,
Victor

[Yarda]

If my script contains:

return "HELLO";

...I get this string properly in my alarm's message.

In case of your suggested code that I simplified (for test purposes) down to:

return "HELLO" . $3;

I get:

Script (CodeToText) execution error: Error 5 in line 1: Invalid operation with NULL value

...the same failure with any other parameters, like $2, $4, $5, $6 ... Only $1 doesn't complain, cos' it is an empty string.

Definition of my alarm's message follows:

Alarm Card%5 %4: %3 Status: %2, Direction: %8, Port Level: %6, Port Number: %7 %[CodeToText]

Misunderstood your comments?

[victor]

Sorry, that was my mistake. Script called via %[] didn't get event's parameters in $1, $2, etc. Instead, you should use $event variable to access event attributes. Event class described here: http://wiki.netxms.org/wiki/NXSL:Event. To access parameters, you can use $event->parameters array. So, correct code in my example would be

default: return "Unknown code " . $event->parameters[5];

Best regards,
Victor

[Yarda]

The $event->... works like a charm. And that seems to cover all my needs. I am a happy hippo.

Will you have any advice also for the previously posted sub-question:

@yarda said in One kind of trap that covers dozens of alarms - how to configure:

Also, I noted, and cannot explain it myself (yet), that when I generate my alarms, I have CRITICAL, MAJOR, MINOR and NORMAL all triggered by one "NORMAL" event, only sometimes I get change of the node's status.

Only sporadically (but not rarely :)) I see the following events in the Event Monitor:

Major SYS_NODE_MAJOR Node status changed to MAJOR
Critical SYS_NODE_CRITICAL Node status changed to CRITICAL
Warning SYS_NODE_WARNING Node status changed to WARNING
Normal SYS_NODE_NORMAL Node status changed to NORMAL

Thank you,
Yarda.

[victor]

Hi!

Can you describe this situation with more details? I'm not sure that I understand it correctly...

Best regards,
Victor