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.
Kalina