...
- First, opEvents extracts the prospective nodes' host name from the input data.
The parser normally extracts ahost
property from the input, which may be an FQDN, DNS short name or IP address.
(The parser may also set the finalnode
property, but that's not recommended and our example parsing rules don't contain such operations.) - 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'snode
property and the procedure is finished. - If no matching association is found, then the DNS is used to find potential intermediate associations.
Thehost
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. - 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.) - 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 optionopevents_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:
...