SNMP Exporter - regex_extracts - not extracting value or not working as expected

27 views
Skip to first unread message

Alexander Wilke

unread,
Sep 5, 2025, 4:58:15 PM (3 days ago) Sep 5
to Prometheus Users
Hello,

I scrape a network device via SNMP and snmp_exporter. scrape in general works but some metrics needs some modification. This is not working.

I have this in my generator.yml:
modules:
  # Cubro Packetbroker
  cubroexa_mib_module:
    walk: [cubro]
    overrides:
      deviceUptime:
        ignore: true

      cpuUtilization:
        type: Float
        regex_extracts:
          Percent:
            - regex: '([0-9.]+)'
              value: '$1'
      memUtilization:
        type: Float
        regex_extracts:
          Percent:
            - regex: '([0-9.]+)'
              value: '$1'


I get this in my generated snmp.yml:

    - name: cpuUtilization
      oid: 1.3.6.1.4.1.32182.10.1.5
      type: Float
      help: This is cpu Utilization. - 1.3.6.1.4.1.32182.10.1.5
      regex_extracts:
        Percent:
        - value: $1
          regex: ^(?:([0-9.]+))$
    - name: memUtilization
      oid: 1.3.6.1.4.1.32182.10.1.7
      type: Float
      help: This is mem Utilization. - 1.3.6.1.4.1.32182.10.1.7
      regex_extracts:
        Percent:
        - value: $1
          regex: ^(?:([0-9.]+))$


This is from the MIB:
            cpuUtilization OBJECT-TYPE
                SYNTAX      DisplayString
                MAX-ACCESS  read-only
                STATUS      current
                DESCRIPTION "This is cpu Utilization."
                ::= { systemInfo 5 }
            memUtilization OBJECT-TYPE
                SYNTAX      DisplayString
                MAX-ACCESS  read-only
                STATUS      current
                DESCRIPTION "This is mem Utilization."
                ::= { systemInfo 7 }


without overrides the Prometheus Metric looks like this:

cpuUtilization{cpuUtilization="12.34%"} 1
cpuUtilization{cpuUtilization="9.4%"} 1
cpuUtilization{cpuUtilization="45.1%"} 1


My goal was to get this:

cpuUtilizationPercent{}  12.34
cpuUtilizationPercent{}  9.4
cpuUtilizationPercent{}  45.1


With the override enabled I get this:

cpuUtilization{}  0
cpuUtilization{}  0
cpuUtilization{}  0

Can someone please help me to understand what I did wrong and provide the correct generator.yml ?
I added "offset: 1.4" as a test but the metric value is still 0 and not 1.4

In addition ist it expected that the regex in the generator is different than in the snmp.yml afterwards?

Thank you very much in advance!

Brian Candler

unread,
Sep 6, 2025, 4:55:42 AM (3 days ago) Sep 6
to Prometheus Users
On Friday, 5 September 2025 at 21:58:15 UTC+1 Alexander Wilke wrote:

I get this in my generated snmp.yml:
...

          regex: ^(?:([0-9.]+))$

You can see that this resulting regex is anchored, so it will not match a value with a literal "%" at the end. So first thing to fix in your generator source is:

            - regex: '([0-9.]+)%'
or
            - regex: '([0-9.]+).*'

 Also, remove "type: Float", or set "type: DisplayString" - because the actual SNMP type is DisplayString, the regex needs to match against a string, and the final value is implicitly parsed as a float.

You can find working examples in the sample generator.yml:

    overrides:
      ...
      pduMainLoadAmp:
        regex_extracts:
          '':
            - regex: '(.*)(.)'
              value: '$1.$2'


    overrides:
      ddmStatusBiasCurrent:
        type: DisplayString
        regex_extracts:
          '':
            - regex: '^(\d+\.\d+).*'
              value: '$1'

Brian Candler

unread,
Sep 6, 2025, 4:59:57 AM (3 days ago) Sep 6
to Prometheus Users
> In addition ist it expected that the regex in the generator is different than in the snmp.yml afterwards?

To clarify this point:

^  = match at start of string only
(?:    )   = non-capturing group
$ = match at end of string only

Therefore, by wrapping your original regex with ^(?:   )$ it anchors it at the start and end of the string, without allowing any spurious characters before or after.  This is for consistency with how Prometheus handles regexs elsewhere, e.g. in label matchers, rewriting rules etc.
Reply all
Reply to author
Forward
0 new messages