Afternoon All,
I came across the following problem at a number of customers recently –
When we get a robot inactive alert ops don’t know how to prioritise the alarm as they don’t know if it’s just the robot or the server which is down.
I wrote the following simple script as a solution, it uses action.ping rather than a callback to net_connect to run a profile, mainly because the customers I’ve dealt with on this don’t want to set a profile in net_connect for each and every robot. Should be pretty straightforward to change it to use a callback to net_connect, I’ll give it a go.
The script runs on robot inactive alarms, gets the ip of the offending robot, pings it and updates the alarm message and severity. The sript assumes that robot inactive alarms have been set to major on the hub, mainly as the customers I spoke to wanted it this way.
We’re assuming network connectivity from the primary hub to the robot too, in multi-site tunnelled environments we’d have to go with a nas on remote hubs, I’ll set up a test environment and make any required additions to the script later.
I don’t know about anybody else but in my opinion this is the sort of functionality we should be incorporating into NMS in future.
I’d welcome any feedback good or bad (I’ll just ignore the bad stuff J, only joking)
Cheers
Dave
David Higginbotham
CA Technologies
Sr Consultant, Pre-Sales