O que é questão de log e por que ela te mata aos poucos
Questão de log é simplesmente aquele problema chato de rastrear informações dentro de um sistema. Você abre o arquivo, encontra uma linha, perde o rastro, procura por mais cinco minutos e descobre que o log tá tão cheio de ruído que não dá pra saber onde começa o sinal. Isso acontece o tempo todo, em qualquer stack que você escolha. Eu já trabalhei com log em produção Java, Python, Node e até alguma coisa embarcada que não vou nomear porque dá vergonha. O problema não é a ferramenta. É a forma como as equipes tratam log como algo secundário. Gera um arquivo de 40GB num mês, ninguém lê nada, e quando surge um bug, começa a correr atrás do prejuízo às 3 da manhã.
Como resolver questão de log na prática
Primeiro passo: pare de logar tudo. Eu sei que parece contra-intuitivo, mas logs excessivos são piores que logs insuficientes. O problema real é a falta de estrutura, não a falta de informação. Quando você entra num projeto onde cada função grava quatro linhas diferentes, você não tem um log, tem um desastre. Segundo: padronize o formato. Use JSON estruturado ou pelo menos um formato fixo que você consiga parsear depois. Campos obrigatórios: timestamp em UTC, nível de log, ID da requisição, mensagem e contexto relevante. Sem isso, você perde horas manualmente.
Terceiro: implemente request tracing. Cada requisição recebe um ID único que atravessa todo o sistema. Quando o problema aparece, você filtra por aquele ID e vê a cadeia inteira de chamadas. Isso elimina a necessidade degrepar arquivos gigantes manualmente. Um detalhe importante que muita gente esquece: o nível de log que você escolhe define se vai conseguir resolver o problema ou não. DEBUG é útil em desenvolvimento. Em produção, ele geralmente gera mais barulho do que informação. Use INFO para o fluxo normal, WARN para coisas que precisam de atenção, ERROR para falhas reais e TRACE apenas para debugging específico de um problema. Eu vejo gente configurando DEBUG em produção porque "pode precisar depois". Aí o disco enche e o sistema cai.
Eu tive um caso específico há alguns meses com um sistema de filas onde os logs de erro mostravam mensagens genéricas demais para ser útil. A mensagem era "falha ao processar mensagem" sem nenhum contexto adicional. O log em si estava correto, mas inútil. A solução foi adicionar um campo de correlação com o payload da mensagem, mas sem gravar dados sensíveis. Usei um hash MD5 do ID do usuário e do tipo de operação. Assim dava pra rastrear a cadeia sem violar GDPR. Funcionou. Demorou uns dois dias pra implementar, mas reduziu o tempo médio de investigação de problema de horas para minutos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Armadilhas comuns que ninguém conta
Log de exceção sem stack trace é informação perdida. Se você captura uma exceção e loga apenas a mensagem, perdeu o contexto completo de onde ela aconteceu. Sempre logue o throw inteiro com o stack trace. Frameworks modernos fazem isso automaticamente, mas configuração errada pode silenciar esses detalhes. Outro erro comum: não rotacionar logs. Um arquivo de log que cresce indefinidamente é uma bomba-relógio. Configure rotação automática por tamanho e tempo. Rotação diária com retenção de 30 dias é um padrão razoável para a maioria dos sistemas. Se o volume for alto, ajuste para semanal com retenção menor. O custo de armazenamento é trivial comparado ao custo de debugar um problema sem os logs antigos.
A questão de log também aparece quando múltiplos serviços tentam escrever no mesmo lugar. Se você tem microsserviços e cada um escreve no mesmo arquivo, o resultado é uma mistura ininteligível. Use log centralizado desde o início. ELK stack, Loki, Datadog, CloudWatch Logs — escolha um e use consistentemente. A consistência importa mais que a ferramenta. Uma limitação importante que precisa ser dita claramente: log não substitui métricas. Se o seu sistema tem um problema de performance, log não vai te dizer que 10% das requisições estão levando mais de 5 segundos. Métricas sim. Log serve para entender o que aconteceu em um ponto específico no tempo. Métrica serve para entender padrões ao longo do tempo. Usar log para análise de performance é como tentar medir a temperatura do forno com um Termômetro de infravermelho apontado para fora — funciona às vezes, mas você está fazendo errado.
Se você precisa de análise de performance em escala, considere usar Application Performance Monitoring (APM) junto com o log. Ferramentas como New Relic, Dynatrace ou até o OpenTelemetry gratuito resolvem parte do problema que log sozinho não alcança. O formato de timestamp também merece atenção. Sempre use UTC. Horário local nos logs é uma fonte constante de confusão, especialmente em sistemas distribuídos com servidores em fusos diferentes. Eu já vi equipe perder meio dia investigando um problema que era simplesmente diferença de horário entre dois servidores.
Sintomas de que sua questão de log precisa de atenção urgente
Se você leva mais de dez minutos para encontrar uma linha específica num arquivo de log, seu sistema tem um problema de log. Se o engenheiro de plantão evita olhar log porque "é pior do que não ter log", tem problema. Se o disk usage sobe 20GB por semana e ninguém sabe o porquê, problema. Reconhecer esses sinais é o primeiro passo para resolver. A correção não é sempre complexa. Na maioria das vezes, é ajustar níveis de log, adicionar correlação de requisição e configurar rotação. O trabalho é mais disciplinar do que técnico. A parte difícil é convencer a equipe a manter o padrão quando o sistema está estável. É mais fácil continuar logando como está do que revisar cada ponto de log existente.
Uma coisa que vale a pena lembrar: log é código. Ele precisa de revisão, teste e manutenção. Se você não revisa log como revisa outra parte do código, o sistema de log vai degradar. E quando degradar, vai demorar para perceber porque ninguém mais confia nos logs que existem.
