...
| 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' ],
'nmis_eventlog' => [ '<nmis_logs>/event.log' ],
# attention: json logs in this directory are REMOVED after consumption
# 'nmis_json_dir' => [ '<nmis_logs>/json' ],
},
|
...
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 particular 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 conf/opCommon.nmis.
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 specifcations 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 black_list_enabled or white_list_enabled are set to true, respectively.
...