Observabilidade não é ter dashboards bonitos, é conseguir responder o que aconteceu às 3 da manhã

São 3h05 da manhã e nenhum alerta acordou ninguém. O aviso chega pelo suporte no Brasil: quem lidera o time escreve que algumas dezenas de clientes estão com pedidos travados em "processing" desde mais ou menos meia-noite.

Você abre o dashboard principal. A CPU está estável, a latência p99 está normal e a taxa de erro está em confortáveis 0,2%. Está tudo verde, e os clientes continuam esperando.

Então você começa a fazer as perguntas que todo incidente traz. Quais clientes? Desde quando, exatamente? O que mudou perto da meia-noite? Em que ponto do fluxo de pedidos essas requests estão parando?

Vinte minutos depois, você está fazendo grep em logs que não incluem o ID do pedido, percorrendo traces em que as requests com falha nunca entraram na amostra, e perguntando no canal do time se alguém fez deploy.

Essa distância entre as perguntas que você precisa responder e o que seus dados conseguem responder de fato é do que trata a observabilidade.

Existe até um nome para uma parede de painéis que continua verde enquanto isso acontece: watermelon metrics, métricas melancia, verdes por fora e vermelhas por dentro. Cada painel é preciso sobre CPU, latência ou taxa de erro, e nenhum deles mostra se um pedido consegue atravessar a fila.

Observabilidade vs. monitoramento: a diferença aparece no meio do incidente

O monitoramento responde perguntas que você já sabia que ia fazer. O serviço está no ar? A latência passou do limite? A fila está crescendo?

Você define a verificação com antecedência, e um dashboard ou um alerta avisa quando ela falha. Isso é útil, e você precisa disso.

Observabilidade é a capacidade de responder perguntas para as quais você não se preparou. A Honeycomb define observabilidade como poder investigar um sistema "fazendo qualquer pergunta sobre o comportamento dele", sem adicionar instrumentação nova "toda vez que surge uma pergunta nova".

Os pedidos travados são uma pergunta nova. Ninguém montou um painel para "pedidos de um provedor de pagamentos que entraram na fila depois do deploy das 23h50 e nunca receberam confirmação". Um sistema é observável quando você ainda consegue chegar a essa resposta em minutos, cruzando os dados que já tem.

Por isso "temos dashboards para tudo" e "temos observabilidade" são afirmações diferentes: uma parede de painéis verdes só cobre o que você previu, e o que quebra às 3 da manhã é, quase por definição, algo que você não previu.

Como a telemetria se acumula sem responder nada

Raramente falta dado nos sistemas que falham às 3 da manhã. Eles têm meses de métricas, logs e traces. O que falta é uma decisão sobre para que servem esses dados, então cada peça chegou ali por hábito.

O livro de SRE do Google tem uma regra direta para isso: sinais que você coleta mas que não aparecem em nenhum dashboard nem alerta são "candidatos à remoção". Você pode seguir essa regra, ou ir um passo antes e decidir para que serve cada sinal antes de coletá-lo.

Você provavelmente vai reconhecer alguns destes:

• Dashboards padrão. O vendor ou o Helm chart vieram com painéis de CPU, memória e request rate. Ninguém escolheu esses painéis, então ninguém sabe que pergunta eles respondem.
• Logs escritos para quem desenvolve, não para o incidente. "Processing order..." fazia sentido enquanto você depurava a feature. Sem o ID do pedido, o cliente, a região ou a versão, você não consegue filtrar essa linha nem cruzá-la com mais nada.
• Traces amostrados para economizar. Guardar 1% dos traces aleatoriamente reduz a conta, e também faz com que a request com falha, que é rara, quase nunca entre na amostra, e esse é justamente o trace que você vai querer às 3 da manhã.
• Labels removidos por cardinalidade. Alguém tirou o label de cliente de uma métrica porque ele fazia o armazenamento explodir. Foi uma decisão razoável, e também é o motivo de você não conseguir saber se um pico afeta todo mundo ou uma única conta.
• Contexto perdido na fila. O trace acompanha a request até a API e para no message broker, porque o contexto do trace nunca chegou ao consumer. No cenário das 3 da manhã, é exatamente ali que os pedidos estavam travados.

Cada uma dessas decisões fez sentido quando alguém a tomou, e juntas elas resultam em um sistema que produz muita telemetria e ainda assim não consegue dizer quem foi afetado, nem por quê.

O mesmo acontece com padrões de resiliência: um circuit breaker que ninguém observa parece proteção no diagrama de arquitetura enquanto descarta tráfego em silêncio.

As cinco perguntas que todo incidente traz

É aqui que alguém costuma questionar: se observabilidade é sobre perguntas que você não previu, como projetar para isso, se ninguém consegue listar todas as falhas com antecedência?

Não precisa. Seja qual for a falha, as perguntas durante o incidente são quase sempre as mesmas cinco, e cada uma depende de dados que precisam existir antes de ele começar:

1. Quem foi afetado e quem está causando? Quais clientes, tenants, regiões ou serviços internos. Isso exige um ID de cliente ou de tenant nos seus eventos, mais a identidade de quem está chamando, incluindo os seus próprios serviços.
2. Desde quando? O momento exato em que começou, não "mais ou menos meia-noite". Isso exige timestamps confiáveis entre serviços e métricas com resolução suficiente para mostrar onde a curva muda.
3. O que mudou? Um deploy, uma feature flag, uma mudança de configuração, uma mudança no tráfego. Isso exige a versão e uma marcação de deploy na sua telemetria, mais um registro das mudanças de configuração e de flags.
4. Onde quebra? Qual serviço, qual salto, qual etapa do fluxo. Isso exige contexto de trace que sobreviva a filas e jobs assíncronos.
5. Está melhorando ou piorando? Se o alcance do problema está crescendo. Isso exige as mesmas dimensões de "quem foi afetado" acompanhadas ao longo do tempo, como a taxa de erro por tenant, e não só um número global.

