Vielleicht hat es jemand von euch mitbekommen: plantwatch.de war Anfang des Jahres für mehrere Tage down und zeigte einen HTTP 500-Fehler.

Der Grund dafür lag bei mir und meinem Hostingprovider, uberspace.de. Zum Jahreswechsel war die letzte Alphaversion von Uberspace 8 veröffentlicht worden.

Da ich grundsätzlich ein Freund von aktueller, wenn nicht gar bleeding-edge Software bin, habe ich Uberspace 8 zum Jahreswechsel, am 30.12.2025, getestet, für gut befunden und alle meine Webseiten auf Uberspace 8 migriert; ja nach der erfolgten Migration sogar den bestehenden Uberspace 7 „Asteroiden“ gelöscht.

Ein konsequenter, mutiger Schritt, der mir später auf die Füße fallen sollte. Uberspace 8 basiert nämlich auf Arch Linux, dessen rolling release Stand durch uberspace eingefroren wird. Updates mit breaking changes – wie der Entfernung einer Pythonversion – sollten durch dieses Einfrieren eigentlich zurückgehalten und – etwa durch Bereitstellung einer selbst kompilierten Pythonversion – abgemildert werden. Das Versionsupgrade von Python 3.13 auf 3.14, das durch die Arch Linux Packetquellen kam, ist uberspace allerdings durchgerutscht.

Im Ergebnis wurde die Executable von python3.13 entfernt, auf die mein venv (virtual environment) verlinkt hatte. Dadurch war der WSGI-Server, der plantwatch.de letztenendes bereitstellt, nicht mehr lauffähig. Und ohne WSGI-Server hat auch das verwendete Django-Webframework nicht mehr funktioniert. Im Ergebnis war die Seite down.

Mangels Monitoring fiel mir das anfangs auch nicht auf. Nachdem es mir aufgefallen ist, war die Fehlersuche vergleichsweise kurz. Nach Laden des venvs fehlte die Executable von python3.13. python –version brachte dann die Erleuchtung. Python 3.13 war durch Python 3.14 ersetzt worden und das venv verwies auf die nicht mehr vorhandene Python 3.13 Version. Die Lösung war denkbar einfach: Ein neues venv anlegen, die Abhängigkeiten installieren, die systemd unit anpassen und sie via systemd neu starten; das wars.

Verantwortlich für die Downtime war mein Faible für bleeding-edge und die Tatsache, dass ich kein Monitoring betrieben habe. Das hat sich inzwischen geändert. Bereits im August 2025 arbeitete ich an einer eigenen Monitoring-Software, sos (service orchestrating service). Geschrieben ist sie natürlich in Java 25 und Spring 4; beide waren im August 2025 noch nicht offiziell veröffentlicht worden. Sie überprüfte bisher jedoch nur auf laufende Prozesse, systemd-Dienste und Datenbankaktivität.

Inzwischen überprüft sie auch HTTP-Statuscodes. Downtimes wie die Letzte wären damit erkannt worden. So sieht sos aus:

Einen Design-Award wird sos nicht gewinnen, doch es erfüllt seinen Zweck. Es läuft auf meinem NAS und zeigt hier die laufenden HTTP-Applikationen, sowohl die lokalen, als auch die extern gehosteten Applikationen.

Dieser Vorfall hat mir die Wichtigkeit von Monitoring wieder deutlich gemacht. Er hat auch dazu geführt, dass ich mein NAS nicht wie eigentlich geplant auf Ubuntu 26.04 upgraden werde, sondern die bisherige Version 24.04 bis zum bitteren EOL betreiben werde; also (inklusive dem für Privatnutzer kostenlosen Ubuntu Pro) noch etwa 8 Jahre.

Bis dahin werde ich den RAM des NAS aufgerüstet haben müssen und vielleicht wird es den einen oder anderen Downtime von plantwatch.de gegeben haben. Im Gegensatz zum letzten Mal, wird er mir aber (hoffentlich) aufgefallen sein.