How to handle SNMP TruthValue type?

[Elliott Balsley]

Some SNMP devices return boolean values as a TruthValue textual convention, where 1 means true and 2 means false.  This is confusing to me, because with most other devices I usually use 0 to mean false.  I tried using regex to change 2 to 0 (shown below) but this didn't work.  How do other folks handle TruthValues with snmp-exporter?

      cdcp4415RgbIlsInstalled:
        regex_extracts:
          '':
            - regex: '2'
              value: 1

This is how the value looks with net-snmp:

% snmpwalk -v2c -c public 10.37.154.146 CDS-PJTR-CP4415RGB::cdcp4415RgbIlsInstalled

CDS-PJTR-CP4415RGB::cdcp4415RgbIlsInstalled.0 = INTEGER: true(1)

[Brian Candler]

On Thursday, 27 March 2025 at 00:20:02 UTC Elliott Balsley wrote:

How do other folks handle TruthValues with snmp-exporter?

For all the sample MIBs in generator.yml, AFAICS they retain the values 1 and 2 as-is. (For example, see ifConnectorPresent and ifPromiscuousMode in IF-MIB)

Personally, I would be inclined not to fight it, and write PromQL expressions appropriately:

# With these filters you can quietly forget that false is 2 rather than 0

ifConnectorPresent == 1

ifConnectorPresent != 1

# If you really need a 0 or 1 value

(ifConnectorPresent == bool 1)

(2 - ifConnectorPresent)

You can't directly use a 0/1 value as a "boolean" in PromQL anyway, except perhaps when multiplying by another value.

[Ben Kochie]

I added some numeric features recently for this specific case.

Here's an example:

https://github.com/prometheus/snmp_exporter/blob/15269c2a5788db885178a8f98de28e7ce10ed0a9/generator/generator.yml#L848-L851

--
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 prometheus-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/prometheus-users/5c5cc8e4-2353-44b4-b41c-05208835800fn%40googlegroups.com.

[Brian Candler]

Shouldn't that be under the "hrDevice" MIB rather than the "mikrotik" MIB?

[Ben Kochie]

Oh yea, that should be fixed. Missed when refactoring those modules.

To view this discussion visit https://groups.google.com/d/msgid/prometheus-users/4e5ce219-b8ef-4213-972a-4bcccf26feacn%40googlegroups.com.

[Elliott Balsley]

That's a clever solution, thanks!

I often use value mappings in Grafana to turn bool values into words like off/on or muted/unmuted, etc., to make it look nice on a state timeline.  If there's a mix of these with other "standard" 0/1 values in the same dashboard it's hard to remember which one's which.  In general, I feel like SNMP data is terribly messy, (at least from the obscure A/V devices I tend to work with), so I want to standardize it as much as possible before recording it.

For that same reason, I'm debating how much to rename things from the MIB.  I'm still on the fence... The metric names from the MIB often don't make much sense to someone who's not an expert on that piece of gear, so I would like to rename them, also adding units (like _percent), and standardizing on snake_case instead of CamelCase.  I would have to include the original name in the help text so you can reference the MIB in case of any questions in the future.  But this takes a lot of time to customize each module...

You received this message because you are subscribed to a topic in the Google Groups "Prometheus Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/prometheus-users/LS3HL_Z2KkA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to prometheus-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/prometheus-users/CABbyFmp%3DJVwZ%3DZaS%2BY-Ww%2BKjT5f%3DRR%3DU9T0kXqV6Xks%3Da96J5A%40mail.gmail.com.

[Ben Kochie]

Metrics are always a mess. ^.^

It's a constant toil to improve metrics on every system.

But, yea, SNMP tends to suffer from more mess due to the complicated nature and lack of good, modern, implementation guides out there.

[Elliott Balsley]

Ben, what do you think about adding that scale+offset logic into the exporter so it happens automatically for TruthValue types?  It could go behind a flag to avoid breaking existing code.

One more question — Is there a nicer way to convert strings to integers?  I thought "type: gauge" would work but it doesn't.  I can do it with regex, but this code is not very readable:

      cdcp4415RgbLiteLocActualBrightness:
        regex_extracts:
          '':
            - regex: '(.*)'
              value: '$1'

[Ben Kochie]

I think adding exporter support for TruthValue textual convention would be nice. A feature flag is OK, but I prefer to enable breaking changes by default. It just stalls the progress of new features if we make every new change opt-in rather than opt-out.

For your second question, I'm not sure.