archibald hat kein sudo und kein linger, aber Docker-Gruppe. Muster wie
bei der llama-swap-Telemetrie auf dem ROG: ein Nutzer-Cron fuehrt den
Exporteur aus, Telegraf laeuft als Container daneben und pusht per
Remote Write zum Collector im Mesh.
- scripts/archivebox-telemetrie.py: liest die ArchiveBox-Logs und die
SQLite-DB IM Container (Host-User mm darf index.sqlite3 nicht oeffnen,
Container-User 911 schon) und schreibt eine Prometheus-Exposition.
Kein node-Label -- das setzt Telegraf per global_tags.
- scripts/install-archivebox-telemetrie.sh: installiert Exporteur,
Cron-Eintrag (jede Minute) und den Container, mit --dry-run.
- stacks/telegraf-container/: telegraf 1.39, network_mode host,
inputs.file (data_format prometheus), outputs.prometheus_remote_write.
Warum: llama-swap laeuft als Nutzer-Unit. Der System-Telegraf liest das
Systemjournal mit priority>=warning und liest damit keine einzige
llama-swap-INFO-Zeile - Loki hatte fuer den ROG null Zeilen. Ausserdem kann
die System-Instanz auf einem Knoten ohne sudo nicht erweitert werden.
- scripts/llamaswap-telemetrie.py: Token/Anfragen je Modell aus llama-swaps
Statistik-API plus llama.cpp /metrics je laufendem Profil (Ports sind
dynamisch, deshalb kein statischer Scrape)
- scripts/llamaswap-logs.py: Nutzer-Journal (llama-swap, kalina-backends)
nach Loki, gleiche Zeilenform wie journal-tail.sh
- telegraf/llamaswap-user.conf + .service: Zugangsdaten per
EnvironmentFile=/etc/default/telegraf, keine Token-Kopie
- scripts/install-llamaswap-user.sh: idempotente Installation mit --dry-run
und Konfigurationspruefung
Die 10-s-Timeouts waren kuerzer als die gemessene Zustellzeit (11-19 s durch
den NetBird-Reverse-Proxy auf x05) -> jeder Batch brach ab. Gemessen: 702
abgelehnte Requests in 20 min, Metriken fehlten still.
Neu: scripts/docker-events-loki.py + Wrapper + systemd-Unit. Docker-Events
(Neustart/OOM/Stop) gehen nach Loki, Spool-Datei + Cursor statt RAM-Puffer.
Die .gz-Dateien INNERHALB eines Backfill-Tarballs sind nochmals
gzip-komprimiert; tarfile entpackt nur die aeussere Ebene. Wer den
Member-Inhalt direkt dekodiert, liest gzip-Magic als Text und verliert
jede Zeile dieser Dateien — real 68.975 von 404.825 (17 %).
- .gz-Member werden ein zweites Mal entpackt, die Zahl wird gemeldet
- --limit-lines greift jetzt auch im Tarball-Zweig
- Beispiele unlesbarer Zeilen zeigen den Dateinamen
Am Ziel gemessen: /tmp ist ein tmpfs mit 15 GB. Eine 10-GB-Rohdatei plus
Sortier-Temp liegt damit im Arbeitsspeicher und bringt Loki/den Rechner
in Bedraengnis. Der Importer prueft jetzt vorher den freien Platz und
bricht frueh ab; die Uebergabe geht nach /data/tmp (863 GB frei).
Der Collector laeuft als root (Logs unter /home/users mit 0700), seine
Ausgabe ist damit 0600 fuer root. scp als normaler Nutzer kam nicht an
die Datei: 'stat ... Keine Berechtigung'. Jetzt werden Kopien mit 644
in /tmp/rawlog-upload/ abgelegt — von beiden Seiten erreichbar.
Der Prometheus-Archiv-Import verdichtet auf Stunde/Domain/Status und
verwirft Referrer, User-Agent und Client-IP. Fragen nach der Herkunft
liessen sich damit nicht rueckwirkend beantworten.
- raw-log-collect.py: liest access+error (inkl. .gz, rotierte Dateien),
schreibt ts_ns/labels/rohzeile und meldet Zeilen ohne Zeitstempel
statt sie still zu verwerfen. Error-Logs ohne Zeitzone (Apache-
Standard) werden korrekt nach UTC verschoben.
- raw-log-backfill.sh: Wrapper mit Messmodus; sammelt auf dem Host,
importiert selbst NICHTS.
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.
Der Survey kennt kein argparse — '--node' wurde still ignoriert (harmlos, aber
irrefuehrend). Argument entfernt und die Puffer-Falle im Aufruf dokumentiert.
BEFUND (x22, gemessen und reproduziert):
Der Aufruf war 'python3 apache-log-survey.py 2>&1 | tee bestand.txt'. Das Skript
gab ALLES erst nach der Scan-Schleife aus (alle print() standen dahinter), und
Python puffert stdout in eine PIPE blockweise (4-8 KB). Die Gesamtausgabe ist
aber nur ~1 KB -> sie landete erst beim Prozessende in der Datei.
Messung mit 2 Mio Zeilen (140 MB):
mit tee: nach 5 s = 0 Bytes, fertig nach 41 s -> dann 1028 Bytes
ohne Pipe: nach 1 s = 0 Bytes
python3 -u: nach 1 s = 0 Bytes
=> Die Datei war leer, weil der Scan LIEF. Auf einem KeyHelp-Host mit tausenden
Logdateien dauert das Minuten und liest sich wie ein Haenger oder Absturz.
FIX (drei Massnahmen, damit das nie wieder passiert):
1. sys.stdout.reconfigure(line_buffering=True) — jede Zeile geht sofort raus,
auch durch eine Pipe.
2. Startbanner VOR dem Scan: Anzahl und Gesamtgroesse der Dateien.
3. Fortschrittszeile pro Datei (Nummer/Gesamtzahl, Zeilen, Groesse, Pfad) plus
eine Zeile fuer nicht lesbare Dateien.
Verifiziert mit 1,4 Mio Zeilen durch eine Pipe: nach 2 s steht das Banner, drei
Fortschrittszeilen erscheinen waehrend des Scans. Gegenprobe mit dem alten Code:
nach 3 s 16 Bytes, alles erst am Ende.
BEFUND (echter Datenverlust, gemessen gegen KeyHelp-Formate):
KeyHelp/Debian schreiben error.log im Access-Format, aber OHNE Zeitzone:
[01/Sep/2026:10:00:05] [core:error] [pid 9] AH00124: ...
TS_FORMATS kannte nur "%d/%b/%Y:%H:%M:%S %z" (MIT Zone). parse_ts() gab None,
hour wurde "unknown", und der Schreiber ueberspringt unknown-Zeilen:
apache_archive_errors_total fehlte KOMPLETT — kein Fehler, kein Log, Panel leer.
Genau die stille Fehlerklasse, die nicht passieren darf.
FIX:
- Format "%d/%b/%Y:%H:%M:%S" (ohne Zone) ergaenzt.
- Unparsbare Zeitstempel werden GEZAEHLT und laut gemeldet (Domain + Beispiel +
Hinweis auf TS_FORMATS) statt still zu verschwinden.
- Neu: scripts/x22-log-backfill.sh — messen (read-only) und parsen in einem
Aufruf, mit Selbstpruefung (Einheiten, Zukunft, Domain-Anzahl) VOR der
Uebergabe und dem sicheren Import-Befehl am Ende.
Verifiziert im Container gegen echte KeyHelp-Formate inkl. rotierter .1 und
.gz-Datei: Messmodus aendert nichts (MD5-Vergleich), Backfill erzeugt alle
fuenf Metriken inkl. errors_total{level=error} und {level=warn}.
Echte x22-Logs: 2000 Zeilen -> 286 Kollisionen (duplicate sample).
Telegraf uebernimmt den Log-Zeitstempel; bei mehreren Treffern pro Sekunde
kollidiert der +1ms-Aufschlag mit echten Zeilen. Prometheus weist den Batch
ab, Telegraf retryt endlos -> FIFO steht -> Node liefert GAR NICHTS mehr.
Fix: eigenes Grok-Muster mit log_time als Feld (Telegraf nutzt eigene ns-Uhr)
+ processors.converter, damit resp_code/verb Tags bleiben.
Gemessen: 2000/2000 Samples, 0 Kollisionen.
Ausserdem: Einheiten-Waechter im Archiver (ms statt s -> Abbruch statt
nutzloser Block).
kalina