Jak naprawić zapełniony dziennik systemd

Dziennik systemd przechowuje wszystkie komunikaty logowania generowane przez serwer, a na serwerze VPS z małą partycją root może on po cichu zająć całą dostępną przestrzeń dyskową. W takiej sytuacji usługi nie uruchamiają się, zapis danych zostaje wstrzymany, a użytkownik traci dostęp do danych diagnostycznych niezbędnych do ustalenia przyczyny awarii. Niniejszy przewodnik opisuje, jak zdiagnozować problem, natychmiast zwolnić miejsce na dysku oraz skonfigurować journald, aby sytuacja się nie powtórzyła.

Diagnozowanie problemu

Zacznij od sprawdzenia, ile miejsca zajmuje dziennik:

journalctl --disk-usage

Wynik ten przedstawia łączny rozmiar wszystkich aktywnych i zarchiwizowanych plików dziennika. Porównaj tę wartość z dostępną przestrzenią dyskową df -h. Na partycji root o pojemności 20 GB nawet 2 GB logów stanowi ponad 10% całkowitej pojemności dysku, co wystarczy, by spowodować problemy.

Następnie sprawdź, które usługi generują najwięcej danych. Ten jednowierszowy kod tworzy ranking 10 największych źródeł logów z ostatnich 24 godzin:

journalctl --since "24 hours ago" | awk '{print $5}' | cut -d'[' -f1 | sort | uniq -c | sort -rn | head -10

Filtruj konkretnie na błędy za pomocą journalctl -p err -b , aby sprawdzić, czy pojedyncza usługa utknęła w pętli awarii i zalewa dziennik. Możesz również sprawdzić, czy journald ogranicza szybkość jakichkolwiek usług:

journalctl -u systemd-journald | grep -i "suppressed"

Komunikaty o stłumieniu oznaczają, że usługa przekroczyła domyślny próg 10 000 wpisów w ciągu 30 sekund. To jest sprawca.

Kilka rzeczy jest szczególnie powszechnych na instancjach VPS. Jeśli Storage=auto jest ustawiony i /var/log/journal/ istnieje, journald korzysta z pamięci trwałej z domyślnym limitem około 4 GB. Na małej partycji root szybko się to zapełnia. Nieprawidłowe wyłączenia mogą również pozostawić uszkodzone pliki dziennika z .journal~ . Pliki te nie są normalnie rotowane i nadal zajmują miejsce

Bezpieczne czyszczenie logów

Przed usunięciem czegokolwiek należy obrócić aktywny plik dziennika, aby zachować bieżące logi:

journalctl --rotate

Następnie usuń zarchiwizowane logi. Możesz wybrać kryteria według wieku, rozmiaru lub liczby plików:

sudo journalctl --vacuum-time=1d
sudo journalctl --vacuum-size=100M
sudo journalctl --vacuum-files=5

Pierwsza opcja usuwa logi starsze niż 24 godziny. Druga zmniejsza całkowity rozmiar dziennika do 100 MB. Trzecia zachowuje tylko pięć najnowszych zarchiwizowanych plików. Wybierz opcję, która pasuje do Twojej sytuacji.

Jeśli dysk jest całkowicie zapełniony, a polecenia journalctl nie reagują, może być konieczne ręczne usunięcie plików dziennika:

