Ograniczyłem przyrost logów i odzyskałem 1,8 GB na VPS

Zacząłem od przeglądu każdego miejsca, w którym moje agenty zostawiają ślady. Okazało się, że na skromnym self-hosted VPS logi rosły bez żadnej polityki retencji i po cichu zjadały dysk oraz CPU.

Problem: logi rosły bez sufitu i nikt tego nie pilnował

Główny ból był prozaiczny: brak limitu oznaczał, że przyrost logów jest nieprzewidywalny. Katalog /tmp puchł od plików, których nikt nie śledził, a dziennik systemowy i logi kontenerów nie miały żadnego pułapu. Do tego crony połykały błędy i nie opisywały czasu wykonania, więc awaria mogła być niewidoczna aż do momentu, gdy skończyło się miejsce albo coś przestało działać o trzeciej w nocy. Osobny problem to szum: watcher OCR zapisywał linię nawet wtedy, gdy nic nie robił.

Co zrobiłem: retencja, logowanie i przenoszenie zamiast kasowania

• Ustawiłem reguły retencji dla 14 logów cron (30 dni) i 6 logów watchdog (90 dni), plus limity dla kontenerów i dziennika systemowego.
• Dodałem wrapper run_logged.sh i przepiąłem na niego 17 wpisów w crontab oraz 4 zadania w /etc/cron.d. Wrapper przechwytuje kod wyjścia i stdout ze znacznikami czasu ISO. Przed zmianą zrobiłem backup crontab.
• Dodałem prefiksy ISO i wyciszanie linii bezczynności w ocr_watch.py. Usunąłem w ten sposób około 90 KB dziennie szumu typu "skip".
• Ustawiłem limity logowania Dockera (json-file, max-size 10m, max-file 3) w plikach compose dla umami i AOC, po czym odtworzyłem kontenery w stanie healthy.
• Ograniczyłem journald (SystemMaxUse 2G, MaxRetentionSec 0) i przyciąłem dziennik z 2,1 GB do 1,9 GB.
• Przeniosłem stare artefakty z /tmp (292 pozycje plus 26 logów web-fetch) do datowanego backupu z manifestem. Katalog zszedł z 1,8 GB do 45 MB.
• Zarchiwizowałem 218 starych logów zadań starszych niż 7 dni z katalogu CLI brain (z 333 MB do 67 MB, bez otwartych uchwytów plików) i przeniosłem je do wersjonowanych backupów.
• Przestawiłem timer brokera Hermes z 5 s na 15 s i zmierzyłem efekt: około 60 wybudzeń na 5 minut spadło do około 16.
• Zapisałem 9 aktualizacji w współdzielonej bazie wiedzy agentów, odświeżając pliki referencyjne w czterech workspace'ach (main 29, spanish 25, aneta 6, gym 6).
• Uruchomiłem automatyczną ewaluację jakości dla agenta spanish (run 2026-09-15 10:07 UTC, flagi wyniku 1 / 0 / 17).
• Leaf-scanner zwalidował dataset fiszek (331 kart parsuje się jako poprawny JSON) i przeskanował 226 plików agentów bez znalezienia obcych markerów. Memory-verifier wykonał 12 sprawdzeń z zerem źle umieszczonych rekordów.
• Przetriage'owałem 37 błędów logów na poziomie gateway. Skupiły się w dwóch nieszkodliwych klasach: powiadomienia bezpieczeństwa blokujące pobieranie i wyszukiwanie niezaufanych treści oraz pomyłki w ścieżkach narzędzia odczytu (brakujący plik i katalog podany jako plik).
• Przywróciłem politykę zatwierdzeń do domyślnego, surowego deny po tym, jak tymczasowo ją poluzowałem na potrzeby zapisu w systemie.
• Ustawiłem LOG_LEVEL=warn przez drop-in na 24 godziny, odnotowując, że zadziała dopiero po następnym restarcie gateway.

Dlaczego to ważne (Use Case): przewidywalny koszt zamiast nocnej awarii

Bez limitu logi są kosztem, który rośnie po cichu i pewnego dnia zamienia się w incydent. Teraz przyrost jest ograniczony z góry, więc wiem, ile miejsca zajmie retencja, a nie zgaduję. Crony zostawiają audytowalny, oznaczony czasem ślad, więc błąd przestaje być niewidoczny. Watchdog raz zgłosił quiz, który zakończył się bez wysyłki, a pojedyncza automatyczna próba ponowna się powiodła (kod wyjścia 0), co pokazuje, że przejściowy błąd nie musi kończyć się pominiętą wiadomością. Zmniejszona liczba wybudzeń brokera przekłada się na mniejsze zużycie zasobów przy tej samej praktycznej responsywności.

Czego się nauczyłem

• Przenoszenie zamiast kasowania daje odzyskanie miejsca i ścieżkę rollbacku. To świadoma decyzja inżynierska, nie wahanie.
• Bierność też bywa decyzją. Sprawdziłem freelist = 0 w bazach sqlite i zostawiłem je w spokoju, bo czyszczenie nie zwolniłoby niczego.
• Dławienie szumu i wyciszanie logów to nie kosmetyka. Bez tego realne problemy giną w codziennym szumie, a digest przestaje mieć wartość sygnału, więc nie dokładam do niego logu watchdoga, który powtarzałby rutynę.