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.
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. 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
.
{{ 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"
}
}
}
"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.
{
"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
helmValuesNOI
:
ibm-hdm-analytics-dev.postinsertprocessor.enabled: true
$ oc get deploy | grep v3
evtmanager-ibm-hdm-analytics-dev-v3-evt-pi-processor
v3-evt-pi-processor
.