2
1
0

Hi,

we receive traps on our NMIS server, and those traps are logged in messages:

Feb  2 19:01:17 proxy01 snmptrapd[11081]: 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.38374.1.1.1.1, SNMPv2-SMI::enterprises.38374.1.1.2.1 = STRING: "b1c2b5bb-57d0-4f98-93b7-83be9589c7a5", SNMPv2-SMI::enterprises.38374.1.1.2.2 = Hex-STRING: 07 E0 02 02 13 00 18 00 2D FA 00 , SNMPv2-SMI::enterprises.38374.1.1.2.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.38374.1.1.2.4 = INTEGER: 1, SNMPv2-SMI::enterprises.38374.1.1.2.5 = INTEGER: 3, SNMPv2-SMI::enterprises.38374.1.1.2.6 = STRING: "https://test.test/eventRedirect/b1c2b5bb-57d0-4f98-93b7-83be9589c7a5", SNMPv2-SMI::enterprises.38374.1.1.2.8 = STRING: "solr", SNMPv2-SMI::enterprises.38374.1.1.2.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

 

and /etc/sysconfig/snmptrapd

#OPTIONS="-Lsd -p /var/run/snmptrapd.pid"
#OPTIONS="-Lo -Lf /var/log/snmptrapd.log -p /var/run/snmptrapd.pid
OPTIONS="-p /var/run/snmptrapd.pid -m ALL -M /usr/local/nmis8/mibs/traps"

 

Any idea or advises?

 

thanks,

 --alex

    CommentAdd your comment...

    2 answers

    1.  
      3
      2
      1

      Hi Alex,

      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 

      /etc/snmp/snmptrapd.conf

      this should look like this.

      "disableAuthorization yes
      traphandle 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

        CommentAdd your comment...
      1.  
        1
        0
        -1

        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. 

        thanks again,

         --alex

        1. Alexander Zangerl

          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

        2. evariant

          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.

        CommentAdd your comment...