Von SNMPv1 zu SNMPv3 und Service-Erkennung

stefanp74 · August 2, 2023, 1:00pm

Checkmk Enterprise Edition 2.2.0p7

Hallo die Runde,

ich steige aktuell von SNMPv1 auf SNMPv3 um und habe etwas eigenartiges zu berichten:
Die Abfrage eines Druckers: Die Hostservices werden erfolgreich abgefragt im GUI wie auch in der Console, allerdings zeigt sich mir ein ganz anderes Bild, wenn ich beim Host auf Service-Erkennung durchführen klicke.
Da werden zB von 16 Services nur 3 als überwacht angezeigt, die restlichen 13 als Verschwundene Services - überwacht, aber nicht mehr vorhanden.

Ich nutze für den Host das klassische SNMP Backend.
Kontexte für SNMPv3 Anfragen wurden hinterlegt.

cmk -nv --debug HP_DRUCKER1

+FETCHING DATA
[SNMPFetcher] Execute data source
[PiggybackFetcher] Execute data source
No piggyback files for 'HP_DRUCKER1'. Skip processing.
No piggyback files for 'xxx.xxx.xxx.xxx'. Skip processing.
Alerts               generalPrinter: Bereitschafts- modus ein
Input Tray 3         Tray 3, Status: Available and idle, Alerts: None, Maximal capacity: 500 sheets, At least one remaining
Input Tray 4         Tray 4, Status: Available and idle, Alerts: None, Maximal capacity: 500 sheets, At least one remaining
Interface 2          [HP ETHERNET MULTI-ENVIRONMENT,ROM none,JETDIRECT,JD149,EEPROM JDI24110033], (up), MAC: xx:xx:xx:xx:xx:xx, Speed: 1 GBit/s, In: 1.05 kB/s (<0.01%), Out: 778 B/s (<0.01%)
Output Standardfach  Output Bin, Status: Available and idle, Alerts: None, Maximal capacity: 300 sheets, At least one filled
Pages                total prints: 96175
SNMP InfoHP ETHERNET MULTI-ENVIRONMENT,ROM none,JETDIRECT,JD149,EEPROM JDI24110033,CIDATE 07/20/2022, hp_drucker1, ,
Supply Papierzufuhrwalzen reinigen HP None Remaining: 46.00%, Supply: 46 of max. 100%
Supply Patrone Cyan HP 651A (CE341A) Remaining: 66.00%, Supply: 66 of max. 100%
Supply Patrone Gelb HP 651A (CE342A) [yellow] Remaining: 69.00%, Supply: 69 of max. 100%
Supply Patrone Magenta HP 651A (CE343A) Remaining: 98.00%, Supply: 98 of max. 100%
Supply Patrone Schwarz HP 651A (CE340A) [black] Remaining: 97.00%, Supply: 97 of max. 100%
Supply Tonerauffangeinheit HP CE980A Some remaining
Supply Transferkit HP CE516A Remaining: 29.00%, Supply: 29 of max. 100%
Supply Vorlageneinzugskit HP L2718A Remaining: 73.00%, Supply: 73 of max. 100%
Uptime               Up since Aug 01 2023 14:05:49, Uptime: 23 hours 52 minutes
No piggyback files for 'HP_DRUCKER1'. Skip processing.
No piggyback files for 'xxx.xxx.xxx.xxx. Skip processing.
[snmp] Success, [piggyback] Success (but no data found for this host), execution time 4.6 sec | execution_time=4.610 user_time=0.040 system_time=0.010 children_user_time=1.460 children_system_time=0.090 cmk_time_snmp=3.020 cmk_time_agent=0.000

Ich verstehe ehrlich gesagt nicht was das bedeutet. Die Services werden überwacht, sind aber nicht mehr vorhanden?
Bekommt man das denn wieder hin?
Wenn ja, wie?
Danke

LG Stefan

andreas-doehler · August 2, 2023, 3:44pm

Kurze Antwort - Nein. Das Problem hier lautet SNMPv3 mit Context. Das ganze ist etwas kompliziert zu erklären.
Probiere mal in der CLI ein cmk --debug -vvI HP_DRUCKER1
Was ist da beim suchen nach den OIDs zu sehen oder in der Aussage.
Wenn man das klassische Backend verwendet sollte hier auch der komplette SNMPget / SNMPwalk Aufruf zu sehen sein.
Ist da auch schon der Context im Aufruf für das allererste SNMPget vorhanden?

stefanp74 · August 3, 2023, 5:51am

Moin,

nun, das erste Ergebnis war nicht sehr vielversprechend, Tonnen an OIDs waren alle samt mit “” behaftet.
Ich habe etwas gestöbert und entdeckt, dass der Host unter der SNMP-Rule “Hosts ohne Systembeschreibungs OID” hinterlegt war. Ich entfernte den Host aus der Rule und startete cmk --debug -vvI HP_DRUCKER1 erneut:

Discovering services and host labels on: HP_DRUCKER1
HP_DRUCKER1:
+ FETCHING DATA
  Source: SourceInfo(hostname='HP_DRUCKER1', ipaddress='xxx.xxx.xxx.xxx', ident='snmp', fetcher_type=<FetcherType.SNMP: 7>, source_type=<SourceType.HOST: 1>)
[cpu_tracking] Start [7f1194df3390]
Read from cache: SNMPFileCache(HP_DRUCKER1, path_template=/omd/sites/pi_prod/tmp/check_mk/data_source_cache/snmp/{mode}/{hostname}, max_age=MaxAge(checking=0, discovery=120, inventory=120), simulation=False, use_only_cache=False, file_cache_mode=1)
[SNMPFetcher] Execute data source
  SNMP scan:
       Getting OID .1.3.6.1.2.1.1.1.0: Running 'snmpget -v3 -l authPriv -a md5 -u USER -A PASSWORD -x AES -X PASSWORD -m "" -M "" -On -OQ -Oe -Ot xxx.xxx.xxx.xxx  .1.3.6.1.2.1.1.1.0'
ERROR: SNMP error
snmpget: Bad context specified

failed.
...

Der Context-Name ist aber richtig eingetragen in den SNMP-Rules und der Host explizit zugewiesen.
Da fehlt doch der Context-Name bei dem snmpget-Befehl … hmmmm

LG Stefan

andreas-doehler · August 3, 2023, 6:07am

Genau das ist das Problem - Context fehlt und wird nur bei den SNMPwalks verwendet aber nicht beim SNMPget für die SystemDescOID.

Der BUG ist schon seit ewigen Zeiten im CMK.
@mschlenker or @martin.hirschvogel - das wäre mal wieder ein Punkt den Ihr weiter leiten könnt

stefanp74 · August 3, 2023, 6:24am

Jössas, und ich such mich wund
d.h. einstweilen zurück zu snmpv1 und abwarten.
Wenn da das Audit nicht wär

Danke

LG Stefan

martin.hirschvogel · August 3, 2023, 6:34am

Jo, kannst du einfach ein Ticket aufmachen, Stefan? Das ist der schnellste Weg und dann wird es auch behoben und die Entwickler können direkt mit dir abstimmen, ob der Fix das Problem auch löst
Und bist du nicht im Urlaub Andreas?