Implementation Guide › Implementation › Create Deliverables (Contract Manager) › Add Service Level Alert Profiles

Add Service Level Alert Profiles

The alert profile allows the definition of conditions under which an alert notification is sent to a predefined recipient using a specified device.

Before creating any profiles, it is worth considering which conditions are important enough to require notification and also who the intended recipients should be. It is important to define profiles which can assist the Contract Manager and System Administrator to effectively manage any problems and service issues encountered. All notifications should be specific in directing the required resources to address the most urgent issues to prevent a situation of breach.

When adding service level alerts there are a number of fields which can be used for determining the status of the Metric and for deciding whether an alert condition should be triggered or not. Any one of the standard Metric details can be used for filtering and condition criteria (such as Contract, Service, Metric names, targets, timeslots, service level results etc) Service Level predictions can also be alerted upon, in which case some additional values such as best/worst case deviation are provided, and service levels can also be estimated. These are extremely useful for deciding whether a service level breach can be recovered from or not, within a given period.

Alerts based upon the System Log and general sections of CA Business Service Insight are other extremely useful features and permit an alert to be sent based upon any action occurring within the system (that is written into the system log). Since almost all actions are logged, this provides a very wide scope for the alert profiles. Common system log alerting profiles consist of:

• Notification of an Adapter running alert for the Data Source Expert.
• Any 'Error' conditions entered in the log, email alert sent to the System Administrator.
• Custom errors created by the Business Logic relevant to specific conditions from the data sources, can generate an email alert to the group responsible for the service within the organization, and the Contract Manager. (i.e. High priority incident has not been resolved within timeframe > send alert to help desk to escalate the issue)
• Repeated invalid login attempts, can be emailed to the System Administrator to determine is someone is trying to hack into the system
• New Translation Entries arrived from the adapter (i.e. New resource entries have been found in a data source, which may need translation in the system to allow the SLA's to be calculated correctly.

Following is the Alert Profile Details window, showing the configuration of a custom alert profile reporting on a custom event type of the 'Helpdesk Ticket Open Events' - If the criteria is matched, then a critical alert is sent to the Helpdesk coordinator to ensure this ticket is managed efficiently. This could be useful for situations where an application is under scrutiny at some time and requires an extra-special level of care.

Following is an example of implementing a Service Level violation alert which is based upon whether the SLA can still be met, considering the current service level and the remaining time left in the business tracking period of the Metric.

Example: Reversible SLA violation alert

This alert is triggered when an objective (Metric) is currently being violated, but since the best case scenario indicates compliance with the objective, the violation can be avoided if a more suitable service level is provided henceforth.

Type: Service level prediction

Condition formula:

#Deviation>0 And #BestCaseDeviation<=0 And #BestCaseServiceLevel<>#WorstCaseServiceLevel And #ClusterItem = ""

Message:

Note that the objective '#Metric' of the Contract '#Contract' is currently being violated, but the violation is reversible.

While the Service level target is #Target, the following service levels are predicted:

• Service Level by now: #ServiceLevel (Deviation: #Deviation%).
• Worst Scenario Service Level: #WorstCaseServiceLevel (Deviation: #WorstCaseDeviation%).
• Best Scenario Service Level: #BestCaseServiceLevel (Deviation: #BestCaseDeviation%).