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.

Verbetes relacionados

Como isso aparece dentro do Atlas?

Ir para a página do produto