Resolved from fix pack
3

About scope-based event grouping

The scope is set in the probe rules file or through enrichment. Scope identifies where the events are originating from based on a common attribute, for example, the location of a server room.

When events occur at the same time and have the same scope, a grouping or containment is automatically created based on the scope set in the ScopeID value. Any subsequent events that have the same ScopeID are placed into the same group. The grouping action continues until no further events for the scope are received for more than a threshold number of seconds (the default is 900 seconds, 15 minutes) after which the grouping is deemed complete. Any subsequent events that are received for the same scope, after the grouping completes, is treated as a separate incident and a new grouping is created.

Resolved from fix pack
4The threshold number of seconds can be defined for each event in the probe rules file or through enrichment by using the QuietPeriod value. If QuietPeriod isn’t set in the events, the event grouping uses the default 900 seconds as the length of time to wait for subsequent events to arrive from the scope, as defined by the global default QuietPeriod stored in the master.properties table. When an event arrives, the scope-based event grouping automation checks the QuietPeriod time set for the event against the current expiry time for the grouping, and uses the time that is longer to define the expiry of the grouping. This approach means that as events arrive with a QuietPeriod time set, the QuietPeriod values are compared against the latest expiry time for the grouping every time, ensuring the biggest catchment of events for that scope.

Functionality delivered in fix pack
17With Fix Pack 17, the scope-based grouping automation’s rollup multiple child events into single journal entries in the parent event. Before Fix Pack 17, the automation’s only inserted one journal entry per each 17-second cycle. From Fix Pack 17, the automation’s immediately insert all children that are currently present, therefore the automation’s can insert many multiple journal entries into the parent event in the same 1-second window. To enable the Fix Pack 17 automation’s, the UID of the user inserting the journal entries is changed to a pseudo user and has an arbitrarily selected UID value of 1000000 or greater, which doesn’t correspond to a real user UID. Therefore, the Fix Pack 17 automation’s function obsoletes the property SEGJournalUID.

Functionality delivered in fix pack
17With Fix Pack 17, new functionality is included with scope-based grouping:
  • You can specify a QuietPeriod within the policy UI for each policy.
  • You can select a check-box to specify that the time window is fixed, instead of the default dynamic value.
  • Improvements were made around creation and availability over multiple datasources, and where those datasources had Display ObjectServers present.
Scope-based event grouping remembers the highest priority child event in the group for the purposes of propagating priority child event information. See the following priorities.
  • first FirstOccurrence
  • last LastOccurrence
  • highest CauseWeight
  • highest ImpactWeight
The following examples outline behavior for a few priorities.
  • Select highest CauseWeight as the highest priority SEGPropagateTextToScopeIDParentCause: 1. The details from the child event with the highest CauseWeight ever seen in the group, are retained and used for populating the CustomText for the synthetic event, even if that child event clears later. This information updates only if a child event arises with a higher CauseWeight.
  • Select first FirstOccurrence as the highest priority SEGPropagateTextToScopeIDParentFirst: 1. The details from the child event with the first FirstOccurrence ever seen in the group are retained and used for populating the CustomText for the synthetic event, even if that child event clears later. This information updates only if a child event arises with an earlier FirstOccurrence.This behavior means that the priority child event is the first child event to enter the group, which is popular function.

An example scenario for event grouping is where a server room has a scope set, for example, ScopeID = 'SITE12'. If the air conditioning fails in the server room, there are environmental alarms from SITE12 showing that the air conditioning failed, and shortly afterward, other alarms, ranging from high room temperature warning events to potentially severe system failure events. Based on the scope and the time period, you can conclude that all of those events are related as they all originated in the same place within the same time window.

To use scope-based event grouping:

  1. Enable scope-based event grouping by installing the event grouping extension as described in Installing scope-based event grouping. After you install the extension, if ScopeID is set, Tivoli Netcool/OMNIbus automatically creates the groupings.
  2. Further refine your event grouping as described in Setting up containment structure.
  3. Understand results made possible and the framework that is provided by event grouping for identifying probable sources and immediate consequences of an incident, as described in Results and weighting.
  4. Resolved from fix pack
15In addition to dynamic time window support, scope-based event grouping now supports fixed time window function for a static value. To enable the fixed time window function, you must prefix the ScopeID entry with FX:. For example,
    • This setting applies a fixed time window of 300 seconds to ScopeID: FX:AUCKLAND. The grouping closes 300 seconds after the grouping is formed.
      ScopeID: FX:AUCKLAND QuietPeriod: 300
    • This setting applies a dynamic time window of 300 seconds to ScopeID: AUCKLAND. The grouping closes as soon as the grouping reaches 300 seconds, since the FirstOccurrence of the most recent event.
      ScopeID: AUCKLAND QuietPeriod: 300
Clearance of a synthetic parent event that is generated by the scope-based event grouping occurs when the following two criteria are met.
  • The parent event no longer has any child events.
  • The expire time for the group QuietPeriod passes without further occurrence of events.
If a scope-based synthetic parent event has no children but the expire time for the group is not yet reached, the parent event defaults to a Severity of 1. The parent clears only after the expire time passes. If another event occurs in the meantime, then the expire time for the group might extend further, which further extends the time before the parent clears. However, a synthetic parent event that is generated by the analytics-based event grouping clears immediately after this parent no longer has any children.

The Tivoli Netcool/OMNIbus journal function is available at the parent level of events within scope-based event grouping. The scope-based event grouping journal function is also usable by the parent records within Event Analytics.

Important: Scope-based event grouping works based on the known relationships. For relationships you do not know about, you can use analytics-based event grouping and seasonal event analysis provided by Netcool Operations Insight. Together with scope-based event grouping, you can form an even more accurate picture of the root causes of a problem, and improve efficiency in pinpointing problems in your network or systems.
Resolved from fix pack
17If you have entitlement to Tivoli Netcool/OMNIbus as part of Netcool Operations Insight you can apply Netcool Operations Insight Related Event grouping to scope based grouping groups to create super groups. The scope based grouping automation’s now support the automatic propagation of the child event details to the super parent journal, so that the super parent will have all the underlying child event details, when ticketed. To enable this function, the following two new properties are added to the master.properties table.
  • SEGJournalToSuperParent Enables journaling to the super parent event, when IntValue is set to 1.
  • SEGMaxSuperParentJournals Defines the maximum number of child events to be journaled to the super parent journal. The default value of IntValue is 100.
For more information about event analytics, see https://www.ibm.com/support/knowledgecenter/SSTPTP_1.6.0/com.ibm.netcool_ops.doc/soc/event_analytics/concept/soc_eventanalytics.html.