Service Health Concepts

ETIs are defined per CI Type (CIT) in the Indicator Definitions screen. They are a concise and clear indication of the nature of an event, and provide a common value used to tie together events from different event sources. Data collectors provide ETI hints within incoming events, and OMi attempts to match the hint with an entry in the indicator definitions. If an ETI is defined as an HI, it is used for event processing and can be used to drive KPI status. ETIs also provide OMi with details needed to perform automated event processing, including topology-based event correlation (TBEC), stream-based event correlations (SBEC), duplicate suppression, and so on.

Different domain managers can use the same ETIs, enabling cross-domain event correlation and effective automation across silos. Management Packs and Content Packs loaded into OMi provide indicator definitions and other monitoring details that OMi will automatically recognize. You can also manually create ETIs in the Indicator Definitions screen.

Additionally, you can create ETI mapping rules to insert ETIs into incoming events or override ETI hints provided by domain managers within the events.

HIs are defined in the Indicator Definitions screen. An HI reflects the state of a CI based on a particular operating characteristic. Each HI is also an ETI, but not the other way around. Unlike an ETI, an HI must have a least two states: one that represents the good state, and one that represents the degraded state.

An HI has a state with descriptive information, like Overloaded or Much Higher Than Normal. Each state is mapped to a status: Normal, Warning, Minor, Major, Critical, Informational, or Unknown. Multiple states can map to one status. For example, the states Overloaded and Much Higher Than Normal can both be mapped to Major severity.

HI status is set by OMi based on events received from data collectors. OMi sets the status automatically based on ETI Hints received in events (and indicator mappings, if configured).

HIs provide the status information that a KPI uses to calculate the overall status of the CI to which the HIs are assigned.

