Oder: Warum „gib mir die fail2ban logs aus“ nicht dasselbe ist wie „gib mir fail2ban-Zahlen“.
Wie beim Sams: Je präziser der Wunsch, desto passender das Ergebnis. Der Wunsch „werte das Angriffsklima aus, indem du die Logs ausgibst“ wurde wörtlich genommen — Ergebnis: eine Kaskade aus sudo -n grep auf /var/log/fail2ban.log, journalctl-Fallback, stille Fehlerbehandlung für verweigerte Sudo-Rechte, extra Report-Appendix. Mehr bewegliche Teile, mehr Fehlerquellen — und am Ende: „das kann nicht stimmen“ bei leerem Log.
Die eigentlich gewünschte Information — aktuell/gesamt gebannt, aktuell/gesamt fehlgeschlagen — stand die ganze Zeit fertig aggregiert in fail2ban-client status sshd bereit. Eine Zeile sed, fertig.
Die Zahlen
| Log-Lösung (inkl. Debug-Zyklus) | Status-Lösung | |
|---|---|---|
| Zeilen Code | 180 | 144 |
| Zeichen | 6.933 | 5.536 |
| ~Tokens (Schätzung, Zeichen/4) | ~1.733 | ~1.384 |
| Rückfragen/Bugreports | 3 | 1 |
| Round-Trips gesamt | 4 | 1–2 |
Fazit: Differenz: ~1.400 Zeichen / ~350 Tokens mehr Code für die komplexere Lösung — Rauschen im Vergleich zum eigentlichen Kostentreiber: 2 zusätzliche Chat-Runden (Bugreport + Diagnose-Fix), bevor die Vereinfachung überhaupt zur Sprache kam. Skaliert nicht mit Zeichen, sondern mit Anzahl Irrtümer bis zum Kern der Frage.
Die Punkte sind in jedem Fall weg:-)
Kleiner Disclaimer: Das sind Code-Volumen-Schätzungen (Zeichen/4 als grobe Tokens-Faustregel), keine exakten API-Billing-Zahlen.
Zuletzt aktualisiert am 11. Juli 2026.