...
For the sake of this discussion let's assume the new vendor can be parsed with the existing cisco_alternate rules found in /usr/local/omk/conf/EventParserRules.nmis.
Here is a list of current vendor's in the EventParserRules.nmis
- winlogd
- junos
- cisco_compatible
- nxlog
- JuniperSyslog
- HuwaeiSylog
If need additional parsers please open a support case, you will need a sample of the syslog in order to proceed
We need to tell opEvents which parser rules to use these parser rules on for the new device /usr/local/nmis8nmis9/logs/newVendor.log. (or what log name that you entered in the rsyslog.conf for the new Device or new Vendor)
This is done by modifying /usr/local/omk/conf/opCommon.nmis.
Find the 'opevents_logs section and add the 'cisco_alternate', '<nmis_logs>/newVendor' relationship.
Just copy one of the examples:
Add the following lines:
'cisco_alternate' => [ '<nmis_logs>/newVendor.log' ],
Code Block |
---|
### /usr/local/omk/conf/opCommon.nmis 'opevents_logs' => { 'cisco_alternate' => [ '<nmis_logs>/newVendor.log' ], 'cisco_syslog' => [ '<nmis_logs>/cisco.log' ], 'nmis_eventlog' => [ '<nmis_logs>/event.log' ], |
...
Code Block |
---|
[root@opmantek ~]# service opeventsd restart Restarting opevents daemon opeventsd [ OK ] [root@opmantek ~]# |
At this point you should be able to go to the Gui > Raw Logs This will allow you to verified you see the logs coming in
Create an event action policy as described here: Event Actions and Escalation
...