AIOps

Many deployments of Cloud Pak for AIOps (AIOps) are done where an existing Netcool environment already exists. Part of the migration over to AIOps is the deactivation of event correlation in the Netcool layer, and reimplementation in AIOps. This is necessary because the way AIOps creates groupings is very different between Netcool and AIOps and the representation and linkages are not compatible:

• Netcool uses either real or synthetic parent events whose children are linked via a key linkage field - often @ParentIdentifier
• AIOps stores grouping information as metadata within each correlated event - parent events are only virtual and are rendered in the Alerts viewer

The major advantage of AIOps over Netcool is that events can be a member of any number of groups, either of the same or different kinds of groups. Whereas Netcool requires a linkage between a parent event and a child event via a static field, AIOps stores this meta-data within the alert payload. There is no programmatic limit on how much meta-data can be stored in an AIOps alert, so it results in a much more flexible grouping model in AIOps.

There are three main grouping capabilities provided in both Netcool Operations Insight (NOI) and AIOps. The following outlines how these can be migrated from the Netcool layer to the AIOps layer:

• Temporal
  Temporal groupings found in either the Netcool/Impact based event analytics or the newer Cloud Native Event Analytics (CNEA) engine are not transferable to AIOps. AIOps will need to ingest event data from Netcool (and other sources) and re-train on the data internally. Any temporal grouping in NOI should be deactivated prior to enabling temporal grouping in AIOps.
• Topology-based
  NOI includes the same topology capability as AIOps and also supports topology-based event correlation. It works the same in both and needs to be set up in AIOps to match the configuration in NOI. Any topology-based grouping in NOI should be deactivated prior to enabling topology-based grouping in AIOps.
• Scope-based
  NOI includes a similar scope-based grouping capability as AIOps. By default, the Netcool Connector maps @ScopeID in NOI to resource.scopeId in AIOps. The default AIOps policy called Default Netcool scope-based grouping - with a rolling window of 15 minutes will automatically detect any inbound events with the resource.scopeId attribute set and will do scope-based grouping on it. As the name suggests, this is done with a rolling 15 minute window. This provides a convenient like-for-like function and makes migration from Netcool to AIOps relatively easy in this respect. You can of course disable this default policy and create your own, if you have more specific or complex requirements - for example, you have a variety of time windows required for different correlation scenarios.

NOTE: Netcool/OMNIbus in the absence of Netcool Operations Insight only has scope-based event correlation, if enabled:

https://www.ibm.com/docs/en/netcoolomnibus/8.1?topic=netcoolomnibus-enabling-scope-based-event-grouping

Custom correlations in Netcool

Many implementations of Netcool include custom correlations where one or more child events are linked to a parent event. Even though the grouping engine itself is eventually deactivated at the Netcool layer, in a combined Netcool/AIOps deployment, the correlation logic can remain in-place, and the grouping instead done at the AIOps layer. This section outlines a method of achieving this.

These are the basic steps:

• Create a field in the Netcool/OMNIbus ObjectServer for each custom correlation
• Modify the correlation logic for each Netcool automation so that any set of correlated events end up with the same unique value in the designated custom correlation field
• Map the custom correlation field to AIOps via the Netcool Connector mapping
• Create an AIOps scope-based grouping policy against the custom correlation field with appropriate time window settings
• The set of events will be correlated together in AIOps

The following is an example of how this might be implemented:

CREATE CUSTOM CORRELATION FIELD

The first step is to create a custom field to hold the key data value that will tie each event set together. Use the nco_sql utility to create the field:

1> ALTER TABLE alerts.status ADD COLUMN CustomCorrelation1 VARCHAR(64);
2> go

MODIFY CORRELATION LOGIC

The next step is to modify the automation that is correlating the events together, whether it be a Netcool/OMNIbus ObjectServer trigger or Netcool/Impact policy. The logic of the automation will be the same as before, the only change will be how to tie the events together. In the new correlation design, the automation will need to compute a key data value that will be set in the newly created custom correlation field - in this case @CustomCorrelation1. The value needs to be set to the same value across all members of the correlation set, and be sufficiently unique so that the wrong things don't inadvertently get correlated together.

MAP CUSTOM CORRELATION FIELD

The next step is to map the custom correlation field to AIOps. This is done in AIOps by editing the mapping of your Netcool Connector instance and adding in a details attribute. The following extract from a Netcool Connector mapping shows the insertion of the details section into the mapping, immediately under the expirySeconds attribute:

    ...
    "eventCount": alert.@Tally,
    "signature": alert.@Identifier,
    "firstOccurrenceTime": alert.@FirstOccurrence,
    "lastOccurrenceTime": alert.@LastOccurrence,
    "severity": alert.@Severity < 0 ? 1 : alert.@Severity = 0 ? 2 : alert.@Severity < 6 ? alert.@Severity + 1 : alert.@Severity >= 6 ? 6,
    "state": alert.@Severity = 0 ? "clear" : "open",
    "acknowledged": alert.@Acknowledged = 1 ? true : false,
    "expirySeconds": alert.@ExpireTime = 0 ? undefined : alert.@ExpireTime,
    "details": {
        "customCorrelation1": alert.@CustomCorrelation1 = "" ? undefined : alert.@CustomCorrelation1
    },
    ...

Click Save to save your new mapping. Note that this results in the Netcool Connector pod restarting. The new mapping will only take effect on events newly inserted into the Netcool/OMNIbus ObjectServer. Note that you can add as many custom correlation fields (comma separated) to this details section, per your requirements.

CREATE AIOPS CORRELATION POLICY

The final step is to create a scope-based grouping automation policy in AIOps to group the incoming event stream by your newly created attribute.

• Give your policy a meaningful name
• Set the priority
• Select "Before an alert is created"
• Add a condition that the policy fires when your custom attribute is "not empty"
• Under "Create a scope-based grouping", enter your custom attribute
• Specify the desired time window
• Specify if the time window is rolling or fixed

Here is an example AIOps automation policy snapshot showing an example condition set:

You should now start to see your custom correlation working in AIOps. Remember, this policy will only work for new events, not existing events.

One of the major advantages in AIOps over Netcool is that you can set up as many of these scope-based grouping automations as needed. You can therefore use this process to migrate all your custom Netcool correlation automations over to AIOps.