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 On Sunday, April 30, 2023 at 11:25:25 AM UTC+2 Jonathan Tougas wrote: > 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. > -- You received this message because you are subscribed to the Google Groups "Prometheus Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/398861ab-75a7-4e46-800c-21339b038924n%40googlegroups.com.
