Creating Event Type and Health Indicators

Incoming events for the various CI types need to be analyzed, so that meaningful event type indicators (ETIs) and health indicators (HIs) can be created.

ETIs are attributes of events (they do not exist as instances in their own right). ETIs are used to categorize incoming events according to the type of occurrence in the managed IT environment. You can configure your monitoring policy in OMi to include an EtiHint. At least one value is required for an ETI, which is used to describe the event occurrence in the environment. An example would be Lost database Connection:Occurred.

Any occurrence on the monitored system of a given type causing an event must be assigned the same ETI. After defining appropriate correlation rules, events are correlated based on the ETIs. The correlation rules relate types of events that can occur on the CI.

HIs determine and display the health of specified aspects of a monitored CI. An HI is used to indicate if a hardware resource is available, and uses one value to represent the normal state of the CI. An example would be ACME System Status:Available. One or more values are used to indicate abnormal states for the CI, such as ACME System Status:Unavailable.

HIs can also indicate the state of a software application, for example, when the load on certain process is normal, high or exceeded. An example of an abnormal state would be Job Queue Length:Too Long for the ACME Work Process CI type.

Only events that provide CI state information can set a health indicator. Health indicators are assigned to a specific configuration item type through the associated ETI.

HIs also provide the data needed by a key performance indicator (KPI) to calculate the availability and performance of monitored resources. See Assigning HIs to KPIs, which shows how to assign HIs from the ACME example to health-based KPIs.

The new CI types for our ACME example environment were introduced in the section Integrate new applications.

For these CI types, there are specific ETIs and HIs. Overview of ETIs and HIs shows the result of an investigation into which ETIs/HIs are important within an ACME environment.

Overview of ETIs and HIs

CI Type Display Name	Category	Name	Value	Severity	Policy
ACME System	HI	ACME System Status	Available	Normal	ACME_SystemStatus001
ACME System	HI	ACME System Status	Unavailable	Critical	ACME_SystemStatus001
ACME Application Server	HI	ACME Application Server Status	Available	Normal	ACME_AppServerStatus_001
ACME Application Server	HI	ACME Application Server Status	Unavailable	Major	ACME_AppServerStatus_001
ACME Work Process	ETI	Job Aborted	Occurred		ACME_opcmsg_001
ACME Work Process	ETI	Job Start Passed	Occurred		ACME_opcmsg_002
ACME Work Process	HI	Job Queue Length	Normal	Normal	ACME_JobQueue001
ACME Work Process	HI	Job Queue Length	Too Long	Major	ACME_JobQueue001
ACME Work Process	ETI	Lost Database Connection	Occurred		ACME_LogFile001

You create HIs and ETIs in the following area of the OMi user interface:

Administration > Service Health > Indicator Definitions

Alternatively, click Indicator Definitions.

Here is an example of how you would create an HI for the CI type ACME System:

1. Open the Indicator Definitions page:

   Administration > Service Health > Indicator Definitions

2. In the left pane, click the CI type you want to set an indicator for, in this example, ACME System.

3. In the central pane, click New. Alternatively, you can click New in the right pane.

   The Create Health Indicator panel opens.

4. In the General section, complete the following information:

   1. Enter the display name of the HI to be created, ACME System Status, an identifier, and, optionally, a description of the HI.

      Note By default, the Identifier field is filled in automatically. For example, if you enter ACME System Status as the display name for the target Service Manager server, ACME_System_Status is automatically inserted in the Identifier field. Of course, you can specify your own name in the Identifier field if you want to change it from the one suggested automatically.

   2. The type of indicator that you want to create for this example, Health indicator with associated event type indicator, is selected by default. If you wanted to create an event type indicator, you would select Event type indicator.

5. In the States section, you can add indicator states by clicking New State, or edit an existing state by clicking Edit.

   In this example, you are adding new indicator states. Therefore, make one state the default state with Normal severity with the value AVAILABLE, and another state with the severity Critical with the value UNAVAILABLE.

   To add the default indicator state with the value AVAILABLE and with normal severity, do the following:

   1. Click New State.

   2. In the Status field, choose Normal.

   3. In the Display name field, enter the display name for the HI indicator state: AVAILABLE.

   4. In the Identifier field, enter the system name of the HI indicator state: AVAILABLE.

   5. Click Add states.

   Repeat these steps using the required values to add the indicator state with the value UNAVAILABLE and with critical severity.

6. Repeat this procedure for other HIs and ETIs you want to create for your CI types.

There are two ways to assign ETIs to an event. Which option you want to use highly depends on the possibility you have to modify the incoming OMi event. We recommend that set ETIs directly in the policy you are using for monitoring. However, it is also possible to assign an ETI to an event with Indicator Mapping Rules.

• Set the EtiHint within an OMi policy

  Overview of ETIs and HIs shows a list of the analyzed ETIs and HIs for the ACME monitoring system. The last column gives the information about which OMi policy creates the event. These OMi policies must be enriched with the appropriate EtiHint.

  The following graphic shows an example configuration of the EtiHint.

  

• Use Indicator Mapping Rules

  In the ACME example, all messages are sent using OM policies. Therefore, the CMAs are used to set the ETIs. However, it is also possible to use mapping rules to set ETIs for incoming OM messages.

  The following graphic shows an example of a filter configuration for db connection down related messages.

  

  The following graphic illustrates the configuration of the mapping rule itself for the Lost Database Connection ETI, using the filter configuration shown above.

  

  With this mapping rule, you match every incoming message where Category=ACME, Sub Category=Work Process and Title=db connection lost to the ETI Lost Database Connection for CI type ACME Work Process.

In cases where a high level of detail is not required, you may have CIs or CI subtypes that are not modeled in the RTSM. This lowers the work associated with discovering and maintaining those CIs, and simplifies your overall model. However, Service Health will not track individual statuses of unmodeled CIs. Instead, a generic ETI for the node is expressed. You can use the custom message attribute SubCiHint to track statuses of unmodeled CI types. When SubCiHint is set, status is tracked separately for each unmodeled CI individually, enabling Service Health to calculate the overall status as the most critical of all the subCis.

For example, you have CPUs with the RelatedCiHint: cpu:<$acme_cpu_id>:<$acme_nodename>@@<$acme_nodename>and SubCiHint: 0. If the CPUs are modeled in the RTSM, the RelatedCiHint will resolve to the CPU CI. Each CPU can have its own status and all this information can be aggregated on the node using calculation rules in Service Health.

If the CPUs are not modeled in the RTSM, the system will not take into account the distinct statuses of each CPU. In this case, if you get the notification CPU0:bad, followed by CPU1:bad and CPU0:good, Service Health calculates the overall status as "good", even though only one of the CPUs became "good" again. The status will flip between good and bad, only taking into account the most recent status update.

In this example, when SubCiHint is set, status is tracked for each CPU. When CPU0 converts to "good" but CPU1 remains "bad", the ETI on the node remains "bad".

For more information on setting the SubCiHint, see Map events to CIs.