O sistema caiu. Seu log deveria explicar por quê.

Source: Dev.to

Introdução

No artigo anterior, trouxe um ponto que pouca gente discute: um log ruim pode ser tão perigoso quanto um bug em produção.
Quando algo falha, o primeiro movimento do time é olhar para o log, esperando encontrar respostas. Na maioria das vezes, porém, o log não cumpre esse papel: é verboso, contém stacktraces extensos gerados pelo framework, mensagens genéricas e pouco contexto útil. A informação existe, mas não é acionável, resultando em tempo perdido filtrando ruído e necessidade de reproduzir o problema.

Por que o log é crítico

• Evidência operacional: o log não é apenas saída técnica; ele serve como prova confiável do que aconteceu.
• Não é para o desenvolvedor, e sim para o sistema se explicar: em um incidente, ninguém quer saber como o código foi escrito, apenas o que aconteceu.
• Qualidade, não ferramenta: a falta de critérios claros gera logs inúteis, independentemente da ferramenta utilizada.

Padrões existentes

Os modelos mais simples e amplamente adotados são:

• 5W + H – o que, onde, quando, quem, por que e como.
• Event + Context + Outcome – evento, contexto e resultado.

Padrões como OpenTelemetry e Elastic Common Schema reforçam a mesma ideia: o log precisa ser estruturado, contextualizado e rastreável. Um bom log descreve um evento, fornece contexto suficiente, indica o resultado claramente e permite correlação.

O que deve ser analisado em logs

1. O fluxo pode ser reconstruído?
   É possível entender início, meio e fim? Buracos no log são pontos cegos de observabilidade.

2. Existe contexto suficiente?
   Identificadores como orderId, paymentId ou userId são essenciais para investigação.

3. A mensagem é clara?
   Mensagens genéricas como “Erro ao processar” não explicam nada. Se for necessário abrir o código para entender o log, ele falhou.

4. O nível de severidade faz sentido?

   • INFO → fluxo normal relevante
   • WARN → comportamento inesperado controlado
   • ERROR → falha com impacto

   Níveis incorretos distorcem a leitura do sistema.

5. Existe rastreabilidade?
   traceId ou correlationId permitem seguir o fluxo entre serviços. Sem eles, cada log é uma peça isolada.

6. Os pontos críticos estão logados?

   • Integrações externas
   • Mudanças de estado
   • Decisões relevantes
   • Retries e fallbacks

7. O sistema se explica?
   O log mostra o que o sistema fez?

   • Tentou novamente?
   • Fez fallback?
   • Abortou?

8. Existe visão de impacto?

   • Operação interrompida?
   • Dados inconsistentes?
   • Impacto no usuário?

9. Existe ruído?
   Excesso de logs atrapalha tanto quanto falta de logs.

10. Existe exposição de dados sensíveis?
    Senhas, tokens, CPF, cartão etc. não devem aparecer em logs.

Onde o QA deve avaliar os logs

Code Review

Embora o review seja feito pelos desenvolvedores, o QA deve garantir que os critérios de log estejam presentes:

• Pontos críticos estão logados?
• Existe contexto suficiente?
• A mensagem é clara?

Testes

Desenvolvimento (integração e unitários)

• Logs são gerados nos cenários relevantes?
• O conteúdo está correto?
• Existem logs indevidos?

Níveis mais integrados (E2E e APIs)

• O log ajuda a explicar o comportamento?
• Permite correlacionar fluxo?
• Evita a necessidade de reproduzir o problema?

Incidentes

• O log ajudou ou atrapalhou?
• Houve ponto cego?

O problema real

Não é falta de log, mas falta de critério. Sem critérios claros:

• Cada desenvolvedor loga de um jeito diferente.
• Cada serviço conta uma história distinta.
• Cada incidente vira investigação manual.

Pergunta simples

Dá para entender o que aconteceu sem rodar o sistema novamente?

Se a resposta for não, há um problema de qualidade.

Fechamento

Log não é detalhe técnico, debug ou opcional. Ele é parte integrante do sistema e precisa ser tratado como tal. Caso contrário, quando for necessário, ele não cumprirá seu papel.