Tutorial de Linux / Investigue falhas do Linux com logs
Para investigar uma falha, identifique o serviço afetado e o horário, reúna registros relacionados da mesma inicialização e do mesmo fuso horário e compare-os com uma reprodução. Uma linha de erro ou a última mensagem, por si só, não basta para estabelecer a causa.
Revise o significado dos estados na introdução ao systemd. Esta aula relaciona horários, estados e registros; a prática de reprodução de falhas e recuperação, em inglês aplica o método em ambiente controlado.
As referências são máquinas virtuais com instalações convencionais do Ubuntu 26.04 LTS ou Rocky Linux 9. Contêineres, WSL e outras versões podem ter serviços e pacotes diferentes. Prepare o console de recuperação e anote as versões seguindo a aula de preparação da máquina virtual, em inglês.
Registre o sintoma, o horário e as alterações recentes
Em vez de “o servidor está com problema”, registre uma observação precisa, como “as solicitações HTTPS do cliente A retornam 502 desde 14:03”. Compare relógios e fusos de cliente e servidor; anote o último funcionamento conhecido e as implantações, alterações de configuração ou reinicializações recentes. Mantenha observações separadas das hipóteses.
date --iso-8601=seconds
timedatectl
systemctl --failed
journalctl --list-bootsSe uma inicialização anterior não aparecer, seus registros podem não ter sido preservados ou podem ter sido removidos. Verifique o armazenamento volátil ou persistente e os limites de retenção. Ausência de entradas não comprova ausência de falha; permissões limitadas também podem ocultar registros.
Filtre o journal por serviço, inicialização e período
Substitua NAME.service pela unidade afetada. Veja o resumo de status, leia os registros da inicialização atual e reduza o período conforme necessário. Um intervalo selecionado e guardado para comparação é mais útil que um fluxo ilimitado de mensagens não relacionadas.
systemctl status NAME.service --no-pager
journalctl -b -u NAME.service --since "30 minutes ago" --no-pager
journalctl -b -p warning --since "30 minutes ago" --no-pager
journalctl -k -b --since "30 minutes ago" --no-pager-u seleciona a unidade, -b a inicialização e -k as mensagens do kernel. -p warning inclui avisos e níveis mais graves, mas aplicações podem registrar prioridades de forma inconsistente ou enviar pistas como saída comum. Após filtrar por prioridade, compare o mesmo intervalo sem esse filtro.
Localize um evento criado com logger
O exercício escreve duas mensagens com uma etiqueta própria sem alterar a configuração de serviços. Ele exige um Linux no qual a saída de logger seja coletada no journal. Contêineres restritos ou sistemas sem socket syslog podem se comportar de outra forma; confira o caminho de coleta antes de interpretar um resultado vazio.
tag="linux-course-log-$(id -u)"
logger -t "$tag" "stage=start case=practice"
logger -p user.warning -t "$tag" "stage=check result=sample-warning"
journalctl -t "$tag" --since "5 minutes ago" --no-pagerLocalize as duas mensagens e seus horários; depois acrescente -p warning à consulta e observe se a mensagem de prioridade comum deixa de aparecer. sample-warning é um aviso criado para o exercício, não uma ocorrência real. Se precisar, consulte com privilégios autorizados; não apague logs de produção nem reinicie a coleta apenas para fazer o teste funcionar.
Compare as mensagens com outras evidências
| Pista | Verificações adicionais |
|---|---|
| Permission denied | Proprietário, permissões de todo o caminho e rótulos SELinux |
| No space left on device | df -h e df -i no sistema montado afetado |
| Address already in use | Porta em uso, processo responsável e processos duplicados |
| Connection refused ou timeout | Endereço em escuta, rota, filtragem e serviço de dependência |
| Reinício repetido ou falha | Configuração da unidade, estado de saída e implantação recente |
Uma mensagem de disco cheio pode apontar para o destino da aplicação, e não para o disco que armazena o log. Uma negativa de permissão pode envolver a travessia dos diretórios superiores ou uma política, além do modo do próprio arquivo. Verifique o recurso indicado em vez de mascarar o problema com execução como root ou permissões abertas a todos.
Verifique arquivos de log e retenção
Aplicações podem registrar em arquivos sob /var/log ou em um coletor central, além do journal. Confirme o caminho configurado antes de usar tail -n 100 ou grep. Examine arquivos rotacionados e comprimidos quando necessário e alinhe formatos de data e fusos horários. journalctl --disk-usage mostra o espaço usado pelo journal.
Apagar ou executar vacuum nos logs durante a investigação pode destruir evidências. Preserve o intervalo necessário em local com acesso controlado e remova tokens, cookies, dados pessoais e endereços internos antes de compartilhá-lo. Registre a causa, a alteração específica, o novo teste nas mesmas condições e as incertezas restantes; depois siga a política de retenção.
