Der x22-Backfill meldete "Zeitraum: 03.12.2024 .. 14.09.2026" und liest sich
damit wie zwei Jahre Historie. Tatsaechlich enthielt die Quelle EINEN einzelnen
Punkt vom 03.12.2024 (eine alte Logzeile) und sonst 30 Tage:
belegte Stunden: 721 von 15.601 im Zeitraum (4.6 % Abdeckung)
groesste Luecke: 620 Tage 03.12.2024 21:00 -> 15.08.2026 22:00
min..max allein sagt nichts ueber die Substanz. Die Selbstpruefung nennt jetzt
zusaetzlich die Zahl der belegten Stunden gegen die Spanne, die prozentuale
Abdeckung und — bei unter 50 % — die drei groessten Luecken mit Datum, plus den
Hinweis auf fehlende/rotierte Logs als typische Ursache.
Verifiziert gegen drei Faelle: (A) 1 alter Punkt + 30 Tage -> 4.6 %, Luecke
benannt; (B) 15 Tage durchgehend -> 100 %, kein Alarm; (C) 29 Tage mit 20-h-
Luecke -> 97.3 %, kein Alarm (echte kleine Luecken sind normal).
x22-log-backfill.sh heisst jetzt keyhelp-log-backfill.sh und leitet NODE aus
hostname -f ab, wenn es nicht gesetzt ist. Damit ist derselbe Ablauf fuer x14
nutzbar, ohne x22 im instance-Label zu tragen.
Der alte Name bleibt als Alias erhalten (laedt das generische Skript, NODE
vorbelegt auf x22) — bereits verteilte Aufrufe laufen weiter.
Verifiziert im Container mit x14-Nachbau: instance="x14.idx.wf-keyhelp",
Messmodus read-only, Selbstpruefung (Einheit/Zukunft/Domains) greift.
mm