Algo aconteceu esta noite: onde o registro realmente está

A máquina reiniciou durante a noite e ninguém pediu isso a ela. Tudo voltou a funcionar, nada está visivelmente quebrado, e a única frase honesta possível é esta: algo aconteceu.

O monitoramento tem três registros e eles respondem a três perguntas diferentes. Um alerta diz que algo aconteceu. Uma métrica diz que forma aquilo teve. Um log diz por quê. Este texto trata do terceiro, e daquele fato incômodo: o log que cobre o minuto interessante é o que mais provavelmente sumiu.

A primeira pergunta é menor do que parece

Antes de qualquer teoria sobre hardware, faça a pergunta mais barata disponível: ela foi desligada, ou morreu?

Uma única linha responde. Um desligamento limpo deixa uma assinatura no fim do log da inicialização anterior: o serviço de registro anota que lhe pediram para parar, e depois anota que parou. Uma máquina que perdeu energia não deixa fim nenhum. O registro simplesmente para no meio de uma atividade comum.

Essa única distinção corta a investigação ao meio. Um fim limpo significa que algo decidiu reiniciar, então procure quem pediu: uma atualização, um cão de guarda, uma tarefa agendada, uma pessoa. Nenhum fim significa que a máquina foi interrompida, então olhe energia, calor, memória e o armazenamento embaixo.

Mas só se a inicialização anterior ainda existir

Aqui está a armadilha. O journal guarda histórico de forma permanente apenas quando existe um diretório específico no disco. Se ele falta, o journal vive na memória, e cada reinício apaga exatamente a prova que você veio buscar. Não há erro nem aviso; você pede a inicialização anterior e ouve que não existe nenhuma.

Vale conferir numa tarde tranquila, e não na manhã em que se precisa. É um diretório, e é ele que separa ter um registro de acreditar que se tem.

Tem também a mesma forma de uma armadilha que merece nome duas vezes: um gravador que compartilha o destino do gravado. O gráfico que você mais quer é o que parou de ser escrito no momento em que ficou interessante; e o log que você mais quer pertence à inicialização que não existe mais.

O arquivo que meia internet manda ler pode não estar lá

Medido numa instalação atual, Proxmox VE 9.2.6 sobre Debian 13.6: o clássico serviço de registro do sistema não está instalado, e /var/log/syslog não existe.

Isso pesa mais do que parece. Boa parte dos conselhos de diagnóstico escritos nos últimos quinze anos começa com "veja /var/log/syslog". Numa máquina atual esse comando não devolve nada, e para quem está sob pressão o resultado se lê como *não tenho logs* em vez de *estou olhando no lugar errado*. O registro do sistema hoje é o journal, e ele não se abre num editor, se consulta.

O Proxmox mantém um segundo registro, e ele responde a outra pergunta

Separado do journal do sistema, o Proxmox VE mantém seu próprio log de tarefas. Toda operação iniciada pela interface web ou pela API vira uma tarefa com identificador, hora de início, hora de fim e status final, e ao lado dos arquivos de cada tarefa existe um arquivo de índice. Em um único host de laboratório esse índice tinha 283 linhas, com cerca de 960 arquivos de tarefa por trás.

Os dois registros são bons em coisas diferentes. O journal é bom em "o que o sistema estava fazendo". O log de tarefas é bom em "quem pediu o quê, e se chegou ao fim". Quando uma máquina virtual tem um instantâneo que ninguém lembra de ter tirado, ou uma mudança aparece sem autor, o log de tarefas costuma responder antes do journal, porque é uma lista de intenções e não um fluxo de eventos.

Decida o teto antes de precisar do histórico

Por padrão o limite do journal é expresso como fração do sistema de arquivos e não como duração. No host medido acima não havia limite explícito e o journal tinha crescido para cerca de 276 MB.

Dois números merecem ser conhecidos de antemão: quanto espaço o journal pode ocupar, e até onde isso alcança de verdade naquela máquina. A ordem importa, e é a mesma que vale para métricas. Decida até onde precisa enxergar para trás, e então escolha o ajuste que chega até lá. Descobrir a resposta no meio do incidente é descobrir que a resposta é "não o bastante".

O que o Atlas faz, e o que não faz

O Atlas não substitui o journal e não tenta ler seus logs por você. Aqui não há busca em logs, e dizer o contrário prepararia uma manhã ruim para você.

O que o Atlas carrega é a primeira metade: o resumo diário informa um reinício não planejado como fato, com máquina e horário, para que a pergunta ao menos seja feita. A leitura continua sendo sua e a resposta continua morando no journal.

É disso que se trata. A pior versão da noite passada não é o reinício que você investigou com o arquivo errado aberto. É o reinício que ninguém notou, porque um registro que ninguém abre não responde a nada.