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.

Input Configuration

The inputs opEvents is supposed to handle are specified in the opevents section of conf/opCommon.nmis, primarily in subsection opevents_logs. opEvents primarily handles event information sourced by consuming and collating log files from sources like NMIS, Tivoli or general syslogs.

...

opEvents handles non-existent log files gracefully, but the log formats need to match the actual content. All log files are reopened on demand (e.g. when log rotation renames a file), and checked at least once every opeventsd_update_rate seconds. The order of log file specifications is not relevant. 

Black and Whitelisting

opEvents ships with ready-made black and whitelist rules to reduce voluminous inputs down to the relevant details, but these can be adjusted at need. These lists are active if the settings  black_list_enabled or white_list_enabled are set to true, respectively.

...

The format is straight-forward: the numeric key controls order of rule application, and the right side is a regular expression that the log entries are matched against.

Normalisation and Enrichment

For the natively-supported log formats (except nmis_json_dir) only the actual parsing is hard-coded; the act of subsequent further extraction and collection of relevant details is configurable - but of course opEvents ships with a substantial set of default normalisation rules. Event normalisation consists of associating a log entry with a node, extracting details, determining whether the event is stateful or stateless, followed by optional additional enrichment from external sources.

...

Please note that the log file format nmis_json_dir is not subject to normalisation; instead the contents of these are expected to be normalised already.

Command-line Event Creation

To provide a simple interface for external programs, opEvents also can create an event "on the fly" with event details from command-line arguments or a JSON file.

...

opeventsd.pl act=create-json path=./myevent_in_format.json

Generic Extensible Parser

In situations where none of the built-in input mechanisms are suitable you can also define your own generic parser rules to integrate just about any text-based log information into opEvents.

...

• 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) and resolve.rev(propname).
  The resolve.fwd() directive expects the property to be a DNS name and queries the DNS for an IP address associated  with the name; the resolve.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.
• 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.

Rules are applied in ascending order, defined by their numeric key, and nesting is fully supported.
Note that the numeric key may contain fractional numbers (e.g. "14.8"), which makes it very easy to insert new rules between existing ones.

opEvents 2.0.6 and newer ships with complete generic parser rules for parsing Cisco syslogs (log format type "cisco_alternate") and SNMP trap logs (log format type "nmis_traplog_alternate"), which you may want to use instead of the default built-in parsers if your log material requires custom processing.

Parser Plugins

For situations where external input must be incorporated into events at the time of parsing, opEvents 2.2 and newer support  user-defined parser plugins.
The directory install/parser_plugins contains an example plugin called TestPlugin.pm and a README file with documetation.

Requirements

All plugins must be valid Perl code. The files must be named Something.pm and reside in the directory conf/parser-plugins. Each plugin must have a proper 'package Something;' namespace declaration that matches the file name, and this package namespace must not clash with any existing opEvents or NMIS components.

It's recommended that the plugin have a version declaration right after the package namespace declaration, e.g.. 'our $VERSION = "1.2.3";'

The plugin may load extra Perl modules with 'use', but it must not use any package-level global variables. All its variables and any objects that it might create must have local scope. The plugin must not use Exporter to export anything from its namespace.

Plugin Interface

A plugin must offer a function called parse_enrich or it will be ignored by opEvents.

When triggered by a plugin(SomeName) parser directive, the parse_enrich function of that plugin will be called with two arguments, line and event (in that order).

• Line is the complete log entry/line that is being processed and cannot be modified.
• Event is a hash reference and contains the preliminary live data structure of the event as parsed so far.
  Event properties can be changed, added and deleted by the plugin function by modifying this live event hash.

The parse_enrich function must return one of the following:

• 1: to indicate that it succeeded,
• 0 or undef: to indicate that event parsing should be aborted for this line and no event should be created (like the parser directive ignore),
• or any other string value as an error message (which will be logged).

Any changes made to the event properties are ignored unless the function completes successfully and returns 1. This also applies to a crashing parse_enrich function, or if is terminated because it ran over time.

Plugin Configuration

The configuration option opevents_plugin_max_runtime (default: 5 seconds) sets the maximum execution time for a single parse_enrich call. If a plugin's function runs longer than that it is terminated and an error message is logged; any changes that it may have made to the live event datastructure are ignored in this case.

Plugin Activation

A generic extensible parser rule can invoke one or more parser plugins using the action directive plugin(PluginName).

When such a plugin call directive is encountered for the first time, the opEvents daemon loads (and caches) all available plugins that meet the requirements. To reread modified plugins, opeventsd must be restarted.

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.