Search, View and Navigation

Event Management

Using Orb Data's considerable experience, the service will provide a recommended list of alerts for each of the supported infrastructure components. Critically, each potential event will be added to a Message Catalogue database that details amongst other things; the message severity, required action, support team to be notified, and message owner. This will ensure that each important service affecting alerts are identified and documented

Best Practice Alerts

In a well installed environment the alerts will have been tuned overtime however if this is not the case an initial set of recommended best practice alerts (situations) per application and Operating System will be applied to the customer’s servers. This will ensure that the customer will have a effective offering within a few days of the service being implemented.

Current best practice alerts are available for:

• Operating Systems
• AIX
• Linux
• Windows
• Solaris
•  Applications
• Exchange
• Active Directory
• .Net
• IIS
• MS SQL Server
• Oracle
• DB2
• WebSphere MQ
• VMware
  
• ITCAM
• ITCAM for Transactions

Message Catalogue

A key component of the Orb Data Managed Service solution is the Message Catalogue. The primary function of the Message Catalogue is to document the alerts that a system or application is capable of generating during its operation with the aim of providing the support teams with information that will enable them to respond to incoming alerts in a timely, appropriate and consistent fashion. 

Orb Data Message Catalogue Entry Format

For a Message Catalogue to be successful it is imperative that a well defined and structured format is applied consistently across all entries.  Although capable of being tailored for individual customer requirements, a typical format for entries in the Orb Data Message Catalogue is as follows:

• Alert Text – the alert as it will appear to the operator
• Severity – the severity of the alert
• Description – more detail about the alert including what has generated it, why it has been generated and what the implications are
•  Business Impact – what impact the problem represented by the alert is likely to have on the immediate service and the business as a whole.  This information is of vital importance as it will help the operator to understand the significance of the alert and therefore the priority that should be attributed to it
• Required Action – how the operator should respond to this alert.  Typically includes what first line support actions should be taken and any cross references to the Known Error Database
• Escalation – how the operator should escalate this alert to the relevant support area, e.g. raise an incident, page on-call etc
• Owner – each entry in the Message Catalogue has a designated owner who is responsible for the content.  This is a key field as it provides a direct contact, should details regarding the message need to be clarified or updates suggested
• Revision History – how this entry in the Message Catalogue has been changed over time

All alerts should have an entry in the Message Catalogue so that each event can be directed to the right place and with as much information as possible. These entries will be added overtime however some fields (such as support contact) will be required from day 1 as this information will be needed to redirect situation to the correct teams.

Integration

Integration will be made with Netcool/OMNIbus and IBM Tivoli Monitoring.