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. On Fri, Mar 28, 2025 at 2:00 AM Elliott Balsley <[email protected]> wrote: > 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' > > On Thu, Mar 27, 2025 at 10:30 AM Ben Kochie <[email protected]> wrote: > >> 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. >> >> On Thu, Mar 27, 2025 at 6:16 PM Elliott Balsley <[email protected]> >> wrote: >> >>> 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... >>> >>> On Thu, Mar 27, 2025 at 3:19 AM Ben Kochie <[email protected]> wrote: >>> >>>> Oh yea, that should be fixed. Missed when refactoring those modules. >>>> >>>> On Thu, Mar 27, 2025 at 11:09 AM 'Brian Candler' via Prometheus Users < >>>> [email protected]> wrote: >>>> >>>>> Shouldn't that be under the "hrDevice" MIB rather than the "mikrotik" >>>>> MIB? >>>>> >>>>> On Thursday, 27 March 2025 at 09:24:56 UTC Ben Kochie wrote: >>>>> >>>>>> 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 >>>>>> >>>>>> On Thu, Mar 27, 2025 at 1:20 AM 'Elliott Balsley' via Prometheus >>>>>> Users <[email protected]> wrote: >>>>>> >>>>>>> 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) >>>>>>> >>>>>>> -- >>>>>>> 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 visit >>>>>>> https://groups.google.com/d/msgid/prometheus-users/5c5cc8e4-2353-44b4-b41c-05208835800fn%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/prometheus-users/5c5cc8e4-2353-44b4-b41c-05208835800fn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>> 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 visit >>>>> https://groups.google.com/d/msgid/prometheus-users/4e5ce219-b8ef-4213-972a-4bcccf26feacn%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/prometheus-users/4e5ce219-b8ef-4213-972a-4bcccf26feacn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> 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 >>>> [email protected]. >>>> 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 >>>> <https://groups.google.com/d/msgid/prometheus-users/CABbyFmp%3DJVwZ%3DZaS%2BY-Ww%2BKjT5f%3DRR%3DU9T0kXqV6Xks%3Da96J5A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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 visit https://groups.google.com/d/msgid/prometheus-users/CABbyFmrs9UKfCE%2BZL-bjQGYzkOa4HnYa7-dL6_FQ-vntYRav0w%40mail.gmail.com.
