Skip to main content

Understand correlation group settings and definition order

The Moogsoft Cloud correlation engine includes a default correlation group and one correlation definition called Similar Sources. You can add additional correlation groups and custom correlation definitions if needed. When you have multiple definitions in a correlation group, the Reorder option becomes available and you can change the order the that Correlation Engine processes the definitions.

NOTE: It is possible to delete all of your correlation definitions in all of your correlation groups, but incidents will not form.

When you create a correlation group or edit an existing one, you can choose whether alerts correlated by this group can match all correlation definitions or whether they can only match one.

Correlation behavior for the "match all" option

When "Alerts can match all correlation definitions" is selected for a correlation group, alerts are evaluated by each correlation definition for inclusion in incidents, starting with the first correlation definition at the top of the list and proceeding to the bottom. Alerts may be clustered into multiple incidents by different correlation definitions. Definition order is irrelevant when this option is selected since alerts are candidates for evaluation by all definitions, however.

Correlation behavior for the "match one" option

When "Alerts can match one definition" is selected for a correlation group, alerts are evaluated by each correlation definition, starting at the top of the list and moving down through the definitions in order. The difference between this option and the "match all" option is that as soon as a match is found, processing stops and the alert is not evaluated by additional definitions. Each alert can be clustered into just one incident using this method (unless lengthy time windows are used).

One potential strategy of changing the order when this setting is selected would be to include very specific correlation definitions at the top of the list, and the more general definitions toward the end.

Example scenarios

Note

The clustering of alerts into incidents is also dependent on the correlation time window. For more information on the impact of time on clustering, see Correlation time window.

For the following examples, assume the following two correlation definitions are configured and enabled:

Definition A
  • Evaluates the source field for similarity (Fields to Correlate = source)

  • Matches at 100% similarity

Definition B
  • Evaluates the manager_id field for similarity (Fields to Correlate = manager_id)

  • Matches at 100% similarity

Assume two alerts with the following fields and values:

Alert 1

Alert 2

"source" = "AWS",

"manager_id" = "VPC",

"check" = "disk space",

class = "cloud"

"source" = "AWS",

"manager_id" = "VPC",

"check" = "memory",

"class" = "network"

Example 1. The "match one" setting selected, Definition A is listed first

One incident forms using the source field. Alert 1 and Alert 2 are members of the incident (both match on the source field at 100%).

Because the evaluation of alert similarity stops as soon as a match is found, the alerts are never evaluated by Definition B because both alerts find a match using the definition listed first (Definition A).



Example 2. The "match one" setting selected, Definition B is listed first

One incident forms using the manager_id field. Alert 1 and Alert 2 are members of the incident.

Because the evaluation of alert similarity stops as soon as a match is found, the alerts are never evaluated by Definition A because both alerts find a match using the definition listed first (Definition B).



Example 3. The "match all" setting selected

Two candidate incidents form, one using the source field and one using the manager_id field. Alert 1 and Alert 2 are members of both candidate incidents.

The two candidate incidents formed include both alerts because both alerts are 100% matches for both correlation definitions.

Important

Because Moogsoft merges identical candidate incidents (those composed of the same Alert IDs) into the same incident, the two incidents resulting from these two alerts would not actually be observed unless additional configuration settings (such as filters) were added. During the merging process, one of the two candidate incidents would be chosen to create the incident, and the other candidate would be merged with it.

Note that incidents which are less than 100% alike can also merge, depending on the percent similarity selected for the correlation group Automatic Merge setting.

The Ignore ordering option becomes more important when an alert potentially matches multiple existing incidents created by different correlation definitions. In this situation, the alert can be included in multiple incidents.

If these two active incidents already existed on your system:

Incident 1

Incident 2

"source" = "AWS",

"manager_id" = "VPC",

"check" = "logs",

class = "database"

"source" = "AWS",

"manager_id" = "VPC",

"check" = "response time",

"class" = "application"

Then Alert 1 and Alert 2 would be evaluated by both A and B correlation definitions and become members of both incidents.