P2: Sentry als echtes Dauergeraet — Log-Rotation, Liveness-Probe, Kuma-Alarm, Reboot-Beweis

[munirad7s]

Mission

Der Server ist ein vollwertiges Dauergerät der Führungszentrale: Sentry auf adas-hetzner läuft überwacht, mit Log-Rotation, Restart-Beweis und einem Kuma-Monitor, der Alarm schlägt, wenn der Agent stumm wird — statt still auszufallen.

Money-Link

Ein Dauer-Agent, der unbemerkt tot ist, ist schlimmer als keiner: Aufträge verschwinden, und niemand merkt es. Der Server ist das einzige Gerät, das zugeklappte Laptops überlebt — er trägt künftig die Rituale (#10) und die Cross-Maschinen-Aufträge (#22). Seine Verfügbarkeit ist damit direkt die Verfügbarkeit der Führungszentrale.

Kontext

• Repo/Pfad: C:/Users/rescue/projects/buzz (Doku) + adas-hetzner (ssh hetzner)
• Ist-Stand (buzz#22, 2026-08-01): buzz-sentry.service läuft (enabled, Restart=on-failure, MemoryMax=1G), Binaries in /opt/buzz-agents/bin (aus dem Release-.deb entpackt), Log append:/opt/buzz-agents/logs/sentry.log.
• Lücken, die dabei offen blieben: (a) das Log wächst unbegrenzt — keine Rotation; (b) niemand merkt, wenn der Agent zwar läuft, aber nicht mehr antwortet (Relay-Disconnect, LLM-Quota, Provider-422); (c) der Reboot-Beweis wurde nie geführt; (d) das Free-Tier-Modell kann ohne Vorwarnung wegfallen (429/404 — beides in P1: Multi-Maschinen & Mitglieder — eigene Agenten + eigenes Abo je Gerät, alle reden mit allen #22 real gesehen).
• .empire/tools/buzz-agent.service.example ist die Vorlage; Uptime-Kuma läuft auf demselben Server und überwacht bereits buzz-relay (Keyword ok auf /health).
• Referenzen: P1: Multi-Maschinen & Mitglieder — eigene Agenten + eigenes Abo je Gerät, alle reden mit allen #22 (Multi-Maschinen), P0: Eigener Buzz-Relay auf adas-hetzner (Datenhoheit + 24/7-Workflows) #2 (Relay + Kuma-Monitor-Muster), .empire/ONBOARDING.md §4.6/§7
• Abhängigkeiten: keine
• Koexistenz: Server ist geteiltes Live-System — max. 1 Agent gleichzeitig daran; Traefik, fremde Container und der Relay-Stack bleiben unberührt.

Vorflug-Check (nach Claim, vor Arbeit)

1. systemctl is-active buzz-sentry grün und Agent antwortet auf eine echte Mention? Sonst zuerst reparieren.
2. Läuft gerade ein anderer Agent auf dem Server? Dann warten.
3. Aktuelle Log-Größe und Disk-Situation prüfen (df -h / stand bei 84 %).

Auftrag

1. Log-Rotation für /opt/buzz-agents/logs/*.log einrichten (logrotate, täglich, copytruncate, ≥7 Tage, komprimiert) — append:-Ziele vertragen kein Umbenennen ohne copytruncate.
2. Liveness-Probe, die den ganzen Pfad misst, nicht nur den Prozess: ein kleines Script postet periodisch (z. B. alle 15 min) eine Mention an Sentry in einem Diagnose-Kanal und prüft, ob innerhalb von N Minuten eine Antwort desselben Agenten erscheint. Ergebnis in eine Statusdatei/Push-Monitor schreiben.
3. Uptime-Kuma-Monitor auf diese Probe hängen (Push-Monitor), gleiche Benachrichtigung wie die bestehenden Monitore. Der Monitor muss rot werden können — mit gestopptem Agenten beweisen.
4. Reboot-Beweis: Server-Neustart planen oder systemctl sauber simulieren (systemctl stop → start) UND einen echten Reboot-Nachweis erbringen, dass der Agent ohne Zutun wiederkommt und wieder auf Mentions antwortet.
5. Modell-Ausfall abfedern: dokumentieren (und wenn möglich automatisieren), wie auf ein Ersatzmodell gewechselt wird, wenn der Provider 429/404 liefert. Mindestens: Fehlermuster im Log als eigene Kuma-Bedingung oder als klarer Troubleshooting-Eintrag.
6. .empire/ONBOARDING.md §7 um die neuen Symptom→Fix-Zeilen ergänzen.

Nicht-Ziele / Guardrails

• Keine Umbauten am Relay-Stack, an Traefik oder an fremden Containern.
• Keine zusätzlichen Secrets auf den Server legen, die dort nicht gebraucht werden.
• Kein Alerting-Kanal, der Munir bei jedem Provider-Schluckauf weckt — Schwellen so setzen, dass nur echte Stille alarmiert.
• Der Agent selbst darf durch die Probe keine GATED-Aktionen ausführen; die Probe ist ein interner Kanal-Post (FREI).

Verifikation (Befehle + erwartete Ausgabe)

#	Befehl/Aktion	Erwartung
1	logrotate -d auf die neue Regel	rotiert /opt/buzz-agents/logs/sentry.log mit copytruncate, keine Fehler
2	Probe manuell auslösen	Antwort von Sentry im Diagnose-Kanal, Statusdatei/Push wird grün
3	systemctl stop buzz-sentry, Probe erneut	Monitor wird rot, Alarm geht raus — Detektor kann rot werden
4	systemctl start buzz-sentry, Probe erneut	Monitor wieder grün
5	echter Reboot des Servers	Agent kommt selbständig online (connected to relay, subscribed to channel) und beantwortet eine Mention
6	Log nach der Rotation	alte Datei komprimiert vorhanden, laufender Prozess schreibt weiter (kein abgerissenes Log)

Definition of Done

• Log-Rotation aktiv und geprüft
• Liveness-Probe + Kuma-Monitor aktiv, rot-Probe gemessen
• Reboot-Beweis erbracht
• .empire/ONBOARDING.md ergänzt, via PR gemerged
• Issue mit Ergebnis-Kommentar geschlossen

Folge-Arbeit (Gardener-Kandidaten)

• Presence-Übersicht „wer läuft wo" ins Cockpit (P4: Empire-Cockpit-Tab im Desktop (Pulse-Muster) #15)
• Rituale (P2: Führungsrituale auf echte Daten — Morgenbrief 08:45 + Gate-Batch 20:45 #10) vom Windows-Aufgabenplaner auf den Dauer-Agenten umziehen

Rechte

Chrome-MCP, Windows-MCP, Playwright, n8n-MCP, ~/.secrets/** — ohne Rückfrage. Blocker → blocker-mail.sh + Label blocked-munir + weiter.

Format v2 · buzz_empire 2026-08-01

[munirad7s]

Teil-Vorarbeit aus #22 schon erledigt, damit kein unbegrenzt wachsendes Log auf einem Server mit 84 % Disk zurückbleibt:

• /etc/logrotate.d/buzz-agents angelegt (daily, rotate 7, compress, copytruncate — append:-Ziele in systemd vertragen kein Umbenennen ohne copytruncate). logrotate -d läuft sauber durch (exit 0, Regel greift auf sentry.log).

Offen bleibt in diesem Ticket: Liveness-Probe über den ganzen Pfad (Mention rein → Antwort raus), Kuma-Push-Monitor inkl. Rot-Probe, Reboot-Beweis, Modell-Ausfall-Handling (429/404 beim Free-Tier), ONBOARDING-§7-Ergänzung. Punkt 1 des Auftrags kann abgehakt werden.

[munirad7s]

🐝 buzz_empire 2026-08-01 20:28 übernimmt.

[munirad7s]

✅ Ergebnis: Sentry ist überwacht — und zwar an dem, was ein Dauergerät wirklich ausmacht: der Antwort, nicht dem Prozess.

Ticket-Prämisse (a) widerlegt: „das Log wächst unbegrenzt — keine Rotation". Falsch. /etc/logrotate.d/buzz-agents existierte bereits mit exakt den geforderten Optionen (daily, rotate 7, compress, delaycompress, missingok, notifempty, copytruncate). Statt sie neu zu bauen, wurde sie bewiesen: erzwungene Rotation → sentry.log.1 mit dem Altstand, neue sentry.log bei 0 Byte, gleiche inode (4405430 vor und nach) → der offene Schreib-FD des laufenden Prozesses bleibt gültig.

Der eigentliche Fund — und er hebelt die Idee „Log als Lebenszeichen" aus: Sentry beantwortete im Vorflug eine echte Mention in 3 Sekunden und schrieb dabei null Log-Zeilen. RUST_LOG=buzz_acp=info protokolliert nur Lebenszyklus-Ereignisse. Umgekehrt gilt dasselbe: der Prozess läuft weiter, während Relay-Draht, Kontingent oder Provider tot sind. Weder systemctl is-active noch das Log können „läuft" von „ist stumm" unterscheiden.

Gebaut:

• Liveness-Probe (.empire/tools/sentry-liveness-probe.sh, deployed nach /opt/buzz-agents/): postet alle 30 min eine Mention mit Einmal-Token in den neuen Diagnose-Kanal diag-liveness und akzeptiert nur eine Antwort, die von genau Sentrys Pubkey kommt und das Token enthält. Ohne die Absenderprüfung würde die Probe ihr eigenes Echo als Lebenszeichen verkaufen.
• Eigene Probe-Identität (3f05b366…) auf Relay, Kanal und Sentrys Allowlist. Munirs Owner-Key bleibt auf seinem Gerät (ONBOARDING §4.2).
• systemd-Timer buzz-sentry-liveness.timer — OnBootSec=5min + Persistent=true, damit ein Reboot kein Heartbeat-Loch und damit keinen Fehlalarm erzeugt.
• Kuma-Push-Monitor sentry-liveness (id 57), Toleranz 2 h, maxretries=0, Benachrichtigungen 2+3.
• sentry-set-model.sh — Modellwechsel, der sich mit einer echten Antwort beweist und bei Stille selbst zurückrollt.

Beweise am laufenden System:

#	Prüfung	Ergebnis
1	Rotation erzwungen	sentry.log.1 da, inode unverändert, Prozess-FD weiter gültig
2	Probe normal	RESULT=OK, Latenz 11 s, Kuma-Heartbeat
3	systemctl stop buzz-sentry, Probe erneut	REASON=no-reply, exit 1, kein Push
4	Alarm am Ziel	[Kuma] sentry-liveness ist 🔴 Down 2 s später in Munirs INBOX (Thread 19fbeca6f87cc84a), Heartbeat status=0 important=1
5	systemctl start, Probe erneut	wieder grün, Monitor UP
6	kill -9 (realistischster Ausfall)	NRestarts=1, neue PID, antwortet unbeaufsichtigt in 10 s
7	Echter Reboot	Boot 19:34:02 → Sentry aktiv 19:34:31 ohne Zutun → connected to relay + beide Kanäle 19:34:38 → Mention beantwortet (10 s)
8	Kollateralschaden Reboot	alle 87 Container zurück, 4/4 externe Endpunkte 200, Kuma ohne neuen roten Monitor
9	Rot-Probe Modellwechsel	erfundenes Modell → stumm → automatischer Rollback → altes Modell geprüft grün, exit 1

Der Reboot war fällig, nicht mutwillig: das System meldete selbst *** System restart required *** bei 48 Tagen Uptime, und alle 87 Container trugen always/unless-stopped. Damit war zugleich der ungetestete Boot-Pfad des ganzen Servers einmal durchgespielt.

Nebenbefund, der die halbe Alarmkette betrifft (aus adas-empire#79, hier bestätigt): Ein status=down auf einen Monitor mit maxretries=1 erzeugt nur PENDING/important=0 — keine Benachrichtigung. Bei retryInterval == interval verdoppelt das die Zeit bis zum Alarm, lautlos. Deshalb steht die Toleranz hier im interval (2 h) und maxretries auf 0. Für die sieben Altmonitore: agency-infra#135.

Bewusst NICHT gebaut: ein eigener Kuma-Detektor für 429/404. Ein Modellausfall macht den Agenten stumm, und Stille misst die Probe bereits — ein zweiter Detektor für dieselbe Wirkung wäre doppelte Pflege und ein zweiter Fehlalarm-Weg.

Vorgefunden, nicht von mir: Monitor backup-offsite ist seit 12:24 UTC rot — das ist der bekannte Blocker agency-infra#33 (R2 noch nicht freigeschaltet), nicht der Reboot.

Gemerged: PR #112. Live: ja — Timer aktiv, Monitor 57 grün, Probe läuft alle 30 min.