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
Zweites String-Feld derselben Klasse wie container_id: inputs.docker liefert
health_status="healthy". Telegraf macht daraus docker_container_health_health_status
und Prometheus antwortet 'bad sample value "healthy"' -> der ganze Flush faellt aus,
auch die Container-Statistiken, die damit nichts zu tun haben.
GEMESSEN auf kalina nach dem ersten Fix: genau EINE 'series were dropped'-Zeile
mit 862 Serien im haengenden Batch, last recorded error health_status. Nach dem
Zusatz: 0 E!, 0 dropped, docker_container_* wieder da (kalina 501, imac 1126
Serien).
Feldliste diesmal empirisch erzeugt statt geraten: telegraf --test des
docker-Inputs ohne Prozessoren, alle Felder mit Anfuehrungszeichen gesammelt --
es sind genau ZWEI (container_id, health_status).
VERSION 1.9.3 -> 1.9.4.
Ein permanenter 400 (vergifteter Batch) blieb am FIFO-Kopf und wurde endlos
wiederholt; die gepufferten Samples alterten dabei bis ueber die Akzeptanz-
grenze des Empfaengers (head_min_time ~2x Blockdauer) und waren danach
unzustellbar — der Knoten verstummte dauerhaft.
GEMESSEN 09.10.2026: 9 von 15 Nodes stumm, Sample-Versatz 185-1071 min
(konstant ueber 72 h), 1680 Ablehnungen/h, danach 'Metric buffer overflow'
= endgueltiger Verlust. Mit der Option wird der Batch verworfen statt
wiederholt ('Received non-retryable status 400. Metrics are lost.') und der
Knoten erholt sich beim naechsten Flush selbst. 5xx/408/429 bleiben retrybar.
Zweiter Fix, gleiche Ursache: der vorhandene processors.override traf nur
'docker_log' und liess docker_container_blkio_container_id (String) durch —
der 400 warf die ganze docker_container_*-Familie weg. Neuer Block
namepass=['docker','docker_container*'] mit fieldexclude der *_id-Felder.
VERSION 1.9.2 -> 1.9.3 (loest den Auto-Updater aus).
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.
GEMESSEN: x22 erzeugt 13,3 Log-Zeilen/s. Die alte Reserve von 20.000
reichte damit nur ~25 min — bei einem Ausfall von einer Stunde waeren
Logs verloren gegangen, ohne dass es auffiele.
200.000 = ~4 h Reserve, belegt nur waehrend eines Ausfalls (Telegraf
puffert nichts, solange der Push klappt). Ein Ueberlauf wird geloggt
('[outputs.loki] Metric buffer overflow'), also nicht still.
Kein Dienstneustart noetig ausser der regulaere Konfigurationslauf.
Bisher wurden NUR access.log gesammelt — real nachgemessen: 31 logfile-Labels,
0 davon error.log. Bei einem KeyHelp-Host mit PHP/CMS fehlten damit genau die
Fehler, fuer die man ins Monitoring schaut.
Error-Logs jetzt in einem EIGENEN Input (name_override=apache_error), roh nach
Loki, mit Tags logtype=error und logfile=<pfad>. Getrennt vom Access-Grok, weil
das Format nicht passt:
[Mon Sep 14 00:10:01.123456 2026] [core:error] [pid 9] AH00124: ...
Liefen sie durch den Access-Parser, entstuenden keine Metriken, aber der
Aggregator wuerde sie in leere Gruppen einordnen.
DREI STILLE FALLEN dabei gefunden und behoben:
1. processors.rename hatte namepass=["journal"] — apache_error behielt das
Feld value, jede Panel-Query mit {.message} haette es nicht gefunden.
2. outputs.loki namepass enthielt apache_error nicht — Input sammelt ein,
Output verwirft, keine Fehlermeldung, Panels leer (wie bei journal damals).
3. outputs.prometheus namedrop ebenso — sonst wandern Textzeilen in die TSDB.
Verifiziert gegen echte KeyHelp-Formate: access=2 Metriken, error=4 Rohzeilen,
Feld heisst message, 0 Error-Zeilen als Metrik.
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).
mm