Allow for extracting numeric time series from string values

[brian-brazil]

Some MIBs aren't quite right, particularly around types. Figure out what's a sane config syntax to allow for per-module overrides of bits of MIBs.

[brian-brazil]

Augments is the other one we've seen, where a MIB didn't specify it itself.

[SuperQ]

Here's a first pass at a proposal config:

modules:
  example:
    walk: [sysUpTime, interfaces, ifXTable, etc]
    lookups:
      - old_index: ifIndex
        new_index: ifDescr
    string_regexps:
      - oid: stringPiOID
        regex: Pi is (\d+\.\d+)
    excludes:
      - uselessOID
      - otherUselessOID

TODO: configurations for augments and syntax changes.

[brian-brazil]

This is presuming that we'd only want to extract one number from a string, and won't have to do anything fancy like dates. I think this should be oid focused, as I forsee multiple interacting options.

[fjaeckel]

The value I see here is to extract signed floats out of SNMP result data, one of the examples I have is optical monitoring data provided by Brocade NetIron (CER/CES/MLX/XMR series) that are widely used in the internet industry where the temperature, Rx/Tx light levels and power of a SFP (or pluggable module in general) is being returned as a string, as brocade thinks its important to say what normal and whats not, an example:

$ snmpwalk -v2c -c community hostname 1.3.6.1.4.1.1991.1.1.3.3.10
iso.3.6.1.4.1.1991.1.1.3.3.10.1.2.65.1 = STRING: "   50.0703 C: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.2.65.2 = STRING: "   50.0625 C: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.2.65.3 = STRING: "   50.0039 C: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.2.65.4 = STRING: "   50.0234 C: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.2.66.1 = STRING: "     NOT SUPPORTED     "
iso.3.6.1.4.1.1991.1.1.3.3.10.1.3.65.1 = STRING: " -000.0493 dBm: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.3.65.2 = STRING: "  000.0285 dBm: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.3.65.3 = STRING: "  000.3414 dBm: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.3.65.4 = STRING: " -000.0091 dBm: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.3.66.1 = STRING: "     NOT SUPPORTED     "
iso.3.6.1.4.1.1991.1.1.3.3.10.1.4.65.1 = STRING: " -003.7355 dBm: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.4.65.2 = STRING: " -003.5134 dBm: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.4.65.3 = STRING: " -003.2688 dBm: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.4.65.4 = STRING: " -003.7509 dBm: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.4.66.1 = STRING: "     NOT SUPPORTED     "
iso.3.6.1.4.1.1991.1.1.3.3.10.1.5.65.1 = STRING: "   55.004 mA: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.5.65.2 = STRING: "   55.004 mA: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.5.65.3 = STRING: "   55.004 mA: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.5.65.4 = STRING: "   44.970 mA: Normal"
iso.3.6.1.4.1.1991.1.1.3.3.10.1.5.66.1 = STRING: "     NOT SUPPORTED     "```

[SuperQ]

It looks like we need to support matching with a replacement, so we can turn "NOT SUPPORTED" into a NaN.

[brian-brazil]

thinks its important to say what normal and whats not

That should have used another object.

It looks like we need to support matching with a replacement, so we can turn "NOT SUPPORTED" into a NaN.

NaN doesn't make sense here mathematically, in this case the correct answer is to exclude that object from the output.

[fjaeckel]

I agree is that it should be excluded instead of rendering a NaN.

[SuperQ]

Ok, so for this case, we would have no regexp match, which would result in a dropped metric. Does that sound like the right thing to do? Then we don't need to worry about the replacement.

[brian-brazil]

This sounds like we might end up with something similar to the jmx exporter, where you can have multiple rules and the first match wins. Do we have an idea of how complex these can get?

[SuperQ]

For SNMP, they don't seem that complex. The 99% use case from talking to other network admins is that extracting a number from a string is all we need.

[brian-brazil]

The above example also has a string that we'd probably want to extract as a bool.

[RichiH]

Yes, the string has two relevant pieces of information that should be extracted. Pluggables not having (supported) DDM is also useful information, but should probably be dumped into an `_info` metric; that's what we do with our self-baked ones.

[RichiH]

Or it could be split out into a different bool.

[brian-brazil]

Thinking a bit, I'm imagining a config structure like:

Temp:
  - regex: '([0-9.]+) C.*'
    value: '$1'   # Converted to float, like jmx_exporter
Status:
  - regex: '.*Normal'
    value: '1'
  - regex: '.*'
    value: '0'

Where Temp/Status would be (possibly empty) suffixes on the object name.

[SuperQ]

I like the idea of multiple regexps, but I think it would be better to match on explicit OIDs.

[brian-brazil]

That'd be within something like :

overrides:
   '0.1.2.3.4':
     ValueExtract: .....

[brian-brazil]

This issue got derailed, so opening a new issue for the original issue.

[SuperQ]

Ok, here's a full concrete example:

modules:
  foundry_optics:
    walk: [SnIfOpticalLaneMonitoringEntry]
    string_regexps:
      snIfOpticalLaneMonitoringTemperature:
        Temp:
          - regex: '([0-9.]+) C.*'
            # value: '$1' <- Default value
        Status:
          - regex: '.*Normal'
            value: '1'
          - regex: '.*'
            value: '0'
    excludes:
      - snIfOpticalLaneMonitoringTemperature

This would result in the original OID metric being dropped, as we don't want to include it in the output.

New metrics would be created based on the regexps:

snIfOpticalLaneMonitoringTemperature_Temp{ifIndex="65",snIfOpticalLaneMonitoringLane="1"} 50.0703
snIfOpticalLaneMonitoringTemperature_Status{ifIndex="65",snIfOpticalLaneMonitoringLane="1"} 1
snIfOpticalLaneMonitoringTemperature_Status{ifIndex="66",snIfOpticalLaneMonitoringLane="1"} 0

So, no regexp match with results in no metric output. Regexps are first match.

[brian-brazil]

The only real change you're proposing there is a default on the value (which makes sense) and not excluding the object by default (which I don't think makes sense, you'll always want it excluded).

As indicated elsewhere I want all of the overrides for an object in once place, so you don't have to look all over the file to find the interactions.

[SuperQ]

Sure, defaulting excluding is I was thinking about, but hadn't decided on. I will change it.

[SuperQ]

Ok, here's an override-OID oriented format:

modules:
  foundry_optics:
    walk: [SnIfOpticalLaneMonitoringEntry]
    overrides:
      snIfOpticalLaneMonitoringTemperature:
        string_metrics:
          Temp:
            - regex: '([0-9.]+) C.*'
              # value: '$1' <- Default value
          Status:
            - regex: '.*Normal'
              value: '1'
            - regex: '.*'
              value: '0'
      someUselessMetric:
        exclude: true
      otherUselessMetric: {exclude: true} # alternate format.

The override string_metrics implies exclude.

[kovalev94]

Is there any way to drop original metric name, instead to concatenate overridden metric name with original metric name?