Hallo.
Hier taucht regelmäßig ein Problem mit einem zu überwachenden “Host” auf. Genauergesagt ist es das IMM eines IBM x3650 M4 Servers, das ich bisher per SNMP v1 abrufe.
Im Webinterface erscheint dazu in regelmäßigen Abständen:
CRIT - [snmp] SNMP Error on 192.168.1.5: Timeout: No Response from 192.168.1.5 (Exit-Code: 1)**CRIT**, Got no information from host, execution time 8.7 sec
Das IMM hat meines Wissens nur eine NIC mit 100 MBit/s (oder sind’s nur 10 MBit/s? ) und reagiert auch auf dem eigenen Webinterface etwas träge … daher wundere ich mich nicht über Verzögerungen.
Nun habe ich etwas gestöbert und folgendes gesehen:
time cmk -Iv IBM_M4_IMM
Discovering services on: IBM_M4_IMM
IBM_M4_IMM:
+ FETCHING DATA
[snmp] Execute data source
ERROR: SNMP error
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: .1.3.6.1.4.1.232.2.2.4.2.0
ERROR: SNMP error
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: .1.3.6.1.2.1.43.11.1.1.6.1.1
...
das geht munter so weiter ... und ganz am Ende:
[piggyback] Execute data source
No piggyback files for 'IBM_M4_IMM'. Skip processing.
No piggyback files for '192.168.1.5'. Skip processing.
+ EXECUTING DISCOVERY PLUGINS (27)
SUCCESS - Found no new services, no new host labels
real 0m11.596s
user 0m1.188s
sys 0m1.031s
Daher steckt vielleicht etwas ganz anderes dahinter als nur ein Zeitproblem? Hat jemand eine Idee, wonach ich da schauen kann?
Danke.
Hallo. Ich hatte eigentlich bisher immer alle Services erfasst, die das IMM von sich aus geboten hat … das waren 25. Mittlerweile habe ich gesehen, dass ein Problem bei der Abfrage der Lüfter besteht. Eigentlich ganz sinnvoll, wenn man das mit überwacht.
Anscheinend muss man irgendwo einen Parameter von int auf float umstellen?! … Konkrekt sieht das dann so aus:
**Ungültiger Check-Parameter**: Untere Grenzen für Lüfterdrehzahl: Der Wert 28 ist vom Typ int, muss aber float sein
Variable: checkgroup_parameters:hw_fans_perc
Parameter:
{'levels_lower': (28, 25)}
Ähnliches gilt für einen Check des Speichers. Da steht dann:
Bin leider nicht weit genug drin, um beurteilen zu können, wie/wo ich das einstellen kann.
Davon abgesehen, ist die Abfrage des IMM aber auch generell offenbar zu langsam, so dass im Dashboard von checkMK auch weiterhin im 20-Minuten-Takt immer wieder erscheint:
CRIT - [snmp] SNMP Error on 192.168.1.5: Timeout: No Response from 192.168.1.5 (Exit-Code: 1)**CRIT**, Got no information from host, execution time 8.4 sec
Der Durchlauf dauert also offenbar zu lange. Vielleicht sollte ich es tatsächlich nur auf die Abfrage “up?” beschränken und fertig?
Das könnte auch eine Lösung sein:
“Ein möglicher Fehler ist, wenn SNMP-Agenten nicht auf die Anfrage nach den Standardinformationen wie z.B. der sysDescr antworten. Diese Geräte sind in der Diagnose wie tot. Und auch in der Serviceerkennung werden sie keine Resultate liefern, wenn Sie nicht durch eine spezielle Konfiguration nachhelfen. Legen Sie dazu für die betroffenen Hosts eine Regel unter Access to agents > Hosts without system description OID mit einem Positive outcome an. Checkmk geht dann einfach davon aus, dass alles in Ordnung ist und überspringt den Test mit der sysDescr . Zwar werden dann auch keine Check-Plugins erkannt, die bestimmte Teile in diesem Text erwarten, aber das spielt in der Praxis keine Rolle, da die betroffenen Plugins so entwickelt wurden, dass sie diesen Fall berücksichtigen.”
Ich bin aber nach wie vor nicht sicher, ob das Problem überhaupt an diesen Services liegt. Schließlich bleiben die Meldungen bestehen – auch, wenn ich die Überwachung der Lüfterdrehzahlen deaktiviere.
Moin … ah jetzt sehe ich wo der Hase begraben ist …
welches Check Plugin ist das denn ??? Ein altes ???
Dann müssen im Script einige Änderungen gemacht werden da ja in der V2 auf Python 3 umgestellt wurde.
Das weiß ich nicht – ich habe einfach SNMP auf dem IMM des Servers aktiviert und es mit checkMK abgefragt … das Ergebnis siehst du oben. checkMK ist hier noch Versoin 1.6p22
Klar … das IMM hat ein eigenes Webinterface. Ist nicht das schnellste – aber läuft.
Ich hatte es ja bereits auf SNMPv2 ungestellt – läuft. Daher weiß ich nicht mehr, warum das ursprünglich auf v1 stand?!?
2.0 habe ich hier noch gar nicht laufen – sehe gerade erst: habe ich das falsch Unterforum erwischt?
Andere checkMK-Server habe ich nicht … nur den einen
Hi. Ich grabe diesen Thread jetzt nochmal aus, denn das Problem besteht auch weiterhin. Das IMM vom Server meldet sich hier auch weiterhin häufig mit den Timeouts. Gibt es evtl weitere oder neue Ideen, was ich da ändern kann?
Ich weiß z.B. nicht, ob es etwas ändern würde, wenn ich einfach auf die Prüfung gewisser Dienste verzichten würde. Es scheint ja eher ein “generelles Erreichbarkeitsproblem” zu sein??
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
) und reagiert auch auf dem eigenen Webinterface etwas träge … daher wundere ich mich nicht über Verzögerungen.
