DX Unified Infrastructure Management

Hi all,

Is there any equivalent of alarm.get from LUA in perl ? Or otherwise, how to access alarm fields from perl ?

Specifically, the scenario is as follows.

I already have a working LUA program which works on each alert in an on-arrival scenario, calls alarm.get and logs individual alarm fields like nimid, level, msg etc to a flat file with one line per alarm. Now instead of this approach, I want to create a perl program which runs in periodic fashion every time, preferably through a timed probe, accessing another queue which subscribes on "alarm" subject.

Is this possible, and if yes, please let me know the callback etc ?

Regards,

Amit Saxena

One way to do something similar to what you are wanting that I have done with vbscript, cscript and cmd apps but not with Perl is to Call the script and pass arguments from the AO Profile using LUA to the script. For example I used this with a custom Remedy script and passed the Alarm.get variables that i needed from the LUA AO Script to a VBScript and then run code in the VBScript and then return variables back to LUA for use with updating the Alarm. For my situation it sends the Alarm Fields to VBS, VBS Creates the ticket with web services and then Echos back the Ticket Number to LUA and places it in Custom 1. Below is the LUA portion of the AO Script. Maybe this will help

--Dim Vars
local a,f,s
--Get the Alarm

--a = alarm.get("XX49920781-94199")
a = alarm.get("VK03385134-00264")
printf(a.message.." "..a.user_tag1.." "..a.user_tag2.." "..a.nimid.." "..a.hub.." "..a.robot)
--Run External VBS to Process the Web Service Calls and Return Incident Number
f = assert(io.popen("cscript F:\\RemedyScripts\\RemedyCreate.vbs ".."\""..a.message.."\"".." ".."\""..a.user_tag1.."\"".." ".."\""..a.user_tag2.."\"".." ".."\""..a.nimid.."\"".." ".."\""..a.hub.."\"".." ".."\""..a.robot.."\"",'r'))
s = assert(f:read('*a'))
s = string.gsub(s, '^%s+', '')
s = string.gsub(s, '%s+$', '')
s = string.gsub(s, '[\n\r]+', ' ')
printf(s)
tblremedy = split(s,":")
if table.maxn(tblremedy) > 1 then
printf(trim(tblremedy[2]))
strremedyid = trim(tblremedy[2])
else
printf("NO SPLIT FOR VALUES")
strremedyid = ""
end

--Update Alarm Custom Field 1 with the Remedy Ticket Number
vals = {nimid=a.nimid,custom_1=strremedyid}
alarm.set(vals)

If you want to process alarm messages from a queue, it would probably be better to run the Perl probe as a daemon rather than a timed probe. Keep in mind though that processing alarm messages means you see them as raw messages and not actual alarms. This might be just what you want, but it is a lot different from processing alarms after they are created.

If you want to get a list of alarms from the NAS in an external script, you can use the get_alarms callback. A while back the callback would return only 200 alarms at a time and required a session in order to get more than that. I think that is not longer the case, but I am not completely sure about that or whether the limit was removed or just increased.

I'm also wondering about this right now. I need to retrieve alarm information (custom fields) based on clear messages. I figured the best way to do it is to do a "transaction_list" callback to NAS, as cleared alarms wont be available in the alarm list anyway. I figure this could also be used for active alarms as well.

-jon

if you want to see a message when an alarm is cleared, you can attach a queue to pick up alarm_close messages and pick these up with a Perl daemon probe. These are emited by the nas when an alarm is closed. I am not sure they have all alarm details in them, but they do have the nimid, with which you can retrieve the rest.

If you want to see all clear messages (some probes send a set at startup for instance) then you can pick up alarms, drop any with a level > 0 and process the remainder.

Hi Robin,

I am actually submitting to alarm_close. The thing is, that the alarm_close message only contains a table of nimid's that are cleared with that message, it doesn't contain the messages themselves. That's why I figured I'd have to go for the transaction history. But eventually I had to go with just the nimid of the cleared alarm as I needed to fetch information from another system based on it.

-jon

If you want full details of alarms when they clear, I think your best bet is to process the alarm_update messages. By default, the NAS will send only alarm_close and not alarm_update when an alarm clears, but you can change that by disabling automatic acknowledgement of clear alarms. If you still want clear alarms to close automatically, you can make that happen in an AO profile. But because the close is not tied to the clear in the NAS configuration any longer, you should still get the alarm_update messages.

Thanks Keith, I had no clue there was such an option in the NAS. While I don't need it for this anymore, I imagine it might come in handy some other time.

-jon

Keith,

It seems to me that alarms that are acknowledged by users in the console will still send only the alarm_close message even if automatic acknowledgement is disabled. If that is indeed the case, it does seem a little weird to me, as some alarms are such that they must be acknowledged. I need to process all clear / close messages. So far going with the alarm_close is working. Also reposting all clears under different subject works, but this of course adds traffic to the bus that basically seems to be "extra".

-jon