Event Viewer: Event relationships display only if the parent and child events match the filter

Event Viewer is only able to show relationships between events if the parent and the child events are all events that match the filter.

Problem

Event Viewer is only able to show relationships between events if the parent and the child events are all events that match the filter. There are some use cases for related events where parent or child events might not match the filter.

Cause

Netcool®/OMNIbus Web GUI is able to show the relationships between events in the Event Viewer, if the Event Viewer view in use has an associated Web GUI relationship. This relationship defines which field in an event contains the identifier of the event's parent, and which field contains the identifier for the current event. For more information about defining event relationships, see https://www.ibm.com/docs/en/SSSHTQ_8.1.0/webtop/wip/task/web_cust_jsel_evtrelationshipmanage.htmlexternal link.

The relationship function works from the set of events that are included in the event list, and the event list displays the events that match the relevant Web GUI filter. See the following example. If you have a filter that is called Critical to show all critical events, the filter clause is Severity = 5, then relationships between these events are shown provided the parent and child events in the relationships all have Severity = 5. If you have a parent event that matches the filter Severity = 5 but has relationships to child events that have a major severity Severity = 4, these child relations are not seen in the event list because the child events do not match the filter. Furthermore, these child relations are not included in the set of events that are returned to the Event Viewer by the server

Resolution

To resolve this problem, you must define your filter with appropriate filter conditions that ensures that related events are included in the data that is returned to the Event Viewer by the server. The following example builds on the example that is used in the previous section.
  1. Make a copy of the Critical filter and name the copy CriticalAndRelated. You now have two filters. Use the original filter when you want to see only critical events. You use the new filter to see related events, even if events are not critical.
  2. Manually modify the filter condition of the CriticalAndRelated filter to include the related events. To manually modify this filter condition, use the advanced mode of the Web GUI filter builder. The following example conditions are based on the current example.
    • The main filter condition is Severity = 5.
    • In an event, the field that denotes the identifier of the parent event is called ParentIdentifier.
    • The value of the ParentIdentifier field, where populated, is the Identifier of an event.
    • If ParentIdentifier is 0, this value is a default value and does not reference another event.
    • Including related child events. To include events that are the immediate child events of events that match the main filter, set this filter condition.
      Severity = 5
      OR
      ParentIdentifier IN (SELECT Identifier FROM alerts.status WHERE Severity = 5)
    • Including related parent events. To include events that are the immediate parent of events that match the main filter, set this filter condition.
      Severity = 5
      OR
      Identifier IN (SELECT ParentIdentifier from alerts.status WHERE Severity = 5)
    • Including related sibling events. To include events that are the other child events of the immediate parents of the event that matches the main filter (the siblings of the events that match the main filter), set this filter condition.
      Severity = 5
      OR
      ParentIdentifier IN (SELECT ParentIdentifier from alerts.status WHERE 
      Severity = 5 AND ParentIdentifier != '')  
    • Including related parents, children, and siblings together. Combine the previous types of filter conditions so that the new CriticalAndRelated filter retrieves critical events, and the immediate children of the critical events, and the immediate parents of the critical events, and the immediate children of those parent events (the siblings). You must have this filter condition.
      Severity = 5
      OR
      ParentIdentifier IN (SELECT Identifier FROM alerts.status WHERE Severity = 5)
      OR
      Identifier IN (SELECT ParentIdentifier from alerts.status WHERE Severity = 5)
      OR
      ParentIdentifier IN (SELECT ParentIdentifier from alerts.status WHERE 
      Severity = 5 AND ParentIdentifier != '')
    • Including related events that are more than one generation away. In the previous examples, the new filter conditions go up to only one level, up or down, from the initial set of critical events. However, you can add more filter conditions to retrieve events that are more than one generation away from the events that match the main filter. If you want to retrieve grandchildren of the critical events (that is, two levels down from the events that match the main filter condition) and immediate children, set this filter condition.
      -- The initial set of Critical events
      Severity = 5
      OR
      -- Children of the Critical events
      ParentIdentifier IN (SELECT Identifier FROM alerts.status WHERE Severity = 5)                             
      -- Children of the previous "child events"
      OR
      ParentIdentifier IN (SELECT Identifier FROM alerts.status WHERE
          ParentIdentifier IN (SELECT Identifier FROM alerts.status WHERE Severity = 5) )  
      Use a similar principal to retrieve parent events that are two levels up, and siblings of the parent events. To pull this scenario together, set this filter condition.
      -- The initial set of Critical events
      Severity = 5
      
      OR
      
      -- Children of the Critical events
      ParentIdentifier IN (SELECT Identifier FROM alerts.status WHERE 
      Severity = 5)                             
      
      OR
      
      -- Children of the previous "child events"
      ParentIdentifier IN (SELECT Identifier FROM alerts.status WHERE
          ParentIdentifier IN (SELECT Identifier FROM alerts.status WHERE 
      Severity = 5) )
      
      OR
      
      -- Parents of the Critical events
      Identifier IN (SELECT ParentIdentifier from alerts.status WHERE Severity = 5)
      
      OR
      
      -- Parents of the previous "parent events"
      Identifier IN (SELECT ParentIdentifier from alerts.status WHERE
          Identifier IN (SELECT ParentIdentifier from alerts.status WHERE Severity = 5) )
      OR
      
      -- Other children of the Critical events' parents
      ParentIdentifier IN (SELECT ParentIdentifier from alerts.status WHERE 
      Severity = 5 AND ParentIdentifier != '')
      
      OR
      
      -- Other children of the Critical events' grandparents
      ParentIdentifier IN (SELECT ParentIdentifier from alerts.status WHERE
          Identifier IN (SELECT ParentIdentifier from alerts.status WHERE 
      Severity = 5 AND ParentIdentifier != '') AND ParentIdentifier != '')
      You can continue this principal to go beyond two levels in the hierarchy. However, with each additional clause the performance of the query degrades due to the embedded subquerying. Therefore, there might be a practical limit to how far away the related events can be.