Hex-STRING instead of DisplayString = trailing NULL

[Jonathan Tougas]

I'm looking for a way to deal with a situation where we end up with null characters trailing some label values: `count({ifDescr=~".*\x00"}) != 0`.

The source of the problem seems to be with `ifDescr` returned as a `Hex-String` instead of what the MIB says should be a `DisplayString`... for __some__ servers.

# Good,  99% of servers:
$ snmpget -v 2c -c $creds 172.21.34.10 1.3.6.1.2.1.2.2.1.2.1
iso.3.6.1.2.1.2.2.1.2.1 = STRING: "eth0"

# Bad, Cisco CVP tsk tsk tsk...
$ snmpget -v 2c -c $creds 172.20.220.88 1.3.6.1.2.1.2.2.1.2.1
iso.3.6.1.2.1.2.2.1.2.1 = Hex-STRING: 53 6F 66 74 77 61 72 65 20 4C 6F 6F 70 62 61 63
6B 20 49 6E 74 65 72 66 61 63 65 20 31 00

I'm currently planning on using `metric_relabel_configs` to cleanup the trailing nulls on these and other similar situations I uncovered.
Is there better way than mopping up like that? Perhaps snmp-exporter can deal with these and convert somehow? I'm not familiar enough with it to figure out if it can or not.

[Daniel Swarbrick]

You can override the type of an OID to force snmp_exporter to always handle it as e.g. DisplayString in your generator.yml, even when dodgy snmp engines return it as different type than what the MIB specifies. Read the "overrides" section of https://github.com/prometheus/snmp_exporter/tree/main/generator#file-format

However, that won't prevent the null bytes from still appearing in the label value, and the only way (currently) to do that is with metric relabelling as you have already discovered. You might want to subscribe to this github issue: https://github.com/prometheus/snmp_exporter/issues/615