Content Comparison

...

• 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.

...