Jak zapobiec zapełnianiu dysku rozruchowego hosta przez logi Dockera?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How Do You Stop Docker Logs From Filling a Host Boot Drive? - Zima Store Online

Zatrzymaj proces natychmiast generujący logi, zidentyfikuj aktywny magazyn logów, a następnie zastosuj ograniczoną rotację i napraw błąd lub pętlę restartów powodującą zalew logów.

Na serwerze NAS lub serwerze domowym opartym na Dockerze dysk rozruchowy może się zapełnić, nawet gdy multimedia i bazy danych znajdują się w innej puli, ponieważ standardowe wyjście i błędy kontenerów, dane dziennika systemd oraz pliki natywne aplikacji mogą nadal pozostawać w systemowym systemie plików. Bezpieczna kolejność działań obejmuje zachowanie wystarczającej ilości najnowszych dowodów, zatrzymanie niekontrolowanego wzrostu, określenie, która warstwa logowania zajmuje miejsce, skonfigurowanie retencji dla istniejących i przyszłych usług oraz sprawdzenie, czy bazowa aplikacja nie emituje już takiej samej ilości danych.

Zlokalizuj magazyn logów, który faktycznie rośnie

Sprawdź ilość wolnego miejsca w systemie plików dysku rozruchowego, a następnie porównaj rozmiar katalogu danych Dockera, plików logów poszczególnych kontenerów, dziennika systemowego oraz katalogów logów aplikacji montowanych z hosta. Zapisz największe ścieżki, zanim cokolwiek usuniesz lub wyzerujesz.

W jednym przypadku dotyczącym miejsca na dysku Dockera standardowe podsumowania Dockera nie wskazywały głównego użytkownika przestrzeni, ponieważ domyślny plik logu rósł niezależnie. Rozstrzygającym dowodem był stale rosnący log kontenera w lokalnej ścieżce magazynu Dockera.

Sprawdź skonfigurowany sterownik logów i ścieżkę logu każdego uruchomionego kontenera, a następnie powiąż największy plik z nazwą kontenera i najnowszymi komunikatami. Jeśli żaden log kontenera nie wyjaśnia wykorzystania miejsca, sprawdź journald i katalogi natywne aplikacji, zamiast zakładać, że każdy problem z miejscem związany z Dockerem dotyczy json-file.

Zatrzymaj głośny kontener przed awaryjnym czyszczeniem

Gdy dysk rozruchowy jest niemal pełny, wstrzymaj lub zatrzymaj kontener generujący dane w najszybszym tempie. Przed odzyskaniem miejsca zapisz ograniczony końcowy fragment logu, liczbę restartów, stan zakończenia, wersję obrazu, środowisko, punkty montowania oraz pierwszy powtarzający się błąd.

Administratorzy często odkrywają, że logi JSON kontenerów mogą zająć pozostałe miejsce na dysku, gdy nie skonfigurowano limitu rozmiaru. Wieloletnia dyskusja na Stack Overflow wskazuje nieograniczony wzrost logów JSON jako odrębne zagrożenie dla pojemności, niezależne od danych obrazów i woluminów.

Nie usuwaj aktywnego pliku logu bez zastanowienia, gdy Docker nadal ma go otwartego, i nigdy nie usuwaj przypadkowych katalogów z drzewa metadanych Dockera. Korzystaj wyłącznie z obsługiwanej przez platformę procedury rotacji lub zerowania dopiero po zatrzymaniu procesu generującego logi, a następnie potwierdź, że odzyskane bloki są widoczne, zanim ponownie uruchomisz usługę.

Zastosuj ograniczoną rotację do każdej długo działającej usługi

Ustaw jawny sterownik logów i skończone limity rotacji w konfiguracji usługi Compose lub kontenera. W przypadku popularnego sterownika JSON najważniejsze ustawienia to maksymalny rozmiar pliku i ograniczona liczba przechowywanych plików.

