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 different log files in the configuration option
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 expected to contain all required event properties.
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 firstname.lastname@example.org .
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.
install/parser_plugins contains an example plugin called
TestPlugin.pm and a
README file with documentation.