Content Comparison

opEvents provides two mechanisms to handle repeated event occurrences in a practical fashion, namely stateful event deduplication and programmable event suppression.

...

• The stateful property indicates the type of state source, and is a free-form string.
  For example, if the event is related to an interface, stateful should be set to "Interface"; if it's about a service, the value "Service" would be most appropriate, etc.
  You may use any state source type you want in your parser rules, but avoid overloading already existing ones like  "Node" and "Interface".
• The  element property indicates which (of potentially many) state sources the event relates to.
  For state type interface, a unique interface identifier should be used (i.e. the ifDescr).
  Like above your parser rules may capture or set the element to anything you desire, as long as the combination of node name, stateful and element is a suitably unique identifier for the particular stateful thing you're trying to track.
• The state property indicates whether the observed state is "good" or "bad".
  opEvents treats the values  up, ok, good, normal or closed as "good", anything else as "bad".
  This comparison is made case-insensitively, i.e. "Good" will work just as well as "OK".

  With the release of opEvents 4.5.0, you can now define custom values for the "good" state by adding the opevents_up_states setting in opCommon.json under opevents.
  This new setting allows you to dynamically configure additional "good" states to suit your specific requirements, providing greater flexibility and customization in state management.
  For example: "opevents_up_states" : ["up","ok","good","normal","closed","online","added","enabled"]

For state tracking opEvents then combines the node name and the values of stateful and element into a lookup key, and associates that key with the state value.
Any repeat events with the same lookup key and the same state value are ignored.

Stateful Deduplication, Forwarded Events and Reorder Protection

Anchor
reorder_protection reorder_protection

If you use an Event Action or Escalation Policy with create_remote_events to forward events to another opEvents server elsewhere, then you might occasionally find that such forwarded events arrive out of order, i.e. an earlier 'down' event might be received after the later 'up' event. This can happen because of network congestion, action processing on the sending side being asynchronous and subject to process limits and similar reasons.

...