...
| Code Block |
|---|
'opevents_logs' => {
# parsertype => list of logfiles (or dirs for nmis_json_dir)
# natively supported: tivoli_log, cisco_syslog, nmis_traplog,
# nmis_eventlog, nmis_slavelog and nmis_json_dir
'cisco_syslog' => [ '<nmis_logs>/cisco.log', "/some/other/log.file" ],
'tivoli_log' => [ '<nmis_logs>/tivoli.log' ],
'nmis_traplog' => [ '<nmis_logs>/trap.log' ],
'nmis_slavelog' => [ '<nmis_logs>/slave_event.log' ], ### DEPRECATED - now uses below parser
'nmis_pollerlog' => [ '<nmis_logs>/poller_event.log' ],
'nmis_eventlog' => [ '<nmis_logs>/event.log' ],
# attention: json logs in this directory are REMOVED after consumption
# 'nmis_json_dir' => [ '<nmis_logs>/json' ],
},
|
...
The default method for Normalisation is with the Generic Extensible Parser conf/EventParserRules.nmis you extend current parser entries or you ca define your own generic parser rules to integrate just about any text-based log information into opEvents. Your event is expected to contain all required event properties. , the minimum for it to be accepted is a date and host entry but for the event to be usable in the Gui it also needs an "event" entry at a minimum.
The generic parser is activated for The generic parser is activated for different log files in the configuration option opevents_parser_rules, in conf/opCommon.nmis , there is one entry for each log file which defines which 'parser' entry is to be used. The rules are defined in conf/EventParserRules.nmis. Here is an excerpt from the generic parser rules example that opEvents ships with: In this case the parser entry (used to associate it with certain log files) is called 'cisco_alternate'
...
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.
Your event is has to include a Host and Date entry to be accepted. For it to be usable in the GUI it also at a minimum needs an "event" property. We recommend it includes further details per this page, event properties.
opEvents 2.0.6 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., plus other syslog, nxlog parsers for various vendors such as Huawei, Juniper, Microsoft, these can be extended and new entries can be contributed via code@opmantek.com .
Parser 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 documentation.
...
A generic extensible parser rule can invoke one or more parser plugins using the action directive plugin(PluginName).
e.g. JSON example
| Code Block |
|---|
"42" : {
"IF" : "Node Down",
"THEN" : "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.
...