Como ler log quando você não sabe o que está procurando
Ninguém me ensinou a ler log. Aprendi na prática, com /var/log/syslog aberto e problema não resolvido. O que aprendi sobre investigação antes de conhecer o nome.
Problema no servidor de email. Mensagens de um domínio específico não estavam sendo entregues. Sem mensagem de erro visível para o usuário — simplesmente sumiam.
Abri o log. /var/log/mail.log. Rolei para baixo. Era texto. Muito texto. Não sabia onde estava o problema, não sabia exatamente o que procurar.
Fiquei olhando por uns dois minutos antes de ter a primeira ideia útil: procurar o nome do domínio que estava com problema.
grep "dominio.com" /var/log/mail.log
Apareceram 40 linhas. Olhei uma a uma. Na linha 23, havia algo diferente das outras: status=bounced em vez de status=sent. E um código de erro que não tinha visto antes.
Três horas depois, entendi: o servidor deles tinha blacklistado nosso IP por volume de envio. A entrega falhava silenciosamente porque o bounce estava indo para uma fila que ninguém monitorava.
Ler log é investigação, não leitura.
A diferença: leitura é linear, começa do início, processa tudo. Investigação começa com hipótese e usa o log para confirmar ou refutar.
O que aprendi sobre investigação por log:
Comece pelo sintoma, não pelo início do log. Log tem horas de evento que não têm relação com o problema. Começar do topo é perda de tempo. Comece pelo timestamp de quando o problema começou. grep com o período de tempo relevante.
Primeiro grep é para volume, segundo é para padrão. Primeiro grep "dominio.com" me deu 40 linhas — muito para ler manual. Segundo grep grep "dominio.com" | grep "status=" me deu a distribuição de status. Padrão fica visível quando você reduz o ruído.
Erro ausente também é informação. Quando o log não tem o que deveria ter — entrega que deveria aparecer e não aparece — isso é dado. Não é "log vazio", é "o processo não chegou até esse ponto."
Contexto antes e depois do erro. A linha com o erro raramente é suficiente. O que aconteceu antes? O que aconteceu depois? Log é narrativa — o erro é um capítulo, não a história inteira.
Hoje trabalho com plataformas de observabilidade — Grafana, Prometheus, Loki, tracing distribuído. As ferramentas são mais sofisticadas. O processo mental é o mesmo.
Hipótese → query → resultado → hipótese refinada. Não é leitura linear de log — é investigação estruturada com log como evidência.
Engenheiro que aprende a investigar com grep e tail aprende o raciocínio. As ferramentas modernas amplificam esse raciocínio, não substituem.
Essa semana: próxima vez que abrir um log, escreva em uma frase a hipótese que está testando antes de começar a ler.