Skąd bierze się przyrost dysku serwera VPN i jak go ograniczyć

Tunel przestaje przyjmować połączenia, usługa restartuje się dwa razy, a potem w jej logu nic się nie pojawia. Ta cisza jest wskazówką, bo to log wypełnił dysk i demon nie ma gdzie zapisać błędu, na który czekasz. Każda długo działająca usługa może osiągnąć ten stan, a usunięcie katalogu o nazwie logs rzadko to naprawia. Trwałym rozwiązaniem jest wiedza, który magazyn urósł, kto odpowiada za jego politykę przechowywania i czy zapisujący naprawdę zwolnił miejsce.

Znajdź magazyn, który urósł, i tempo, w jakim rósł

Zacznij od dwóch liczb, o których łatwo zapomnieć: wolnych bloków i wolnych inodów. System plików może zgłaszać dużo miejsca i mimo to odmówić zapisu, bo zabrakło inodów, co zdarza się, gdy usługa tworzy jeden plik na sesję. Poproś o oba odczyty na tym samym wolumenie, bo odpowiedzi mogą się różnić tego samego popołudnia. Zrób to, gdy host jest zdrowy, aby liczby opisywały normalne działanie, a nie awarię.

df -h /var
df -i /var

Następnie przypisz przyrost właścicielowi. Własna liczba zużycia journala obejmuje tylko journal i nigdy nie zobaczy demona piszącego do ścieżki z jego pliku konfiguracyjnego.

journalctl --disk-usage

Przyrost w czasie mówi więcej niż jakikolwiek pojedynczy odczyt. Pozostawiony włączony poziom debugowania, pętla ponownych prób zapisująca każdą próbę albo plik przechwytywania, którego nikt nie zatrzymał: każdy z nich może w jednej chwili wyglądać zwykle, a godzinę później alarmująco. Weź jeden odczyt, przeczekaj zajęty okres, weź drugi i podziel przez interwał. Tempo, które potrafisz podać, zamienia pojemność w decyzję, a nie w pożar.

Co rotacja robi z otwartym plikiem

Plik logu to nazwa wskazująca na inode, a miejsce wraca dopiero, gdy zamknięty zostanie ostatni otwarty deskryptor. Zmień nazwę pliku, a zapisujący nadal wypełnia ten sam inode; usuń go, a zapisujący nadal wypełnia inode bez żadnej nazwy. Ten stan jest powodem, dla którego zdanie „usunąłem plik, a dysk pozostał pełny” opisuje deskryptory plików, a nie zepsuty system plików. Restart zapisującego albo wybór trybu rotacji, który ponownie otwiera plik, to co naprawdę zwraca bloki.

lsof +L1 | head

Polityka należy do komponentu, który zapisuje plik. Journal egzekwuje własne limity przechowywania z pliku konfiguracyjnego, a usługa oparta na plikach zwykle polega na logrotate, albo z regułą tworzenia i sygnałem ponownego otwarcia, albo z trybem obcinania w miejscu, gdy zapisujący nie może otworzyć pliku ponownie. Najpierw potwierdź decyzję, niczego nie zmieniając:

logrotate -d /etc/logrotate.conf

Gdzie należy umieścić limit i jak duży powinien być

Umieść limit tam, gdzie skonfigurowany jest zapisujący, a nie w punkcie montowania. Kwota na całym wolumenie chroni hosta, ale nie mówi, która usługa zawiedzie pierwsza, a globalny skrypt czyszczący zwykle usuwa dowody potrzebne przy następnym incydencie. Limit journala, liczba rotacji z maksymalnym rozmiarem i przechowywanie na poziomie aplikacji ograniczają każdy jednego producenta. Razem ograniczają całość; osobno każdy jest domysłem.

Wyznacz ten limit na podstawie przechowywania, którego możesz bronić, a nie wolnego miejsca. Jeśli przegląd wymaga tygodnia prób połączenia, journal musi utrzymać tydzień przy najwyższym oczekiwanym tempie, a to tempo to liczba zmierzona wcześniej.

Logowanie debugowania to tryb tymczasowy z zapisanym czasem rozpoczęcia, a nie plan przechowywania. Trzymaj kwestię prywatności w tej samej decyzji, bo logi połączeń niosą adresy i identyfikatory. Dłuższe przechowywanie to także wybór dotyczący przetwarzania danych i powinien go podjąć ktoś, kto zna oba ograniczenia.

Zweryfikuj limit po restarcie

Zmiana przechowywania, która trwa do następnego restartu, nie jest zmianą. Zrestartuj zapisującego, potwierdź, że nowy limit obowiązuje, i sprawdź, czy rotacja nadal działa później. W przypadku journala jeden restart i jeden odczyt zużycia odpowiadają na oba pytania:

systemctl restart systemd-journald
journalctl --disk-usage

W usłudze opartej na plikach uruchom zadanie rotacji raz ręcznie i potwierdź, że plik został zastąpiony, a deskryptor otwarty ponownie. Zapisujący, który trzyma stary deskryptor, przechodzi powierzchowną kontrolę i zawodzi przy następnym zapełnieniu wolumenu. Obserwuj wolne miejsce podczas testu, bo plik, który się zmniejszył, a miejsce nie wróciło, oznacza, że stary inode jest nadal trzymany.

Porównaj następny odczyt z tym

Wróć po tygodniu i porównaj tempo przyrostu z zapisanym. Zgodne tempo oznacza, że limit się trzyma, a obciążenie jest stabilne; podwojone tempo oznacza, że coś się zmieniło, a użytecznym pytaniem jest co. Najpierw przeczytaj zawartość logu pod kątem powtarzających się błędów, bo pętla ponownych prób jest jednocześnie objawem i przyczyną objętości. Potem sprawdź wszystko, co zostało niedawno włączone, w tym poziomy debugowania włączone podczas incydentu i nigdy nie wyłączone.

Trzymaj kopie zapasowe poza tym samym wolumenem albo zaakceptuj, że jeden pełny dysk zabierze kopię ze sobą. Kopia zapisana na hoście, który chroni, nie jest planem odzyskiwania, a jej przechowywanie wymaga własnej odpowiedzi.

Zapisz, co jest przechowywane, gdzie, jak długo i kto to usuwa. To zdanie jest wynikiem i jedyną częścią tej pracy, która przetrwa następny restart.