Wie ein Verbindungslimit der Datenbank fast die Macs meiner Kunden neu gestartet hätte
Wir betreiben eine kleine Flotte von Mac minis für Kunden. Ein Daemon auf einem Hub fragt jede Maschine per SSH ab, schickt Telemetrie an eine Control Plane und eskaliert, wenn eine Maschine verstummt. Zuerst wartet er. Dann startet er die Maschine über eine smarte Steckdose stromlos neu. Dann ruft er einen Menschen.
Letzte Woche lieferte die Control Plane plötzlich 500er. Dreizehn Minuten später hielt der Daemon alle vier Macs für tot und protokollierte für jeden einen Neustart per Strom. Zwei gehörten zahlenden Kunden. Ein dritter war an diesem Morgen verkauft worden.
Was wirklich ausgefallen war
Ein Datenbank-Verbindungspool. Die Control Plane läuft auf Serverless-Funktionen gegen einen Postgres-Pooler, der projektweit auf fünfzehn Verbindungen begrenzt ist. Ein paar warme Funktionen belegten alle, und jede API-Route mit Datenbankzugriff schlug fehl. Die Details stehen in einem eigenen Beitrag.
Die Macs waren in Ordnung. SSH funktionierte. Jede GUI-Sitzung lief. Der Kunde, der gerade auf einem davon baute, merkte nichts. Kaputt war nur das System, dessen Aufgabe es war zu wissen, ob die Macs kaputt sind.
Wie eine gesunde Flotte tot aussah
Der Daemon speicherte pro Maschine einen Zeitstempel: die letzte erfolgreiche Abfrage. Die Eskalationslogik verglich ihn mit jetzt. Die Abfrage holte, durchaus vernünftig, zuerst die Maschinenliste von der Control Plane. Schlug das fehl, brach sie früh ab.
Während des Ausfalls lief also keine Abfrage, kein Zeitstempel rückte vor, und alle Lücken wuchsen gemeinsam. Die Eskalationslogik wusste nicht, dass der Daemon es gar nicht versucht hatte. Sie sah dreizehn Minuten Schweigen von vier Maschinen und tat, wofür sie gebaut war.
ladder: Unit 02 unreachable 12m51s → power cycle ladder: Unit 03 unreachable 12m51s → power cycle ladder: Unit 04 unreachable 12m51s → power cycle ladder: Unit 05 unreachable 12m43s → power cycle
Warum nichts neu startete
Es war keine smarte Steckdose eingerichtet. Der Schritt für den Neustart per Strom suchte eine Steckdose, fand keine und machte weiter. Danach zeigten die vier Maschinen Laufzeiten von sechs Tagen, sechs Tagen, einem Tag und etwa einer Stunde. Nichts war angefasst worden.
Das ist Glück, kein Design. Smarte Steckdosen sind für die nächste Charge Maschinen geplant. Wären sie schon montiert gewesen, hätte ein Verbindungsproblem der Datenbank drei Kunden-Macs den Strom abgedreht. Einer davon war womöglich mitten in einem Build. Keiner hatte etwas falsch gemacht.
Die Lösung
Der Daemon speichert jetzt, wann er zuletzt die Maschinenliste abrufen und die Maschinen tatsächlich ansprechen konnte. Die Eskalationslogik handelt nur, wenn das kürzlich passiert ist. Und sie protokolliert den Grund: Der Fehler liegt bei der Control Plane, nicht bei den Maschinen.
ladder: skipped, no successful unit poll in 14m02s (control plane, not the units)
Diese Zeile sagt genau, was sie verweigert und warum. So hätte die alte Zeile schon beim ersten Mal lauten sollen.
Die Regel dahinter ist einfach. Eine Fehlerbehebung muss einen Beleg verlangen, dass die Prüfung gelaufen ist. "Wir haben versucht, ihn zu erreichen, und sind gescheitert" ist ein Beleg. "Wir haben nichts von ihm gehört" ist keiner. Genauso sieht nämlich auch ein Ausfall des Zuhörers aus.
Was Sie in Ihrer eigenen Automatisierung testen sollten
Wir hatten getestet, was passiert, wenn ein Mac stirbt. Wir hatten nie getestet, was passiert, wenn das stirbt, was die Macs überwacht. Das sind nicht dieselben Tests. Und beim zweiten greift das System zum Stromschalter.
Fragen
- Sollten Wiederherstellungsschritte wie ein Neustart per Strom überhaupt automatisch laufen?
- Ja, aber nur bei einem positiven Beleg, dass das Ziel selbst ausgefallen ist. Ein Schritt, der beim Fehlen von Informationen auslöst, löst bei jedem Ausfall dessen aus, was die Informationen sammelt.
- Wie testet man das, ohne die Produktion kaputtzumachen?
- Legen Sie den Beobachter lahm, nicht die Knoten. Sperren Sie dem Daemon den Weg zu seiner Control Plane und beobachten Sie, was die Fehlerbehebung entscheidet. Eskaliert sie, schließt sie aus Schweigen.
- Was ist der richtige Schwellenwert für unerreichbar?
- Länger als jede erwartbare kurze Störung der Control Plane. Und er sollte erst nach einem gescheiterten Versuch zu zählen beginnen, den Knoten zu erreichen. Nie ab dem Zeitpunkt, an dem der Knoten zuletzt zufällig gesehen wurde.
Rechnen Sie selbst nach mit dem Kostenrechner oder mieten Sie einen Runner.