Checkmk-Überwachung von Läufen und Hängern #15

New issue

Closed

opened 2026-10-15 17:08:54 +02:00 by thorsten.spille · 0 comments

thorsten.spille commented

2026-10-15 17:08:54 +02:00

Owner

Ziel: verlässlich erkennen, dass eine Replikation nicht ins Stocken gerät – auch wenn zsync in einem Deadlock hängt, weil ZFS darunter blockiert. Ein Pidfile allein reicht nicht: ein hängendes zfs receive sieht aus wie ein langer gesunder Lauf.

zsync berichtet (rein additiv):

/run/bashclub-zsync/<config>.state: pid, Prozessstartzeit (gegen PID-Wiederverwendung), Phase (list_source | snapshot | send | delete | checkzfs), Dataset, Zeitstempel je Schritt
per trap EXIT /var/lib/bashclub-zsync/<config>.last: Ende, rc, Dauer, Datasets ok/fehlerhaft
Historie der letzten ~10 Startzeiten

Local Check (nur Dateien + /proc, kein zfs-Aufruf, keine eigene Sperre – Halter per lslocks), ein Service pro Config:

Zustand	Erkennung	Status
letzter Erfolg zu alt	siehe Intervall unten	WARN/CRIT
Lauf fehlerhaft	rc≠0	WARN
Phase hängt	Phasen ohne Transfer dauern > X min	WARN/CRIT
Transfer stockt	`/proc/<pid>/io` von `zfs receive` ändert sich über N Prüfungen nicht	CRIT
ZFS blockiert	Prozesse im Baum > X min im Zustand D, `wchan` (z. B. `txg_wait_synced`) im Text	CRIT
abgestürzt	state „läuft“, PID tot oder fremd (OOM, kill -9, Reboot)	WARN
Überlappung	zweiter Lauf an der Sperre abgewiesen	WARN

Metriken: Laufzeit, Bytes, Datasets ok/fehlerhaft, Alter des letzten Erfolgs.

Erlaubtes Alter ohne Pflicht-Config:

Intervall: bei systemd-Timer exakt aus dem Timer, sonst Median der letzten Startabstände (robust gegen Handläufe); optional monitor_max_age als Override, 0 = aus (Wechseldatenträger)
erlaubt = Intervall + max(20 %, 5 min) + Dauer des letzten erfolgreichen Laufs, gemessen ab Ende des letzten erfolgreichen Laufs; WARN ab dem ersten verpassten Lauf, CRIT nach ~3 Intervallen
Lernphase bis 5 Startabstände: ohne bekannten Abstand OK („Lernphase 0/5“), danach vorläufiges Intervall mit höchstens WARN (zu frühes Warnen ist ok), nie CRIT; danach scharf. --reset-history startet die Lernphase neu (z. B. nach Änderung des Zeitplans)
Hänger-, Absturz-, D-Zustand- und rc-Prüfung sind vom ersten Lauf an voll aktiv
Servicetext nennt die Quelle des Intervalls, z. B. interval 24h (learned from 10 runs)

Auslieferung: Datei unter /usr/share/bashclub-zsync/checkmk/; postinst verlinkt nach /usr/lib/check_mk_agent/local/, wenn das Verzeichnis existiert (Classic- und Push-Agent); dpkg-Trigger für eine spätere Agent-Installation; Opt-out per /etc/bashclub/zsync-checkmk.disabled; postrm entfernt den Link. TrueNAS: manuelle Anleitung.

Grenze: Hänger auf der Quelle sind nur indirekt sichtbar (Transfer stockt); den Datenstand je Dataset prüft weiterhin checkzfs.

Braucht die Sperre pro Config. Vorschlag: direkt danach umsetzen, damit die übrigen Features schon überwacht getestet werden.

Rahmen: Default = bisheriges Verhalten, der Replikations-/Löschalgorithmus bleibt unverändert, optionale Tools werden per which erkannt (fehlen sie, läuft alles wie bisher mit Logmeldung). Eigener Branch/PR mit Test. Teil von 2.0.0, Reihenfolge siehe Roadmap.

