prometheus / snmp_exporter

SNMP Exporter for Prometheus
Apache License 2.0
1.72k stars 631 forks source link

generator overrides ignore "version" in synology MIB #650

Open tvojacek opened 3 years ago

tvojacek commented 3 years ago

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

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 commented 3 years ago

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 commented 3 years ago

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

SuperQ commented 3 years ago

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

xkilian commented 3 years ago

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 commented 3 years ago

@xkilian Several things would help

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 commented 3 years ago

You can close issue if needed.