AIOps

Based on defined conditions, you can partition the events in temporal relations into separate event groups based on factors such as technology, location, or user ownership. The supergroups that are created from these partitioned groups allow you to do things such as generating distinct tickets for different technologies, or to assign to different user groups.

Step 1: Enable Guardrails & Policy registry service swagger:

You can edit the NOI CR YAML file in one of the following two ways.

• Edit from the command line with the oc edit noi or oc edit noihybrid command, depending on whether your deployment is full cloud or hybrid.
• Edit the deployment from Red Hat® OpenShift® with the Operator Lifecycle Manager (OLM) console: Operators > Installed Operators > IBM Cloud Pak for AIOps Event Manager. Click the NOI or NOIHybrid tab and select your deployment. Then, click the YAML tab to edit and save the YAML file. Your changes are auto-deployed.

[root@api.noiocp.cp.fyre.ibm.com ~]# oc edit noi 

spec:

helmValuesNOI:

  ibm-hdm-analytics-dev.policyregistryservice.swagger.enabled: true

  ibm-hdm-analytics-dev.postinsertprocessor.enabled: true

Delete the noi-operator pod to have it recreated

[root@api.noiocp.cp.fyre.ibm.com ~]# oc get pod | grep noi-operator
noi-operator-dc7865f69-qlvgd                                      1/1     Running     0               44d

[root@api.noiocp.cp.fyre.ibm.com ~]# oc delete pod noi-operator-dc7865f69-qlvgd
pod "noi-operator-dc7865f69-qlvgd" deleted

[root@api.noiocp.cp.fyre.ibm.com ~]# oc get deploy | grep policyregistry
aiops-ibm-hdm-analytics-dev-policyregistryservice           2/2     2                  2           44d

Verify the SWAGGER UI is enabled  by running the following command for policyregistryservice deployment

[root@api.noiocp.cp.fyre.ibm.com ~]# oc edit deploy aiops-ibm-hdm-analytics-dev-policyregistryservice

        - name: ENABLE_SWAGGER_UI
          value: "1"

Find the URL for access Policy Swagger UI 

[root@api.noiocp.cp.fyre.ibm.com ~]# FULL_ROUTE=$(oc get route | grep policyregistry.ibm-netcool-prod.aiops.io) && echo $FULL_ROUTE | awk '{ print "https://"$2$3"/docs/v1alpha/system/#/"}'

https://netcool-aiops.apps.noiocp.cp.fyre.ibm.com/policyregistry.ibm-netcool-prod.aiops.io/docs/v1alpha/system/#/

Use this URL to create/update/delete guardrail policies.

Authorization for the API can be obtained from the NOI systemauth-secret in the namespace where you deployed NOI.

[root@api.noiocp.cp.fyre.ibm.com ~]# oc -n evtmanager get secret aiops-systemauth-secret -o jsonpath='{.data.username}' | base64 -d && echo

system
[root@api.noiocp.cp.fyre.ibm.com ~]# oc -n evtmanager get secret aiops-systemauth-secret -o jsonpath='{.data.password}' | base64 -d && echo
Z1234324343456XY

Step 2 : Identify which field you want to use for setting up guardrails 

In this example, we will use 'SupportZone' custom column that is added to ObjectServer.

2.1 Update gateway configmap

The necessary step to using any custom Object server field in the condition is ensuring that the ea events gateway has been configured to propagate the field to the events payload. Any custom fields will be added to the details block of the event payload. 

Edit ea-noi-layer-eanoigateway configmap to add custom column 'SupportZone'

[root@api.noiocp.cp.fyre.ibm.com ~]# oc edit cm aiops-ea-noi-layer-eanoigateway
configmap/aiops-ea-noi-layer-eanoigateway edited

   \   'SupportZone'    =    '@SupportZone',\n

Delete the gateway pod to restart it with the updated configmap.

2.2 Create guardrails policies:

Using Swagger UI – POST

https://netcool-aiops.apps.noiocp.cp.fyre.ibm.com/policyregistry.ibm-netcool-prod.aiops.io/docs/v1alpha/system/#/

Request body:

  {
    "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.details.SupportZone }}",
            "then": [
              {
                "actionId": "com.ibm.hdm.noi.actions.impl.EnrichPrependCorrelationKey",
                "arguments": {
                  "value": {
                    "$template": "{{event.details.SupportZone}}"
                  },
                  "event": {
                    "$variable": "event"
                  }
                }
              }
            ]
          }
        }
      ]
    }
  }

Verify policy is created using Swagger UI – GET

2.3 Test guardrails

Now insert /delete a broader set of events from different Support Zones at least 3 times so temporal policy gets created.

Once the temporal policy is created it will start creating temporal groups.

As you can see in the screenshot below, temporal groups are created within the SupportZone.