Jak zapobiec zapełnianiu dysku systemowego przez logi Jellyfin
Nie należy nigdy dopuścić do tego, aby logi Jellyfin rozrosły się do rozmiaru konkurującego z bazą danych, pamięcią podręczną lub systemem operacyjnym o ostatnie wolne gigabajty. Zapobiegaj awarii, ograniczając zarówno szczegółowość własnych logów Jellyfin, jak i warstwę logowania kontenera lub hosta, która może ponownie gromadzić te same zdarzenia.
Najłatwiej przeoczyć to na małym dysku systemowym serwera domowego, ponieważ jednocześnie mogą rosnąć dwie niezależne ścieżki logów: Jellyfin zapisuje logi aplikacji, a Docker, journald lub inny menedżer usług może osobno przechowywać stdout i stderr. Zacznij od ustalenia, która ścieżka faktycznie zajmuje miejsce, następnie ogranicz przechowywanie na tej warstwie, zweryfikuj czyszczenie podczas normalnego użytkowania i skonfiguruj alert dotyczący wolnego miejsca, aby przyszła sesja debugowania nie zapełniła dysku po cichu.
Ustal, który magazyn logów faktycznie rośnie
Najpierw wykonaj pomiary, a dopiero potem coś usuwaj. Porównaj rozmiar skonfigurowanego katalogu logów Jellyfin z magazynem logów środowiska uruchomieniowego kontenerów lub menedżera usług i sprawdź, który z nich zmienia rozmiar podczas odtwarzania typowego skanowania biblioteki lub sesji odtwarzania. Jeśli rośnie tylko jedna ścieżka, napraw właśnie ją, zamiast jednocześnie wprowadzać wiele zmian w rotacji logów.
Przewodnik rozwiązywania problemów Jellyfin ostrzega, że logowanie debugowania może generować bardzo dużą ilość danych wyjściowych i jest przeznaczone do krótkich sesji diagnostycznych, dlatego pierwszym krokiem zapobiegawczym powinno być sprawdzenie, czy niestandardowy plik logging.json nie pozostawił włączonych szczegółowych kategorii. Przed zmianą wartości przechowywania zapoznaj się z wskazówkami dotyczącymi logowania debugowania.
Jeśli własny katalog logów Jellyfin ma stabilny rozmiar, ale ilość wolnego miejsca na dysku systemowym hosta nadal maleje, sprawdź następnie logi środowiska uruchomieniowego. Oznacza to, że usuwanie plików logów Jellyfin usunie jedynie widoczny objaw, podczas gdy druga warstwa logowania będzie nadal się rozrastać.
Ustaw granicę przechowywania na poziomie środowiska uruchomieniowego
W przypadku kontenerów wybierz sterownik logowania i zasadę rotacji z określonym limitem maksymalnym, zamiast polegać na nieograniczonym wzroście. Zastosuj to ustawienie do nowo tworzonych kontenerów i zapisz wybrany limit, aby późniejsze odtworzenie pliku compose nie usunęło zabezpieczenia.
Dokumentacja Dockera informuje, że domyślne logowanie json-file może zużywać znaczną ilość miejsca na dysku, jeśli rotacja nie jest skonfigurowana, podczas gdy sterownik local domyślnie wykonuje rotację. Wykorzystaj te zasady rotacji logów kontenerów, aby zdecydować, czy ograniczyć max-size/max-file, czy użyć sterownika lokalnego.
Po zmianie zasad środowiska uruchomieniowego odtwórz kontener Jellyfin, jeśli wymaga tego używane środowisko, i potwierdź, że aktywny kontener faktycznie korzysta z nowego sterownika. Ustawienie na poziomie demona, które dotyczy wyłącznie nowych kontenerów, nie jest skuteczną naprawą, dopóki instancja Jellyfin go nie odziedziczy.
Utrzymuj przydatne czyszczenie Jellyfin, ale nie traktuj go jako jedynego zabezpieczenia
Jellyfin zawiera zadania konserwacyjne, które usuwają logi, pamięć podręczną, logi aktywności i dane transkodowania, ale zaplanowane czyszczenie jest drugą linią obrony, a nie powodem, by pozostawiać logowanie bez ograniczeń. Zadanie może się nie wykonać, opóźnić albo uruchomić dopiero po tym, jak nagły przyrost danych zużyje pozostałe wolne miejsce systemowe.
Za pomocą historii zadań w panelu potwierdź, że zadanie czyszczenia logów wykonuje się pomyślnie, a następnie porównaj rozmiar katalogu logów przed i po jego kolejnym zaplanowanym uruchomieniu. Jeśli katalog nigdy się nie zmniejsza, zbadaj błędy zadań lub niezgodność ścieżki, zamiast bezmyślnie skracać harmonogram.
Praktycznym rozwiązaniem dla serwera domowego jest zachowanie widoczności stanu aplikacji i procesów związanych z multimediami bez dopuszczania do tego, aby pliki diagnostyczne zdominowały dysk rozruchowy. To samo podejście, stawiające zasoby na pierwszym miejscu, jest przydatne podczas rozwiązywania problemów z buforowaniem Jellyfin, ponieważ logi pomagają tylko wtedy, gdy wskazują rzeczywiste wąskie gardło.
Używaj logowania debugowania jako czasowego trybu diagnostycznego
Gdy potrzebujesz danych debugowania, przed jego włączeniem określ czas rozpoczęcia, okno odtwarzania problemu i warunek zakończenia. Zarejestruj działanie powodujące awarię, zapisz odpowiedni fragment logu w bezpiecznym miejscu, a następnie natychmiast po zebraniu dowodów przywróć normalny poziom szczegółowości konfiguracji.
Nie pozostawiaj włączonego logowania debugowania przez wiele dni tylko dlatego, że obecnie jest dostępne wolne miejsce na dysku. Spokojny wieczór i skanowanie biblioteki mogą generować zupełnie różne ilości danych, więc ustawienie, które podczas jednego testu wydaje się niegroźne, może stać się kosztowne podczas zaplanowanych zadań.
Po powrocie do normalnego logowania uruchom usługę ponownie, jeśli wymaga tego konfiguracja, i wykonaj zwykłe odtwarzanie oraz jedno zaplanowane zadanie. Tempo przyrostu logów powinno wrócić do wartości bazowej; jeśli tak się nie stanie, ponownie otwórz konfigurację i sprawdź, czy oczekiwany plik jest tym, który Jellyfin faktycznie wczytał.
Dodaj warunek zatrzymania oparty na wolnym miejscu, zanim dysk osiągnie stan krytyczny
Skonfiguruj prosty alert dla systemu plików zawierającego dane Jellyfin, logi środowiska uruchomieniowego lub system operacyjny. Próg powinien pozostawiać wystarczająco dużo miejsca na zbadanie przyczyny i bezpieczne zatrzymanie usług, zamiast czekać, aż zapisy zaczną się nie udawać w całym hoście.
Jeśli ilość wolnego miejsca niespodziewanie spada, najpierw zatrzymaj źródło logów generujące najwięcej danych, zachowaj niewielką próbkę diagnostyczną i usuń wyłącznie znane, zbędne logi lub pamięci podręczne. Nie zaczynaj od usuwania baz danych Jellyfin, konfiguracji ani nieznanej zawartości woluminów w celu odzyskania miejsca.
Zapobieganie jest zakończone, gdy normalne odtwarzanie, zadanie biblioteki i ponowne uruchomienie nie powodują już nieograniczonego wzrostu, a alert pozostaje bezpiecznie powyżej progu wyzwalania. Jeśli ilość miejsca nadal spada mimo ograniczenia logowania, przeprowadź szerszy audyt wykorzystania dysku, ponieważ nie ma już dowodów, że przyczyną są logi Jellyfin.
Polecane produkty
Wsparcie i wskazówki
Więcej do przeczytania
Czy w Jellyfin używać jednego wspólnego konta, czy osobnych kont domowników?
Wybierz konta domowe Jellyfin zgodnie z potrzebnymi granicami tożsamości, dostępu, kontroli rodzicielskiej i odzyskiwania dostępu.
Dlaczego użycie pamięci przez Jellyfin pozostaje wysokie po zakończeniu pracy?
Oddziel wzrost zużycia pamięci przez proces Jellyfin od pamięci podręcznej Linuksa i zbadaj problem tylko wtedy, gdy zużycie pamięci stale rośnie lub powoduje rzeczywistą...
Oznaki, że układ pamięci masowej Jellyfin zaczyna stwarzać ryzyko konieczności odzyskiwania danych
Przeprowadź audyt ról pamięci masowej Jellyfin, oddziel bieżący stan od kopii zapasowych i danych możliwych do odbudowania, a następnie potwierdź układ, wykonując przywracanie.
