Logs úteis para investigação

O problema

Quando o sistema quebra e ninguém entende por que, o reflexo comum e despejar log em todo lugar.

O resultado costuma ser este:

• tela cheia
• pouca clareza
• custo maior
• investigação ainda lenta

E, claro, a pessoa de plantao abrindo aquele mar de texto e pensando coisas nada gentis sobre quem escreveu aquilo.

Modelo mental

Log bom não e o que imprime mais.

Log bom e o que ajuda a responder rápido:

• o que falhou
• em qual fluxo
• com qual contexto
• desde quando
• com que impacto

Ou seja:

log útil e ferramenta de investigação, não despejo emocional de runtime

Quebrando o problema

Logue nas fronteiras importantes

Nem toda função interna merece log.

Os pontos que mais ajudam costumam ser:

• entrada de request
• chamada para dependência externa
• erro de negócio relevante
• fim de job
• decisão importante do fluxo

Isso reduz ruido e aumenta a densidade de informação útil.

Coloque contexto que ajude a conectar pontos

Uma mensagem vaga como error while processing quase sempre obriga alguém a abrir o código no meio do incidente.

Melhor incluir contexto como:

• request_id
• user_id ou tenant_id quando fizer sentido
• nome do fluxo
• dependência envolvida
• status retornado
• latência

Contexto transforma log em pista de verdade.

Pense em busca, não só em leitura

Log de produção quase nunca vai ser lido linha por linha.

Ele precisa ser pesquisavel.

Por isso, campos estruturados e nomes consistentes ajudam mais do que frases “bonitas”.

Quem investiga quer filtrar, agrupar e correlacionar. Não admirar sua prosa.

Se a pessoa precisa abrir o código só para descobrir em qual fluxo a falha aconteceu, o log ainda chegou pobre demais.

Diferencie sinal de spam

Se tudo vira error, nada mais e prioridade.

Se tudo vira log, nada mais chama atencao.

Use nivel e frequência com critério.

Logar cada loop interno pode até aliviar sua ansiedade durante desenvolvimento. Em produção, costuma virar poluicao.

Também vale separar log útil de curiosidade de depuração. Nem tudo que ajuda você localmente merece virar custo permanente em produção.

Exemplo simples

Compare estes dois casos.

Log ruim:

Error happened

Log melhor:

checkout_failed request_id=9f2 order_id=8342 provider=stripe status=timeout latency_ms=4500 retryable=true

O segundo não e melhor porque tem mais texto.

Ele e melhor porque, quando alguém abre o painel de logs, já consegue responder:

• qual fluxo falhou
• qual dependência participou
• se parece timeout
• se existe chance de retry

Agora a investigação começa mais perto da causa.

Erros comuns

• Logar estado demais e ainda assim esconder a informação central.
• Escrever mensagem vaga que não explica o evento.
• Engolir stack trace ou código de erro original.
• Não carregar request_id ou contexto equivalente entre serviços.
• Tratar log como substituto de raciocínio de investigação.

Como um senior pensa

Quem tem mais experiência costuma escrever logs pensando no pior horario possível.

O raciocínio e algo como:

“Se isso quebrar de madrugada, o que eu gostaria de encontrar em uma unica busca para entender o problema sem abrir dez arquivos?”

Essa pergunta melhora muito a qualidade do sistema.

Porque o log deixa de ser autobiografia da aplicação e vira ferramenta operacional.

O que o entrevistador quer ver

Em entrevista, esse tema mede maturidade de produção.

O avaliador quer ver se você:

• pensa em contexto e rastreabilidade
• sabe escolher onde logar
• evita ruido inutil
• entende que observabilidade existe para reduzir incerteza

Uma resposta forte costuma soar assim:

“Eu pensaria os logs a partir das perguntas que eu precisaria responder num incidente. Em vez de imprimir tudo, eu priorizaria fronteiras importantes e contexto estruturado para conseguir filtrar por fluxo, dependência, request e impacto.”

Log bom poupa minutos de investigação. Em incidente real, minutos contam.

Quem escreve log sem pensar em busca esta terceirizando sofrimento para a pessoa de plantao.