I'm looking for the best way to handle alarms coming from about 15 process probes. What I am looking to do is
#1. (preprocess) and run a script on the alarms and write the data out to a text file.
#2. then exclude the alarms.
Is this possible?
I would usually handle this using an auto-operator, but I think it should be possible using a pre-processing rule. According to the documentation, the file.write() method is available for use in PPR scripts. You could write to a file using file.write(<file location>,<text to write>) then use "return nil" to exclude the alarm.
Well, not finding a way to handle this. The problem is they want a text file written every 5 minutes saying, "it's up", it's up.. it's up.. (the alarm message that is)
I tried talking them into just taking the DOWN but they want what they want. So I'm trying to find a way not to have 100 alarms sitting in my alarm window.
So which part are you having trouble with? Problems writing the text file? Problems keeping them out of the alarm console?Have you considered leaving the alarms open but making them invisible?
problem with keeping it out of the alarm console.
Invisible would still keep way too many alarms in the console so I would rather process them, write the test file then dump them. It seems now that all I will be able to do is let them come into the console then query for what I want to write to the file then either close them or make them invisible.
In the pre-processing script, are you ending with a "return nil"?
I think the problem I am now having is (I'm off track). I'm trying to read the DB file (alarm.list) which I know will not work because what am I trying to do already says the alarm is in the console view.
I do not see anything in the docs anywhere that points me on how to read the alarm message (queue).
Here is what I was trying to do.
local buffer = ""file.delete ("d:\\Alarms\\output.txt")al = alarm.list ("severity","Information")if al ~= nil then for i,a in pairs(al) do buffer = (buffer .. a.time_supp .. "," .. a.hostname .. "," .. a.message .. "\n") endendfstat=file.write ("d:\\Alarms\\output.txt",buffer)if fstat ~= false then print("File written")end
Then of course if I do (return nil) I will never see anything because the above script have no info.
Are you running this script in a pre-processing rule? If so, the alarm.list() function should not be available. In pre-processing, the fields from an alarm message are in a (table) variable named event.
If you run the script as a scheduled job, it should work, and then you should not need to use "return nil". You would need to use the action.close() function to remove them from the alarm console.
So either way the information goes into the DB before it can be exluded correct? and looking at the last page in the nas brief that would be a yes... So either way is just skinning the cat a different way...
No, pre-processing lets you deal with an alarm message as it arrives at the NAS before it becomes an alarm and before it goes into the NAS database. If you "return nil" from a custom pre-processing script, you will never see the alarm.
AO profiles work on alarms, not alarm messages, so they only take action after the alarm is in the database.
OK. I get it.. so until now I could exclude (gui) and now I just have to figure out how to deal with the alarm messages during pre processing phase. Something I don't have the talent for but can learn if I can find the correct documentation or examples. Does the NAS Brief help with that or only with alarms already in the alarms db?
The NAS Technical Brief (whitepaper) covers everything related to scripting pretty well, including pre-processing.
There are probably only 2 things you need to worry about if you try to convert your script from an AO profile to a pre-processing rule:
Because you are working with an alarm message rather than a full alarm, some of the fields are not available. The whitepaper lists out the available fields, so that should make it fairly simple.
Do you have a link to latest NAS Brief? I saw 528 I think.
The contents of the whitepaper are in the online documentation for the NAS.
Look near the end (labeled "Appendix 1" in the help for older versions).
Retrieving data ...