In my earlier blog, titled “From OMi Events to CI Status”, I promised to write about these special KPIs which behave somewhat differently than other KPIs. So here I’m, with another post – though a bit late, trying to explain these KPIs and its purpose.
As explained in the blog, typically events are mapped to HIs, HIs to KPIs and KPIs on a CI, provide the CI status. The KPIs in this process are typically called health based KPIs (as they are based on Health Indicators).
HI State is a persistent state and is not dependent on the lifecycle state of the underlying event. This means that if an operator closes an event that had mapped to a critical HI state, the HI will not change its state.
In order to change the HI state (and hence corresponding KPI and CI status), either there has to be another event that maps to the desired HI state OR an operator selects the action “close and reset Health Indicator” on the event OR reset the HI by using the service health REST API.
In many event management products like HP OM, the service tree elements were colored purely based on the severity of the corresponding events. If a critical event is closed, then the color of the service element will get reset. Many customers like to continue with this approach in OMi and for that purpose, these special KPIs can be used.
Unassigned Events and Unresolved Events KPIs:
Unassigned Events KPI is calculated based on the severity and count of open unassigned events related to a CI (i.e. events with state “Open”). The KPI status is the highest severity of all events and value is the count of events with highest severity. For example, if there are 5 “open” events for a CI, out of which 1 is critical severity and 4 are major severity events, then KPI status will be critical and value will be 1. If critical severity event is assigned and state changes to “in progress”, then KPI status will change to Major and value will be 4.
Unresolved Events KPI is calculated based on the severity and count of unresolved events related to a CI (i.e. events with state “Open” or “In Progress”). The KPI status is the highest severity of all events and value is the count of events with highest severity. For example, if there are 5 “open” or “in progress” events for a CI, out of which 1 is critical severity and 4 are major severity events, then KPI status will be critical and value will be 1. If critical severity event is closed, then KPI status will change to Major and value will be 4. Note that in this case, if critical event is just assigned, then KPI status will continue to be critical with a value of 1.
Internally, these KPIs also make use of HIs but these HIs are hidden and created automatically
KPI status calculation as described above is the default behavior and it can be changed by changing the infra settings as shown below.
By default, every CI type has these two special KPIs assigned
These KPIs are not propagated from child CIs to parent CIs unlike health based KPIs; However, this behavior can be changed by changing the KPI propagation rules that are used to stop the propagation.
What is the use of these KPIs?
For CI status visualization: if you want to see the colored status of a CI in OMi service health dashboards, then KPIs are needed and these event based KPIs provide a quick way of achieving this by just using the severity and lifecycle state attributes of events
CI status change based on event lifecycle state: In some monitoring setups, events are sent for exception or error conditions but for normal condition, no event is sent which makes it difficult to use the health based KPIs. For such setups, it is preferred that when the critical event for a CI is closed, KPI and CI color changes accordingly.
Sometimes, especially for events from 3rd party domain managers, it may not be known in advance what kind of events will come to OMi and hence mapping them to health based HIs and KPIs might be difficult. In such cases, these KPIs can be used for CI status calculation.
Useful for a “Dispatcher” kind of operator role in the operations center wherein these KPIs give a quick view of events that are not yet assigned to anyone and events that are not yet resolved.
Custom Event based KPIs using “Subcategory” attribute:
Though easy to use, unlike health based KPIs which provide very granular level health of a specific aspect of a CI, the default events based KPIs, do not provide any specific health information about the CI. It only indicates no of open events and their severity for a CI but tells nothing else. To make these KPIs more useful, OMi allows to create more event based KPIs based on the event “Subcategory” attribute.
You can count active events (unresolved and unassigned) for a specified event subcategory and display the result with associated KPIs. This means you can have KPIs like “Unassigned Events – Security”, “Unresolved Events – Security” for security category, “Unassigned Events – Network”, “Unresolved Events – Network” for network category etc. Such KPIs provide a little more information than the default Event KPIs.
You can configure subcategories for which the event count based HIs should be calculated in the Health Indicators for Unresolved and Unassigned Events Infrastructure Settings. Corresponding HIs are automatically created as soon as a new subcategory is added in the Settings Manager.
Steps to Create Custom Event based KPIs:
Define a new event subcategory
For every subcategory added above, there will be two HIs created automatically and these can be seen in the Admin -> Service Health -> Health and Event Type Indicators UI
Define new KPIs corresponding to each of the newly created HIs and assign them to be calculated based on HIs only
Define propagation rules so that these KPIs are not propagated from child to parent CI (just like the default event KPIs behave)
New KPIs will be calculated based on count and severity of active events that match the subcategory defined above
As an example, see the two new KPIs – based on “Security” subcategory, highlighted in the below screen shot of Service Health 360 View:
For more details of the above steps to create custom events based KPIs, please refer to the OMi Admin Guide :