9
CheckMK - IDRAC via IPMI
Moin,
seit Kurzem haben wir CheckMK als Hardware-Appliance. Es läuft alles gut. Nur eins nervt.
Wir überwachen via IDRAC die Hardware unserer Dell-Server. Eingesetzt wird IPMI. Das funktioniert vom Prinzip auch. Aber es kommt mehrfach täglich vor, dass ein großer Teil bis alle Sensoren den Status "UNKN" haben mit der Meldung "Item not found in monitoring data." Dann gibt es auch entsprechend viele Mails mit der Meldung. Kurz darauf funktioniert es wieder. Alle Daten kommen rein und die Fehler verschwinden. Es ist also die Konfiguration vom Prinzip richtig. Wenn ich händisch die Abfrage starte (Host -> Run service discovery) erhalte ich erst einmal
Drunter steht, dass ich einen Rescan starten soll. Mache ich das, dann werden in der Regel alle Sensoren erkannt und gehen in den Status "OK". Es kommt aber auch vor, dass das ebenso schief läuft und diverse Sensoren den Status "UNKN" erhalten. Wenn das passiert, reicht meist ein erneuter Rescan und die Sensoren sind wieder alle OK.
Ich habe sowohl FreeIPMI als auch IPMITool getestet. Bei beiden funktioniert es im Prinzip. Bei beiden kommt es aber auch zu den Falschmeldungen. Zur Zeit ist eingestellt:
Benutzername und Passwort sind natürlich auch konfiguriert.
Auf Seiten der IDRAC ist der entsprechende User eingerichtet. Er hat die Rechte "Operator" für IPMI-LAN, IPMI-serielle und SNMP. Seriell via LAN ist aktiviert und IPMI ist auch aktiviert mit dem Level "Operator".
Dann haben wir noch auf Seiten des CheckMK auf Anraten eines Dienstleisters folgende Regeln:
Trotzdem funktioniert die Abfrage der Werte nicht stabil. Während ich hier schreibe ist wieder eines der Bleche angeblich gar nicht vorhanden. Die anderen fünf stehen mit allen Sensoren auf OK. Zwischenzeitlich waren aber auch alle auf OK. Also auch das Blech, dass gerade angeblich gar nicht da ist. Nun gehen mir und leider auch unserem DL die Ideen aus.
Kennt einer von Euch das Problem und hat die Lösung? So jedenfalls ist das Monitoring sinnbefreit.
So. Zum Abschluss: Jetzt ist der Server, der gerade rumgespackt hat wieder auf OK. Dafür ist ein anderer mit 14 Sensoren "UNKN".
Liebe Grüße
Erik
seit Kurzem haben wir CheckMK als Hardware-Appliance. Es läuft alles gut. Nur eins nervt.
Wir überwachen via IDRAC die Hardware unserer Dell-Server. Eingesetzt wird IPMI. Das funktioniert vom Prinzip auch. Aber es kommt mehrfach täglich vor, dass ein großer Teil bis alle Sensoren den Status "UNKN" haben mit der Meldung "Item not found in monitoring data." Dann gibt es auch entsprechend viele Mails mit der Meldung. Kurz darauf funktioniert es wieder. Alle Daten kommen rein und die Fehler verschwinden. Es ist also die Konfiguration vom Prinzip richtig. Wenn ich händisch die Abfrage starte (Host -> Run service discovery) erhalte ich erst einmal
OK [mgmt_ipmi]: Success
OK [snmp]: Success
CRIT [special_ipmi_sensors]: No cached data availableCRIT
OK [piggyback]: Success (but no data found for this host)Drunter steht, dass ich einen Rescan starten soll. Mache ich das, dann werden in der Regel alle Sensoren erkannt und gehen in den Status "OK". Es kommt aber auch vor, dass das ebenso schief läuft und diverse Sensoren den Status "UNKN" erhalten. Wenn das passiert, reicht meist ein erneuter Rescan und die Sensoren sind wieder alle OK.
Ich habe sowohl FreeIPMI als auch IPMITool getestet. Bei beiden funktioniert es im Prinzip. Bei beiden kommt es aber auch zu den Falschmeldungen. Zur Zeit ist eingestellt:
Use IPMITool
Privilege Level: OPERATOR
IPMI Interface: lanplus - IPMI v2.0 RMCP+ LAN interfaceBenutzername und Passwort sind natürlich auch konfiguriert.
Auf Seiten der IDRAC ist der entsprechende User eingerichtet. Er hat die Rechte "Operator" für IPMI-LAN, IPMI-serielle und SNMP. Seriell via LAN ist aktiviert und IPMI ist auch aktiviert mit dem Level "Operator".
Dann haben wir noch auf Seiten des CheckMK auf Anraten eines Dienstleisters folgende Regeln:
Maximum number of check attempts for service: 6
Normal check interval for service checks: 10 minutes
Retry check interval for service checks: 5 minutes
Service check timeout (Micro Core): 5 minutesTrotzdem funktioniert die Abfrage der Werte nicht stabil. Während ich hier schreibe ist wieder eines der Bleche angeblich gar nicht vorhanden. Die anderen fünf stehen mit allen Sensoren auf OK. Zwischenzeitlich waren aber auch alle auf OK. Also auch das Blech, dass gerade angeblich gar nicht da ist. Nun gehen mir und leider auch unserem DL die Ideen aus.
Kennt einer von Euch das Problem und hat die Lösung? So jedenfalls ist das Monitoring sinnbefreit.
So. Zum Abschluss: Jetzt ist der Server, der gerade rumgespackt hat wieder auf OK. Dafür ist ein anderer mit 14 Sensoren "UNKN".
Liebe Grüße
Erik
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667919
Url: https://administrator.de/contentid/667919
Ausgedruckt am: 03.12.2024 um 17:12 Uhr
9 Kommentare
Neuester Kommentar
Hallo,
ich habe mit Zabbix bei IPMI auch nicht durchlaufend Ergebnisse.
Warum der Timeout im CheckMK nicht wie gewünscht arbeitet kann ich nicht sagen.
Aber ich monitore per SMTP und das läuft bei mir besser.
Grüße Uwe
ich habe mit Zabbix bei IPMI auch nicht durchlaufend Ergebnisse.
Warum der Timeout im CheckMK nicht wie gewünscht arbeitet kann ich nicht sagen.
Aber ich monitore per SMTP und das läuft bei mir besser.
Grüße Uwe
SNMP hatte ich vorher im Einsatz. Da war das Problem, dass nur ein Drittel der Sensoren überhaupt Daten lieferte und die allgemeine Meinung der Hinweise, die ich im Inet gelesen habe, war, dass es mit IPMI besser ginge. Und es muss doch auch möglich sein, das stabil zu kriegen.
Moin.
Ich hoffe, ihr meint _SNMP_...
Die ganzen BMC-Controller, egal ob IPMI, Redfish, iDRAC, BMRC oder wie auch immer die Hersteller ihre Inkarnation davon getauft haben, sind nicht primär auf immer wiederkehrende Anfragen eines Monitoring-Systems ausgelegt. Soll heissen: Die CPU der Dinger ist einfach nicht performant genug, um die reinkommenden Abfragen innerhalb der Timeouts zu beantworten.
Bei der Verwendung von IPMI (via freeipmi) kannst du wenig an den Timeouts ändern, bei SNMP kannst du die Wartedauer/Timeout der Checks hingegen via CheckMK-GUI beeinflussen. Eure Einstellung sind schon sehr weit vom Standard entfernt und mehr als großzügig bemessen, daran klemmt es eher nicht.
Mit der 2.3.0 hat CheckMK eine neue Redfish-Version eingeführt, das hat bei uns die Probleme beim Monitoring von aktuellen Supermicro-IPMIs deutlich entschärft. Ob das auch bei nem iDRAC geht, kann ich dir leider nicht beantworten - habe aktuell genau null DELL-Server am Start...
Cheers,
jsysde
Ich hoffe, ihr meint _SNMP_...
Die ganzen BMC-Controller, egal ob IPMI, Redfish, iDRAC, BMRC oder wie auch immer die Hersteller ihre Inkarnation davon getauft haben, sind nicht primär auf immer wiederkehrende Anfragen eines Monitoring-Systems ausgelegt. Soll heissen: Die CPU der Dinger ist einfach nicht performant genug, um die reinkommenden Abfragen innerhalb der Timeouts zu beantworten.
Bei der Verwendung von IPMI (via freeipmi) kannst du wenig an den Timeouts ändern, bei SNMP kannst du die Wartedauer/Timeout der Checks hingegen via CheckMK-GUI beeinflussen. Eure Einstellung sind schon sehr weit vom Standard entfernt und mehr als großzügig bemessen, daran klemmt es eher nicht.
Mit der 2.3.0 hat CheckMK eine neue Redfish-Version eingeführt, das hat bei uns die Probleme beim Monitoring von aktuellen Supermicro-IPMIs deutlich entschärft. Ob das auch bei nem iDRAC geht, kann ich dir leider nicht beantworten - habe aktuell genau null DELL-Server am Start...
Cheers,
jsysde
Moin,
Steht doch da.
Klar meinen wir das. Danke für den Hinweis.
Hmmmmmm. Aber eine Anfrage alle zehn Minuten sollte doch auch die lahmste CPU nicht überfordern.
Ja, ich habe erst einmal etwas extreme Werte genommen in der Hoffnung, dass es dann geht und man sich langsam an das Maximum herantasten kann. Aber eigentlich wäre für uns ein Monitoring alle zehn Minuten ausreichend. Tatsächlich stelle ich bei der Langzeitbeobachtung fest, dass es etwas besser geworden ist. Jetzt wäre meine Frage, an welcher Schraube ich drehen muss, um das ganz weg zu kriegen.
Unsere Version:
Offensichtlich nicht wirklich.
Liebe Grüße
Erik
Steht doch da.
Klar meinen wir das. Danke für den Hinweis.Die ganzen BMC-Controller, egal ob IPMI, Redfish, iDRAC, BMRC oder wie auch immer die Hersteller ihre Inkarnation davon getauft haben, sind nicht primär auf immer wiederkehrende Anfragen eines Monitoring-Systems ausgelegt. Soll heissen: Die CPU der Dinger ist einfach nicht performant genug, um die reinkommenden Abfragen innerhalb der Timeouts zu beantworten.
Hmmmmmm. Aber eine Anfrage alle zehn Minuten sollte doch auch die lahmste CPU nicht überfordern.
Bei der Verwendung von IPMI (via freeipmi) kannst du wenig an den Timeouts ändern, bei SNMP kannst du die Wartedauer/Timeout der Checks hingegen via CheckMK-GUI beeinflussen. Eure Einstellung sind schon sehr weit vom Standard entfernt und mehr als großzügig bemessen, daran klemmt es eher nicht.
Ja, ich habe erst einmal etwas extreme Werte genommen in der Hoffnung, dass es dann geht und man sich langsam an das Maximum herantasten kann. Aber eigentlich wäre für uns ein Monitoring alle zehn Minuten ausreichend. Tatsächlich stelle ich bei der Langzeitbeobachtung fest, dass es etwas besser geworden ist. Jetzt wäre meine Frage, an welcher Schraube ich drehen muss, um das ganz weg zu kriegen.
Mit der 2.3.0 hat CheckMK eine neue Redfish-Version eingeführt, das hat bei uns die Probleme beim Monitoring von aktuellen Supermicro-IPMIs deutlich entschärft.
Unsere Version:
2.3.0p10.cee (default)Ob das auch bei nem iDRAC geht, kann ich dir leider nicht beantworten - habe aktuell genau null DELL-Server am Start...
Offensichtlich nicht wirklich.
Liebe Grüße
Erik
Moin.
Wobei: Deine Fehlermeldung entsteht gar nicht beim Check selbst, sondern bei der Discovery (CheckMK_Discovery). Die rödelt natürlich alles durch, was der jeweilige Host an Informationen zu bieten hat, ermittelt also die zu monitorenden Services. Wir haben unsere Discovery auf 1x täglich gestellt, das hat vor allem bei Juniper-Switches zu einer deutlichen Entlastung/Verringerung dieser UNKN-Meldungen geführt. Zusätzlich haben wir die Benachrichtigungen so angepasst, dass UNKN gar keine Mail mehr erzeugt, sondern einfach nur im Dashboard angezeigt wird.
Wenn ich Montag wieder im Büro bin, kann ich dir auch die genauen Einstellungen übermitteln.
Cheers,
jsysde
Zitat von @erikro:
[...]Aber eine Anfrage alle zehn Minuten sollte doch auch die lahmste CPU nicht überfordern.
Das kommt stark darauf, was die CPU gerade so macht... Ich habe das gleiche Probleme wie du und beobachte dieses Verhalten seit der Einführung von CheckMK bei uns Anfang 2023. Wir monitoren allerdings mit den Default-Timeouts (also deutlich öfter) und wenn ich mir die CPU-Auslastung so im Graphen anschauen, erledigt die CPU auf den IPMIs immer irgendwas, die Auslastung ist nie NULL, sondern immer mind. 30%/40%, teils auch >90%. So richtig schlau bin ich da auch noch nicht daraus geworden, was genau da passiert und warum die Checks teils einfach fehlschlagen.[...]Aber eine Anfrage alle zehn Minuten sollte doch auch die lahmste CPU nicht überfordern.
Wobei: Deine Fehlermeldung entsteht gar nicht beim Check selbst, sondern bei der Discovery (CheckMK_Discovery). Die rödelt natürlich alles durch, was der jeweilige Host an Informationen zu bieten hat, ermittelt also die zu monitorenden Services. Wir haben unsere Discovery auf 1x täglich gestellt, das hat vor allem bei Juniper-Switches zu einer deutlichen Entlastung/Verringerung dieser UNKN-Meldungen geführt. Zusätzlich haben wir die Benachrichtigungen so angepasst, dass UNKN gar keine Mail mehr erzeugt, sondern einfach nur im Dashboard angezeigt wird.
Wenn ich Montag wieder im Büro bin, kann ich dir auch die genauen Einstellungen übermitteln.
Cheers,
jsysde
Zitat von @jsysde:
Wenn ich Montag wieder im Büro bin, kann ich dir auch die genauen Einstellungen übermitteln.
Wenn ich Montag wieder im Büro bin, kann ich dir auch die genauen Einstellungen übermitteln.
Da wäre ich Dir sehr dankbar. Die Mails habe ich inzwischen auch schon ausgeknipst. Und mit den momentanen Einstellungen (ich habe noch ein wenig gedreht nach der Anfrage hier) ist es auch schon deutlich besser geworden.
Moin nochmal,
ich fand Deine Erklärung ja einleuchtend. Jetzt habe ich wieder eine elend lange Liste mit UNKN und habe nachgeschaut:
3% ist ja nun nicht gerade soooooooo viel.
Liebe Grüße
Erik
ich fand Deine Erklärung ja einleuchtend. Jetzt habe ich wieder eine elend lange Liste mit UNKN und habe nachgeschaut:
OK
Management Interface: IPMI Sensor CPU_Usage Open the action menu Status: OK, 3.00 %3% ist ja nun nicht gerade soooooooo viel.
Liebe Grüße
Erik
also ich persönlich mach das eigentlich so
IPMI, iDrac, HP ILO
Dort den SMTP Emails Server reinpflegen und bei änderungen oder Problemen Email generieren lassen an das IT Postfach. Somit ist das System auch überwacht, zwar nicht so schön wie checkmk oder prtg aber kommt aufs selbe raus.
Wenn was los ist bekommste Email, ob das nun rot leuchtet oder ist ja wurst.
IPMI, iDrac, HP ILO
Dort den SMTP Emails Server reinpflegen und bei änderungen oder Problemen Email generieren lassen an das IT Postfach. Somit ist das System auch überwacht, zwar nicht so schön wie checkmk oder prtg aber kommt aufs selbe raus.
Wenn was los ist bekommste Email, ob das nun rot leuchtet oder ist ja wurst.
Moin,
Nein, tut es nicht. Oder richtest Du das für alle ca. 350 Sensoren auf allen Blechen ein? Das wäre ein nicht zu rechtfertigender Aufwand. Zumal das höchst unsicher ist, setzt es doch voraus, dass die internen Mechanismen einen Fehler als Fehler erkennen. Mir wäre auch nicht bekannt, wo und wie ich in IDRAC oder ILO die Grenzwerte für die Warnung der zu langsamen Lüfterrotation oder der zu hohen Prozessortemperatur einstellt.
Das ist für uns sicherlich keine Lösung.
Liebe Grüße
Erik
Zitat von @ThePinky777:
also ich persönlich mach das eigentlich so
IPMI, iDrac, HP ILO
Dort den SMTP Emails Server reinpflegen und bei änderungen oder Problemen Email generieren lassen an das IT Postfach. Somit ist das System auch überwacht, zwar nicht so schön wie checkmk oder prtg aber kommt aufs selbe raus.
also ich persönlich mach das eigentlich so
IPMI, iDrac, HP ILO
Dort den SMTP Emails Server reinpflegen und bei änderungen oder Problemen Email generieren lassen an das IT Postfach. Somit ist das System auch überwacht, zwar nicht so schön wie checkmk oder prtg aber kommt aufs selbe raus.
Nein, tut es nicht. Oder richtest Du das für alle ca. 350 Sensoren auf allen Blechen ein? Das wäre ein nicht zu rechtfertigender Aufwand. Zumal das höchst unsicher ist, setzt es doch voraus, dass die internen Mechanismen einen Fehler als Fehler erkennen. Mir wäre auch nicht bekannt, wo und wie ich in IDRAC oder ILO die Grenzwerte für die Warnung der zu langsamen Lüfterrotation oder der zu hohen Prozessortemperatur einstellt.
Das ist für uns sicherlich keine Lösung.
Liebe Grüße
Erik
Wenn was los ist bekommste Email, ob das nun rot leuchtet oder ist ja wurst.