KPIs are defined in KPI Definitions. A KPI represents the overall status of CIs based on one or more HIs, and the KPI state of any child CIs. KPIs use business rules to collate the values from multiple HIs and set a KPI status, such as: Critical, Major, Minor, or Normal. For example, a KPI for a database can include multiple HIs representing the run state (Up, Down), the cache-hit ratio (0%, 50%, 100%), the length of query queues (Empty, Full), and response times (#ms) to determine overall health (KPI value).

Some common out-of-the-box KPIs include:

• Performance KPIs. These KPIs are based on performance related HIs, like queue length, CPU load, response time, and so on.
• Availability KPIs. These KPIs are based on availability-related HIs, like ping availability, server state, process state, connection state, and so on.
• KPIs that reflect event status. For example, the unassigned events KPI sets its value based on events not yet assigned to a staff member to investigate. The unresolved events KPI sets its value based on events with underlying problems that have not yet been resolved.

The color of each KPI reflects the KPI's current severity. KPI status is determined by a business rule. One resource with a critical problem does not mean that all dependent resources are also critical. KPIs can use data from multiple sources to determine the overall effects up and down dependency chains and determine the severity status accordingly.

After an HI is calculated, OMi calculates the KPIs that are based on this HI, using the business rule definitions in Business Rules and specified in the KPI's definition. If this calculation causes a change in the status of a KPI, OMi recalculates the corresponding KPI of each parent CI, using the new status information. If the new measurement causes a change in the status for that KPI, the new status is again passed up the hierarchy to the corresponding KPI instances for the parent CIs, and so on.

There are many ways you can change the way a KPI is calculated:

1. Manually. In CI Customizations, you can edit the indicator you want to modify. You can change the following: Rule, Calculation Method, Related Health Indicators, Thresholds. For information, see CI Customizations.
2. Assignment. In KPI Assignments, you can select the CI Type and change the relevant assignment. In order for the change to take effect on existing CIs, click Apply all rules. For information, see KPI Assignments.
3. Propagation. In Propagation Rules, you can add or modify propagation rules to change the KPI’s rule, which should be different from the default business rule. Propagation changes are applied immediately the next time a propagation happens (like when a KPI is created on a CI). Propagation rules are not applied retrospectively. The only way to re-apply a propagation rule is to delete the KPI from the child and the parent, and then re-apply the KPI to the child which triggers propagation to the parent. For information, see Propagation Rules.
4. Definitions. Each indicator that was created is linked to its Indicator Definition and only deviations from that entity are saved for that indicator (for example: rule parameters and threshold setting). To change default values to all indicators (which are still linked to the entity) just edit the Definition entity. For information, see Indicator Definitions and KPI Definitions.

OMi provides a selection of predefined KPIs and HIs to work with Service Health. HI and KPI definitions come from content packs that send information to OMi. These content packs contain the default parameters for each HI and KPI.

HI and KPI definitions generally include the following:

• The business rule which calculates status and value of the HI and KPI. (Event-based HIs do not use business rules.)

• The calculation source ("Calculation Based On"). HIs are calculated based on incoming events; KPIs are calculated based on HIs, other KPIs, or both. For example, a KPI's status might be generated from HIs on child CIs (for example, when using the Summary of Values rule), or from other KPIs attached to the same CI (for example, when using the Impact Over Time rule).

• The thresholds (objective values) that the HI and KPI measurement is compared against; and the status (color) allocated to the HI and KPI based on the defined thresholds.

• Where and how to display the status indicator for the HI and KPI in Service Health, and where to store KPI measurements.

A KPI or HI can be attached to a CI in one of the following ways:

• Assignment. HIs and ETIs are automatically attached to a CI when a valid ETI is received in an event. A KPI assignment rule associates a KPI with HIs whose values are used to calculate the KPI state. The KPI assignment rule also identifies the CIT to which the KPI can be attached.

  For more information on KPI assignments and how they define the default indicators, see KPI Assignments.

• Propagation. KPIs may be attached to a CI as a result of propagation from child CIs. Most KPIs propagate up through the hierarchy, so that parent CIs have the same KPIs as all their child CIs.

  Each KPI added by propagation has its own business rule and properties. For example, the Availability KPI for a child CI may use the Worst Status Rule (taking the worst status of all the HIs on the CI), while the same KPI for the parent CI (added by propagation from the child CI) may use the Percentage Rule.

  For more information on the propagation mechanism and how it defines the default KPIs, see Propagation Rules.

• Manual Administration. KPIs can be manually attached to a CI in CI Customizations. You may want to attach new KPIs to a CI, in addition to the default/propagated KPIs, to broaden the information displayed on the CI. For example, you can add an OT Impact KPI to assess the ongoing cost of an application that is not available.

  For details, see CI Customizations.

When a KPI is assigned to a CI or a CI is attached to another CI, the propagation mechanism propagates the appropriate KPIs to the parent CIs. By default, when a KPI is assigned to a CI, the KPI is automatically propagated to the CI's parents. KPIs are propagated from child CIs to parent CIs; HIs are not propagated to parent CIs.

Since Service Health can be adjusted a various levels, order of precedence is significant. Changes made manually in CI Indicators override all others. Assignment takes precedence over propagation rules. For example, if you have a propagation rule that propagates the Application Availability KPI with a Percentage Rule from the node CI type to the business application CI type, and you also have a KPI assignment on the business application CI type that specifies the Worst Status Rule, then it overrides the assignment from the propagation rule.

Incoming events in OMi provide Service Health with updated health status information about CIs in your environment. Smart mapping technology is employed to map events to CIs. The system looks for hints in certain event attributes, compares these hints with CI attributes, and then maps an event to the best matching CI. If you are using predefined content packs in OMi, these hints will be automatically set and recognized. After an event has been mapped to a CI, it can be mapped to an event type indicator (ETI) based on indicator definitions or indicator mapping rules. If an ETI is also an HI, the Service Health logic component translates the ETI to an HI, automatically creates a new HI if it is not yet in the system, and maps the HI state to its status. The ETI is also used for further event correlation, like stream-based and topology-based event correlation. Then, the KPI engine calculates the KPI status for its CI based on the changes in the associated HIs, according to a business rule. This KPI status is propagated based on triplet rules defined in the impact model and exceptions defined in propagation rules. Finally the health information is displayed with colors and status information in your consolidated operation workspace.

You can use Content Packs to export and import your changes to Service Health across OMi environments. You can put the following Service Health artifacts into a Content Pack:

• Business Rules
• HIs
• KPIs
• Context Menus
• KPI Assignments
• Propagation Rules

For more information, see Management Templates and Aspects.