Page History

...

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.)
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, and .
   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:

...