Click the Correlations tab to create rules that correlate alerts with actions. Correlation rules enable RightITnow ECM to automatically take action on alerts without any intervention from you. After the Categorization service creates an alert, the Correlation service enriches the alert by applying the built-in enrichment rules before processing any other correlation rules. When a rule closes an alert, it updates the comment with what the audit log shows, for example, "Closed by rule 'Delete Clear Alerts'."
Enrichment rules include:
Maintenance rule - Sets the maintenance field to TRUE if the alert's entity is in maintenance. You can add an additional action or action group to this default behavior, for example, sending an email informing the supervisor of the maintenance period. You may also de-duplicate against alerts that are not maintenance.
Close Maintenance rule - Dynamically closes a maintenance window based on a condition from an incoming alert.
Tag rules - Sets the Tags column in the Alerts table to the value specified in the rule. For example, if the message contains the word, "postfix" or "sendmail," then set the Tags column value to "email:"
After applying the enrichment rules, the Correlation service executes the other types of correlation rules:
Upon Event Arrival - Rules that trigger actions based upon the alert attributes, for example, if the entity has an owner, set the owner of the alert to be the same as the entity. These rules are evaluated upon arrival of the alert or modification of the alert's event count.
Upon Closed Event Arrival - Rules that trigger actions based upon the alert attributes, for example, if the entity has an owner, set the owner of the alert to be the same as the entity. These rules are evaluated when an event is de-duplicated against a closed alert and the alert was not re-opened by the workflow. Unlike in Upon Event Arrival rules, Upon Closed Event Arrival rules cannot execute actions against a set of triggering alerts, and cannot check whether a subset of alerts exist.
Periodic Rules - Rules that execute actions on a periodic basis based upon the alert attributes, for example, a rule that sets the alert severity to Clear when the severity is Info.
Timed Conditions (X in Y) - Rules that trigger actions if an alert occurs X number of times over a Y period. If you only want to act if an alert has occurred X times without restrictions over the period, you can use a correlation rule (upon creation) and use the eventcount field in the conditions section.
Note: Creating Rules on the Fly - RightITnow ECM provides the very powerful ability for your operators to build rules on the fly from the Alerts menu. See Creating Rules on the Fly for how to create rules on the fly and Modifying Rules Created on the Fly for how to modify the rules you create on the fly.
Use the graphical rule builder in the RuleBuilder pane on the right to create Correlation rules.
To create or edit a correlation rule, in the left pane, select a rule to modify, or click Create in the lower left side of the screen, and then follow the instructions in the illustration and accompanying table below for the tasks to complete in the RuleBuilder pane on the right (this example is a an Upon Event Arrival rule. The fields that appear will vary depending upon the chosen rule type):
|
Enter a name and description for the rule. |
|
Select the type of rule. See Correlating_Alerts for a description of possible rule types. |
|
Incoming events may not always be processed in the order of their timestamps but in the order they arrive into ECM. If this option is enabled and the timestamp for the current event being processed is older than the timestamp of the previously received event, then the rule will not be applied. |
|
ECM can skip applying rules to alerts if the specified time has not elapsed since the last qualifying event. |
|
Select on which kinds of alerts to run the actions: all alerts, alerts not in maintenance, or alerts in maintenance. |
|
Use the + controls to select a connector type and name. |
|
Define the triggering alert. |
|
Click to add a logical AND clause to the triggering conditions criteria that will also require that the specified conditions exist in existing alerts before triggering the correlation rule. Enable Exclude incoming alert from matching the filter to prevent ECM from considering the incoming alert when checking existing alerts, even if it matches the filter below. |
|
Define the alert that must also exist. |
|
Click to take the specified actions on the triggering alert on success or failure. |
|
Click to take the specified actions on the matching alerts on success or failure. Enable Exclude incoming alert from matching the filter to prevent ECM from considering the incoming alert when checking existing alerts, even if it matches the filter below. |
|
Define the matching alerts. |
|
Click Save to save the rule, Save and Deploy to save and activate the rule, or Cancel to abandon your changes. |
See Building Conditions Using Wildcards to learn how to use wildcards in conditions.
Note: You can edit existing rules by selecting the rule in one of the rules panes on the left and editing it in the Rulebuilder pane on the right.
Use the check boxes shown in the figures below to query for alerts that match attributes of incoming alerts:
and
This functionality allows you to create filters like:
You can compare incoming event tokens with the last value of the event token.
To query against the last value of an event token, select the desired token in the first field of the Condition Builder and the Old version of the same token in the last field, as shown below:
Note that you can also compare custom fields with other custom fields of the same type and also with "old custom field" values. This allows, for example, comparing the incoming event time with the max event time in the existing alert.
By default, ECM de-duplicates events
received from an entity that is in maintenance only against alerts that
are in maintenance. If the event would de-duplicate against an alert that
is not in maintenance and there are no alerts in maintenance, then a new
alert, with different de-duplication criteria, is created. The following is an example of
how events are de-duplicated by default:
Event 1 tokens are: {message=”node down”, entity=”192.168.12.11”, connector=”soap-connector”, severity=”5”}.
Event 2 tokens are: {message=”node
down”, entity=”192.168.12.11”, connector=”soap-connector”, severity=”5”}
Both match the categorisation rule with the following de-duplication criteria
{event.message}{event.entity}{event.connector}
So both events should de-duplicate against the same alert. If Event 2 is sent while the entity is in maintenance, the following de-duplication criteria is used, hence creating a new alert:
{event.message}{event.entity}{event.connector}MAINTENANCE
Enabling the following option when creating a Maintenance correlation rule allows events to de-duplicate against alerts that are not in maintenance:
If the "Check entity hierarchy for parents in maintenance" option on the Maintenance Rule is enabled, entities will inherit their parents' maintenance windows up to the top-level entity, but not the maintenance windows of the parents' groups.
As described above, a tag rule updates the Tags column in the Alerts table to the value specified in the rule. When building a tag rule, you name and describe the rule, choose the connector and build conditions like you do for any other type of rule, but you can also select multiple tags to add or remove should the conditions of the rule be met:
Removing tags has the following constraints:
When executing the tag rules on incoming alerts, if the rule removes tags, it will only remove tags that were added via the event token "tag" or by another tag rule. This is executed before the alert is stored in the database, so tags that are already in the database (previously added) will not be removed.
If the rules are evaluated using the "Evaluate Tags" action, then tags will be removed from the database.
A Timed Condition triggers an action/action group if the count of the number of events of a set of alerts during a period of time reaches an expected value. You can configure the timed condition to execute the action once or repeatedly.
The events that are counted by the timed condition are only the events that are de-duplicated into the set of alerts captured by the condition’s rule that occur during the period of time, disregarding the events that happened before the start time of the period. It will also disregard the events after the period has finished.
When an alert arrives, RightITnow ECM evaluates it against the rule of all timed conditions whose period has started and has not yet finished. If the evaluation of a rule is successful, then the event count of the timed condition increases and a reference to the alert is kept. RightITnow ECM then checks if the number of expected events is the same as the current event count. If this occurs, then the action is invoked and the period of time reset, passing as an argument that the alert arrived. If the condition is set to execute once, then the condition is no longer checked. Otherwise, the period of time is reset. When the period finishes, the period of time is reset. Selecting the Reverse Timed Condition option triggers the rule if the number of received events in the time period is less than the expected number of events, for example, automatically close an alert if it happens less than 10 times in 1 hour.
You can configure a timed condition to group by an alert field, for example, entity or entity group, the count of events of the set of alerts that satisfy the condition. As a result of this, a condition will have a counter for each different value of the field selected to group by. Also, each counter will have its own period of time, but they will all have the same length.
The only fields that can be used to group by are: entity, entity group, connector, severity, and priority.
A use case for the group by feature would be to execute an action if n events arrive of alerts containing “Server down” in its description. But these counters should be for each entity in RightITnow ECM. So, instead of creating a timed condition for each entity, it is enough to create one rule and group by entity.
To build a timed condition rule:
This invokes the following RuleBuilder sections unique to Timed Condition correlation rules:
Configure these sections as described in the illustration above.
You can change the order in which RightITnow ECM executes correlation rules according to the needs of your organization:
When reordering rules as described above, you can nest Upon Event Arrival correlation rules by dragging and dropping them. Correlation rules that have a parent are evaluated only if the parent rule evaluates true:
RightITnow ECM affords the ability to create correlation rules on the fly from the Alerts console. See Creating Rules on the Fly for more information. This section describes how to modify rules created on the fly.
To modify rules created on the fly:
Select the rule created on the fly from the Upon Event Arrival section of the Correlations tab, as shown below:
Modify the selected rule as described in Building Correlation Rules.
If you have access to the Configuration tab, you can modify the default behavior of the Create Rule on the Fly function to match your business processes. See Configuring Create Rule on the Fly for more information.
Note: If the Rules Created on the Fly tab is enabled on your system, you can click it to change the value of parameters and adjust the schedule of rules created on the fly:
The ability to deploy and undeploy rules allows you to create libraries of rules and deploy them at will. To deploy or undeploy a rule, click the checkmark adjacent to the rule you wish to deploy or undeploy, and then click the Deploy or Undeploy button at the bottom of the Correlation Rules pane.
You can schedule the deployment and un-deployment of the following types of Correlation rules:
This allows you to take rules online and offline very conveniently.
To configure the deployment schedule:
The Scheduling window appears.
Use the Scheduling window to configure the schedule:
The Start Time is when the rule will be deployed, and the End Time when it will be undeployed.
