Page History

...

• an event name, which specifies the name of the newly created event,
• a list of events (more precisely, their names), which are the events to consider for correlation,
• a (minimum) count of events that have to be detected to trigger the rule,
• an optional list of groupby clauses, which define whether the count is interpreted globally for all named events, or separately within smaller groups,
• optional delayedaction and autoacknowledge clauses, which define how the triggering events should be handled,
• an optional enrich clause, which adjusts the content of the newly created event,
• from version 2.2 .0a onwards, optional copy_first, copy_last, copy_highest and copy_groupby clauses which further control the contents of the newly created event,
• from version 2.2 onwards, an optional inhibit parameter, which disables correlation temporarily after a rule has fired,
• and finally a window parameter, which defines the time window to examine.

...

In version 2.2 this limitation has been removed, and much more precise control of the event content is possible.

Content Control Directives (Version 2.2

...

and newer)

When a synthesis rule creates a new event, the following steps are performed:

...

'1' => {
   name => "Very Sick Node",
   events => [ "Node Down", "SNMP Down", "Interface Down", "Service Down",
               "Service Degraded", "Interface Flap", "Node Flap", "WMI Down" ],
   window => 120,
   count => 3,
   groupby => [ 'node.name' ], # we want separate events for each node of course
   enrich => { stateful => "Very Sick Node", priority => 5, state => 'down', element => undef }, # new event is stateful only if stateful is set or copied by name
   copy_last => [ qr//, 'node' ], # can set from node here (all events share it)
   copy_groupby => [ 'node' ], # or from here; must set it explicitely somewhere, or the event goes to opevents_correlation_node
},

Stateful Synthetic Events (Version 2.2

...

and newer)

By default, synthetic events are not stateful events, i.e. they are not subject to deduplication and they cannot be acknowledged (or 'closed') by any future 'opposite' event.

...

1. Without inhibit, after the first 20 events for group A you'll get one synthetic event for group A; another after the next 20 and so on.
   For group B, one synthetic event will be generated for the first 20; the remaining 5 are too few to trigger anything.
2. With inhibit set to 40 seconds (for example), you'll get the very first group A synthetic event as before, but then no synthetic events for this rule and group A for the next 40s;
   After that correlation for group A resumes 'from scratch' and any events received from then onwards are counted and correlated as normal.
   For group B with its fewer triggers the inhibit behaviour doesn't change anything visibly, there's still just one synthetic event.
   Note that the inhibit timer for group A is totally independent of any inhibit for group B: inhibit applies to a particular rule and its full groupby context.

In opEvents version 2.2, the combination of the options autoacknowledge and inhibit does not acknowledge trigger events that occur during the inhibit period; only 'successful' triggers are acknowledged. This has been changed for greater consistency and better  storm control in versions 2.2.1 and newer, where successful triggers and any trigger events occurring during the inhibit period are also acknowledged automatically.