Nos últimos anos, mergulhei fundo no mundo da Observabilidade e, se tem uma coisa que aprendi, é que a gente começa achando que é sobre ferramenta e termina entendendo que é sobre sanidade mental.
Ouço muito falar sobre os “três pilares” (logs, métricas e traces), mas a real é que ter os três não serve de nada se eles não conversam entre si. Já perdi a conta de quantas vezes vi dashboards todos verdes enquanto rolava uma war room porque o cliente estava sentindo algo estranho. A verdade é que ninguém vai mapear todos os cenários possíveis, mas o nosso trabalho é chegar o mais perto disso.
Monitoramento vs. Observabilidade: Vale destacar uma diferença crucial: Monitoramento é reativo; Observabilidade é investigativa. Monitorar é saber que o servidor caiu ou ficou lento. Observabilidade é entender por que uma requisição de um usuário específico falhou em um microsserviço que você nem sabia que estava instável. É sobre ter respostas para perguntas que você não planejou com antecedência.
O cliente não liga para a sua CPU: O usuário não quer saber se o processador está em 10% ou 90%. O que ele percebe é que a latência subiu e a operação falhou. O foco precisa estar nos Golden Signals: latência, erro e tráfego. O resto é detalhe técnico.
A conta sempre chega Mas aí vem o banho de realidade: o custo. Quando construímos algo novo, queremos taguear tudo. Só que a fatura chega — seja do Datadog, do Splunk ou de qualquer outro player. E se você estiver usando uma stack Open Source (como Grafana/Loki/Tempo), não se iluda: você pode não pagar licença, mas paga a infra, o processamento, o armazenamento e a mão de obra para manter a alta disponibilidade de tudo isso.
O padrão que salva: OpenTelemetry: E já que falamos de ferramentas, um aprendizado vital foi sobre o OpenTelemetry. Hoje em dia, não faz mais sentido ficar “preso” ao agente proprietário de um fornecedor. O OTel virou o padrão: é plug and play e te dá a liberdade de mudar. Se a fatura do vendor atual pesou ou se outra ferramenta entrega mais valor, você só aponta os dados para outro lugar e pronto. Migrar já é uma dor de cabeça por natureza; não ter que re-instrumentar todo o código para isso é o que diferencia um projeto bem feito.
No fim do dia, o segredo é avaliar o custo-benefício e criar algo que te deixe dormir tranquilo. O melhor sistema não é o que nunca falha (isso nem existe), mas aquele que te entrega dados rápidos o suficiente para resolver o problema em minutos com dados, e não em horas com “chute”.
