PDA

View Full Version : beta5 reports traffic incorrectly in some cases


bbrendon
02-01-2006, 22:57
After upgrading from beta2 to beta5, I have one SNMP 1 (tried 2 as well) item that doesn't work.

Type: I tried it as numberc 64 and float.
Store value: delta (speed per sec)
No multipliers are used
Units are set to "bps"

Snmpget reports it as:
IF-MIB::ifOutOctets.16777219 = Counter32: 3114709372

Zabbix reports: 3689348614.51 Gbps

I tried deleting and recreating the item, no luck. All the other traffic stats for this host are correct except for Outgoing traffic on this one particular interface.

chocho63
06-01-2006, 12:47
I've got the same problem with beta5. It worked fine with type 'numeric' on beta2, but values are strange with 'numeric 64 bits' in beta5.

herr_bpl
06-01-2006, 18:10
Yes, I can confirm it too, i even cleaned out database and no luck, still those gigabytes there...

herr_bpl
06-01-2006, 18:22
I guess it is because counter on port is something over 2000000000 ...
[root@hermes root]# snmpwalk -v 1 -c public 10.200.200.17 .1.3.6.1.2.1.2.2.1.16.3
IF-MIB::ifOutOctets.3 = Counter32: 3220320828

But value in database is something like 307445717877260288.000000

Below is a sniff from debug
-------------------------------------------------------------------
005878:20060106:181430 SNMP [a932tH5q@10.200.200.17:161:0]
005878:20060106:181430 OID [.1.3.6.1.2.1.2.2.1.16.3]
005878:20060106:181430 In get_value_SNMP() 0.2
005878:20060106:181430 In get_value_SNMP() 0.3
005878:20060106:181430 Status send [0]
005878:20060106:181430 In get_value_SNMP() 0.4
005878:20060106:181430 In get_value_SNMP() 1
005878:20060106:181430 In get_value_SNMP() 2
005878:20060106:181430 AV loop()
005878:20060106:181430 OID [.1.3.6.1.2.1.2.2.1.16.3] Type [65] Value[18446744072684625374]
005878:20060106:181430 In process_new_value()
005878:20060106:181430 In add_history(ifOutOctets3,,3,1)
005878:20060106:181430 In add_history(17914,UINT64:18446744072684625374)
005878:20060106:181430 ITEM_STORE_SPEED_PER_SECOND(ifOutOctets3,999999999 999.999878,0.000000)


Siim

razorgt
10-01-2006, 08:00
I have the same problem, only on some routers for some reason. Any thoughts as to a fix anyone?

Glenn

Alexei
10-01-2006, 16:13
I did lots of testing today. ZABBIX results are perfectly in sync with results of snmpget/snmpwalk here (the latest Ubuntu, SNMP v1).

I believe that the huge values are related to a bug (?) in net-snmp libraries.

Are you on 32 or 64bit systems?

chocho63
11-01-2006, 11:37
I'm on a 32 bits Intel System

Alexei
11-01-2006, 20:56
Please can you try the latest zabbix_server/poller/checks_snmp.c from CVS. Hopefully it fixes this problem.

Note that this file will generate some extra debug files.

chocho63
12-01-2006, 15:54
That works correctly with this patch.

Alexei
12-01-2006, 16:01
Excellent! Please could you post extract from log file which has different results for UI64 and ULONG? Thanks.

chocho63
12-01-2006, 16:16
Here is a sample of my log file :

001513:20060112:161301 OID [IF-MIB::ifOutOctets.2] Type [65] UI64[18446744072748322272]
001513:20060112:161301 OID [IF-MIB::ifOutOctets.2] Type [65] ULONG[3333737952]
001513:20060112:161301 OID [IF-MIB::ifOutOctets.2] Type [65] UI64[746277083]
001513:20060112:161301 OID [IF-MIB::ifOutOctets.2] Type [65] ULONG[746277083]
001513:20060112:161301 OID [IF-MIB::ifOutOctets.2] Type [65] UI64[18446744073122259149]
001513:20060112:161301 OID [IF-MIB::ifOutOctets.2] Type [65] ULONG[3707674829]
001513:20060112:161301 OID [IF-MIB::ifOutOctets.2] Type [65] UI64[18446744072054222590]
001513:20060112:161301 OID [IF-MIB::ifOutOctets.2] Type [65] ULONG[2639638270]


001513:20060112:161302 OID [IF-MIB::ifInOctets.2] Type [65] UI64[18446744072921099701]
001513:20060112:161302 OID [IF-MIB::ifInOctets.2] Type [65] ULONG[3506515381]
001513:20060112:161302 OID [IF-MIB::ifInOctets.2] Type [65] UI64[746845043]
001513:20060112:161302 OID [IF-MIB::ifInOctets.2] Type [65] ULONG[746845043]

Alexei
12-01-2006, 17:06
Thanks. Everything seems to be fine. You may use the very latest checks_snmp.c to get rid of the messages. Thanks again!