Identifiera först vilken Plex- eller containerlogg som växer och hur snabbt; radera inte loggar blint medan processen fortfarande producerar samma fel.
En full systemdisk kan orsaka mer skada än försämrad övervakning: databaser, paketuppdateringar och containrar kan också behöva ledigt utrymme. Mät tillväxten under ett kort intervall, bevara ett exempel som fångar den upprepade händelsen och åtgärda sedan det störande tillståndet innan du stramar åt lagringstiden. Målet är begränsad loggning och en åtgärdad grundorsak, inte permanent undertryckning av loggar.
Identifiera den exakta skrivande processen och filen
Containerns stdout, Plex-applikationsloggar, proxiloggar och värddatorns journaler kan växa oberoende av varandra. Den största katalogen räcker inte; du behöver processen och meddelandemönstret som förklarar tillväxten.
Docker kan fånga containerns stdout och stderr via sitt loggningssystem, samtidigt som en applikation skriver till sina egna filer. Jämför därför båda sökvägarna innan du ändrar lagringstiden.
Använd kontroller av disk användning och fil tillväxt under tio minuter och fånga sedan ett kort exempel från den snabbast växande filen. Om ett meddelande upprepas kontinuerligt ska du åtgärda det tillståndet innan du roterar loggarna mer aggressivt.
Åtgärda upprepade fel innan du minskar lagringstiden
Ett felkonfigurerat monterat filsystem, ett otillgängligt beroende eller en omstartsloop kan generera betydligt mer loggning än normal drift. Kort lagringstid döljer symptomet utan att minska skrivbelastningen.
Tillämpa kontroller av fel och mättnad på det beroende som nämns i det upprepade meddelandet och återskapa sedan tillståndet en gång efter den misstänkta åtgärden.
Om loggtillväxten minskar efter att det underliggande felet har åtgärdats bör du behålla ett måttligt diagnostikfönster. Om den inte gör det ska du fortsätta spåra den skrivande processen i stället för att minska lagringstiden ytterligare.
Ställ in ett lagringsfönster utifrån verksamhetens behov
Längre lagringstid är inte automatiskt säkrare när loggar sällan används längre tillbaka än vid den senaste felsökningen. Det användbara fönstret bör täcka normal incidentidentifiering och samtidigt ta hänsyn till systemdiskens kapacitet.
För små installationer visade avvägningar kring logglagring att det operativa värdet av mycket långa fönster avtar, vilket talar för en uttrycklig policy i stället för en obegränsad standardinställning.
Uppskatta den dagliga loggvolymen efter att felet har åtgärdats, multiplicera den med det önskade felsökningsfönstret och reservera en marginal av ledigt utrymme för Plex-tillstånd och uppdateringar. Dokumentera lagringsvärdet bredvid layouten för beständiga applikationsdata så att det överlever när containern ersätts.
Verifiera att disken inte längre kan fyllas okontrollerat
En lagringsregel är bara framgångsrik om det använda utrymmet stabiliseras under både normal drift och ett avsiktligt återskapat fel. Övervakningen bör bekräfta att rensningsmekanismen faktiskt körs.
Mät ledigt utrymme, loggkatalogens storlek och den äldsta sparade filen under minst en hel rotationscykel. Om den äldsta gränsen inte flyttas som förväntat ska du korrigera rotationsmekanismen innan incidenten avslutas.
Behåll det ursprungliga exemplet med hög tillväxt tillsammans med incidentanteckningarna, men inte på produktionssystemets aktiva volym. På så sätt bevaras bevisen utan att produktionsloggens sökväg kan växa obegränsat.
Support och tips
Mer att läsa

Kan Jellyfin dela ett grafikkort eller en accelerator med en annan container på ett säkert sätt?
GPU-delning är villkorad: verifiera enhetens synlighet och drivrutinsstöd, kör sedan båda arbetsbelastningarna och håll utkik efter mjukvarubaserad reservlösning.

Så här avgör du om ett Jellyfin-fel kommer från klienten eller servern
Ett Jellyfin-fel hör till klienten när det följer med en specifik enhet; det hör till servern när flera klienter misslyckas via samma sökväg och...

Så konfigurerar du cache och tillfällig lagring i Jellyfin
Separera beständig lagring, återskapningsbar cache och tillfällig transkodningslagring, och verifiera sedan kapacitet och behörigheter med ett riktigt uppspelningstest.

