Os três pilares, e o que falta neles

Monitoramento responde perguntas que você preparou antes: “a CPU passou de 80%?”, “o serviço respondeu ao health check?”. Observabilidade é conseguir responder perguntas que você não previu — “por que só os pedidos com cupom, no checkout, ficaram lentos depois das 14h?” — sem publicar código novo para descobrir.

A diferença prática não é a ferramenta, é o dado: sistema observável emite contexto suficiente para você fatiar o problema por dimensões que ninguém pensou em antes.

Métricas: agregadas e baratas

Uma métrica é um número no tempo, com poucos rótulos. É barata porque já vem agregada: milhões de requisições viram alguns milhares de pontos. Serve para tendência, alerta e SLO.

# taxa de erro do serviço, por rota — a pergunta que abre quase todo incidente
sum by (route) (rate(http_requests_total{status=~"5.."}[5m]))
  / sum by (route) (rate(http_requests_total[5m]))

O limite é a agregação: a métrica diz que a latência subiu, quase nunca de quem. Não coloque user_id, request_id ou URL completa em label — isso é o erro de cardinalidade descrito abaixo.

Logs: detalhados e caros

O log é o evento com contexto: o que aconteceu com aquela requisição, naquele instante. Responde “o quê”, com precisão, e é o único pilar que carrega mensagem de erro original.

O custo cresce com volume e com retenção, e log não estruturado só é pesquisável por força bruta. Emita JSON com campos estáveis desde o primeiro dia — muda pouco no código e muda tudo na investigação.

Traces: causalidade entre serviços

O trace mostra o caminho de uma requisição atravessando serviços, com o tempo gasto em cada trecho. É o pilar que responde “onde” o tempo foi embora quando há cinco serviços e dois bancos no caminho. Métrica mostra a distribuição, trace explica o caso.

O que falta nos três

Os pilares não são categorias separadas na prática — são visões do mesmo evento. Sozinhos eles falham em dois pontos:

• Não se conectam por acidente. Sem trace_id no log e sem exemplar ligando métrica a trace, você repete a investigação três vezes. Correlação é decisão de instrumentação.
• Não explicam consumo interno. Latência que não aparece em span nenhum costuma ser GC, lock ou CPU dentro do processo; para isso existe continuous profiling (Pyroscope, Parca), que é o quarto sinal, e eventos de mudança (deploy, feature flag, migração) anotados na linha do tempo.

Alta cardinalidade: o custo real

Cardinalidade é o número de combinações distintas de labels. Cada combinação vira uma série temporal com custo de memória e disco no Prometheus.

# quantas séries cada métrica gera — rode antes de culpar o hardware
curl -s 'http://prometheus:9090/api/v1/status/tsdb' | jq '.data.seriesCountByMetricName[:10]'

Um label com o e-mail da pessoa em uma métrica de requisição pode gerar centenas de milhares de séries e derrubar o Prometheus. A regra: dimensão de alta cardinalidade vai para log ou trace, nunca para label de métrica.

Como escolher, na prática

Pergunta	Pilar
Está pior que ontem? Devo acordar alguém?	Métrica
O que exatamente falhou nesta requisição?	Log
Onde o tempo foi gasto entre os serviços?	Trace
Por que o processo consome tanta CPU?	Profile

Comece pelo mais barato que responde: métrica para detectar, trace para localizar, log para entender.

Próximo passo: aprenda a coletar e consultar o primeiro pilar em Prometheus e PromQL.