Wątek dotyczący rotacji na forum społeczności Dockera wyjaśnia, że opcje takie jak max-size i max-file ograniczają ilość lokalnej historii przechowywanej przez jeden kontener. Wymaganiem operacyjnym jest skończona polityka rotacji, a nie jeden plik rosnący bez końca.

Dobierz limity na podstawie tego, jak szybko trzeba zdiagnozować incydent oraz ile miejsca na dysku rozruchowym host może bezpiecznie zarezerwować. Odtwórz usługę, aby uruchomiony kontener otrzymał nową konfigurację logowania, następnie sprawdź jej efektywne ustawienia i wykonaj mały, kontrolowany test, aby potwierdzić prawidłową rotację plików.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Ustaw wartości domyślne dla przyszłych kontenerów, nie zakładając, że zmienią istniejące

Skonfiguruj domyślne ustawienia na poziomie demona lub platformy dla nowo tworzonych kontenerów, aby pominięcie ustawienia w usłudze nie przywróciło po cichu nieograniczonego lokalnego logowania. Pozostaw usługom krytycznym możliwość zastosowania węższego nadpisania, gdy wymagają one innego poziomu diagnostyki.

Zmiana domyślnego ustawienia logowania Dockera nie przepisuje automatycznie konfiguracji hosta we wszystkich istniejących kontenerach. Te same wskazówki społeczności rozróżniają ustawienia domyślne demona od ustawień przypisanych podczas tworzenia kontenera, dlatego stare usługi trzeba sprawdzić i świadomie odtworzyć.

Najpierw zastosuj zmianę do jednej niekrytycznej usługi. Potwierdź, że pobieranie logów, monitorowanie, alerty i procedury wsparcia nadal działają, a następnie odtwarzaj pozostałe usługi w kontrolowanych partiach, nie usuwając ich trwałych woluminów.

Napraw zdarzenie powodujące zalew logów

Limity rotacji ograniczają szkody, ale nie naprawiają kontenera, który restartuje się co kilka sekund, ponawia próby połączenia z niedostępną bazą danych, rejestruje każde sprawdzenie stanu, otrzymuje atak lub zalew żądań albo pozostawiono go w trybie debugowania po zakończeniu rozwiązywania problemu.

Jeden z użytkowników Dockera powiązał log JSON o rozmiarze około 80 GB z nadmierną ilością danych debugowania, pokazując, jak dane wyjściowe na poziomie debugowania mogą przeciążyć dysk rozruchowy, nawet gdy rotacja jest natychmiastowym zabezpieczeniem.

Pogrupuj powtarzające się komunikaty według częstotliwości i czasu wystąpienia pierwszego z nich, a następnie napraw najwcześniejszy błąd będący przyczyną. Przewodnik ZimaSpace dotyczący ustalania zależności powodującej pętlę restartów jest kolejnym krokiem diagnostycznym, gdy błędy połączenia, montowania, sekretów lub gotowości generują lawinę logów.

Śledź osobno logi Dockera, journald i natywne logi aplikacji

Kontener może wysyłać standardowe wyjście do Dockera, jednocześnie zapisując własne pliki w montowanym katalogu, a sama usługa Dockera może wysyłać zdarzenia demona do journald. Każdy magazyn ma innego właściciela retencji i niezależnie może zapełniać ten sam dysk rozruchowy.

Operatorzy serwerów domowych zgłaszali wzrost katalogów logów aplikacji mimo oczekiwania, że rotacja na poziomie Dockera będzie je ograniczać. Przypadek opisany w społeczności TrueNAS podkreśla potrzebę ustalenia, która warstwa logowania odpowiada za retencję, zanim zmienisz limity.

Zapisz punkt odniesienia po naprawie: wykorzystanie miejsca na dysku rozruchowym, największe pliki logów, rozmiar dziennika, liczbę restartów kontenerów oraz dzienny przyrost. Naprawę można uznać za zakończoną dopiero wtedy, gdy każdy aktywny magazyn ma ograniczoną politykę, głośna usługa pozostaje stabilna przy normalnym obciążeniu, a celowy restart nie powoduje ponownego tworzenia nieograniczonych plików.