Hallo Frank … ich habe mich heute nochmal mit check_MK auseinandergesetzt, weil mir mal wieder eine SDKarte abgeraucht ist (INTENSO-Karten kann nicht nicht mehr empfehlen … )
Erneut habe ich nach Update-Möglichkeiten gesucht … und siehe da:
Das könnte die richtige Lösung für das Problem sein, wie’s aussieht!
Ich habe es vorhin ausprobiert. Das läuft einwandfrei auf einem RasPi!
Das einzige, was ich nicht wiederfinde, ist das „Restore“ im WATO-Menu. Ich hatte gehofft, dass ich da ein altes Backup der 1.2er Version einspielen kann …!??
Die Oberfläche ist natürlich moderner und auch die ganzen check_MK_agents sind jetzt viel besser zu finden. Leider kann ich einen Server trotz installiertem check_MK-agent (1.5,deb) nicht dazu bringen, überwacht zu werden. Ich erhalte seltsamerweise immer die Meldung:
Inventory failed for this host: Error running check_mk --automation try-inventory -- @noscan Proxmox.
Invalid output from webservice (invalid syntax (, line 1)):
Proxmox: Check local returned empty service description - ignoring it.
(wiederholt sich dann x-fach)
Hat das schon mal jemand gesehen bzw weiß, was das soll?
Ich kann nur Boot von USB empfehlen, die RasPi 3 können das, funktioniert bei mir mit den meisten USB-Sticks, (nicht mit allen) und die halten dann schön lange. Alternativ gibts auch mSATA-Karten oder Du steckst gleich nen usb-sata-controller mit ner SSD dran. Das hält dann lange.
Einziger Nachteil: die USB-Schnittstelle ist wohl zusammen mit allen anderen Peripheriegeräten (USB-Ports, WLAN, LAN,…) an einem USB-Port an der CPU angebunden, dementsprechend ist der Datendurchsatz nicht superberauschend, aber wer braucht das schon…
nur eine Idee: warum richtest du nicht einfach einen Container in Proxmox dafür ein? Ich kenne Proxmox jetzt nicht, aber meine mich zu erinnern, dass sie auch Linuxcontainer supporten (ähnlich wie LXD unter Ubuntu). So ein Container braucht kaum Ressourcen und du kannst die offiziellen Check_MK Versionen benutzen.
Hi. @maxEG Ich hatte das Booten via USB Stick bereits eingestellt, der MoniPi stand aber leider trotzdem mit einer Kernel-Panic. Hab’s neu aufgesetzt…
@zefanja Die Idee eines extra Containers ist natürlich ganz gut, wenn man von ARM weg will – aber nicht im Sinne einer unabhängigen Überwachung des Systems. Bisher lief nagios3 ja auch direkt auf dem lml-Server. Da macht das aber wenig Sinn, wenn der Hypervisor steht. Daher muss die Überwachung unabhängig vom Rest laufen und daher sind ja einige auf die sparsamen RaspberryPis umgestiegen.
@Michael: Stimmt natürlich. Alternativ gibt es auch stromsparende Rechner, die nicht ARM sind. Sind vielleicht etwas teurer als ein Pi, aber bieten sonst die gleichen Vorteile. Oder falls man sowieso noch einen zweiten oder dritten Server laufen hat, kann man es auch da laufen lassen.
Hi Stephan.
Also ich habe mir gestern die aktuelle Version von check_MK 1.5p9 angeschaut. Sieht alles schick aus – keine Frage. Aber die fehlende Möglichkeit zum Restore ist für mich schon fast ein K.O.-Kriterium. Mir ist nicht klar, wie man eine so elementare Funktion rauswerfen kann?? In dem oben zitierten Link schrieb ja einer, dass er sich mit GIT als Versionskontrolle behilft aber ein Restore via WebGUI ist meiner Meinung nach trotzdem besser. Mit anderen Worten: Ich bleibe einfach vorerst weiterhin bei Version 1.2.4p5. – sooo oft muss man da ja zum Glück nicht ran
klar, schön ist das nicht. Wir haben damals von 1.2 auf 1.4 und nun auf 1.5. ein Upgrade gemacht. Das lief ohne Probleme durch. Vielleicht hast du ja Glück und findest eine ARM Version für 1.4 und 1.5 und kannst das Upgrade damit machen. Aber das hast du wahrscheinlich schon probiert.
Brauchst du ja nicht mehr, wenn du ein Vollbackup machen kannst
Das ist schon richtig, besser ist es, aber in der Praxis hat es bisher keinen Unterschied gemacht für uns. Wenn der HyperVisor ausfallen sollte (was schon passiert ist), muss man eh an den Bare-Metal Server ran. Und wenn er ausfällt, kann er auch nicht mehr überwacht werden und da bringt mir auch kein RaspPi was. Solange der HyperVisor läuft kann er auch von einem Container aus überwacht werden.
Besser ist es natürlich, wenn das Monitoring extra läuft, denn ich bekomme mit, wenn der HyperVisor offline geht, aber das merke ich auch so, da dann bei uns fast nichts mehr im Netz geht
Hi.
Ja, hast Recht … beide Wege funktionieren. Die Sache mit dem Full-Backup spricht für den HyperVisor – und LXC/LXD schluckt ja kaum Ressourcen. Leider konnte ich mein altes Backup von Version 1.2.4 nicht unter 1.5.0 einspielen, per WebGUI geht’s jetzt gar nicht mehr. Aber genauso wenig lief es über die Shell mit „omd restore“. Es scheint zu alt oder inkompatibel zu sein!?!
Und seltsamerweise habe ich auch mit Version 1.5 und dem aktuellen check_MK-Agent das Problem von oben:
Inventory failed for this host:…
Seltsam … hat vorher nie Probleme gemacht…
Schöne Grüße,
Michael
Ja, das hatte ich bereits ausprobiert – und funktioniert in der Server-Shell problemlos
( beide Versionen: check_MK_agent 1.2 wie auch 1.5). Es ist auch scheinbar nur dieser zu überwachende Server betroffen. Ich hatte ihn unter check_MK auch schon komplett entfernt und neu aufgenommen … gleiches Ergebnis.
Seltsam, oder?
Michael
Hallo Frank (@ironiemix).
Ich pushe diesen Thread nochmal nach oben, da das Thema wieder aktuell wird: Der MoniPi mit check_MK 1.2 auf dem guten alten Raspi2 ist nun doch sehr in die Jahre gekommen. Zwar macht er noch das, was er soll, aber ein Update auf eine aktuelle Version wäre nicht sooo schlecht.
Du meintest in einem anderen Thread, dass dein check_MK-Monitoring völlig extern läuft und einen Tunnel in dein Schul-Servernetz aufmacht. Das ist eine gute Sache; würde ich mit OPNSense & Wireguard vielleicht nachmachen!? Hat das schon mal jemand auf diesem Weg gemacht?
Die Alternative wäre ein neues Image auf einem Raspi3 wie das oben bereits verlinkte: GitHub - chrisss404/check-mk-arm: Checkmk for Raspberry Pi.
Aber dann hängt man wieder bei SD-Karten und|oder USB-Sticks, die alle Nase lang abrauchen.
Es gibt von offizieller Seite ja auch einen fertigen docker-Container – aber auch da habe ich bisher keine Erfahrungswerte. Ihr?
für mich ist das ziemlich tot. Der Raspi reicht nur für kleine Installationen, weil check_mk schon auch Ressourcen braucht, das ständige hinterherrennen hinter einem ARM build nervt.
Check MK ist in 5 Minuten auf einem CX11 für 2,98 im Monat installiert, da lohnt der Aufwand einfach nicht, weil ich für den Preis eines Raspi schon mal 12 Monate Monitoring habe.
Zum Monitoring durch die FW kann man dann vorgehen wie man möchte (und kann), VPN, SSH Tunnel oder Check-MK Multisite.
Ist das Ubuntu-basiert? Wir haben einen dicken vServer (für die Homepage und moodle bei einem Provider). check_MK wäre auch dort gut untergebracht – wenn da nicht die Sache mit dem Tunnel wäre. Ich weiß wie gesagt nicht, wie gut oder schlecht wireguard auf so einem System laufen würde…?!
Wenn du das Playbook eh schon fertig hast, wäre ein Upload vielleicht auch für andere ganz hilfreich?!
Hallo Frank.
Mittlerweile ist v1.6p12 installiert – nicht mehr auf 'nem Pi, sondern auf „richtiger x86 Hardware“. Das läuft auch wunderbar; auch wenn man leider die Konfiguration vom alten 1.2er System nicht mehr einspielen kann. Aber da die Hosts eh in ein eigenes Management-Netz kommen, müssen sie eh alle angepasst werden … von daher ist Handarbeit angesagt.
Was ich Dich aber noch fragen wollte: Du hattest daaaamals mal von einem Monitoring-Tool für’s Smartphone oder den Desktop erzählt. War das aNag?
Es gibt im Playstore neuerdings auch „Probe for OMD and Nagios“ – weiß aber nicht, ob das was kann. Kennst du das?
Die Alarmierung per eMail ist vermutlich nicht so eine gute Idee – bzw kann es nervig werden (je nachdem, wie granular man alles eingestellt hat…)?!?
Daher nochmal nachgefragt: Wie machst du das?
Dein checkMK_Unifi-Plugin habe ich als nächstes auf der to-do-Liste. (OT: Wobei ich mich da ja weiterhin die ganze Zeit frage, ob wir die Unifi-APs nicht demnächst nachts/am Wochenende/an Feiertagen/während der Ferien abschalten sollten?!?
In den unifi-Settings kann man ja das entsprechende WLAN-Signal zeitgesteuert „abschalten“ – ich weiß aber nicht, wie sich der AP selbst verhält, wenn er nichts mehr zu tun hat. Geht der dann in einen „Stromsparmodus“? Hat das mal jemand von Euch gemessen? Das würde uU ja schon viel ausmachen, wenn man die Dinger nicht jede Nacht per PoE oder Steckdose abschalten will oder kann…)
)
Klingt für mich nicht vernünftig?!
