Work with events

Events originating from many different sources can be processed, for example:

• HPE Software applications:

  • OM for UNIX

  • OM for Windows

  • HPE Network Node Manager i (NNMi)

  • SiteScope

  • HPE Systems Insight Manager

• Third-party management software, normally used to monitor specific environments or special needs not monitored by other solution components:

  • Microsoft Systems Center Operations Manager, Active Directory, Exchange

  • BlackBerry Enterprise Server

  • SAP

Alerts, for example, from CI Status Alerts and Event Based Alerts, can also generate events in OMi.

Event synchronization enables bidirectional communication between managers, for example, OMi and HPOM. Updates and modifications to events can be exchanged. For example, changes of ownership or modifications to the severity status of an event are synchronized between servers. All events forwarded from OM servers are treated as allowing read and write. Any changes made to these events result in a back synchronization to the originating HPOM server.

Notifications are Emails, SMSs, and Pager messages that OMi can send on receipt of events with predefined characteristics.

For example, if critical events for the most important business-relevant services are received by OMi during any weekend period, the engineer responsible for these services is immediately informed by an email, SMS, or pager message, or any combination of these.

Event priorities can be automatically calculated from the business model and the event's severity. Event priority is assigned one of the following values Lowest, Low, Medium, High, or Highest.

The event priority calculation is executed in the event pipeline on new events. It also can be started manually on multiple events from the console context menu.

Input parameters for the calculation are:

• Severity of the event

• Business criticality of the related CI (if available)

  Note If no CI is related to the selected event, the priority is None.

The business impact is provided by the Business Impact Service (BIS) and the severity is an attribute of the event.

The calculation of priority is based on the relationship in the following table.

In event forwarding, the calculated priority is forwarded to the receiving application. If the CI related to the event is configured in the receiving application, the event priority is recalculated by each receiving application. If the CI related to the event is not configured in the receiving application, the event priority contained within the forwarded event is used.

Event Correlation is used to automatically identify and display the real cause of problems. Events that are only symptoms of the cause event can be filtered out using the Top Level Items filter, resulting in a clearer overview of the actual problems that need to be solved. Event correlation relies on defining relationships between correlation rules, ETIs and ETI-values associated to events, and CIs and relations between these CIs.

The topology-based event correlation process works as follows:

• Checks whether a relationship exists between the events being correlated.

• Monitors the CIs and ETI values assigned to events being correlated.

• Determines relationship between two events by checking if there is a relationship in the topology database between the CIs to which the events are related.

The correlation result is displayed in the Event Browser with an icon in the C column to indicate that it is the result of a correlation process.

— Event is the cause of another event

— Event is the cause of one event and a symptom of another event

— Event is a symptom of another event

Events related as a result of correlation with the selected Event are displayed in the Related Events tab. The selected event can also be a symptom event and you can also see its cause in the Related Events tab.

If a better correlation is achieved and the correlation rule responsible for the new correlation possesses a higher weighting than the rule that generated the existing correlation, the new correlation replaces the existing one.

All possible correlation results are recorded and displayed in the Potential Causes sub-tab located in the Related Events tab. It shows the possible cause events, together with a reference to the correlation rule that generated the correlation. Additional information, such as the rule weight factor, and the time when the event was received, are also displayed. Operators can inspect all possible causes for a symptom event, better understand the matching correlation rules, and, if they have the appropriate permissions, manually change the cause of that event to any one of the available alternatives when investigating a problem.

For details about correlated events, related events, and potential causes, see Related Events.

For more information about the icons used in the Event Browser, see Use the Event Browser (HTML). For more information about setting up correlation rules, see Topology-Based Event Correlation Overview.

Event history is a log of information about who or which component has changed values of an OMi event. This feature enables an operator to see how event attribute values changed during the life of an event, for example, the sequence of severity changes. Event history information is available in a separate tab in the Event Details pane and can be viewed by any user with access to that event.

An event history entry is created for the following cases:

• User changes an attribute of an event by using the Event Browser.

• An external user or application changes event attributes by using the Northbound Interface.

• OM or another OMi instance synchronizes an attribute change to OMi.

• Duplicate suppression changes an existing event.

• Automatic closing of related events.

• Control is transferred, canceled, or returned.

• Server is added to the event forwarding list.

An event history entry is not created in the following cases:

• Events which are modified by the opr-close-events tool.

The following list summarizes the main technical characteristics of event history information:

• User cannot modify existing history information.

• Closing, deleting, and archiving events deletes history, but history is included as part of the XML output produced by the opr-archive-events tool.

• There is no limit to the number of history entries per event.

History is created if one or more of the following properties of an event are modified:

• Cause (cause/symptom relationship)

• Duplicate Count (Can be enabled and disabled in the Operations Management Infrastructure Settings under Duplicate Events Suppression Settings > Generate history lines for Duplicate Event Suppression).

• Correlation Rule

• Description

• Severity

• OM user

• AssignedGroup

• Custom Attributes

• Time Received

• Title

• Lifecycle state

• Priority

• Assigned User

In addition, changes to event annotations are also tracked as changes in the event history.

This task describes how to manually change the automatically-assigned priority of an event.

1. Open the Event Browser to display the list of known events:

   Workspaces > Operations Console > <select a perspective>

2. In the Event Browser, select the event for which you want to change the priority value.

3. Open the Event Details pane.

4. Select the required priority from the Priority list.

5. Click Save.

This task describes how to manually recalculate the priorities for selected events in the Event Browser. This may be necessary when Business Criticality values changed in the underlying business model, and you want these changes reflected in your active events.

1. Open the Event Browser to display the list of known events:

   Workspaces > Operations Console > <select a perspective>

2. In the Event Browser, select the events for which you want to recalculate the priority.

3. Right-click one of these events and select Recalculate Priority from the context menu.

   The priority value for the selected events is updated.

View closed events