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
Event Property | Description | Example |
eventid | A globally unique Event ID | |
| Unix time of the event (seconds since 1970). | 1385076573 |
| The event time in human readable format | 2013-11-11T13:39:41 |
| The name of the node in question. Normally the same as the NMIS node name. | |
| The DNS hostname or IP address of the node in question, as extracted from the input data. | |
| Name of the event | Node Down, Node Up |
| What element of the node the event refers to. Optional. | FastEthernet1, Neighbor 1.2.4.5 |
| Is the state good or bad, up or down. | up/down, open/closed, etc |
| Name of the stateful object. Optional, but always present if | Node, Interface, OSPF Neighbor |
| Other event details | |
| Where did the event originate? | cisco_syslog, trap, NMIS, (remote) API |
| Has the event been marked for escalation? | 0 or 1 |
priority | opEvents priority level, see opEvents priority levels vs. NMIS and Syslog levels | 0 to 10 |
| Has the event been acknowledged? | 0 or 1 |
| Is this event a flap? | 0 or 1 |
action_required | Should the GUI show the event as open? | 0 or 1 |
Optional but Common Properties
In addition to those a number of properties are optional and created only under certain conditions:
Event Property | Description | Example |
---|---|---|
interface_description | The ifAlias (or Description) of the interface in question
| |
authority | The server name of the system that originated the event; Optional, only relevant for remotely/API-generated events. | |
location | The URI for this event at the originating server. Optional, only relevant for remotely/API-generated events. | |
duplicateof | list of Event IDs that this one is a duplicate of | |
nodes | lists nodes that caused this synthetic event | |
eventids | list of Event IDs that were involved in causing this synthetic event | |
| Unix time, until then the event is held back from processing for actions and policies | 1385079231 |
action_checked | Has the event been processed wrt. actions and policies? | 0 or 1 |
<scriptname>.output | If an event triggered a script action that is set to save, then the script output is stored in this property. | |
synthetic | whether this event was created by a correlation policy action, or because a watchdog expired | 0 or 1 |
watchdog | whether this is a watchdog expiration event | 0 or 1 |
notes | a list of originator- and time-tagged comments for this event (optional, supported in opEvents 2.0 and newer) |
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:
- 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 a new node record is created.
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'snode.host
property.
The only thing guaranteed aboutevent.host
is that at the time of the event creation it was somehow, possibly even just temporarily, associated with the node in question. - The opEvents dashboard and event-centric pages all show the
event.node
property as primary id, and theevent.host
property as supplementary information. - Editing a node's
host
oraddresses
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.