Force returned values as signed int32? about snmpcollector HOT 4 CLOSED

Hello @matejv , I've reviewed the RFC where is defined this snmp type here ( https://datatracker.ietf.org/doc/html/rfc2578#section-7.1.7)

7.1.7.  Gauge32

   The Gauge32 type represents a non-negative integer, which may
   increase or decrease, but shall never exceed a maximum value, nor
   fall below a minimum value.  The maximum value can not be greater
   than 2^32-1 (4294967295 decimal), and the minimum value can not be
   smaller than 0.  The value of a Gauge32 has its maximum value
   whenever the information being modeled is greater than or equal to
   its maximum value, and has its minimum value whenever the information
   being modeled is smaller than or equal to its minimum value.  If the
   information being modeled subsequently decreases below (increases
   above) the maximum (minimum) value, the Gauge32 also decreases
   (increases).  (Note that despite of the use of the term "latched" in
   the original definition of this type, it does not become "stuck" at
   its maximum or minimum value.)

As you can read 4294967295 is 2^32-1 and a valid value , you should also note that Gauge32 represents a non-negative integer . ( 32 bits) so it seems like it can never be -1

regarding this information snmpcollector seems to be returning the correct value.

from snmpcollector.

Thank you @toni-moreno

I understand this. The problem is that the SNMP device I'm polling is returning data type wrong. It should not be Gauge32, but Integer32 (signed, to allow for negative values).

I'm unlikely to be able to get the vendor to fix their device unfortunately. So I thought SNMPcollector would be able to:

• ignore the snmp type sent by the device and just take the raw bits of the value
• interpret those raw bits as Integer32 type (that is a signed int, allowing negative values)

I was under the impression that setting DataSrcType to Integer32 would achieve this.

If may I ask - what do the different (SNMP SMI Type) *Integer* options actually do? If the value data type is determined by the snmp type sent by device. It doesn't seem to make any difference of I choose here Integer32 or UInteger32, if device sends Gauge32. Correct?

from snmpcollector.

Hello again @matejv , sorry for the late response.

Unfortunately for you snmpcollector doesn't force sign or size conversion , it handle data with its original type always .

you can see code yourself.

and here how to decode data.

and not sure if this policy should change in the future, because this would be a big breaking change.

instead you could create a new STRING EVAL field to force yourself conversion from the original , by only creating a evaluation expression like my_orig_field > 4294967295 ? ( 4294967295 - my_orig_field )

https://github.com/toni-moreno/snmpcollector/wiki/Component:-SNMP-Metrics#about-stringeval-metrics

Of course you don't need to send my_orig_field to the backend DB , you can choose not to send in the measurement configuration , choosing "never report" my_orig_field.

Let me know if this STRING EVAL new field would resolve your issue.

from snmpcollector.

I was looking at the code and I suspected as much, but I'm not really used to golang so I wanted to make sure.

I agree that changing current behavior might break stuff for many users, so best not to change it. In the end the fault lies in the buggy device I am using.

I did end up using your STRINGEVAL suggestion. I've done some maths and came up with a bit different formula:

(my_orig_field > 2147483647) ? (my_orig_field - 4294967294) : my_orig_field

2147483647 is the largest possible 32bit signed int. If we know we are operating with signed numbers, then any value larger than that must be negative. I've done some tests and checked results via this form also. If anyone else in the future will stumble across this issue.

Thany ou very much for your help and for creating this amazing tool. Best SNMP poller I've ever used!

from snmpcollector.