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 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.
Here is an example configuration fragment:
The natively understood formats are:
|nmis_eventlog||An event log file created by NMIS|
|nmis_slavelog||An NMIS slave 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|
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
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
white_list_enabled are set to
The black list contains a set of filtering rules which remove matching log entries from opEvents' input stream. The white list rules can be used to ensure that matching input entries are processed; if the white list is enabled, then only events matching the white list will be processed (but raw logging is still performed for forensics purposes). Enabling both black and white list options simultaneously is not useful.
Both black and white lists are configured in
conf/EventListRules.nmis, in sections like this example:
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.
Normalisation is controlled by the configuration files
EventTrapRules.nmis, all of which have a similar format. Here is an example config fragment from the syslog rules:
The key component is the
rules section, which controls what details are extracted from a log entry and how they are saved a sevent properties. There are a few ways of augmenting the event with information:
- if both
namedirectives are present and if the regex matches and captures something from the log entry, then a named property (with name from the
namedirective) will be created, with the value being the captured content.
- if a
regexdirective is present and matches, then all other directives will be copied to the event as static properties.
- EventNmisRules.nmis handles NMIS logs, which are somewhat more structured; here the
regexis applied either to the whole entry, or only to the variable named by the directive
variableif that directive is present.
(You might also encounter the deprecated legacy format of using directives
value to set just one property to a fixed value.)
In the example above, rule 1 will be active if a "line protocol down" log entry is detected, and in that case it'll add properties "priority", "event", and "stateful", all with static values. Rule 10 will be active if the log entry contains "Interface <something>", and it'll copy over the matched <something> as the value of the property named "event".
All normalisation rules are checked in sequence of their numeric key, and all the ones whose
regex directive matches will contribute to the new event's properties. Normalisation and enrichment then continues using information from NMIS; events are associated with the relevant nodes, stateful deduplication is performed etc.
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.
To create an event on the fly, you have to call
opeventsd.pl with the argument
act=create-event, which causes it to use all further key=value pairs in the arguments to construct an event, like this example:
Your event is expected to contain all required event properties and no further normalisation is performed. The option action_required should be set to 1 so that opEvents will process the event with Action Policies, or 0 to have opEvents not process with action policies.
Alternatively you can save your desired event's properties in a file in JSON format, and use
act=create-json to instruct opeventsd to create an event from it:
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.
The generic parser is activated by the configuration option
conf/opCommon.nmis, and the rules are defined in
conf/EventParserRules.nmis. Hiere is an excerpt from the generic parser rules example that opEvents ships with:
The format is straight-forward: the top key allocates a new log format type (here
cisco_alternate) which you would use in
opevents_logs for your log files. Under that key there are any number of (nested) capture rules, which control what to match in an input, and how to copy material to the newly created event. These rules use a format very similar to the Event Actions and Escalation policies:
IF defines a regular expression that the log entry has to match,
THEN declares what to do in that case, and a successful rule with optional
BREAK statement skips the rules on the same nesting level.
THEN expression consists of a nested sub-policy or of a single action statement. The action statement is an AND-separated list of action statements:
set.propertyname(value) sets the named property to the static value. No quoting of the value is required, but ")" cannot be part of the value.
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.
- in opEVents versions newer than 2.0 there is the additional action
ignore. This aborts parsing of this input 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.
Rules are applied in the order defined by their numeric key, and nesting is fully supported.