opEvents can process information from a variety of sources, some of which can be extended to suit non-standard deployments. This document briefly documents how to configure opEvents' input sources.
...
The natively understood formats are:
| Format Name (Parser Type) | Description |
|---|---|
| nmis_eventlog | An event log file created by NMIS |
| nmis_slavelog | An NMIS poller event log file |
| nmis_traplog | An NMIS trap log file |
| nmis_json_dir | A directory of NMIS event logs in JSON format |
| cisco_syslog | A Syslog log file containing logs created by Cisco devices |
| tivoli_log | A Tivoli log file |
To enable a particular log file or format, you need to add an entry for the log file in question to the list of files for the appropriate log format; check the cisco_syslog entry in the example above for the syntax. The tokens <nmis_something> in the example work like centrally-defined shortcuts or macros; they are replaced by the actual locations given in the directories section at the beginning of conf/opCommon.nmis.
...
set.propertyname(value) sets the named property to the static value.
No quoting of the value is required or supported.
The character ")" cannot be part of the value before opEvents 2.2; In 2.2 and above it may only be present if you use the explicit list format for your action statement.capture(propname1,propname2,...) saves the respective captures from the regex in the named properties. The captures are assigned in their order in the regular expression; if you want grouping but not capturing, use(?:....)in your regex. Note that you cannot use multiple capture statements in one THEN.- opEvents version 2.0 introduces the new action
ignore. This aborts all parsing of this input line altogether and no event is created for it.
Normally the generic parser is expected to extract suitable information for an event from every single input line, which might not work well if your log data is coming from multiple sources or can't be suitably prefiltered. - In opEvents version 2.2 we've added the directives
resolve.fwd(propname)andresolve.rev(propname)
Theresolve.fwd()directive expects the property to be a DNS name and queries the DNS for an IP address associated with the name; theresolve.rev()directive interprets the property as an IP address and looks for a host name for it. If the resolution is successful, the property value is replaced by the DNS data; otherwise the property is left as-is.
e.g. to resolve a BGP Peer address which is stored in the element name, add an entry to DNS or /etc/hosts and include resolve.rev(element) as a parser directive. - opEvents 2.2 also adds the new directive
plugin(PluginName), which invokes an external parser plugin for further enrichment or modification of the event.
This functionality is described in more detail in the next section.
...
If a plugin named 'PluginName' is available, its parse_enrich function is executed and if successful, the modifications made by the function replace the event properties. Parsing then continues normally.