A few weeks ago I blogged about using event rate to alert to problems, the idea being to free a technician from needing to watch an alerts view and allow them to go and do some more productive tasks when no serious issues existed. The missing component then was how to alert this technician when the event rate suddenly spiked indicating a problem had occurred that required them to return to their desk.
A similar situation arose with a demo we have been building for a port authority. There the target audience for new alarms was a supervisor out on the dockside far away from a console in a control room.
In both these scenarios a mechanism using the new mobile UI and OMNIbus' ability to automatically send emails was used to create a practical solution.
OMNIbus ships with an automation "mail_on_critical" which can be copied and modified to create a new trigger "mail_on_eventrate_warning".
for each row eventrate in alerts.status where eventrate.Node = 'stats_eventrate' and
eventrate.Grade < 2 and eventrate.Acknowledged = 0 and
eventrate.LastOccurrence <= ( getdate() - 120 )
execute send_email( eventrate.Node, eventrate.Severity, 'Netcool Email', 'email@example.com', eventrate.Summary, 'localhost');
execute jinsert( eventrate.Serial, %user.user_id, getdate(), 'Email notification sent');
update alerts.status via eventrate.Identifier set Grade=2;
You may recall that the eventrate warning trigger created a synthetic event with @Node = 'stats_eventrate' so this can be used in the filter.
An alternative is to use Netcool Impact to generate the email via a policy, and this is the way it was done in the ports demo.
An eventrate warning alarm will now send out an email to the address 'firstname.lastname@example.org'. As this automation stands the email is rather basic, but in the ports demo the Impact policy resulted in a more sophisticated email:
Including URLs in the body of the email means that it is easy for the recipient to open the Event Dashboard set up to view these events.
The Event Dashboard is part of WebGUI and it needs, for this application, to be enabled for mobile UI. This is one of the settings available to a WebGUI administrator under the edit page dialogue. On a mobile device the Event Dashboard is rather basic but contains all the event details
The limitation with the present mobileUI is that it is read only and there is no option to either update the Journal or to use any Tools from the mobile UI. Plans exist to enhance the UI in OMNIbus 8.1 next year to provide Tools but the usual caveats about intentions not being commitments apply.
However there is a work around.
You may have noted that the email sent out by Impact in the ports scenario had "Serial = xxxx" at the end of the Subject line. This creates a link to the event in OMNIbus through the unique @Serial field. Now if the recipient replies to the email, with or without putting in any text in the body, then the Impact policy will detect the email coming in, parse the Serial number of the event from the end of Subject line and use that to update the original event. In the ports scenario the update was to acknowledge the event and to mark it for Trouble Ticket creation.
This meant that the ports demo had a complete scenario where an issue was detected through monitoring the mechanical components of a dock crane, an event was created in OMNIbus, a notification of that event was emailed out to a supervisor on the dockside who would be able to lift the covers on the crane's generator. If an engineer needed to be called then the supervisor could just reply to the email, that would generate the work order and when the work order was cleared then the OMNIbus alarm would be cleared too - and this would be visible to the dock supervisor on the same smartphone.
Those who monitor alarms and events need no longer be desk-bound