...
The natively understood formats are:
Format Name (Parser Type) | Description |
---|---|
nmis_eventlog | An event log file created by NMIS |
nmis_slavelog | An NMIS slave 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 |
...
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
andname
directives are present and if the regex matches and captures something from the log entry, then a named property (with name from thename
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 directivevariable
if that directive is presentmatching is performed on most of log input, but different across the various parsers:
For parser typesother thannmis_eventlog
andnmis_slavelog
the regex is applied to the eventdetails
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:
- only to the event property named by the directive
variable
if that directive is present (e.g.'variable' => 'node'
), - or to the whole, unsplit input log entry.
- only to the event property named by the directive
- Parser types except
nmis_eventlog
andnmis_slavelog
: if a rule block contains aregex
directive which matches, then any key-value entries forevent
,priority
,state
orstateful
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.
...