Yes, it exists and it is being populated by a number of unknown traps from a specific PDU that we only have a handfull of. I am trying to get the majority of our PDUs and UPSs working on traps before moving onto this handfull. (These traps that are showing up in snmpttunknown are using the standard community string of 'public' and there doesn't appear to be a way to change it on the PDUs, I haven't dove off into this issue as it's secondary at this point).nscott wrote: It did however say that it had found unknown traps as well, which may very well be what is happening to your traps. Does the /var/log/snmptt/snmpttunknown.log file exist? I see you and Scott had spoken about it before, but that was never specified whether or not that file existed and when its last modification date was. Can you see if it exists, when was it created? Then what exists inside of it? If the OIDs that are getting relegated to the unknown log are the traps you want to have Nagios use, we'll have to add those to an snmptt.conf file.
However, if I go back to the snmpttunknown.log.1 file I do see some traps from a unit which should be configured correctly:
This is what is showing in the log:
Code: Select all
Sun Mar 31 04:22:04 2013: Unknown trap (.1.3.6.1.4.1.2468.1.2.1.2) received from xxx.xxx.xxx.xxx at:
Value 0: xxx.xxx.xxx.xxx
Value 1: xxx.xxx.xxx.xxx
Value 2: 47:12:37:36.93
Value 3: .1.3.6.1.4.1.2468.1.2.1.2
Value 4: xxx.xxx.xxx.xxx
Value 5:
Value 6:
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.4.1.2468.1.2.1.1.2.4.0=100
Ent Value 1: .1.3.6.1.4.1.2468.1.2.1.1.2.5.0=1080
Ent Value 2: .1.3.6.1.4.1.2468.1.2.1.1.2.2.0=0
Ent Value 3: .1.3.6.1.4.1.2468.1.2.1.2=The UPS has switched to battery backup power
Code: Select all
MIB: USHA-MIB (file:./USHAP.MIB) converted on Tue Jan 29 15:05:39 2013 using snmpttconvertmib v1.3
#
#
#
EVENT ushaPowerRestored .1.3.6.1.4.1.2468.1.2.1.2.0.1 "Status Events" Normal
FORMAT INFORMATION: Utility power has been restored. $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "INFORMATION: Utility power has been restored. $*"
SDESC
INFORMATION: Utility power has been restored.
Variables:
EDESC
#
#
#
EVENT ushaPowerFail .1.3.6.1.4.1.2468.1.2.1.2.0.2 "Status Events" Critical
FORMAT WARNING: Utility power not available. $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "WARNING: Utility power not available. $*"
SDESC
WARNING: Utility power not available.
Variables:
EDESC
#
#
#
EVENT ushaReturnFromLowBattery .1.3.6.1.4.1.2468.1.2.1.2.0.3 "Status Events" Normal
FORMAT INFORMATION: The UPS has returned from a low battery $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "INFORMATION: The UPS has returned from a low battery $*"
SDESC
INFORMATION: The UPS has returned from a low battery
condition.
Variables:
EDESC
#
#
#
EVENT ushaLowBattery .1.3.6.1.4.1.2468.1.2.1.2.0.4 "Status Events" Warning
FORMAT SEVERE: The UPS batteries are low and will soon be exhausted. $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "SEVERE: The UPS batteries are low and will soon be exhausted. $*"
SDESC
SEVERE: The UPS batteries are low and will soon be exhausted.
If utility power is not restored the UPS will put itself
to 'sleep' and immediately cut power to the load.
Variables:
EDESC
#
#
#
When I compare the two OIDs (from unknown.log and from snmptt.conf), it appears as if the unknown.log is either truncating the OID or the UPS simply isn't sending the whole OID?
Would this cause the problem? I will have to dig through the others to see if the same is happening for the other PDUs that we are running.
