Pre-Processing Rule Script vs. Profile Script

[Mike Bowling]

I have a script that appends specific verbiage to an alert AND changes the severity of the alert…and it works great when initiated by a Pre-Processing Rule.

I noticed that a NAS Profile can execute scripts as well but when I create a profile, using the exact same parameters as the PPR, nothing happens when the matching alert comes in.

Is there something different about how the Profile runs the script vs the PPR?

Basically, the alert being generated is INFORMATIONAL and I want nothing appended to the alert message until the overdue age reaches 6 hours…but I also want the severity changed from INFO to CRITICAL at the same time it escalates the alert.  Again the PPR rule runs the script fine but I would rather have the Profile do it so it will make all the changes when the overdue age is reached.

Any ideas?

[Jim Christensen]

There are major differences in a script for pre-processing and one used by an AO profile. The pre-processing script works with an "event" object. The AO profile script with an "alarm" object. Pre-processing scripts also have a limited set of functions that are applicable. Consult the nas probe documentation for a complete reference.

[Mike Bowling]

Thanks for the clarification...figured it might be a fundamental difference like that.  Haven't worked with scripts much so this really helps.

[Petr Ketner]

Hi Mike,

Definitely would help to share your AO Profile/PreprocessingRule Profile

Regards

[Mike Bowling]

So here is the script that a pre-processing rule calls:

-- This script changes severity to CRITICAL and appends instructions to end of alert for Ops console --

if event.user_tag2 == nil then
event.message = event.message .. " - Create ticket for Field Services - TEST"
event.level = 5
return event
else
event.message = event.message .. " - Create ticket for "..event.user_tag2.." Field Services - TEST"
event.level = 5
end
return event

Basically, I have probe on a number of robots that generates a MINOR alert that needs to stay at that severity for 6 hours then get escalated to CRITICAL.  I know the severity can be escalated by a profile but it is only to the next level.  Since I can use 'overdue age' in a profile and then run a script, I'm thinking this might be the best way to handle...just not sure how to create Profile script vs PPR script.

Also wondering if instead of using script could I use other options like new_alarm or visibility to keep the alarm invisible until the overdue age is reached...??

[Garin Walsh]

There are a couple things to keep in mind when consider the "how do I achieve this" when there are multiple routes.

For processing alarms, you generally have four places you can affect the behavior: the source probe configuration, NAS preprocessing script, alarm enrichment probe, and nas AO script.

In my usage, I categorize my functionality like:

Source probe: this is core functionality

NAS preprocessing script: this is functionality that should have been in the source probe or functionality that impacts most/all alarms similarly and/or functionality that would affect how nas ultimately handles the alarm.

Alarm enrichment: Addition of well structured database data to most/all alarms

NAS AO: All other automation

From a growth standpoint, the preprocessing script option doesn't scale well - NAS will pick only a single one of the matching preprocessing profiles and run it. So in your case you couldn't have a process profile that adds text to some alerts and a preprocess profile that changes severity for some overlapping set of alarms and expect that common set to have both operations applied. What I have found is that you really can only have a single monolithic preprocessing script and then incorporate into it the profile filter logic.

Also, it was mentioned before, but preprocessing scripts operate on an "event" and AOs operate on an "alarm". Or maybe in a different perspective, the preprocessing function is a filter - it accepts a stream of events, filters them, and emits a stream of events. AO profiles are different, they match an existing alarm, operate on it and save the results, that save event retriggers the evaluation of whether any AO profiles match. The result is that AO profiles can create loops in processing while a preprocessing script can not.

So, to your question, the operation "appends specific verbiage to an alert AND changes the severity of the alert" is a good candidate for a preprocessing script. This is essentially a "source probe generates an incorrect alarm which needs to be corrected" event.

The "I want nothing appended to the alert message until the overdue age reaches 6 hours" part requires an AO for two reasons - First, there's no "time" data that's usable in a preprocessing script related to the alarm message, and second, the preprocessing script operates on the inbound data before it becomes an alarm and so there's nothing cause the nas to do something after 6 hours.

Your AO to change the priority would look something like:

al = alarm.get () -- retrieve the alarm data related to the activated profile

al.level = 5 -- Set the alarm level to critical

alarm.set(al) -- Store the alarm back to the nas

Your profile would need to have the matching criteria and the overdue age set.

[Mike Bowling]

Is there something I need to modify?

[Garin Walsh]

alarm.get () in an AO profile returns the alarm data that invoked/matched the profile. When run within the IDE, there's no invoking AO profile and so no alarm. That is why it returns nil.

If you have the nimid of an existing alarm, you can supply that value as a string argument to the function for testing.

When I am testing I will use something like

al = alarm.get ()

if ( al == nil ) then

   al = alarm.get ("AB1234567890")

end

But for prod usage, you don;t want that because it's possible for an alarm to disappear between when the AO is invoked and when you go to use it.