Hi,
I configured an item to monitor incoming traffic on an interface of a Gigabit switch. I'm using the relevant SNMP HC counter (High Capacity, 64bit instead of 32bit, as advised for Gb) and I store the speed in bps because I find Bps for network traffic hard to work with.
Everything seems to work, the incoming values correspond with the values I read on the switch and the connected server, except, during a test where I pushed the interface to the limit (with iperf) and got sustained speed of +900Mbps, the item/graph suddenly reported a max speed of 3.03Gbps. Impossible of course on a 1Gbps interface
I have a theory about why this might be happening (and a possible fix), but first, the relevant settings, so you can all see what I'm talking about:
Type: SNMPv2 agent
SNMP OID: ifHCInOctets["index","ifDescr","A2"]
Type of information: Numeric (float)
Units: bps
Use custom multiplier: 8
Store value: Delta (speed per second)
So, SNMP reports the value as octets, Zabbix multiplies it by 8 to get bits and it stores the delta in bps. But... the value reported by the switch could need up to 64bits to represent in binary! If Zabbix multiplies it by 8 upon receiving, then it might get a number that is too huge for Zabbix to handle (needing more than 64bits to represent) and the result is an overflown value. Making the delta with the previous value very large of course. Could that be what happened during my test? What kind of type does Zabbix use to handle numbers internally? (I would doubt it has anything in place to handle numbers bigger than 64 bit?)
A possible fix for this might be to compute the delta first and then multiply it by the multiplier. I haven't really thought it through, but I think that in all cases this would result in the same value stored in the database, while avoiding intermediate results that are too huge to handle?
Of course, it also possible that the SNMP 64bit counter had just overflown (is that a proper verb btw?
) during the test... Which I'm totally ok with if Zabbix can't handle that particular situation (it would be hard to do so). But I'd like to rule out any other possibility.
I configured an item to monitor incoming traffic on an interface of a Gigabit switch. I'm using the relevant SNMP HC counter (High Capacity, 64bit instead of 32bit, as advised for Gb) and I store the speed in bps because I find Bps for network traffic hard to work with.
Everything seems to work, the incoming values correspond with the values I read on the switch and the connected server, except, during a test where I pushed the interface to the limit (with iperf) and got sustained speed of +900Mbps, the item/graph suddenly reported a max speed of 3.03Gbps. Impossible of course on a 1Gbps interface
I have a theory about why this might be happening (and a possible fix), but first, the relevant settings, so you can all see what I'm talking about:
Type: SNMPv2 agent
SNMP OID: ifHCInOctets["index","ifDescr","A2"]
Type of information: Numeric (float)
Units: bps
Use custom multiplier: 8
Store value: Delta (speed per second)
So, SNMP reports the value as octets, Zabbix multiplies it by 8 to get bits and it stores the delta in bps. But... the value reported by the switch could need up to 64bits to represent in binary! If Zabbix multiplies it by 8 upon receiving, then it might get a number that is too huge for Zabbix to handle (needing more than 64bits to represent) and the result is an overflown value. Making the delta with the previous value very large of course. Could that be what happened during my test? What kind of type does Zabbix use to handle numbers internally? (I would doubt it has anything in place to handle numbers bigger than 64 bit?)
A possible fix for this might be to compute the delta first and then multiply it by the multiplier. I haven't really thought it through, but I think that in all cases this would result in the same value stored in the database, while avoiding intermediate results that are too huge to handle?
Of course, it also possible that the SNMP 64bit counter had just overflown (is that a proper verb btw?
) during the test... Which I'm totally ok with if Zabbix can't handle that particular situation (it would be hard to do so). But I'd like to rule out any other possibility.