Correlation guardrails

By using guardrails, the operation centers can ensure that the output of correlation algorithms is reflected in the live Alert Viewer and the ticket assignment workflows are not conflicting with the algorithms.

Understanding policies

Algorithms such as temporal grouping and scope-based event grouping are useful for discovering groups of events that can be correlated together due to commonalities or time-based relationships between events. But the output of such methods can conflict with the operation center's operational logic and rules. A common example is that multiple internal teams represent various lines of business or technology areas with the operations center and ticket assignment, and generation workflows. By using the correlation guardrails capability, administrators can ensure that the resulting groups for scope and temporal grouping are not conflicting with custom business and operational level constraints.

The policy system provides v3 policies that are processed by the Post Insert processor. The v3 policies act on any user specified input entity. The v3 policies implement the action to enrich the event in the processing pipeline. Specifically, for guardrails, the results are populated to a topic that is used by downstream processors.

Guardrails-highlevel

Configuring policies

Policies that describe a set of actions such as com.ibm.hdm.noi.actions.impl.EnrichPrependCorrelationKey are run whenever an entity triggers. Multiple policies might exist for any entity trigger that is given. The actions across all policies are run in an order that is determined by the priority of each policy. Policies are stored and managed by the policy registry.

com.ibm.hdm.noi.actions.impl.EnrichPrependCorrelationKey can be used at the beginning of a correlation key for any subsequent v1 policy grouping that takes place on an event; for example, scope based event grouping or temporal grouping.
Note: Only the highest priority (lowest value) instance of this action per an entity is applied and is opposed to create supergroups for multiple rules.

The arguments that must be provided are shown in the following example:

The actionId must be set to com.ibm.hdm.noi.actions.impl.EnrichPrependCorrelationKey.

The arguments template for this action includes a value block, where the value must be set by the $template. The $template must contain a handlebars string that is a value in the format {{ a.field.name }} to be parsed by the processor at run time. If the value at the beginning of the correlation key is missing, then the next priority policy will be attempted. If no other policies attempt to implement the action to enrich the event in the processing pipeline, its output provides a degraded level of service. To implement the guardrails, the event configuration must remain as is.
{
  "actionId": "com.ibm.hdm.noi.actions.impl.EnrichPrependCorrelationKey",
  "arguments": {
    "value": {
      "$template": "{{event.resource.location}}"
    },
    "event": {
      "$variable": "event"
    }
  }
}
This action results in the adding of the payload to the input entity as the action output.
"aggregationProperties": {
  "ea-correlation-key-prepend-value": "$POLICY_DEFINED_VALUE"
}

The v1 policy inference service transparently passes this value downstream to the ea-aggregation-deduplication service to apply the action during its first-level grouping algorithm, as shown in the following sequence diagram.

Guardrails-Sequence-diagram
The following example shows that satisfies the condition, that the location is non-null, and uses the condition to partition the resulting groups:
{
    "metadata": {
      "labels": {
        "ibm.com/is-default": "false"
      },
      "name": "Basic Guardrails policy",
      "description": "Prepends the correlation key with a user set value to constrict correlation globally",
      "createdBy": {
        "id": "system",
        "type": "system"
      }
    },
    "state": "enabled",
    "executionPriority": 50,
    "spec": {
      "trigger": {
        "entityId": "event",
        "triggerId": "aiops.ibm.com/trigger/event-post-insert"
      },
      "actions": [
        {
          "actionId": "aiops.ibm.com/action/internal/conditional",
          "arguments": {
            "condition": "not {{ isEmpty event.resource.location }}",
            "then": [
              {
                "actionId": "com.ibm.hdm.noi.actions.impl.EnrichPrependCorrelationKey",
                "arguments": {
                  "value": {
                    "$template": "{{event.resource.location}}"
                  },
                  "event": {
                    "$variable": "event"
                  }
                }
              }
            ]
          }
        }
      ]
    }
  }

Enable policy registry service swagger

To enable the policy registry service swagger, see Enabling policy registry service swagger.

Configure policy registry service swagger

Note: By default, configuring policy registry service swagger is disabled.
To enable the configuration, edit the Netcool® Operations Insight® or noihybrid CR and add the following command to helmValuesNOI:
ibm-hdm-analytics-dev.postinsertprocessor.enabled: true
Attention: Guardrails work only with temporal grouping and scope policies. It does not operate on topology-based grouping or temporal patterns since resource values can be configured or modified by the users.
To ensure that the update was successful, run the following command:
$ oc get deploy | grep v3
evtmanager-ibm-hdm-analytics-dev-v3-evt-pi-processor
Important: The output of a deployment must contain the term v3-evt-pi-processor.