73 lines
3.9 KiB
Markdown
73 lines
3.9 KiB
Markdown
# Failover-Poller Reaktivierung + Update-Cadence (2026-08-06)
|
||
|
||
## Ausgangslage
|
||
|
||
- Am **2026-08-03** wurde `mesh-master-poller.sh` deaktiviert (Flag `AUSFALL_FALLBACK_AKTIV=0`),
|
||
weil das **30s-Fenster zu aggressiv** war: `VERPASST=30` < 1 Polling-Zyklus (30–60s), wodurch
|
||
jeder frische Task (HelloWorld, Wissensbasis) fälschlich auf `ziel_agent='beliebig'` umgeleitet wurde.
|
||
- Am **2026-08-06** (Nutzer zufrieden mit Systemzustand) wieder aktiviert — aber **robust** statt aggressiv.
|
||
|
||
## Nutzer-Grundregel (WICHTIG)
|
||
|
||
> „zeiten erfragen noch mit problemlöser vorher!!!" — **bevor Betriebs-Zeitparameter (Failover-Fenster,
|
||
> Polling-Intervalle) gesetzt werden, IMMER den Problemlöser konsultieren**, nicht eigenmächtig raten.
|
||
> Ablauf: `mesh-task-create.sh UnraidHermes "<auftrag>" brainstorming high 0.5 "<Briefing + JSON-Frage>"`
|
||
> an einen online-rechenstarken Agenten (UnraidHermes), Ergebnis-JSON validieren, DANN umsetzen.
|
||
> Der 03.08.-Fehler kam genau von Setzen ohne Abstimmung.
|
||
|
||
## Vom Problemlöser (UnraidHermes) empfohlene Parameter
|
||
|
||
```json
|
||
{
|
||
"verpasst_sekunden": 180,
|
||
"modus": "nur_alarm",
|
||
"ping_check": true,
|
||
"begruendung": "180s = 3 volle Polling-Zyklen bei 30-60s Cron-Intervall. Nur-Alarm statt auto_relabel verhindert Fehlumlackierung wie am 03.08. Ping-Check: Alarm feuert nur wenn Ziel-Agent wirklich down, nicht bei Latenz/Auslastung."
|
||
}
|
||
```
|
||
|
||
Begründung:
|
||
- **180s statt 30s:** 30s war < 1 Zyklus → jeder frische Task sofort "verwaist". 60s = 1 Zyklus (zu knapp,
|
||
kein Cron-Jitter-Puffer). 180s = 3 Zyklen → ein online Agent hat 3 Chancen den Task zu sehen; ein
|
||
beschäftigter Agent wird nicht fälschlich als weg erkannt.
|
||
- **Ping-Check:** `ping -c1 -W2 <zt-ip>` vor Alarm; nur wenn Ziel wirklich down → Alarm. Verifiziert
|
||
2026-08-06: frischer Task = still, alter Task + online Agent = still (kein Fehlalarm). Laptop war
|
||
wieder online → korrekt kein Alarm.
|
||
- **Modus `nur_alarm`:** schreibt nur `AUSFALL_ALARM` ins Event-Log `/srv/work/log/events.jsonl`,
|
||
Master entscheidet manuell. Kein Auto-Relabel (die Wurzel des 03.08.-Bugs). Späteres Upgrade auf
|
||
`auto_relabel` NUR nach nachgewiesener Ping-Erkennungs-Stabilität.
|
||
|
||
## Umsetzung in mesh-master-poller.sh
|
||
|
||
- `AUSFALL_FALLBACK_AKTIV=1`
|
||
- `VERPASST=180`
|
||
- Schleife über `offen/*.json`: Alter = `now - anlage_ts`; wenn `>180s` → Agent-IP aus Registry auflösen,
|
||
Ping-Check; wenn online → `continue` (kein Alarm); wenn down → Event-Log-Eintrag (`AUSFALL_ALARM`).
|
||
- Cron: `* * * * * /usr/local/bin/mesh-master-poller.sh >> /var/log/mesh-poller.log 2>&1` (alle 60s).
|
||
- Kein Auto-Relabel, kein `beliebig`.
|
||
|
||
## Update-Cadence (Nutzer-Entscheid 2026-08-06)
|
||
|
||
Brainstorming über Rhythmus (Technik/KI-Experte/Nerd/Kaufmann) ergab: **wöchentlich** statt täglich.
|
||
|
||
| | täglich | alle 3 Tage | **wöchentlich** |
|
||
|---|---|---|---|
|
||
| Risiko | klein, oft | mittel | kumuliert, 1× gebündelt |
|
||
| Aufwand | 28×/Monat | 10×/Monat | **4×/Monat** |
|
||
| Mesh-Sync | ständig driftend | ok | 1× sauber synchron |
|
||
|
||
Politik:
|
||
- **Sicherheits-Hotfixes** (SSH, Auth, Keys, ZeroTier) → **sofort**, nicht warten.
|
||
- **Feature-/Routine-Updates** → wöchentlich gebündelt; alle 4 Agenten in einem Zug + 1× Verifikation.
|
||
- Changelog vor dem Durchziehen kurz auf Breaking-Changes prüfen.
|
||
- Umsetzung: Cron-Job `mesh-hermes-wochenupdate` (Mo 06:00, deliver=telegram, no_agent) ruft
|
||
`/root/.hermes/scripts/update_mesh.sh` — updatet Master + UnraidHermes .34.142 + SwitchHermes .20.26 +
|
||
LaptopHermes .178.202 synchron (`hermes update --yes` via SSH + sshpass), verifiziert Versionen.
|
||
Stille bei "kein Update nötig"; Meldung nur wenn es was zu tun gibt/Problem.
|
||
|
||
## Verifikations-Hinweis
|
||
|
||
- Der Alarm-Zweig (echte Down-IP) konnte an dem Tag live nicht mehr getestet werden (alle Agenten online;
|
||
destruktiver Test wurde angehalten). Kern-Verhalten (frisch=still, alt+online=still) verifiziert; der
|
||
Down-Pfad ist trivialer Code, aber als "validiert" erst nach einem echten Ausfall anzusehen.
|