we receive traps on our NMIS server, and those traps are logged in messages:
Feb 2 19:01:17 proxy01 snmptrapd: test.test [UDP: [10.121.240.140]:38916->[10.121.240.187]]: Trap , RFC1213-MIB::sysUpTime.0 = Timeticks: (389384063) 45 days, 1:37:20.63, SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.38322.214.171.124.1, SNMPv2-SMI::enterprises.383126.96.36.199.1 = STRING: "b1c2b5bb-57d0-4f98-93b7-83be9589c7a5", SNMPv2-SMI::enterprises.383188.8.131.52.2 = Hex-STRING: 07 E0 02 02 13 00 18 00 2D FA 00 , SNMPv2-SMI::enterprises.383184.108.40.206.3 = STRING: "The health test result for SOLR_SOLR_SERVERS_HEALTHY has become bad: Healthy Solr Server: 9. Concerning Solr Server: 0. Total Solr Server: 10. Percent healthy: 90.00%. Percent healthy or concerning: 90.00%. Critical threshold: 90.00%.", SNMPv2-SMI::enterprises.383220.127.116.11.4 = INTEGER: 1, SNMPv2-SMI::enterprises.38318.104.22.168.5 = INTEGER: 3, SNMPv2-SMI::enterprises.38322.214.171.124.6 = STRING: "https://test.test/eventRedirect/b1c2b5bb-57d0-4f98-93b7-83be9589c7a5", SNMPv2-SMI::enterprises.383126.96.36.199.8 = STRING: "solr", SNMPv2-SMI::enterprises.383188.8.131.52.10 = STRING: "EV_SERVICE_HEALTH_CHECK_BAD"
But the traps aren't show up in NMIS => SNMP_traps, events or other logs. I followed the instructions from SNMP Traps with Cisco and Other devices
Here my snmptrapd.conf:
authCommunity log testnmis# traphandle SNMPv2-MIB::coldStart /usr/bin/bin/my_great_script cold
#OPTIONS="-Lsd -p /var/run/snmptrapd.pid"#OPTIONS="-Lo -Lf /var/log/snmptrapd.log -p /var/run/snmptrapd.pidOPTIONS="-p /var/run/snmptrapd.pid -m ALL -M /usr/local/nmis8/mibs/traps"
Any idea or advises?
Well that looks right for the snmptrapd configuration, it is reading in the MIB files from the right place hence the outptut is not just OID numbers.
The snmptrap output you have - is this from the local messages sylog log?
For NMIS to display the snmptrapd messages they should be ending up in: /usr/local/nmis8/traps/trap.log
As such I think you need to update one other snmp config which is
this should look like this.
"disableAuthorization yestraphandle default /usr/local/nmis8/bin/traplog.pl"
The changes to this config are part of the install instructions / setup of SNMPD, discussed here:
SNMPD, Net-SNMP and collecting stats of the NMIS server itself
The Cisco page you referred to should also reference this as well to make sure it has been assessed so I will update the wiki entry to make it clearer.
Let me know if I have made the right assumptions by checking the /etc/snmp/snmptrapd.conf content and the log entries in /usr/local/nmis8/traps/trap.log
All acted reasonably and responsibly to ensure their customers and users are protected against this technique, Brother Printer error code 0x803c010b and we're confident that going forward.
Awesome, that was absolutely right. Now the traps are shown in the correct log. But now another question pops of in my head - how can I notify users when a trap is received? I looked into Escalation Policy, but doesn't found a variable for.
to be honest, i'm not quite sure what you're trying to achieve by notifying users whenever /a/ trap comes in; on a busy system that will be very very often and create a lot of noise. but if you check the snmptrapd.conf documentation you'll find that snmptrapd comes with an example traphandler script "traptoemail" which does pretty much what its name implies. snmptrapd does support multiple traphandler hooks.
regarding nmis and traps: nmis does at this time not process traps beyond presenting them in the log viewer; our event managent application opEvents does support traps as inputs. you can find more info about it in its wiki section: https://community.opmantek.com/x/dIA5
Thats not the case here. We monitor some 20 nodes+ hadoop clusters, and the cluster management sends _only_ traps when a service falls down. We need
1. an archiving system for all traps for compliance reasons
2. the possibility to send out notifications to the certain groups
The use of the default snmptrapd is a good tip - damn, I never thought of this. Thought NMIS could handle this.
Powered by a free Atlassian Confluence Open Source Project License granted to Opmantek. Evaluate Confluence today.