Nice, that sounds like it might fix it. I’m running the docker image prom/snmp-agent:main which was published 2 days ago. But I don’t know which commit that refers to.
I read the description of this new patch: first attempt to match the lookup node so that the OID matches that of the metric in all but the last branch. In case no match is found, it reverts to the old behavior. Would it be better to attempt this recursively, so if it fails to find the name in the last branch, then it looks one branch up, and so on? I’m curious, if it were implemented that way, would there ever be a need to specify multiple MIBDIRS? On Mon, Nov 20, 2023 at 21:43 Ben Kochie <sup...@gmail.com> wrote: > Have you updated your generator recently? We added a patch that tries to > use OIDs closer to the original index first. > > See: https://github.com/prometheus/snmp_exporter/pull/828 > > There's also now support for multiple files in the exporter, as well as > different input filenames in the generator. You could do something like > this: > > MIBDIRS="mibs/base:mibs/vendorA" > generator --generator-path="generator-vendorA.yml" > --output-path="snmp-vendorA.yml" > MIBDIRS="mibs/base:mibs/vendorB" > generator --generator-path="generator-vendorB.yml" > --output-path="snmp-vendorB.yml" > snmp_exporer --config.file="snmp-*.yml" > > Longer-term, I want to add the ability to specify MIBDIRS pre module in > the generator. This way you can put the conflicting MIBs in different dirs > and still have one config. > > On Tue, Nov 21, 2023 at 4:18 AM 'Elliott Balsley' via Prometheus Users < > prometheus-users@googlegroups.com> wrote: > >> Aha! I found the problem by looking closer at the generated snmp.yml. >> This PDU manufacturer OID is *1418*. I have another MIB installed from >> a different manufacturer *1718* which also has an OID called >> outletName. So the generator config I shared before actually produces >> incorrect snmp.yml as below. The solution I found is to be explicit in the >> lookup like this: >> lookups: >> - source_indexes: [outletIndex] >> lookup: 1.3.6.1.4.1.1418.6.5.1.2 >> >> Is this expected behavior and is there a better way to handle it? >> >> Incorrect snmp.yml: >> - name: outletStatus >> oid: 1.3.6.1.4.1.1418.6.5.1.6 >> type: gauge >> help: ' - 1.3.6.1.4.1.1418.6.5.1.6' >> indexes: >> - labelname: outletIndex >> type: gauge >> lookups: >> - labels: >> - outletIndex >> labelname: outletName >> oid: 1.3.6.1.4.1.1718.3.2.3.1.3 >> type: DisplayString >> >> On Mon, Nov 20, 2023 at 6:41 PM 'Elliott Balsley' via Prometheus Users < >> prometheus-users@googlegroups.com> wrote: >> >>> I'm trying to configure snmp-exporter with a PDU, using a lookup to >>> label each outlet with its human-readable name (outletName) by referencing >>> its outletIndex. But when I try to do this, the outletName label is an >>> empty string. Is there something wrong with my generator config? Example: >>> >>> >>> >>> >>> * walk: - 1.3.6.1.4.1.1418.6.5 lookups: - >>> source_indexes: [outletIndex] lookup: outletName* >>> >>> This is how the metrics look. >>> *outletStatus{outletIndex="0",outletName=""} 1* >>> >>> Without any lookups, the outletName appears correct: >>> *outletName{outletIndex="0",outletName="1-MacStudio"} 1* >>> >>> Below is how the raw SNMP data looks: >>> >>> % snmptable -v2c -c netflixsnmp -m IBOOTPDU-MIB 10.37.155.163 >>> 1.3.6.1.4.1.1418.6.5 >>> SNMP table: IBOOTPDU-MIB::outletTable >>> >>> outletIndex outletName outletInitialState outletCycleTime >>> outletControl outletStatus outletActualStatus >>> 1 1-MacStudio last 10 >>> on on on >>> 2 2-Mezzo-1 last 10 >>> on on on >>> 3 3-UltraStudio last 10 >>> on on on >>> 4 4-MP-60 last 10 >>> on on on >>> 5 5-Mezzo-2 last 10 >>> on on on >>> 6 6-Core110f last 10 >>> on on on >>> 7 Outlet-7 last 10 >>> on on on >>> 8 8-Roku last 10 >>> cycle on on >>> >>> I'm not sure if this matters but I noticed the outletIndex values start >>> at 1, while the OID table indexes start at 0. Could that be the problem >>> here? >>> I've attached the MIB. I also opened a Github issue with more details >>> in case this is a bug: >>> https://github.com/prometheus/snmp_exporter/issues/1039 >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Prometheus Users" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/prometheus-users/MPuTk5yDsAg/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> prometheus-users+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/prometheus-users/19aca381-36e0-4e05-8044-6aecda223da6n%40googlegroups.com >>> <https://groups.google.com/d/msgid/prometheus-users/19aca381-36e0-4e05-8044-6aecda223da6n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> > You received this message because you are subscribed to the Google Groups >> "Prometheus Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to prometheus-users+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/prometheus-users/CALajkdhdvtgpQz5iq_7cFtyvYNc8hCzqxE29kEUGmuCsoZ42Ng%40mail.gmail.com >> <https://groups.google.com/d/msgid/prometheus-users/CALajkdhdvtgpQz5iq_7cFtyvYNc8hCzqxE29kEUGmuCsoZ42Ng%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Prometheus Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/CALajkdihxN4n%3DN3oPhGKRUNHLwJ-Ve-75viF4qdsrSzH7iLb%2Bg%40mail.gmail.com.