sudo rm -rf /var/log/journal/*
sudo systemd-tmpfiles --create --prefix /var/log/journal

Jest to ostateczność. Spowoduje to usunięcie wszystkich zapisanych logów i odtworzenie katalogu z prawidłowymi uprawnieniami. Po zakończeniu czyszczenia uruchom ponownie demona i sprawdź:

sudo systemctl restart systemd-journald
journalctl --disk-usage

Konfiguracja limitów rozmiaru Journald

Domyślne ustawienia journald są dość liberalne. Na serwerze VPS są one zbyt liberalne. Edytuj konfigurację, aby ustawić sztywne limity przechowywania logów. Utwórz plik nadpisujący zamiast edytować bezpośrednio główną konfigurację, aby Twoje zmiany przetrwały aktualizacje pakietów:

sudo mkdir -p /etc/systemd/journald.conf.d/
sudo nano /etc/systemd/journald.conf.d/size-limits.conf

Kluczowe dyrektywy:

Ustawienie obu SystemMaxUse i SystemKeepFree zapewnia podwójne zabezpieczenie: logi są ograniczone do stałego rozmiaru, a system zawsze ma zapas miejsca niezależnie od tego, co jeszcze znajduje się na dysku.

Pamięć trwała a pamięć ulotna

Dyrektywa Storage= kieruje, gdzie trafiają logi. Ustaw Storage=persistent , aby zapisywać logi na /var/log/journal/ na dysku. Jest to zalecane w przypadku serwerów produkcyjnych, ponieważ logi przetrwają restart i można zbadać awarie po fakcie. Jeśli katalog nie istnieje, należy go utworzyć:

sudo mkdir -p /var/log/journal

Alternatywą jest Storage=volatilepolega na przechowywaniu logów w pamięci RAM w /run/log/journal/. Logi znikają po ponownym uruchomieniu. Ma to sens w przypadku kontenerów o krótkotrwałym działaniu lub serwerów, które przekazują wszystkie logi do systemu zewnętrznego.

Wyłączanie kompresji na serwerach o dużym natężeniu ruchu

Journald domyślnie kompresuje obiekty danych większe niż 512 bajtów. Na serwerach obsługujących duże przepustowości logów powoduje to obciążenie procesora. Ustaw Compress=no , jeśli przekazujesz logi na zewnątrz i nie musisz minimalizować lokalnej pamięci. Ustaw to również ForwardToConsole=no w środowisku produkcyjnym. Przekazywanie do konsoli jest synchroniczne, a zawieszona wirtualna konsola szeregowa może całkowicie zablokować demona journald.

Po każdej zmianie konfiguracji uruchom ponownie usługę:

sudo systemctl restart systemd-journald

Automatyzacja zarządzania logami

Ręczne czyszczenie nie jest skalowalne. Utwórz timer systemd, aby usuwać logi zgodnie z harmonogramem. Skonfiguruj jednostkę usługi w /etc/systemd/system/journal-vacuum.service:

[Unit]
Description=Vacuum old journal logs
 
[Service]
Type=oneshot
ExecStart=/usr/bin/journalctl --vacuum-time=7d --vacuum-size=500M

Następnie utwórz pasujący timer w /etc/systemd/system/journal-vacuum.timer:

[Unit]
Description=Weekly journal vacuum
 
[Timer]
OnCalendar=Sun 02:00
Persistent=true
 
[Install]
WantedBy=timers.target

Włącz go za pomocą sudo systemctl enable --now journal-vacuum.timer. Timer uruchamia się w każdą niedzielę o 2 w nocy i w jednym przebiegu stosuje zarówno retencję opartą na czasie, jak i na rozmiarze.

Jedna rzecz, której timer nie wychwyci: uszkodzone pliki dziennika. Po nieprawidłowym wyłączeniu systemu journald umieszcza uszkodzone pliki w kwarantannie, dodając ~ do nazwy pliku. Te .journal~ Pliki te nadal wliczają się do wykorzystania miejsca na dysku, ale nie zostaną automatycznie usunięte. Należy okresowo sprawdzać i usuwać stare pliki:

find /var/log/journal/ -name "*.journal~" -mtime +30 -delete

Przekazywanie logów na zewnątrz

W przypadku serwerów, na których potrzebne jest długoterminowe przechowywanie bez powiększania lokalnej pamięci masowej, należy przekierować logi do scentralizowanego systemu. Najprostszym podejściem jest włączenie przekazywania syslogów w journald.conf:

ForwardToSyslog=yes

W przypadku logów strukturalnych z pełnymi metadanymi (PID, UID, nazwy jednostek) użyj systemd-journal-remote do wysyłania wpisów w formacie JSON na platformę zarządzania logami. Zewnętrzna pamięć logów chroni również ścieżkę audytu w przypadku awarii dysku lokalnego lub naruszenia bezpieczeństwa serwera

Wniosek

Pełny dziennik systemd jest łatwy do naprawienia i łatwo mu zapobiec. Kluczowe kroki:

• Sprawdź wykorzystanie za pomocą journalctl --disk-usage i zidentyfikuj usługi generujące nadmierny ruch.
• Natychmiast zwolnij miejsce za pomocą journalctl --rotate a następnie --vacuum-size lub --vacuum-time.
• Ustaw wyraźne limity rozmiaru w pliku nadpisującym journald.conf.
• Zautomatyzuj czyszczenie za pomocą timera systemd.
• Przekaż logi na serwer zewnętrzny w celu długoterminowego przechowywania.

Plany VPS i serwerów dedykowanych FDC zapewniają przepustowość wejścia/wyjścia dysku oraz przestrzeń dyskową niezbędną do obsługi obciążeń związanych z logami produkcyjnymi.