Como impedir que os registos do Home Assistant ocupem todo o disco do sistema

Evite que os registos do Home Assistant encham o disco identificando primeiro o ficheiro exato que está a crescer, corrigindo o evento repetitivo e aplicando a retenção na camada responsável por esse registo.

Num pequeno servidor doméstico, os registos do Home Assistant Core, os registos do Docker, os registos do Supervisor ou dos complementos e o journal do sistema anfitrião podem todos consumir o mesmo disco do sistema, embora exijam correções diferentes. Meça o crescimento durante um curto período controlado, preserve provas suficientes para identificar o processo que escreve, use limites reversíveis e interrompa as escritas não essenciais se o espaço restante for demasiado reduzido para um reinício ou uma cópia de segurança segura.

Identificar qual o registo que está a consumir espaço

Registe o espaço total disponível e, em seguida, liste os maiores ficheiros e diretórios no sistema de ficheiros afetado, sem apagar nada. Compare novamente os tamanhos após cinco a dez minutos, enquanto o Home Assistant funciona normalmente. O ficheiro cujo tamanho muda é mais útil do que uma lista estática de ficheiros antigos de grandes dimensões.

Os casos do Home Assistant mostram que o esgotamento do disco pode ter origem em diferentes camadas, incluindo os registos do sistema, e não na base de dados do Recorder. Uma discussão resolvida atribuiu o crescimento ao journal do systemd, pelo que a primeira distinção é qual o diretório que continua a crescer, e não se o Home Assistant parece estar ocupado.

Se um registo do Core crescer, inspecione o componente e a mensagem que se repetem. Se os registos JSON do Docker crescerem, inspecione o controlador de registos do contentor. Se o journal crescer, inspecione o serviço que está a emitir as mensagens. Se o espaço livre já estiver criticamente baixo, pare o contentor não essencial mais ruidoso ou o próprio Home Assistant antes que novas escritas dificultem a recuperação.

Corrigir os erros repetidos antes de reduzir a visibilidade

Conte a mensagem predominante e associe os respetivos carimbos temporais a um dispositivo, integração, automatização, complemento ou evento de rede. Um aviso repetido milhares de vezes costuma ter mais valor preventivo do que dezenas de entradas isoladas e não relacionadas. Guarde uma amostra curta com a versão e o acionador antes de alterar as definições.

Um problema do Home Assistant Core documentou um erro do Tradfri que fez um registo ultrapassar os 10 GB e esgotou o disco do sistema. Esse exemplo específico de uma versão demonstra uma integração a inundar um registo; apoia o isolamento da origem, e não a conclusão de que o Tradfri ou a rotação são sempre a causa.

Desative o registo de depuração quando terminar a captura; em seguida, recarregue ou desative apenas a integração ruidosa confirmada e repita o acionador original. Se a taxa de mensagens diminuir drasticamente, corrija essa integração ou a respetiva dependência. Se isso não acontecer, reponha a definição e avance para a próxima origem verificada, em vez de suprimir todos os avisos.

Definir a retenção na camada responsável pelo registo

Defina uma política limitada separadamente para o journal do anfitrião, o controlador de registos do Docker, o proxy inverso e os restantes complementos. O nível de registo do Core não limita o armazenamento do journal do systemd, e uma opção de tamanho do Docker não roda um ficheiro escrito diretamente dentro de um diretório de configuração montado.

Escolha limites que mantenham histórico suficiente para cobrir o intervalo entre verificações, preservando simultaneamente espaço para cópias de segurança, atualizações, operações na base de dados e recuperação. O artigo relacionado da ZimaSpace sobre o espaço livre do Home Assistant explica por que motivo consumir a margem final pode interromper operações que necessitam temporariamente de espaço adicional em disco.

Documente cada política na configuração que sobrevive à recriação. Reinicie ou recrie apenas o serviço afetado, confirme que a definição está ativa e mantenha o valor anterior pronto para reverter a alteração. Não use uma eliminação geral agendada como substituto da identificação de um processo de escrita anormal.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verificar se o crescimento permanece limitado com o acionador original

Reproduza o evento que provocou a inundação, como um dispositivo ficar offline, uma nova tentativa de uma integração, uma cópia de segurança ou uma falha de rede. Acompanhe o tamanho do mesmo ficheiro, a taxa de mensagens, o espaço livre, o estado do serviço e a resposta da automatização durante mais tempo do que o período de crescimento anterior.

Um resultado satisfatório apresenta uma ocupação de registos estável ou em rotação, sem perda dos diagnósticos necessários, gravações normais do histórico e espaço livre suficiente para a próxima cópia de segurança e atualização. Reinicie o anfitrião uma vez e repita o acionador, para comprovar que os limites permanecem ativos após a recriação do serviço.

Reverta uma alteração de retenção se esta remover as provas necessárias para diagnosticar uma falha persistente. Se o registo continuar a crescer depois de a origem confirmada ter sido isolada, faça a escalada com a mensagem repetida, o componente emissor, a versão, a taxa de crescimento e o caminho de armazenamento; volte a interromper as escritas se o disco se aproximar do esgotamento.