🌐 Auch auf: English · Français · Español
Zeit für ein Geständnis. Vor einiger Zeit habe ich festgestellt, dass fail2ban auf meinem Server zwei Tage lang tot war – und ich hatte keine Ahnung. Eine Konfigurationsdatei zeigte auf einen Log-Pfad, den es nicht mehr gab, fail2ban weigerte sich zu starten, systemd zuckte mit den Schultern, und das Ganze saß einfach… nur da. Hat niemanden gebannt. Ganz still und leise. 🙈 Das Gruselige ist nicht, dass ein Dienst gestorben ist – Dienste sterben nun mal. Das Gruselige ist, dass mir nichts Bescheid gesagt hat. Eine Sicherheitsmaßnahme kann ausfallen und alles offen lassen, und du merkst es erst, wenn du gezielt nachschaust. Also habe ich das Vernünftige getan und einen Watchdog eingebaut, dessen einziger Job es ist, zu bemerken, wenn etwas schiefläuft, und mich dann anzubrüllen.🤔 Warum Monit (und kein selbstgebasteltes Skript)
Mein erster Impuls war ein kleines Bash-Skript mit Cron-Timer. Dann fiel mir ein: Das Problem ist längst gelöst, und wer Monitoring neu erfindet, landet bei einem Watchdog, der selbst still und leise ausfällt. Es gibt etablierte Werkzeuge: Prometheus + Alertmanager (super, wenn du sowieso schon in dieser Welt lebst), Icinga/Zabbix (hervorragend, aber für eine Hobby-Kiste mit Kanonen auf Spatzen geschossen) und Monit – ein winziger, spezialisierter Daemon, der genau eine Sache gut macht: Dienste und Ressourcen überwachen und Alarm schlagen (oder automatisch neu starten), wenn sie sich danebenbenehmen. Für einen Blog auf Homelab-Niveau hat Monit vor allem aus einem Grund gewonnen: Es alarmiert nicht nur, es kann sich selbst heilen. Stirbt fail2ban, startet Monit es neu und schickt mir eine Mail. Aus dem zweitägigen Ausfall wäre ein zweiminütiger Aussetzer plus Vorwarnung geworden.📦 Voraussetzungen & Installation
- AlmaLinux 9 mit aktiviertem EPEL (dort wohnt Monit):
dnf install monit– du bekommst Monit 6.0. - Ein funktionierendes Mail-Relay. Ich hatte
msmtpfür die rkhunter-/ClamAV-Alarme schon auf meinen Provider eingerichtet, also konnte Monit dieselben Zugangsdaten nutzen. - Root, weil Systemdienste, Firewall und Festplatte geprüft werden.
/etc/monitrc (Daemon-
Einstellungen + Mail-Relay) und eine Drop-in-Datei mit Checks in /etc/monit.d/.⚙️ Was es tatsächlich prüft
Die Philosophie: Schweigen, solange alles gesund ist. Monit mailt nur bei einer Zustandsänderung – etwas Gesundes fängt an zu versagen, oder etwas Kaputtes erholt sich. Ein ruhiges Postfach bedeutet eine gesunde Kiste, also ist eine Mail von Monit nie bloßes Rauschen.- 🥷 fail2ban – der Ehrengast. Automatischer Neustart über systemd; will es partout nicht oben bleiben, hört Monit mit dem Hin und Her auf und schickt stattdessen einen „Ich geb’s auf“-Alarm. Genau der Fehler, mit dem alles anfing, würde jetzt erkannt.
- 🔌 sshd, k3s, node_exporter, Prometheus, Grafana – Alarm, wenn die systemd-Unit nicht aktiv ist.
- 🧱 Firewall – nicht nur „läuft die Unit“, sondern „steht die Input-Chain von nftables wirklich auf Default-Drop“. Eine Firewall, die geladen, aber geleert ist, ist schlimmer als nutzlos, also prüfe ich den tatsächlichen Zustand.
- 📦 K3s-Pods – alles, was in CrashLoopBackOff / ImagePullBackOff / OOMKilled / Error hängt.
- 💽 Festplatte, Last, Speicher – der langweilige Ressourcenkram, der Server um 3 Uhr nachts still und leise umbringt.
check process fail2ban with pidfile /run/fail2ban/fail2ban.pid
start program = "/usr/bin/systemctl start fail2ban"
if does not exist then restart
if 3 restarts within 5 cycles then timeout
check program firewall with path "/usr/local/sbin/monit-check-firewall.sh"
if status != 0 then alert📧 Die Mail-Falle (eine gute Stunde meines Lebens)
Jetzt kommt der Teil, der dir Zeit spart. Mein funktionierendesmsmtp-Setup nutzte STARTTLS auf Port 587. Also habe ich Monit natürlich genauso
konfiguriert. Monit scheiterte prompt mit:Mail: Authentication failed -- no supported authentication methods foundusing
ssl bedeutet implizites SSL, dessen Standardport 465 ist,
nicht 587. Auf 587 redete Monit im Klartext, der Server bot vor STARTTLS (das nie
passierte) kein AUTH an, und Monit folgerte, es gebe „keine unterstützten
Authentifizierungsmethoden“. 🤦 Um zu beweisen, dass das Relay selbst in Ordnung war (und keinem Phantom hinterherzujagen),
habe ich die Zugangsdaten direkt mit ein paar Zeilen Python smtplib getestet –
auf beiden Ports klappte die Anmeldung sauber, und der Server bot AUTH PLAIN
LOGIN an. Also: Relay gut, Monit-Konfiguration falsch. Die Lösung war ein Wort und eine
Zahl:set mailserver smtp.example.com port 465
username "..." password "..."
using ssl🧪 Wie ich es getestet habe (auf die ehrliche Art)
Ein Watchdog, den du nie bellen gehört hast, ist bloß Deko. Also habe ich ihn bellen lassen. Ich habe einen ungefährlichen, unkritischen Dienst gestoppt (node_exporter), mit monit validate einen sofortigen Check erzwungen, statt auf den nächsten Zyklus
zu warten, und zugeschaut. Dann habe ich den Dienst wieder gestartet, um den Weg der
Wiederherstellung zu bestätigen. Das hier ist tatsächlich in meinem Postfach gelandet – ein
Ausfall, eine Wiederherstellung und (aus einem zweiten Durchlauf) noch ein Ausfall:Monit on www.apt-upgrade.me reported:
Status failed: svc_node_exporter
at Tue, 28 Jul 2026 08:33:52
Action: alert
status failed (1) -- systemd service 'node_exporter' is inactive (expected: active)
-- Monit watchdogMonit on www.apt-upgrade.me reported:
Status succeeded: svc_node_exporter
at Tue, 28 Jul 2026 08:35:53
Action: alert
status succeeded (0) -- no output
-- Monit watchdogMonit on www.apt-upgrade.me reported:
Status failed: svc_node_exporter
at Tue, 28 Jul 2026 08:37:04
Action: alert
status failed (1) -- systemd service 'node_exporter' is inactive (expected: active)
-- Monit watchdog
