Debug e producao / Logs e observabilidade
Logs e observabilidade
Logs e Observabilidade Sem Ruido
Como gerar sinal util para investigar sistema real sem transformar log em enchente de texto inutil.
O problema
Muita equipe percebe que falta visibilidade e responde jogando mais log em tudo.
O resultado costuma ser o pior dos dois mundos: custo maior e pouca clareza.
Tem dado demais, mas sinal de menos.
Modelo mental
Observabilidade boa nao e sobre despejar informacao.
E sobre conseguir responder perguntas importantes quando algo sai do normal:
- o que falhou
- onde falhou
- quando começou
- quem foi afetado
Se seu log nao ajuda nisso, ele provavelmente so esta ocupando espaço.
Quebrando o problema
Uma forma simples de melhorar sinal e esta:
- logue eventos importantes, nao cada linha de codigo
- inclua contexto suficiente para correlacionar a falha
- diferencie info, warning e erro com criterio
- pense em busca futura antes de escrever a mensagem
Isso deixa a investigacao muito mais util depois.
Exemplo simples
Compare estes dois logs:
Error happened
e
checkout_failed orderId=8342 userId=192 provider=stripe status=timeout
O segundo nao e melhor porque esta maior.
Ele e melhor porque ajuda voce a encontrar o fluxo, o impacto e o ponto da falha sem adivinhar.
Erros comuns
- logar demais e tornar a busca inutil
- logar de menos e perder o contexto da falha
- escrever mensagem vaga que exige abrir codigo para entender
- esquecer correlacao entre requests, jobs e chamadas externas
Como um senior pensa
Um senior forte pensa no log como ferramenta de investigacao futura.
Normalmente isso soa assim:
Se esse fluxo quebrar as tres da manha, o que eu precisaria ver no log para entender rapido o que aconteceu?
Essa pergunta costuma melhorar muito a qualidade do sinal.
O que o entrevistador quer ver
Em entrevista, isso costuma mostrar maturidade rapido:
- voce entende que observabilidade e diagnostico, nao verborragia
- voce sabe escolher contexto util
- voce pensa em correlacao e busca, nao so em imprimir erro
Quem faz isso bem parece alguem que facilita operacao real, nao so implementacao local.
Log bom nao e o que fala muito. E o que ajuda a confirmar uma hipotese rapido.
Se para entender a falha voce ainda precisa adivinhar o contexto, o log ainda esta fraco.