Generator converts a Walk to a Get when it shouldn't

[lukeyeager]

snmp_exporter version

Current main branch (3f0e656)

What device/snmpwalk OID are you using?

The tree in question is enterprises.raritan.pdu2.measurements.measurementsOutlet.outletSensorMeasurementsTable (1.3.6.1.4.1.13742.6.5.4.3). When I use generator to walk the full tree it works fine.

The problem occurs when I try to use generator to walk only the subtree at measurementsOutletSensorValue.1.1 (that's pduId="1",outletId="1").

If this is a new device, please link to the MIB(s).

http://support.raritan.com/px2/version-2.4.1/mibs/pdu2-mib-020400-39592.txt (last updated 2012-09-15). If that link dies, I am seeing the same behavior with a much newer MIB, too (last updated 2019-05-20), but I can't find that one online. I expect the one linked in #835 would work, too.

What did you do that produced an error?

$ cat generator.yml
modules:
  raritan:
    walk:
      - 1.3.6.1.4.1.13742.6.5.4.3.1.4.1.1
    overrides:
      sensorType:
        type: EnumAsInfo

$ MIBSDIR=./mibs/ ./generator --fail-on-parse-errors generate

What did you expect to see?

I expected to see a single entry at .raritan.walk, and nothing at .raritan.get. I expected this partly because snmpwalk treats the given OID as a subtree:

$ snmpwalk -v 2c -c public -m PDU2-MIB "${agent}" 1.3.6.1.4.1.13742.6.5.4.3.1.4.1.1
PDU2-MIB::measurementsOutletSensorValue.1.1.rmsCurrent = Gauge32: 1283
PDU2-MIB::measurementsOutletSensorValue.1.1.rmsVoltage = Gauge32: 240
PDU2-MIB::measurementsOutletSensorValue.1.1.activePower = Gauge32: 294
PDU2-MIB::measurementsOutletSensorValue.1.1.apparentPower = Gauge32: 308
PDU2-MIB::measurementsOutletSensorValue.1.1.powerFactor = Gauge32: 95
PDU2-MIB::measurementsOutletSensorValue.1.1.activeEnergy = Gauge32: 5769495
PDU2-MIB::measurementsOutletSensorValue.1.1.onOff = Gauge32: 0
PDU2-MIB::measurementsOutletSensorValue.1.1.frequency = Gauge32: 600

What did you see instead?

$ head -n4 snmp.yml
# WARNING: This file was auto-generated using snmp_exporter generator, manual changes will be lost.
raritan:
  get:
  - 1.3.6.1.4.1.13742.6.5.4.3.1.4.1.9

And, when I try to use this snmp.yml in the exporter, it fails because this oid should be walked rather than get'd:

ts=2023-05-26T16:07:40.472Z caller=main.go:106 level=debug module=raritan target=myagent msg="Starting scrape"
ts=2023-05-26T16:07:40.473Z caller=collector.go:220 level=debug module=raritan target=myagent msg="Getting OIDs" oids=1
ts=2023-05-26T16:07:40.474Z caller=collector.go:230 level=debug module=raritan target=myagent msg="Get of OIDs completed" oids=1 duration_seconds=1.317168ms
ts=2023-05-26T16:07:40.474Z caller=collector.go:244 level=debug module=raritan target=myagent msg="OID not supported by target" oids=.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.1
ts=2023-05-26T16:07:40.474Z caller=main.go:117 level=debug module=raritan target=myagent msg="Finished scrape" duration_seconds=0.002738154

I presume that the bug lies somewhere near here: https://github.com/prometheus/snmp_exporter/blob/3f0e656c18/generator/tree.go#L292

[SuperQ]

I think that was one of those cases where the device and the MIB don't match. I'd have to dig through the issues, but I've seen that one before.

[lukeyeager]

Any idea how snmpwalk makes it work, then? Maybe they optimistically try a walk if a get fails?