Nagios Support Forum

I have some Tripplite PDUs and Falcon UPSs that I am trying to monitor via SNMP traps across our system.

Following this document, I loaded the mib to my Nagios server:
Then I ran addmib as follows (this is the second time as I was checking everything):
Followed by a restart of the snmptt service:
I tried searching the forum for an answser and came across this thread. I tried following the suggested steps in there, which were identical to the document, to no avail.

I still have the following showing up in /var/log/snmptt/snmpttunknown.log:
When I check this device via the GUI, I see the following:
I get this even when the UPS has gone offline. It still tells me that the Traps are OK.

I'm at a loss as to other places/things to check?

Have you taken a look at the following?:

http://support.nagios.com/forum/viewtop ... nknown.log

slansing wrote:Have you taken a look at the following?:

http://support.nagios.com/forum/viewtop ... nknown.log

I did, as in my post:

I tried searching the forum for an answser and came across this thread. I tried following the suggested steps in there, which were identical to the document, to no avail.

On my system, when I get an unknown trap, I check the snmptt.conf file to make sure the OID is being handled. In your example I'd search for
.1.3.6.1.4.1.850.100.2.0.4 in snmptt.conf for an EVENT line with that exact OID.
(NOTE: check snmptt.conf or whatever file your trap definations were saved to, I think nagios stuffs the translated mibs in snmptt.conf by default)

Here's a random entry from my snmptt.conf:

EVENT topologyChange .1.3.6.1.2.1.17.0.2 "Status Events" Normal
FORMAT A topologyChange trap is sent by a bridge when any of $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "A topologyChange trap is sent by a bridge when any of $*"
SDESC
A topologyChange trap is sent by a bridge when any of
its configured ports transitions from the Learning state
to the Forwarding state, or from the Forwarding state to
the Blocking state. The trap is not sent if a newRoot
trap is sent for the same transition. Implementation of
this trap is optional.
Variables:
EDESC

Also, I'd make sure that the snmptt.conf file is being loaded (or whatever file contains the trap definition):
I don't like putting everything in one file so I tend to add mibs by hand to snmptt.ini:
[TrapFiles]
# A list of snmptt.conf files (this is NOT the snmptrapd.conf file). The COMPLETE path
# and filename. Ex: '/etc/snmp/snmptt.conf'
#/etc/snmp/snmptt.conf.files/ROOMALERT24E-MIB.conf
snmptt_conf_files = <<END
/etc/snmp/snmptt.conf
/etc/snmp/snmptt.conf.files/CMC-TC-MIB.conf
/etc/snmp/snmptt.conf.files/DFM-MIB.conf
/etc/snmp/snmptt.conf.files/iDRAC-MIB.conf
/etc/snmp/snmptt.conf.files/SANSCREEN-MIB.conf
/etc/snmp/snmptt.conf.files/SUN-HW-TRAP-MIB.conf
/etc/snmp/snmptt.conf.files/SUN-ILOM-PET-MIB.conf
END

I also run /etc/init.d/snmptt restart
after changing the snmptt.ini file to pick up the changes.

Almost forgot. This line in snmptrapd.conf sends the traps to snmptt:
traphandle default /usr/local/sbin/snmptt

jwelch -

Thanks for your response! I did as suggested and I searched my snmptt.conf file for .1.3.6.1.4.1.850.100.2.0.4 and the pattern was not found.

When I search the MIB files on the disk for the UPS that's throwing the traps (from the CD directly), I don't find that trap.

I'm not sure what this means, other than maybe I'm using a different version of MIBs than what the UPS its self is using to generate traps?

yeah, trying to pull OIDs out of the mib file is a PITA. Doable, but still painful. It's much easier to run the mib file through snmpttconvertmib, then look for the OID you want in the output file. (And if it's all good, you can put the file somewhere and add it to snmptt.ini manually or add the ones you care about to snmptt.conf.)
If you have two different versions of TRIPPLITE-MIB.txt, you may need to clean out the existing entries in snmptt.conf manually, then reload the correct file.

This is the command I run to input the mib file (TRIPPLITE-MIB.txt for example) and spit out the traps to TRIPPLITE-MIB.conf. The parms are to set the traphandler and format the info the traphandler will use to send the info to nagios. (Assuming that TRIPPLITE-MIB.txt is in your current directory. If not,
add the appropriate path.)

/usr/local/bin/snmpttconvertmib --in=TRIPPLITE-MIB.txt --out=TRIPPLITE-MIB.conf --exec='/usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*"'


BTW, the snmpttconvertmib variable definitions are here:
http://snmptt.sourceforge.net/docs/snmp ... stitutions

jbennett wrote: I'm not sure what this means, other than maybe I'm using a different version of MIBs than what the UPS its self is using to generate traps?

This certainly is possible. I would check with the manufacturer to see if the have multiple MIBs for different versions

I suppose my next question is this:

I have 185 UPSs and 189 PDUs that I have traps configured for in Nagios.

Last night we had a pretty severe storm roll through with very high winds.

Some of our locations are without power now, yet the trap check says OK. I have some UPSs that are on battery back-up, yet the traps say OK.

It seems like the traps aren't populating in Nagios?

an example:

In my snmptt.log, I have the following as the last entry in the log:
I check Nagios for this host, and I see the attached details.

Am I wrong in assuming that the Traps should be reporting that the UPS has switched to battery backup power?

<I missed the 'Trap Reset' part of the status message and the slightly later timestamp the first time I looked at your screenshot.>

Looking at the text of the trap in your logfile, it does say that the ups has switched to battery backup power, but the timestamp of the GUI is a few minutes later. Do you have something that resets the trap status? (freshness check, maybe?) If you disable that, then the trap should remain in the CRITICAL state (if u update ur snmptt.conf entry) until you submit a manual check result to clear it.

"Thu Dec 20 14:39:54 2012 .1.3.6.1.4.1.2468.1.2.1.2.0.8 Normal "Status Events" xxx.xxx.xxx.xxx - WARNING: The UPS has switched to battery backup power. 100 1104 14793 The UPS has switched to battery backup power"

I assume you expect the entry to be red with a status of critical. In this case, it looks like the translated trap entry in snmpt.conf (or wherever it is) was assigned the severity 'normal', which nagios translates to 'OK'. If this trap is only called when the unit goes on battery, you can change the severity in the snmptt.conf entry to match what you want it to show up as in nagios. This is from the Adjusting Trap Severity section of "Integrating_SNMP_Traps_With_XI.pdf":

---
Adjusting Trap Severity
Edit the Trap Translator configuration file located at /etc/snmp/snmptt.conf and alter the severity of each EVENT to match your personal
needs. The default severity level is “Normal” (equivalent to an “Ok” state in Nagios). You may want to change some events to have a
“Warning” or “Critical” severity level (equivalent to “Warning” and “Critical” states in Nagios, respectively). A “<NA>” severity level maps
to an “Unknown” state in Nagios.
---