Najpierw ustal, który log Plexa lub kontenera rośnie i w jakim tempie; nie usuwaj logów bez zastanowienia, gdy proces nadal generuje ten sam błąd.
Pełny dysk systemowy może zaszkodzić nie tylko obserwowalności: bazy danych, aktualizacje pakietów i kontenery również mogą potrzebować wolnego miejsca. Zmierz przyrost w krótkim odstępie, zachowaj próbkę zawierającą powtarzające się zdarzenie, a następnie usuń źródło nadmiernego generowania komunikatów, zanim zaostrzysz zasady przechowywania. Celem jest ograniczenie rozmiaru logów i usunięcie przyczyny źródłowej, a nie trwałe wyciszenie logowania.
Ustal dokładny proces i plik zapisujący logi
Standardowe wyjście kontenera, logi aplikacji Plex, logi serwera proxy i dzienniki systemowe hosta mogą rosnąć niezależnie od siebie. Największy katalog to za mało; potrzebujesz procesu i wzorca komunikatów wyjaśniających ten przyrost.
Docker może przechwytywać standardowe wyjście i standardowe wyjście błędów kontenera za pośrednictwem swojego systemu logowania, podczas gdy aplikacja może jednocześnie zapisywać własne pliki, dlatego przed zmianą zasad przechowywania porównaj obie ścieżki.
Przez dziesięć minut sprawdzaj użycie dysku i przyrost rozmiaru plików, a następnie pobierz krótką próbkę z najszybciej rosnącego pliku. Jeśli jeden komunikat powtarza się bez przerwy, usuń przyczynę tego stanu, zanim zaczniesz częściej obracać logi.
Usuń powtarzające się błędy, zanim skrócisz okres przechowywania
Nieprawidłowo skonfigurowane podpięcie, niedostępna zależność lub pętla awarii mogą generować znacznie więcej logów niż normalna praca. Krótki okres przechowywania ukrywa objaw, ale nie zmniejsza obciążenia zapisem.
Zastosuj kontrole błędów i przeciążenia wobec zależności wskazanej w powtarzającym się komunikacie, a następnie po podejrzanej poprawce odtwórz ten stan jeszcze raz.
Jeśli przyrost logów zmniejszy się po usunięciu błędu źródłowego, zachowaj umiarkowane okno diagnostyczne. Jeśli nie, nadal śledź proces zapisujący logi, zamiast ponownie skracać okres ich przechowywania.
Ustal okres przechowywania na podstawie potrzeb operacyjnych
Dłuższe przechowywanie nie zawsze jest bezpieczniejsze, gdy logi rzadko są potrzebne do analizy starszej niż ostatnie rozwiązywanie problemów. Przydatne okno powinno obejmować wykrywanie typowych incydentów, a jednocześnie uwzględniać pojemność dysku systemowego.
W przypadku małych wdrożeń analiza kompromisów związanych z przechowywaniem logów wykazała malejącą wartość operacyjną bardzo długich okresów przechowywania, wspierając ustanowienie wyraźnej polityki zamiast nieograniczonego ustawienia domyślnego.
Oszacuj dzienny wolumen logów po usunięciu błędu, pomnóż go przez wymagane okno rozwiązywania problemów i pozostaw zapas wolnego miejsca na dane stanu Plexa oraz aktualizacje. Udokumentuj wartość okresu przechowywania obok układu trwałych danych aplikacji, aby ustawienie przetrwało wymianę kontenera.
Sprawdź, czy zużycie miejsca na dysku nie może już rosnąć bez ograniczeń
Zasada przechowywania logów jest skuteczna tylko wtedy, gdy zajęte miejsce stabilizuje się zarówno podczas normalnej pracy, jak i po celowym odtworzeniu jednego błędu. Monitorowanie powinno potwierdzić, że mechanizm czyszczenia rzeczywiście działa.
Przez co najmniej jeden pełny cykl rotacji mierz wolne miejsce, rozmiar katalogu z logami i wiek najstarszego zachowanego pliku. Jeśli granica najstarszych plików nie przesuwa się zgodnie z oczekiwaniami, napraw mechanizm rotacji, zanim uznasz incydent za zamknięty.
Zachowaj oryginalną próbkę szybkiego przyrostu wraz z notatkami dotyczącymi incydentu, ale nie na woluminie systemu produkcyjnego. Dzięki temu zachowasz dowody, nie dopuszczając jednocześnie do nieograniczonego wzrostu ścieżki logów produkcyjnych.
Wsparcie i wskazówki
Więcej do przeczytania

Czy Jellyfin może bezpiecznie współdzielić kartę graficzną lub akcelerator z innym kontenerem?
Udostępnianie GPU jest warunkowe: sprawdź widoczność urządzenia i obsługę sterowników, a następnie uruchom oba obciążenia i obserwuj, czy oprogramowanie nie przełącza się na tryb...

Jak sprawdzić, czy błąd Jellyfin pochodzi z klienta, czy z serwera
Błąd Jellyfin należy przypisać klientowi, gdy występuje na jednym urządzeniu; należy go przypisać serwerowi, gdy wiele klientów ulega awarii w tej samej ścieżce, a...

Jak skonfigurować pamięć podręczną i pamięć tymczasową Jellyfin
Oddziel trwałe dane, odbudowywalną pamięć podręczną i tymczasową pamięć na transkodowanie, a następnie zweryfikuj pojemność i uprawnienia za pomocą rzeczywistego testu odtwarzania.

