Retenção de logs e orçamento de disco em um host: journald, logrotate e dimensionamento do log de eventos do Windows

O que é

Todo armazenamento de logs em um host tem um limite de tamanho, definido de forma diferente em cada mecanismo. A página journald.conf(5) documenta SystemMaxUse= como a configuração que limita o total de espaço em disco que o journal persistente em /var/log/journal pode usar (padrão: 10% do sistema de arquivos, com teto de 4G; os limites persistentes só valem se /var/log/journal existir). Há ainda as configurações relacionadas SystemKeepFree= (padrão 15%, com o mesmo teto), SystemMaxFileSize= e, baseadas em tempo, MaxRetentionSec=/MaxFileSec=, que controlam a rotação e a idade dos registros independentemente do tamanho. A página logrotate.conf(5) documenta maxage, que remove os arquivos de log rotacionados com mais de um determinado número de dias, independentemente da contagem rotate também configurada; assim, um limite de quantidade e um limite de idade podem valer ao mesmo tempo, e a idade só é verificada quando o log é rotacionado. No Windows, wevtutil sl <channel> /ms:<bytes> define o tamanho máximo de um log de eventos em bytes, conforme a documentação do wevtutil. Depois disso, o log passa a sobrescrever os eventos mais antigos (wrap) ou exige limpeza/arquivamento manual, dependendo do comportamento de retenção configurado para o canal.

Por que importa

Um armazenamento de logs que enche silenciosamente para de aceitar novas entradas ou começa a sobrescrever as antigas. Nos dois casos, perde-se justamente a evidência necessária durante um incidente. Dimensionar esses limites é uma decisão de planejamento de capacidade: se forem pequenos demais, a evidência desaparece antes que alguém a leia; se forem grandes demais, os logs passam a disputar espaço em disco com as aplicações, questão que o artigo sobre saúde de disco desta série trata do lado do armazenamento.

A retenção como questão de conformidade ou legal (por quanto tempo tipos específicos de registro devem ser mantidos e com quais controles de acesso) é uma decisão da política da própria organização e, quando aplicável, de seu departamento jurídico. Este artigo trata apenas das configurações mecânicas de orçamento de disco, não do que qualquer regulamentação exige.

Como aplicar

• Defina SystemMaxUse= em /etc/systemd/journald.conf (ou em um drop-in) com um valor fixo adequado à partição, por exemplo SystemMaxUse=2G, aplique com systemctl restart systemd-journald e confirme o uso atual com journalctl --disk-usage; journalctl --vacuum-size=2G reduz imediatamente os arquivos arquivados.
• Para arquivos gravados pelo rsyslog ou por aplicações e rotacionados pelo logrotate, combine rotate <N> (manter N ciclos) com maxage <days> no arquivo correspondente em /etc/logrotate.d/, de modo que os arquivos sejam descartados pelo primeiro limite que for atingido.
• Para canais do Windows encaminhados ou mantidos localmente, verifique o tamanho atual e defina um novo limite de forma não interativa: wevtutil gl Security mostra o maxSize atual; wevtutil sl Security /ms:1073741824 (em um prompt elevado) o define como 1 GiB; segundo a documentação, os tamanhos são arredondados para múltiplos de 64 KB, com mínimo de 1 MB.
• Encaminhe para um coletor remoto tudo o que precisa sobreviver à reconstrução de um host (veja os artigos desta série sobre encaminhamento com rsyslog e journald), em vez de depender apenas da retenção local.

Armadilhas

• Supor que um valor alto de SystemMaxUse= significa que os logs são mantidos para sempre; MaxRetentionSec= e a pressão de disco ainda podem remover entradas antes.
• Configurar o modo de um log do Windows como "overwrite as needed" (sobrescrever conforme necessário) sem também encaminhá-lo, o que faz os eventos antigos se perderem sem aviso quando o limite de tamanho é atingido.
• Tratar qualquer uma dessas configurações como se cumprisse um requisito de retenção, sem verificar o que esse requisito realmente especifica.