Supervised Event Correlator
The Supervised Event Correlator microservice is part of the RCA3 solution. It takes Supervised Correlation Policies, runs supervised machine learning algorithms, identifies an existing root cause event or creates a new root cause event, and correlates the remaining symptom events to the root cause event.
Supervised Event Correlator Prerequisites
Before deploying the microservice, confirm that a microservice cluster is set up. See Microservice Cluster Setup.
Deploying Supervised Event Correlator
To deploy the microservice, run the following commands:
su - assure1
export NAMESPACE=<namespace>
export WEBFQDN=<WebFQDN>
a1helm install <microservice-release-name> assure1/supervised-event-correlator -n $NAMESPACE --set global.imageRegistry=$WEBFQDN
In the commands:
-
<namespace> is the namespace where you are deploying the microservice. The default namespace is a1-zone1-pri, but you can change the zone number and, when deploying to a redundant cluster, change pri to sec.
-
<WebFQDN> is the fully-qualified domain name of the primary presentation server for the cluster.
-
<microservice-release-name> is the name to use for the microservice instance. Oracle recommends using the microservice name (supervised-event-correlator) unless you are deploying multiple instances of the microservice to the same cluster.
You can also use the Unified Assurance UI to deploy microservices. See Deploying a Microservice by Using the UI for more information.
Changing Supervised Event Correlator Configuration Parameters
When running the install command, you can optionally change default configuration parameter values by including them in the command with additional --set arguments. You can add as many additional --set arguments as you need.
For example:
-
Set the parameters described in Default Supervised Event Correlator Configuration in one of the following ways:
-
Set LOG_LEVEL or one of the redundancy parameters by adding --set configData.<parameter_name>=<parameter_value>. For example, --set configData.LOG_LEVEL=DEBUG.
-
Set CONFIG_CHECK, POLL_LAST, or POLL_TIME by adding --set-string configData.<parameter_name>=<parameter_value>. For example, --set-string configData.CONFIG_CHECK=1200.
-
-
Enable redundancy for the microservice by adding --set redundancy.enabled=true.
Default Supervised Event Correlator Configuration
| Name | Default Value | Possible Values | Notes |
|---|---|---|---|
| LOG_LEVEL | INFO | FATAL, ERROR, WARN, INFO, DEBUG | Logging level used by application. |
| CONFIG_CHECK | 900 | Integer | Time in seconds between config checks (reading in of new / changed policies). This number should be bigger than poll time. |
| POLL_LAST | 300 | Integer | Time in seconds to check every poll time. This number should not be smaller than the poll time to avoid gaps. |
| POLL_TIME | 300 | Integer | Time in seconds between polls of the event list (and processing of events). |
| REDUNDANCY_POLL_PERIOD | 5 | Integer | The number of seconds between status checks from the secondary microservice to the primary microservice. |
| REDUNDANCY_FAILOVER_THRESHOLD | 4 | Integer | The number of times the primary microservice must fail checks before the secondary microservice becomes active. |
| REDUNDANCY_FALLBACK_THRESHOLD | 1 | Integer | The number of times the primary microservice must succeed checks before the secondary microservice becomes inactive. |
Setting Up Supervised Event Correlator Policies
You can add Supervised Correlation Policies or modify existing Supervised Correlation Policies in the UI. From the Configuration menu, select Events, then select Supervised Correlations. See Supervised Correlations in Unified Assurance User's Guide for more information.
Supported Meta Event Tokens
The following table shows the supported meta event tokens.
| Keyword | Description |
|---|---|
$ACTOR |
Supervised Correlation policy name |
$ACTION |
event-supervised-correlator |
$GROUPBY |
Supervised Correlation policy Group BY value if set. Else empty |
$POLICYID |
Supervised Correlation policy ID |
$POLICYNAME |
Supervised Correlation policy name |
$STARTTIMESTAMP |
Timestamp of first (oldest) event in cluster |
$TIMESTAMP |
Timestamp Meta Event got created / renewed |
Dynamic Meta Event Field Mapping
You can configure an event field in a meta event to derive its value from the symptom events matched by a Supervised Correlation Policy. This feature applies only when the policy creates a meta event as its root cause.
To configure a dynamic value:
-
Open Configuration, select Events, select Processing, then select Meta Events.
-
Click Add to create a new meta event for the policy, or select an existing meta event that the policy uses.
The Meta Event window appears.
-
In an event field in the Meta Event window, enter a complete strategy token in this form: <FieldName:strategy>.
For example, set the Event Type field to <EventType:majority> to use the most frequent non-empty event type among the matched symptom events.
Note:
Use strategy tokens only in meta event templates that are dedicated to Supervised Event Correlator. Other meta event consumers do not resolve these tokens and use the configured token as static text.
Strategy Token Syntax
The token must be the complete, configured event field value, with both field name and strategy. Supervised correlation policies do not support:
-
Tokens embedded in other text, such as Cluster <Node:latest>.
-
<FieldName> without a strategy, as used in watcher-style substitution forms.
Field names and strategy names are not case-sensitive.
Note:
$GROUPBY is the existing Supervised Correlation Policy group-by token. It is not a strategy token.
The following table shows the available strategies.
| Strategy | Result |
|---|---|
| common | Uses the value only when all non-empty matched values are identical. |
| majority | Uses the most frequent non-empty matched value. If values are tied, Supervised Correlation Policy uses the first matching value. |
| latest | Uses the source-field value from the matched event with the latest LastReported value. |
| oldest | Uses the source-field value from the matched event with the oldest LastReported value. |
| highestSeverity | Uses the source-field value from the matched event with the highest Severity value. |
| max | Uses the maximum numeric source-field value. Non-numeric values are ignored. |
| min | Uses the minimum numeric source-field value. Non-numeric values are ignored. |
| sum | Uses the sum of numeric source-field values. Non-numeric values are ignored. |
| count | Uses the number of matched symptom events. The field name is required by the syntax but does not affect the result. |
| distinct | Joins distinct non-empty source-field values with a vertical bar (|) in their encountered order. |
Example: Configure an Interface-Outage Meta Event
Use the following procedure to create a meta event for an interface-outage cluster. In this example, several events from an access router indicate an interface outage. The generated meta event identifies the most common alarm type and includes the node, location, highest severity, and distinct symptom summaries.
-
From the main navigation menu, select Configuration, then Events, then Processing, and then Meta Events.
-
Click Add to create a meta event for the supervised correlation policy.
The Meta Event window appears.
-
In the Name field, enter a descriptive static name, such as Access Router Interface Outage.
-
In Event Fields, enter the following values:
-
In Event Type, enter <EventType:majority>. This value identifies the most common alarm type in the cluster, such as Interface Down.
-
In Device, enter <Node:majority>. This value identifies the node that generated most of the matched events.
-
In Location, enter <Location:common>. This value is populated only when all matched events have the same location.
-
In Severity, enter <Severity:highestSeverity>. This value identifies the highest severity in the cluster.
-
In Event Text, enter <Summary:distinct>. This value lists the distinct symptom summaries, separated by a vertical bar.
-
-
Save the meta event.
-
From the main navigation menu, select Configuration, then Events, and then Supervised Correlations.
-
Click Add to create a supervised correlation policy. Enter a name, such as Access Router Interface Outage Correlation.
-
In Match Fields, add the event fields that identify the interface-alarm symptoms. For example, add EventType, Node, and Location.
-
In Root Cause, select the meta event that you created in step 2. Do not enter values in the Root Cause field list when you select a meta event.
-
In Symptoms, configure the criteria for the interface alarms. For example, select an equality operator for EventType and enter the expected alarm types, such as Interface Down and Link Down, with each value on a separate line. Specify the applicable Nodes and Location values for the access router.
-
In Cluster Conditions, select Node as the Group By field. Set Minimum Members to 3 and Time Window (Secs) to 300, or use values appropriate for the expected alarm volume and correlation window.
-
Set Status to enabled, and then save the policy.
When the policy identifies a qualifying cluster, Supervised Event Correlator creates or refreshes the meta event. For example, if most matched symptoms have the EventType Interface Down, the generated meta event has Interface Down as its EventType. If EventType values are tied, Supervised Event Correlator uses the first matching value.
Note:
-
When Supervised Event Correlator creates or refreshes a meta event with the same EventKey, it recalculates and updates each configured dynamic event field.
-
If a source field is missing, a strategy is not recognized, a required value is unavailable, or no usable value exists, Supervised Event Correlator sets the event field value to empty.