**Ziel:** verlässlich erkennen, dass eine Replikation nicht ins Stocken gerät – auch wenn zsync in einem Deadlock hängt, weil ZFS darunter blockiert. Ein Pidfile allein reicht nicht: ein hängendes `zfs receive` sieht aus wie ein langer gesunder Lauf. **zsync berichtet (rein additiv):** - `/run/bashclub-zsync/<config>.state`: pid, Prozessstartzeit (gegen PID-Wiederverwendung), Phase (list_source | snapshot | send | delete | checkzfs), Dataset, Zeitstempel je Schritt - per `trap EXIT` `/var/lib/bashclub-zsync/<config>.last`: Ende, rc, Dauer, Datasets ok/fehlerhaft - Historie der letzten ~10 Startzeiten **Local Check (nur Dateien + /proc, kein `zfs`-Aufruf, keine eigene Sperre – Halter per `lslocks`), ein Service pro Config:** | Zustand | Erkennung | Status | |---|---|---| | letzter Erfolg zu alt | siehe Intervall unten | WARN/CRIT | | Lauf fehlerhaft | rc≠0 | WARN | | Phase hängt | Phasen ohne Transfer dauern > X min | WARN/CRIT | | Transfer stockt | `/proc/<pid>/io` von `zfs receive` ändert sich über N Prüfungen nicht | CRIT | | ZFS blockiert | Prozesse im Baum > X min im Zustand D, `wchan` (z. B. `txg_wait_synced`) im Text | CRIT | | abgestürzt | state „läuft“, PID tot oder fremd (OOM, kill -9, Reboot) | WARN | | Überlappung | zweiter Lauf an der Sperre abgewiesen | WARN | Metriken: Laufzeit, Bytes, Datasets ok/fehlerhaft, Alter des letzten Erfolgs. **Erlaubtes Alter ohne Pflicht-Config:** - Intervall: bei systemd-Timer exakt aus dem Timer, sonst Median der letzten Startabstände (robust gegen Handläufe); optional `monitor_max_age` als Override, `0` = aus (Wechseldatenträger) - erlaubt = Intervall + max(20 %, 5 min) + Dauer des letzten erfolgreichen Laufs, gemessen ab Ende des letzten erfolgreichen Laufs; WARN ab dem ersten verpassten Lauf, CRIT nach ~3 Intervallen - Lernphase bis 5 Startabstände: ohne bekannten Abstand OK („Lernphase 0/5“), danach vorläufiges Intervall mit höchstens WARN (zu frühes Warnen ist ok), nie CRIT; danach scharf. `--reset-history` startet die Lernphase neu (z. B. nach Änderung des Zeitplans) - Hänger-, Absturz-, D-Zustand- und rc-Prüfung sind vom ersten Lauf an voll aktiv - Servicetext nennt die Quelle des Intervalls, z. B. `interval 24h (learned from 10 runs)` **Auslieferung:** Datei unter `/usr/share/bashclub-zsync/checkmk/`; postinst verlinkt nach `/usr/lib/check_mk_agent/local/`, wenn das Verzeichnis existiert (Classic- und Push-Agent); dpkg-Trigger für eine spätere Agent-Installation; Opt-out per `/etc/bashclub/zsync-checkmk.disabled`; postrm entfernt den Link. TrueNAS: manuelle Anleitung. **Grenze:** Hänger auf der Quelle sind nur indirekt sichtbar (Transfer stockt); den Datenstand je Dataset prüft weiterhin checkzfs. Braucht die Sperre pro Config. Vorschlag: direkt danach umsetzen, damit die übrigen Features schon überwacht getestet werden. --- **Rahmen:** Default = bisheriges Verhalten, der Replikations-/Löschalgorithmus bleibt unverändert, optionale Tools werden per `which` erkannt (fehlen sie, läuft alles wie bisher mit Logmeldung). Eigener Branch/PR mit Test. Teil von 2.0.0, Reihenfolge siehe Roadmap.

thorsten.spille added this to the 2.0.0 milestone

2026-10-15 17:08:54 +02:00

thorsten.spille added the

enhancement

label

2026-10-15 17:08:54 +02:00

thorsten.spille referenced this issue

2026-10-15 17:08:54 +02:00

Roadmap 2.0.0 #16

thorsten.spille referenced this issue from a pull request that will close it,

2026-10-15 18:52:48 +02:00

Checkmk-Überwachung von Läufen und Hängern #19