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?
Schöne Grüße,
Michael
Hallo,
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.
Oder man nimmt was ganz anderes als Check_mk (Prometheus? https://en.wikipedia.org/wiki/Prometheus_(software)).
Ich persönlich finde check_mk immer noch top, macht halt keine so hübschen Bildchen, aber ich kenn mich halt aus.
Wenn Interesse besteht, könnte ich das Playbook zur Installation auf dem CX11 kommentieren und irgendwo ablegen.
VG
Frank
Hallo Frank.
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?!
Danke und schöne Grüße,
Michael
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…)
Schönen Gruß,
Michael