generator overrides ignore "version" in synology MIB

[tvojacek]

Host operating system: output of uname -a

Linux merkur 5.8.0-50-generic #56-Ubuntu SMP Mon Apr 12 17:18:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

https://github.com/prometheus/snmp_exporter.git

generator does not have --version flag commit fd422f33391cadee34ca76ed0988c2c6491a8261

What did you do that produced an error?

Downloaded default MIBs: git clone https://github.com/prometheus/snmp_exporter.git cd snmp_exporter/generator make mibs Generated run generator using default generator.yml make generator ./generator generate cat snmp.yml |grep -B 1 1.3.6.1.4.1.6574.1.5.3

What did you expect to see?

in snmp.yml

• name: version oid: 1.3.6.1.4.1.6574.1.5.3 type: DisplayString help: The version of this DSM - 1.3.6.1.4.1.6574.1.5.3

What did you see instead?

• name: version oid: 1.3.6.1.4.1.6574.1.5.3 type: OctetString help: The version of this DSM - 1.3.6.1.4.1.6574.1.5.3

if I edit SYNOLOGY-SYSTEM-MIB.txt change name from version ->versionDSM and in generator.yml version->versionDSM problem is fixed and overrides work as expected.

[SuperQ]

Yes, because version is duplicated in multiple MIBs, the generator is not able to match based on names for lookups correctly.

The lookups currently don't support numeric OIDs for matching.

The only way to fix this is to drop the kemp_loadmaster config/MIBs from your setup.

[tvojacek]

I understand. It is unfortunate that even default snmp.yml is broken. Can we add some info in to readme.md?

[SuperQ]

IMO, we should come up with a way to fix this bug.

[xkilian]

You mean lookups supporting OIDs, or the fact there are collisions in the current generator.yml.

We simply should not have a single generator file with everything combined, the more people add to it the more collisions there will be. Once we merge the generator file management and add support for collector to read multiple config files, this problem will go away. Then each device type can have its own generator/mibsdir/snmp.yml file. No more collisions. :-)

Then filtering... Then relabelling in collector... Rule the world.. humm. yeah!

[SuperQ]

@xkilian Several things would help

• Support OIDs for lookups.
• Splitting the generator.yml so we can run multiple passes with different MIBDIRS vars with different MIB subsets
• Possibly filtering MIB definitions at the module level.

There's a few ways we can go with this.

There are a bunch of non-obvious MIB conflicts that we need to deal with, so trying to smash everything into one MIBDIRS path is not sustainable. We need to have a composition of different MIBs in different dirs. I know @RichiH was looking into the legality of inline vendoring MIBs like other projects do.

[tvojacek]

You can close issue if needed.