Run AO by LUA script

[Legacy User]

It's any chance to run an Auto-Profile by a LUA script?

 

I checked the nas options by the Probe utility but I don't see any commandset to force any run, just for scripts.

[Anon Anon]

Hi,

 

Use triggers

 

-jon

[Legacy User]

It's not possible to do your suggestion.

 

I will explain what's supposed.

 

If there is a specific alarm, the nas must exclude or close the alarms before a certain AO runs.

 

My first try was to create a preprocessing rule calling a script. This script checked a trigger state and if the trigger is true the alarm was not returned. BUT the problem is: trigger.state is not supported on preprocessing rules.

 

Ok, now I am trying to develop another mechanism to do this.

For now I have a trigger that catch if an alarm is presented.

I though a few steps:

1. create a AO on the first position calling a script
2. the script will check if the trigger is true, if yes it will close the alarm, if not it will call an AO

 

Ah and put the overdue age on this last AO is not possible, must be on message arrival.

 

Do you have any ideia to perform this?

 

Thanks in advanced.

[Anon Anon]

Hmm it needs to exclude and if there is already an alarm, it needs to close that one?

[Legacy User]

Yes, if there is a specific alarm the others that match AO conditions must be closed.

 

After review all entire process I simplify all this dependencies. One AO that calls a script, the script checks the trigger state and if true it closes the alarm.

Then, the other two AO profiles has an overdue age 10 seconds, is enough to runs well.

 

BTW, thanks!

[Anon Anon]

BTW you can check trigger state in pre-processing scripts. You have to call the state() function rather than trigger.state(). It calls the same function.

 

I believe all of the Nimsoft-specific function libraries are disabled in Lua scripts run by pre-processing rules. This is done to avoid causing pre-processing to take too much time and slow incoming alarm messages. I believe the state() function was added specifically to bypass that restriction.

[Anon Anon]

Keith is right on the money here. Use the state() function is pre-processing scripts to evaluate a trigger state. I believe this is still in the documentation for the nas probe. However, I have not reviewed the latest doc for accuracy or completness to be able to say that conclusivley.

From the 4.20 nas docs......

Custom Pre-Processing
The event table is placed into the LUA context prior to executing the "custom" pre-processing rule. You may alter (launder) the event by setting the fields message, sid, source, hostname, user_tag1, user_tag2, visible and origin.

EDIT note: missing from this list are the custom 1 - 5 fields which can also be altered.

The following fields are present for the script to use:
.source - source of the alarm (typically ip-address)
.hostname - resolved name (robotname or ip-address to name resolution)
.level - severity level (0-5)
.sid - subsystem identification.
.message - alarm message text.
.origin - origin of the alarm (stamped by nearest hub, or in some cases the robot.)
.domain - name of originating Nimsoft domain.
.robot - name of the sending robot.
.hub - name of the nearest hub to the sending robot.
.prid - name of probe issuing the alarm.
.user_tag1 - user tag 1 (as set by robot).
.user_tag2 - user tag 2 (as set by robot).
.supp_key - suppression identification key.
.visible - flag for visibility (true = visible)

The script is expected to return the event (modified or not) or nil. A nil indicates that the event is to be skipped.
Note that the user_tag1 and user_tag2 fields will be stored in the database when the inbound alarm translates into a new event. 
Note that all pre-processing handling will, by nature, slow down the processing of inbound alarms.
Note that only a subset of the lua methods are available to the pre-processing script. The trigger.state method, through the state method, is available. These classes and methods are not available:

■ exit
■ sleep
■ nimbus
■ pds
■ trigger
■ action
■ database
■ alarm
■ note.