From 704e8c1aaa45cd775b96eb2e45d13e311470c4f3 Mon Sep 17 00:00:00 2001 From: arnol Date: Fri, 7 Aug 2026 19:05:44 +0200 Subject: [PATCH] Showcase nachgezogen: restliche Portfolio-Dateien auf aktuellen Stand --- 02-AdGuard-CT100.md | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/02-AdGuard-CT100.md b/02-AdGuard-CT100.md index f51b8c5..8110a02 100644 --- a/02-AdGuard-CT100.md +++ b/02-AdGuard-CT100.md @@ -144,6 +144,51 @@ dns: **Manueller Schritt an der Fritzbox:** Heimnetz → Netzwerk → Netzwerkeinstellungen → IPv6-Adressen bearbeiten → DNS-Server → eigenen DNSv6-Server eintragen. **Die ULA-Adresse verwenden** (`fd23:...`, per `ip -6 addr show eth0` im Container ermitteln — steht als "scope global dynamic mngtmpaddr"), **nicht** die GUA (`2a02:...`) — die ULA bleibt stabil, die GUA kann sich bei einem ISP-Präfixwechsel ändern und die Konfiguration stillschweigend brechen. +## 9. Query-Log-Retention (der "stille Wachser") + +Der netzwerkweite Resolver protokolliert **jede** DNS-Anfrage aus dem gesamten LAN — genau der +Log-Typ, der unbemerkt wächst, weil niemand ihn täglich ansieht. Bei diesem Durchlauf gefunden: +`querylog.json` bei mehreren hundert MB, Retention stand auf `interval: 90d` (Standard-Vorschlag von +AdGuard Home, nie bewusst gesetzt). + +```yaml +# /opt/AdGuardHome/AdGuardHome.yaml +querylog: + interval: 7d # vorher: 90d +``` + +```bash +pct exec 100 -- systemctl stop AdGuardHome +pct exec 100 -- sed -i 's/interval: 90d/interval: 7d/' /opt/AdGuardHome/AdGuardHome.yaml +pct exec 100 -- systemctl start AdGuardHome +``` + +⚠️ **NICHT TUN: nach dem Ändern des Intervalls erwarten, dass die alte, große Datei sofort +schrumpft.** AdGuard rotiert beim nächsten Start die bisherige Datei nach `querylog.json.1` +(Standard-Log-Rotationsmuster) und beginnt eine neue, leere `querylog.json` — die Altlast +bleibt als `.1`-Datei liegen, bis der *nächste* Rotationszyklus sie ersetzt. Für sofortige +Platzrückgewinnung die `.1`-Datei manuell löschen (reine Altdaten, keine laufende Datei): +`pct exec 100 -- rm /opt/AdGuardHome/data/querylog.json.1`. DNS-Auflösung/Blocking läuft davon +komplett unberührt weiter (`dig`-Verifikation direkt danach: Blocking + normale Auflösung beide +sofort wieder da). + +### Nachtrag: `size_memory` täuscht einen hängenden Log vor + +AdGuards `querylog.size_memory` (Standard 1000) puffert Einträge im Arbeitsspeicher und schreibt sie +erst gebündelt auf die Platte — die Datei auf der Platte kann deshalb minutenlang unverändert wirken, +obwohl AdGuards eigene Web-UI (die direkt aus dem Live-Puffer liest) völlig normal weiterläuft. Kein +Bug, keine Aktion nötig — vor einem Neustart erst im UI selbst gegenprüfen, nicht nur die Datei-`mtime`. + +**Realer Vorfall, unabhängig davon:** `querylog.json` wuchs innerhalb weniger Tage deutlich schneller +als üblich, und der AdGuard-Prozess peakte dabei nahe ans Container-Speicherlimit heran. Ursache: +**nicht** ein AdGuard-Problem selbst, sondern ein Notify-Flood eines separaten Docker-Image-Watchers +auf dem Monitoring-Container (siehe `08-monitoring.md`) — die Registry-Abfragen dieses Watchers allein +machten einen Großteil der geloggten Zeilen aus, zeitlich exakt deckungsgleich mit dem Vorfall. Nach +dessen Behebung fiel die Anfragerate um mehr als eine Größenordnung. **Lehre:** ein +Ressourcen-Ausreißer bei AdGuard muss nicht an AdGuard selbst liegen — erst per `IP`/`QH`-Auswertung +des Query-Logs den tatsächlichen Verursacher finden (`python3` über die JSON-Zeilen, `Counter` nach +Client und Domain), bevor an CPU/RAM-Zuteilung gedreht wird. + ## Verifikation ```bash