Obracać log watchdoga VPN bez psucia zapisującego

Kontrola stanu VPN, która co minutę dopisuje jedną linię, po cichu tworzy drugi obowiązek: zdecydować, jak te linie opuszczają dysk. Naprawa tunelu nic nie robi dla tego obowiązku, a zmiana nazwy pliku nie przekierowuje procesu, który nadal trzyma stary deskryptor. Najpierw odpowiedz na pytanie o miejsce docelowe, a potem dopasuj rotację do sposobu, w jaki zapisujący go otwiera.

Wybierz miejsce docelowe przed polityką rotacji

Jednostka systemd, która już wysyła swoje wyjście do dziennika, trzyma retencję w jednym miejscu. journald wymusza limity, takie jak SystemMaxUse i MaxRetentionSec , więc watchdog, który tam loguje, dziedziczy ograniczenie bez dodatkowej pracy. Dodanie obok drugiego nieograniczonego pliku podwaja utrzymanie bez korzyści.

Dedykowany plik zasługuje na swoje miejsce, gdy czyta go coś innego: parser, eksport audytu lub strona oczekująca stabilnej ścieżki. Po podjęciu tej decyzji plik potrzebuje właściciela, trybu i polityki rotacji zapisanych razem, bo wszystkie trzy są poprawne tylko jako zestaw. Ścieżka, którą każdy może utworzyć, jest też ścieżką, którą każdy może zastąpić, więc uprawnienia katalogu należą do tej samej notatki. Zapisz to wszystko obok kontroli, a następna zmiana zacznie się od tych samych faktów.

Napisz blok pasujący do zapisującego

Zacznij od zapisującego, który otwiera ścieżkę przy każdym wywołaniu, dopisuje linię i kończy pracę. Ten wzorzec przeżywa rotację bez żadnej współpracy procesu, bo następne uruchomienie otwiera plik, który właśnie znajduje się pod tą ścieżką. Poniższy blok zachowuje tydzień wersji i odtwarza plik z właścicielem i trybem, których potrzebuje zapisujący:

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

Podręcznik logrotate definiuje liczbę jako liczbę zachowanych obróconych wersji, a nie jako gwarancję siedmiu dni historii, a słowo kluczowe daily jest oceniane podczas wykonywania zadania, a nie działa jako własny harmonogram. W większości dystrybucji to wywołanie należy już do timera systemd lub wpisu cron, więc sprawdź, który istnieje, zanim dodasz drugi. Dopasowanie własności jest ważniejsze niż liczba retencji. Skopiowanie trybu tylko dla roota na plik zapisywany przez konto usługi zatrzymuje logowanie przy następnej rotacji, a awaria pojawia się godziny później jako nieaktualny znacznik czasu, a nie jako błąd. Potwierdź użytkownika zapisującego, zanim skopiujesz blok skądinąd.

Zapisujący, który nigdy nie otwiera ponownie, wymaga innego rozwiązania

Długo działający proces trzymający otwarty deskryptor nadal pisze do przemianowanego inode. Miejsce nie jest zwalniane, a widoczny plik przestaje rosnąć, co wygląda jak zepsuta rotacja, dopóki nie sprawdzisz inode. Albo naucz proces ponownego otwierania, albo spraw, by rotacja kopiowała i obcinała zamiast zmieniać nazwę.

Ścieżka ponownego otwarcia jest czystsza tam, gdzie oprogramowanie ją obsługuje: wyślij udokumentowany sygnał lub uruchom udokumentowane polecenie i pozwól procesowi samemu otworzyć nowy plik. Alternatywą jest copytruncate , które kopiuje zawartość pod obróconą nazwę, a następnie obcina oryginał w miejscu, więc deskryptor pozostaje ważny, ale zapisy trafiające między kopią a obcięciem giną.

W przypadku jednostek uruchamianych przez systemd skieruj StandardOutput do dziennika lub do pliku i pozwól jednostce zarządzać cyklem życia. Pętla shellowa, która dopisuje przez tee -a bez limitu rozmiaru, jest układem, który podczas awarii zapełnia partycję, bo nieudana kontrola często loguje znacznie więcej niż zdrowa.

Przetestuj rotację bez czekania na timer

Tryb debugowania raportuje, co by się stało, i niczego nie dotyka, co czyni go bezpiecznym pierwszym uruchomieniem po zmianie. Wymuś prawdziwą rotację, gdy będziesz zadowolony, a potem potwierdź, że następna linia logu trafia do nowego pliku, a nie do przemianowanego:

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

Czytaj wyjście w tej kolejności. Przebieg debugowania powinien nazwać plik i zamierzone działania; wymuszone uruchomienie powinno wytworzyć oczekiwaną obróconą nazwę; tail powinien pokazać nowy wpis po ponownym uruchomieniu zapisującego. Rosnąca wartość df przy kurczącym się widocznym pliku oznacza opisany powyżej problem z deskryptorem.

Powtórz wymuszone uruchomienie dwa razy, aby zobaczyć, jak zachowuje się retencja, gdy wersje już istnieją. Usunięcie najstarszego pliku to oczekiwany wynik, a brak usunięcia zwykle oznacza, że liczba lub znak wieloznaczny w obróconej nazwie nie zgadzają się z tym, co utworzył logrotate.

Zachowaj możliwość wycofania i pisemny zapis

Zapisz poprzedni blok przed edycją i odnotuj, który harmonogram go uruchamia, bo wycofanie, które przywraca plik, ale nie timer, odtwarza połowę pierwotnego problemu. Po przywróceniu obróć raz ręcznie, a potem potwierdź, że konto zapisującego może pisać na ścieżkę logu. Jeśli usługa działa pod systemd, przeładuj jednostkę po każdej zmianie przekierowania jej wyjścia, bo działający proces nadal pisze do starego celu. Przeczytaj sam kolejne linie logu, zamiast ufać, że jednostka wróciła czysto.

Zapisz tryb, właściciela, liczbę retencji i oczekiwany budżet dyskowy obok samej kontroli. Gdy później kontrola zmieni się z jednorazowego skryptu w demona, polityka rotacji musi się zmienić razem z nią, a ta notatka mówi następnej osobie, które założenie pękło.

Na koniec trzymaj decyzję o logu oddzielnie od decyzji o odzyskiwaniu. Nieudana kontrola powinna podążać za własną polityką odzyskiwania połączenia, a nie za regułą ukrytą w logrotate, i żaden układ logowania nie powinien być powodem restartu działającego tunelu.