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

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, nin