Em um belo dia, você está trabalhando normalmente quando de repente recebe um chamado: um gateway de APIs crítico para o negócio está apresentando intermitências e os usuários estão com dificuldades para acessar serviços chave que determinam a produtividade da sua empresa como um todo. Até aí tudo bem - você junta os responsáveis pelo gateway, abre uma war room rotineira para identificar o problema e começa pela forma mais simples de identificar o problema: os logs.

Nos primeiros minutos, após abrir o Splunk, Dynatrace, AWS Cloudwatch ou o que quer que esteja sendo utilizado para logs - você percebe que não aparece nada de errado. O logging não está sendo realizado de maneira correta, sendo utilizado apenas em situações onde operações começam e terminam, mas quase nunca para erros - e pior, quando os erros estouram no logs, apenas o título (conhecido como "Message" em muitas linguagens) é exposto e não dá nenhuma pista real do que está acontecendo, se provando completamente inúteis e apenas ofuscando ainda mais o conteúdo da lista de logs em produção.

Próximo passo: vamos utilizar a nossa ferramenta de observabilidade para entender melhor como os requests estão se comportando? Após alguns outros minutos explorando, você e sua equipe percebem que a maioria dos erros é 500 - perfeito: agora nós iremos conseguir entender os motivos desse erro e resolver esse problema de uma vez por toda, certo? Errado. A gateway, especificamente as APIs internas que estão dando problema, está retornando apenas um status code 500 e isso nos remete a uma situação intrigante - antigamente os erros 500 eram estourados com uma stack trace completa na cara do usuário, mas isso foi identificado como prejudicial pela equipe de desenvolvimento, que fez com que os erros 500 não retornassem mais nada ao invés de identificar o problema e dinamicamente construir uma mensagem de erro que faça sentido para a situação - ou mesmo fazer o log corretamente, o que também seria uma opçãok, inclusive, a mais adequada.

Agora, o que resta para a sua equipe é simplesmente subir uma alteração de emergência que ainda não vai resolver o problema - uma melhoria na qualidade dos logs, atrasada porém necessária, que vai - prontamente - providenciar à equipe de desenvolvimento todas as informações necessárias para identificar o problema. Fazendo a subida - que provavelmente vai custar mais um dia de intermitências para os usuários - agora é necessário esperar para que os usuários tentem acessar novamente (e recebam as mensagens de erro, caso elas existam - pois o próprio restart da aplicação após as atualizações pode fazer os erros sumirem magicamente - quem nunca?). Com os logs agora populados com mensagens de erro significativas, é hora te começar a trabalhar no que realmente importa: a solução do problema.