Diese Woche sitze ich vor dem Log meines Kamerasystems auf dem Heimserver und sehe, was ich nicht sehen wollte: Der Heartbeat läuft weiter, obwohl der rclone-Prozess längst abgestürzt ist. Das System hält sich für lebendig, ist es aber nicht.
Genau dafür gibt es einen Dead Switch, und genau an dieser Stelle hatte meiner einen blinden Fleck.
App-Architektur im Kleinen: Lebenszeichen richtig definieren
camera-s3-stream ist ein privates Sicherheitssystem für meinen Heimserver. IP-Kameras streamen per RTSP, ffmpeg schneidet Segmente, und rclone schiebt die Stücke in einen S3-Bucket. Ein eigener Heartbeat-Prozess meldet sich regelmäßig bei einem Dead-Switch-Endpunkt. Solange er sich meldet, ist alles gut. Bleibt er aus, gibt es Alarm.
Das klingt wasserdicht, war es aber nicht.
Das Problem war eine versteckte Kopplung: Der Heartbeat hing am Exit-Code von rclone. Wenn rclone hängenblieb, also nicht abstürzte, sondern einfach keine Segmente mehr übertrug, lief der Heartbeat trotzdem weiter. Der Dead Switch bekam weiter sein Signal. Es gab keinen Alarm und keinen Hinweis, nur Stille.
In einem Überwachungssystem ist das die gefährlichste Art von Fehler: kein Absturz, kein Eintrag im Fehlerlog, es kommen einfach keine Daten mehr.
Die Korrektur besteht aus zwei Teilen.
Erstens bekommt ffmpeg jetzt einen ausdrücklichen RTSP-Timeout (-timeout 10000000, also zehn Sekunden in Mikrosekunden). Bisher konnte ffmpeg bei einer hängenden Kameraverbindung unbegrenzt festhängen. Jetzt bricht es sauber ab, statt still zu blockieren.
Zweitens ist der Heartbeat jetzt von rclone entkoppelt. Er prüft nicht mehr, ob rclone erfolgreich war, sondern ob tatsächlich ein frisches Segment im Ziel-Bucket angekommen ist. Konkret: ob sich der Zeitstempel des neuesten Objekts innerhalb eines festgelegten Fensters verändert hat. Ohne frisches Segment kein Heartbeat, ohne Heartbeat Alarm.
Das ist ein grundlegend anderer Ansatz. Vorher zählte, ob der Prozess lebt, jetzt zählt, ob er etwas liefert. Der zweite Maßstab ist strenger und ehrlicher.
Ich muss zugeben, dass ich diese Lücke länger kannte, als mir lieb ist. Ich hatte sie als “theoretisches Problem” abgehakt. Diese Woche habe ich verstanden, warum das keine gute Idee war.
Ablaufdiagramm: Dokumentation, die stimmt
Der zweite Commit dieser Woche war Dokumentation, aber nicht die kosmetische Sorte.
Das bestehende Ablaufdiagramm zeigte noch den alten Weg, auf dem der Heartbeat am Exit-Code von rclone hing. Nach dem Umbau stimmte das nicht mehr. Ein Diagramm, das einen falschen Zustand beschreibt, ist schlimmer als gar keins, weil es einem das Gefühl gibt, das System zu verstehen, obwohl man es nicht tut.
Ich habe das Diagramm aktualisiert und die Bedeutung des Heartbeats ausdrücklich aufgenommen: welches Signal als Lebenszeichen durch ein frisches Segment gilt, welches Zeitfenster akzeptabel ist und was passiert, wenn es überschritten wird. Zwei Stunden Arbeit für etwas, das kein Nutzer je sieht. Trotzdem war es die richtige Entscheidung.
Was das mit App-Entwicklung zu tun hat
Systeme, die still versagen, sind in der Praxis das schwierigste Problem, ob es nun um ein Kamera-Backup, eine mobile App oder einen Hintergrundprozess in einem Geschäftssystem geht. Ein Absturz fällt auf. Ein Prozess, der läuft, aber nichts tut, bleibt wochenlang unbemerkt.
Wenn Sie eine App bauen lassen, lohnt es sich, diese Frage früh zu stellen: “Wie merken Sie, dass das System still versagt?” Wer darauf keine klare Antwort hat, hat das Problem noch nicht durchdacht. Auf meiner Leistungsseite beschreibe ich, wie ich solche Fragen von Anfang an in die Architektur einbaue.
Nächste Woche bekommt wahrscheinlich AutoBrew etwas Aufmerksamkeit. Was genau, entscheide ich zu Wochenbeginn, je nachdem, wie weit die Prüfung des aktuellen Builds im App Store bis dahin ist.