No artigo anterior, trouxe um ponto que pouca gente discute: um log ruim pode ser tão perigoso quanto um bug em produção.
Agora vem a pergunta natural:
Se log é tão crítico assim, o que exatamente deveria ser analisado?
Na prática, quando algo falha, o primeiro movimento do time é olhar para o log. É ali que todos esperam encontrar respostas.
O problema é que, na maioria das vezes, o log não cumpre esse papel.
Logs verbosos, com stacktraces extensos gerados pelo framework, mensagens genéricas e pouco contexto útil. Informação existe, mas não é acionável.
O resultado é previsível: tempo perdido filtrando ruído, dificuldade para chegar no ponto exato da falha e, muitas vezes, necessidade de reproduzir o problema para entender o que aconteceu.
Isso não é problema de ferramenta. É problema de qualidade.
Na visão de QA, log não é saída técnica. Log é evidência operacional.
E evidência precisa ser confiável.
Log não é para o Dev. É para o sistema se explicar
Quando um incidente acontece, ninguém quer saber como o código foi escrito.
A pergunta é simples:
O que aconteceu?
Se o log não responde isso, alguém vai ter que investigar manualmente.
E isso custa tempo, confiança e dinheiro.
Padrões já existem. O problema é não usar
Não falta referência.
Os modelos mais simples e 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:
log precisa ser estruturado, contextualizado e rastreável.
Não tem complexidade aqui.
Um bom log descreve um evento, com contexto suficiente, resultado claro e possibilidade de correlação.
O que deve ser analisado em logs
1. O fluxo pode ser reconstruído?
Dá para entender início, meio e fim? Se não dá, existe um problema de observabilidade. Buraco em log é ponto cego.
2. Existe contexto suficiente?
Dá para saber qual entidade foi afetada? Sem orderId, paymentId, userId, não existe investigação.
3. A mensagem é clara?
“Erro ao processar” não explica nada. Se precisa abrir o código para entender o log, ele falhou.
4. O nível de severidade faz sentido?
Tudo como INFO ou tudo como ERROR é erro.
- INFO → fluxo normal relevante
- WARN → comportamento inesperado controlado
- ERROR → falha com impacto
Severidade errada distorce leitura do sistema.
5. Existe rastreabilidade?
Dá para seguir o fluxo entre serviços? Sem traceId ou correlationId, cada log vira uma peça isolada. Peça isolada não explica sistema distribuído.
6. Os pontos críticos estão logados?
- integrações externas
- mudanças de estado
- decisões relevantes
- retries e fallbacks
Log só no erro final não resolve.
7. O sistema se explica?
O log mostra o que o sistema fez?
- tentou novamente?
- fez fallback?
- abortou?
Sem isso, o diagnóstico fica incompleto.
8. Existe visão de impacto?
Falhou. E daí?
- operação interrompida?
- dado inconsistente?
- impacto no usuário?
Log técnico sem impacto não ajuda decisão.
9. Existe ruído?
Mais log não significa melhor log. Excesso atrapalha tanto quanto falta.
10. Existe exposição de dados sensíveis?
Senha, token, CPF, cartão. Se aparece em log, existe problema.
Onde o QA deveria avaliar isso
Log não deve ser avaliado só em produção.
Code Review (código do sistema)
O review é feito pelos Devs. Ainda assim, critérios de log precisam estar presentes:
- pontos críticos estão logados?
- existe contexto suficiente?
- a mensagem é clara?
O papel do QA não é executar o review. É garantir que o critério exista.
Testes
Principalmente em testes de desenvolvimento (integração e, quando necessário, unitários):
- logs são gerados nos cenários relevantes?
- o conteúdo está correto?
- existem logs indevidos?
Aqui o log faz parte da validação.
Em níveis mais integrados (E2E e APIs), o log vira suporte:
- ajuda a explicar o comportamento?
- permite correlacionar fluxo?
- evita precisar reproduzir problema?
Incidentes
- o log ajudou ou atrapalhou?
- houve ponto cego?
O problema real
Não é falta de log. É falta de critério.
Sem critério:
- cada dev loga de um jeito
- cada serviço conta uma história diferente
- cada incidente vira investigação manual
Uma pergunta simples
Dá para entender o que aconteceu sem rodar o sistema novamente?
Se não dá, existe problema de qualidade.
Fechamento
Log não é detalhe técnico. Não é debug. Não é opcional.
Log é parte do sistema. E precisa ser tratado como tal.
Caso contrário, no momento em que ele for necessário, ele não vai cumprir o seu papel.
Top comments (0)