Introduction

opEvents processes syslog, SNMP Traps, NMIS Events into a common format for further processing. This process is called normalisation.  

The following tables represents the standard properties of normalised events - but as event properties are pretty much infinitely adaptable and extensible (e.g. from custom parser rules or event action policies), the tables cannot be exhaustive.

Standard Properties

Optional but Common Properties

In addition to those a number of properties are optional and created only under certain conditions:

Additional event properties to capture additional event data

opEvents works on an event, the event can be thought of as a document and all the contents of that document move through opEvents together, additional properties are added and updated during event processing.  It is also not only possible but strongly encouraged to add additional properties as the richer the event, the more useful it will be during processing, obviously the data captured should be relevant and useful.  This is easily done during event parsing and a variable is created by including a new variable name in the capture statement, see more details in opEvents EventParserRules - Adding Rules For SNMP Traps.

During event processing by EventActions, you can tag events with the tag function, and use it for event processing and conditions.  If an event is tagged like this: 

				'1' => {
					IF => 'event.details =~ "outage_current=true"',
					THEN => 'tag.outageCurrent(TRUE)',
					BREAK => 'false'
				},

The result would then be available to be used in the variable event.tag_outageCurrent, e.g.

IF => 'event.tag_outageCurrent eq "TRUE"',

Using event tagging is a powerful way to implement event policies and have an easy to follow flow in EventActions.

Node vs. Host, and how opEvents handles inconsistent input data

opEvents works hard to normalize inputs from disparate and often inconsistent input data; one of the most common issues is event input data that lacks the correct node name, only has an IP adress or a DNS shortname and not an FQDN and similar.

Here is an overview of the heuristic that opEvents applies to make sure that events are associated with the correct node:

1. First, opEvents extracts the prospective nodes' host name from the input data.
   The parser normally extracts  a host property from the input, which may be an FQDN, DNS short name or IP address.
   (The parser may also set the final node property, but that's not recommended and our example parsing rules don't contain such operations.)
   In case of the NMIS event log being the source, only the NMIS node name is available and is used as host name for all subsequent steps.
2. opEvents now looks for the one node that is identified by this hostname/address etc.
   This is done by looking in a cache of associations between FQDNs, shortnames  and IP addresses that opEvents maintains.
   If this succeeds, then the node's name is set as the event's node  property and the procedure is finished.
3. If no matching association is found, then the DNS is used to find potential intermediate associations.
   The host property is resolved via the DNS, forward to IP address if it was a hostname, or reverse to FQDN if it was an IP address.
4. If this intermediate step resulted in something that is associated with a known node, then that node is used and the intermediate info is added to the cache.
   (There are also some internal safeguards to reduce the number of DNS requests opEvents might perform.)
5. If none of this worked, then the original raw, untranslatable, host property is used as a new node's name.
   In opEvents 2.0.4 and newer, the configuration option opevents_auto_create_nodes controls the behaviour in this situation: if set to false, the event is skipped.
   If set to true (or not present), then a new node record is created. (Older versions of opEvents always created new but somewhat incomplete node records in this case.)

The consequences of this normalisation setup are as follows:

• An event's event.node property will always identify the node that is associated with the event.
• The event's event.host property is set from the raw inputs, and is very often not the same as a known node's node.host property, nor is it guaranteed to exist.
  The only thing guaranteed about event.host is that at the time of the event creation it was somehow, possibly even just temporarily, associated with the node in question.
  For NMIS eventlog as source the event.host is always the NMIS node name.
• The opEvents dashboard and event-centric pages all show the event.node property as primary id, and the event.host property as supplementary information.
• Editing a node's host or addresses properties in the Edit Nodes GUI does not affect any existing events; it just sets up association info for finding the right node for future events.