...

The natively understood formats are:

...

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. .

Please note that the selection of the built-in parsers is tied to the value of the format name; all custom parsers that you might define must have their own, unique format names which must not clash with any of the built-in parser types.

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.

...

• if both regex and name directives are present and if the regex matches and captures something from the log entry, then a named property (with name from the name directive) will be created, with the value being the captured content.if a 
• The regex directive 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 regex is applied either to the whole entry, or only to the variable named by the directive variable if that directive is presentmatching is performed on most of log input, but different across the various parsers:
  For parser typesother than nmis_eventlog and nmis_slavelog the regex is applied to the event details property, which at this point holds most of the input log entry (usually everything except node and timestamp)
  For the event log parsers, the match is applied to:

1. 1. only to the event property named by the directive variable if that directive is present (e.g. 'variable' => 'node'),
   2. or to the whole, unsplit input log entry.

• Parser types except nmis_eventlog and nmis_slavelog: if a rule block contains a regex directive which matches, then any key-value entries for event, priority, state or stateful in that rule block will be copied to the event as static properties.

(You might also encounter the deprecated legacy format of using directives name and value to set just one property to a fixed value.)

...

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. This parser type or format name must be distinct and not clash with any built-in parsers (e.g. creating a parser type "nmis_eventlog" won't work).

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.

...