Create a simple demo of scope-based event grouping

Body

This blog will show you how to set up a simple demo of scope-based event grouping using the Simnet Probe.  You will need:

• OMNIbus 8.1 installed with the latest fix pack (FP8 due out soon)
• OMNIbus Web GUI 8.1 installed with the latest fix pack
• Netcool/Probe for Simnet installed

1) Set up an Aggregation ObjectServer and import the scope-based event grouping code via nco_sql:

$OMNIHOME/bin/nco_sql -server AGG_P -user root -password netcool < $OMNIHOME/extensions/eventgrouping/objectserver/scope_event_grouping_aggregation.sql

2) Next add the following to the end of your Simnet Probe rules, start it up, and point it at your ObjectServer:

if (regmatch(@Summary, "^Link*"))
{
    @NormalisedAlarmName = "Link Up/Down"
    @ImpactWeight = 500
    @CauseWeight = 100
}
else if (regmatch(@Summary, "^Machine*"))
{
    @NormalisedAlarmName = "Machine Up/Down"
    @ImpactWeight = 400
    @CauseWeight = 500
}
else if (regmatch(@Summary, "^Diskspace*"))
{
    @NormalisedAlarmName = "Disk space issue"
    @ImpactWeight = 100
    @CauseWeight = 600
}
else if (regmatch(@Summary, "^Port*"))
{
    @NormalisedAlarmName = "Port Error"
    @ImpactWeight = 300
    @CauseWeight = 600
}

if (match(@Node, "Washington"))
{
    @ScopeID = "US"
}
else if (match(@Node, "London") or match(@Node, "Moscow") or match(@Node, "Rome") or match(@Node, "Berlin"))
{
    @ScopeID = "EMEA"
}
else if (match(@Node, "Beijing"))
{
    @ScopeID = "CHINA"
}
else if (match(@Node, "Sydney"))
{
    @ScopeID = "AUSTRALIA"
}
else if (match(@Node, "Tokyo"))
{
    @ScopeID = "JAPAN"
    @CauseWeight = "700"
}

else if (match(@Node, "link1") or match(@Node, "link2") or match(@Node, "link3"))
{
    @ScopeID = "EMEA"
    @SiteName = "London"

    if (match(@Node, "link1")) {

        @CauseWeight = "200"
    }
    else if (match(@Node, "link2")) {

        @ImpactWeight = "600"
    }
}
else if(match(@Node, "link4") or match(@Node, "link5") or match(@Node, "link6"))
{
        @ScopeID = "US"
    @SiteName = "New York"
}

@CustomText = @Node

It sets the ScopeID field for you (the key field necessary to activate the grouping function) plus one or two other things such as SiteName to create sub-groups.

3) Next set up a view that includes "IBM Related Events" on the Relationships tab.  If you don't have this relationship present, simply create one that links the ParentIdentifier field to the Identifier field.

4) Open your Event Viewer and you should see something like the following:

Features:

• It auto-propagates TTNumber to unticketed child events (if property is set).
• It auto-propagates Acknowledged status to child events (if property is set).
• It auto-propagates OwnerUID and OwnerGID to child events (if property is set).
• The synthetic parent event inherits the highest Severity of the child events - as well as the first FirstOccurrence and the last LastOccurrence.
• The Summary field of the synthetic parents can be customised to suit.
• It rolls up child events into journal entries in the parent events (if relevant properties are set).  This is so that you can cut a ticket off the parent and include all the underlying child events in the ticket diary.  The goal is one incident = one ticket.  It looks something like this:

The properties that drive the behaviour of scope-based event grouping are documented here.

You don't have to modify any trigger or procedure code in order to configure its behaviour - just modify the properties in the master.properties table - handy!
 

NOTES:

• Note that there are two types of event grouping in NOI: scope-based where we define the scope (ScopeID) and analytics-based where the analytics finds the groupings in the historic event archive.  By applying these two methods, we are grouping together events based on known relationships and unknown relationships respectively.
• Telcos are using the scope-based grouping on telco devices in a couple of different ways so far.  One telco customer sets ScopeID to be the BSC controller ID.  Another telco customer has the site ID encoded into all their events already - so they just use that (ie. geographical).  Scope-based event grouping's premise is that "if you get some events from the same place at the same time, they're probably related to the same problem" - hence physical proximity is a good way to select ScopeID.
• Enterprise customers tend to be setting up the ScopeID themselves.  One large North American bank has the line-of-business ID encoded into their event streams - and are using that as their ScopeID.  Another European bank is using the data centre location as their ScopeID.
• Some customers however don't know what their scope should be - so they are using the analytics to find the groups for them.  And some are using a mixture of both - to find and group as much as possible based on both known and unknown relationships.
• By logically grouping events together, it makes it much easier for operators to manage, makes it much easier to triage a problem, means you can cut one ticket per problem, reduces MTTR, and ultimately saves the business a lot of money - both in terms of reduction in the number of duplicate tickets opened - and the time it takes to resolve the problem.

See Also:

• About scope-based event grouping
• How can I use scope-based event grouping in Watson AIOps?