Ajuste o registo do Plex corrigindo primeiro os erros ruidosos e, em seguida, dimensione a retenção de acordo com a janela do incidente que realmente precisa de diagnosticar.
Reduzir o volume dos registos antes de saber o que está a repetir-se pode apagar a única evidência de uma falha de dependência. Meça qual é o ficheiro que cresce, qual o processo que escreve nele e com que rapidez a mensagem se repete. Depois de corrigir a causa-raiz, defina uma política limitada que preserve histórico suficiente para a deteção normal de incidentes.
Identifique o processo que escreve antes de alterar os níveis
Os registos da aplicação Plex, o stdout dos contentores, os proxies inversos e os diários do anfitrião podem crescer separadamente. Identifique o processo que escreve exatamente no ficheiro em causa, em vez de reduzir todas as fontes de registos ao mesmo tempo.
O tratamento dos registos de contentores do Docker pode capturar stdout e stderr independentemente dos ficheiros geridos pela aplicação.
Meça o crescimento do diretório durante dez minutos e recolha uma amostra curta do ficheiro que cresce mais rapidamente. Guarde a amostra antes de alterar a retenção.
Corrija os erros repetidos antes de rodar os registos mais depressa
Uma falha de montagem, um ciclo de reinícios ou um serviço inacessível podem gerar várias ordens de grandeza mais de saída do que uma operação normal. Uma retenção curta esconde o padrão sem reduzir a carga de escrita.
Aplique verificações de erros e saturação à dependência indicada na mensagem repetida antes de alterar o nível de registo.
Corrija o erro e reproduza-o uma vez. Se o crescimento diminuir acentuadamente, mantenha uma janela de diagnóstico moderada em vez de suprimir permanentemente a mensagem.
Defina a retenção a partir do tempo de deteção
A janela adequada é suficientemente longa para recuar até antes de um incidente típico ser detetado, mas suficientemente pequena para proteger a margem de espaço livre no disco do sistema. Não há vantagem em conservar meses de registos detalhados que nunca são utilizados.
A capacidade e a rotatividade das cópias de segurança do armazenamento são uma analogia útil: a retenção deve estar associada ao valor operacional, e não a “guardar tudo”.
Estime o volume diário de registos depois da correção e multiplique-o pela janela de resolução de problemas pretendida. Reserve espaço livre para a base de dados, atualizações e outras tarefas do sistema. Armazene os registos e as definições de retenção juntamente com uma estrutura persistente de dados da aplicação que sobreviva à substituição do contentor, sem permitir que os diagnósticos temporários se tornem estado permanente.
Verifique o mecanismo de rotação
Uma alteração de configuração só está concluída quando o limite mais antigo avança e o tamanho total dos registos estabiliza durante a operação normal e após um erro reproduzido.
Os testes operacionais de restauro baseiam-se na validação do comportamento, e os registos devem seguir o mesmo princípio, em vez de se confiar apenas num ficheiro de configuração.
Observe pelo menos um ciclo completo de rotação. Mantenha a amostra de diagnóstico original fora do diretório de registos ativos para que as evidências sobrevivam sem permitir que os registos de produção cresçam sem limites.
Suporte e Dicas
Mais para Ler

Deve fazer uma cópia de segurança do Jellyfin em funcionamento ou parar primeiro o serviço?
Prefira cópias de segurança com o serviço parado, pela sua simplicidade; utilize instantâneos em funcionamento apenas quando o estado da aplicação for capturado de...

Porque é que o Jellyfin funciona a altas temperaturas ou faz ruído quando ninguém está a transmitir?
O calor em inatividade normalmente indica atividade em segundo plano ou uma carga de trabalho de um anfitrião partilhado; por isso, identifique o processo...

Quando deve reconstruir em vez de reparar o Jellyfin?
Escolha recriar em vez de reparar quando o problema for a divergência do ambiente de execução e o estado persistente estiver salvaguardado; não «recrie»...