Se um campo não está lá às 3 da manhã, nenhuma query e nenhuma ferramenta vai produzi-lo. Dois postmortems públicos do último ano mostram como isso fica na prática.

Quem está causando? Em abril de 2026, quedas intermitentes no data plane do Bluesky afetaram cerca de metade dos usuários por aproximadamente oito horas, e encontrar a causa raiz levou cerca de quatro dias. Um serviço interno novo estava enviando lotes enormes de requests a partir de um único data center.

Como resumiu Jim Calabro, o engenheiro do Bluesky que escreveu o postmortem: "não tínhamos métricas por cliente no data plane". As métricas confirmavam a queda e não davam como ver qual cliente estava por trás dela.

O que mudou? Durante a queda global da Cloudflare em novembro de 2025, as falhas iam e voltavam em ondas, e a primeira leitura do time foi um ataque DDoS massivo. A status page deles, hospedada fora da Cloudflare, caiu ao mesmo tempo por pura coincidência, o que deixou a teoria do ataque ainda mais convincente.

A causa real foi uma mudança de permissões em um cluster de ClickHouse. Uma query que monta o feature file do Bot Management começou a retornar linhas duplicadas, o arquivo dobrou de tamanho, e o proxy atingiu o limite de 200 features e começou a retornar erros 5xx. As ondas vinham do fato de alguns nós do banco de dados ainda gerarem um arquivo bom enquanto outros geravam um ruim.

Cada falha apareceu na telemetria; o difícil foi ligar essas falhas à mudança de permissões.

É isso que significa instrumentar com intenção: garantir que, seja qual for o bug, essas cinco perguntas tenham resposta nos dados.

Como instrumentar com intenção na prática

Comece pelas perguntas e vá de trás para frente até chegar à telemetria. Na prática, isso se resume a algumas decisões concretas.

Prefira wide events a muitas linhas de log soltas. Um único evento estruturado por unidade de trabalho (o que costuma se chamar wide event), com request ID, cliente ou tenant, região, versão, feature flags ativas e resultado, responde mais perguntas do que vinte linhas dizendo "step 3 done". Também é muito mais fácil de filtrar e agrupar.

Anexe o deploy a tudo. Cada evento e cada span devem carregar a versão do serviço ou o commit. Quando surgir "o que mudou?", você quer comparar antes e depois do deploy, e não sair perguntando no Slack.

Propague o contexto em todas as fronteiras. Chamadas HTTP costumam ter isso pela auto-instrumentação do OpenTelemetry. Filas, jobs agendados e webhooks normalmente não têm, e é aí que se escondem incidentes como o dos pedidos travados.

Amostre com intenção. Se você precisa fazer sampling de traces, guarde todos os erros e todas as requests lentas, e amostre só as saudáveis, para que os traces que você guarda sejam os que um incidente vai pedir.

O tail-based sampling faz isso, e não sai de graça: o collector precisa segurar cada trace até ele terminar para decidir se guarda, o que custa memória e adiciona mais um componente para operar. Compare isso com a frequência com que você precisa dos traces que hoje descarta.

Decida onde ficam os dados de alta cardinalidade. IDs de cliente não cabem em todo label de métrica, mas precisam ficar em algum lugar onde você consiga consultá-los, como eventos estruturados ou traces. Descartá-los em todo lugar é o jeito de perder "quem foi afetado?".

Todas essas são decisões sobre o que o seu código emite, e você pode tomá-las com as ferramentas que já tem.

Um teste para fazer esta semana

Pegue o último incidente real do seu time. Abra o canal do incidente, não o postmortem, e anote cada pergunta que alguém fez enquanto ele acontecia: "Isso é só no Android?", "Começou com o release 2.14?", "De quantos clientes estamos falando?".

Postmortems chegam depois e tendem a pular os becos sem saída, que é onde os dados que faltam costumam aparecer.

Depois tente responder cada uma com os dados que você tem hoje, com um cronômetro rodando.

Anote quais levam dois minutos, quais levam vinte e quais você não consegue responder. As que você não consegue responder são o seu backlog de instrumentação, ordenado pela frequência com que aparecem.

É mais útil do que auditar seus dashboards, porque parte do que você precisou quando algo quebrou.

Onde entra o orçamento de ferramentas

O custo é o principal critério para escolher uma ferramenta de observabilidade pelo terceiro ano seguido, segundo 65% de quem respondeu à pesquisa de observabilidade 2026 da Grafana Labs. É um filtro razoável para aplicar depois que você sabe quais perguntas a ferramenta precisa responder.

Nenhuma plataforma consegue produzir um ID de tenant que ninguém registrou ou um trace que ninguém guardou, por melhor que armazene e visualize todo o resto.

É assim que uma stack cara e um sistema que não consegue responder "quem foi afetado?" acabam convivendo por meses: o orçamento foi para armazenar telemetria antes de alguém decidir quais perguntas ela precisava responder.

Volte por um momento aos pedidos travados. Com um ID de cliente em cada evento, a versão em cada span e contexto de trace que atravessa a fila, as perguntas das 3h05 (quais pedidos, desde quando, depois de qual mudança) se resolvem com uma ou duas queries, e quem está de plantão volta para a cama antes que o suporte no Brasil precise mandar uma segunda mensagem.