Os registros: a única coisa que cresce sem ninguém ter decidido
Tudo o que enche o seu disco foi você quem colocou. Menos os registros. E quando algo falha a escrita acelera: os registros crescem mais rápido justo quando você menos consegue olhar.
AtlasPVE ·
Este verbete responde a
- proxmox arquivos de log cresceram
- proxmox journal encheu o disco
- proxmox logrotate
- proxmox limpar var log
- proxmox disco enchendo causa
A maior parte do que enche o seu disco foi você quem colocou: máquinas virtuais, backups, imagens de instalação. Cada uma foi uma decisão.
Os registros são diferentes. Eles crescem porque o sistema está rodando. Ninguém nunca disse "que este arquivo fique maior".
O crescimento é lento mas sem limite
Um arquivo de registro pode crescer alguns kilobytes por dia. Isso não chama atenção por meses. Um ano depois ele ainda é pequeno.
Mas ele não tem teto. E um crescimento sem teto, por mais lento que seja, vira problema se você esperar o bastante.
O multiplicador que ninguém espera: a falha acelera a escrita
Aqui está o ponto de verdade do artigo.
Um sistema saudável escreve pouco. Se uma verificação dá erro a cada execução, a cada execução cai uma linha no mesmo arquivo. Para uma tarefa que roda a cada quinze minutos são noventa e seis linhas por dia, e não para.
Ou seja, o registro cresce mais rápido justo quando você menos consegue olhar: enquanto uma falha está acontecendo.
E a pior versão disso
Aparece um problema, os registros aceleram, o disco enche. O disco cheio cria problemas novos. Os problemas novos produzem mais registros.
A partir daí fica mais difícil achar a falha original, porque a maioria dos erros na tela não é consequência do primeiro problema e sim do disco cheio.
A regra: tudo o que escreve precisa de um teto
"Depois a gente limpa" não é plano. O que é preciso é um limite mecânico que funcione sem ninguém precisar lembrar.
Essa regra não vale só para os registros do sistema: vale para todo arquivo produzido pelos serviços que você roda, pelas tarefas agendadas e pelos coletores.
Dois erros comuns ao montar a rotação
Um: a regra quebrar por causa de um arquivo que não existe. Alguns arquivos só aparecem quando o recurso correspondente é usado. A regra precisa ser escrita para não dar erro quando um arquivo falta; senão um recurso que você nunca usa para a rotação inteira.
Dois: o método de rotação errado. Renomear o arquivo e mandar ao serviço que escreve um sinal de "reabra" é o método comum, mas só funciona se existir um serviço de vida longa. Se quem escreve é uma tarefa curta que abre e fecha toda vez, não há para quem mandar o sinal; nesse caso o método certo é copiar o conteúdo e esvaziar o arquivo no lugar.
Os dois são falhas silenciosas: a regra está lá, o arquivo continua crescendo, e ninguém percebe que a regra não funciona.
E a pergunta da máquina já instalada
Se você escreve uma regra de rotação só no script de instalação, ela nunca alcança as máquinas instaladas antes de a regra existir. Essas máquinas rodam anos sem ela.
O certo é escrever a regra a cada inicialização: assim as instalações mais antigas recebem a regra ao passar para uma versão nova.
O que o Atlas faz
Este artigo inteiro saiu de uma medição que o Atlas fez sobre si mesmo, então precisa ser contado com honestidade.
O Atlas roda com permissão de root na máquina do cliente e escreve em vários arquivos de registro: o resumo do vigia a cada quinze minutos, a saída das atualizações planejadas a cada execução, o próprio registro de autoatualização. Foi medido e nenhum deles estava sendo rotacionado, porque a instalação não escrevia regra de rotação em lugar nenhum. Numa máquina em serviço, o registro do vigia tinha chegado a cento e oitenta kilobytes em trinta e dois dias e não havia mecanismo para reduzir.
O número parece pequeno e naquele dia não era problema. O problema era que o crescimento não tinha limite, mais a aceleração descrita acima. Os registros de atualizações planejadas capturam toda a saída do gerenciador de pacotes a cada execução, o que pode chegar a megabytes por execução.
Agora a regra é escrita, e as duas armadilhas acima são tratadas de propósito: arquivos ausentes são tolerados, e a rotação usa o método copiar e depois esvaziar, porque quem escreve são processos curtos lançados por uma tarefa agendada.
E a regra é escrita na inicialização, não no script de instalação. O motivo é exatamente a pergunta acima: para que as máquinas instaladas antes também recebam a regra ao passar para uma versão nova.
Fontes
A documentação oficial do Proxmox. Em inglês, e é ela que dá a palavra final neste assunto.