Observabilidade: métrica, log e trace, e o que cada um responde

Monitoramento responde "está funcionando?". Observabilidade responde "por que não está?".

A diferença importa porque a segunda pergunta é a que você faz durante um incidente, e ela exige dados que você precisa ter coletado antes.

Os três pilares e suas perguntas#

Métrica responde "o quê" e "quanto".

É número agregado ao longo do tempo: taxa de requisição, taxa de erro, latência por percentil, uso de recurso. Barato de guardar, porque a agregação descarta o detalhe. Excelente para alerta e para painel.

Ruim para investigar um caso específico: justamente porque o detalhe foi descartado na agregação.

Log responde "o que aconteceu neste caso".

Evento com contexto. Caro em volume, porque não agrega nada.

E aqui vai o conselho mais prático deste artigo: log estruturado. JSON, com campos consistentes, sempre com o identificador de correlação. Log em texto livre é impossível de consultar exatamente quando você mais precisa: durante o incidente, quando você quer filtrar por cliente, por rota e por faixa de tempo ao mesmo tempo.

Trace responde "onde foi o tempo".

Ele segue uma requisição por todos os serviços e mostra a árvore de chamadas com a duração de cada trecho. É a ferramenta que responde "por que essa requisição levou dois segundos" em trinta segundos, em vez de duas horas.

Se você tem arquitetura distribuída e não tem trace, você está investigando incidente com uma mão nas costas.

1. Métricao quê e quantoNúmero agregado no tempo. Barata, porque a agregação descarta o detalhe. Boa para alerta e painel, ruim para caso específico.
2. Logo que aconteceu aquiEvento com contexto. Caro em volume, porque não agrega nada. Estruturado, ou é impossível de consultar no incidente.
3. Traceonde foi o tempoA árvore de chamadas de uma requisição, com a duração de cada trecho. Responde em trinta segundos o que levaria duas horas.

O que liga os três#

O identificador de correlação: o trace id.

Ele nasce na borda, viaja em cabeçalho por todas as chamadas internas, e aparece em todo log.

Com ele, você olha uma métrica anômala, encontra um trace lento daquele período, e pula direto para os logs daquela requisição específica, em todos os serviços. Sem ele, cada pilar é uma ilha.

Se o seu sistema não tem propagação de trace id, é a primeira coisa a implementar. É barato, é mecânico, e muda o jogo. OpenTelemetry resolve isso de forma padronizada na maioria das linguagens.

Os quatro sinais dourados#

Se você só tiver quatro métricas por serviço, que sejam estas, do livro de SRE do Google:

Latência. Por percentil, e separando as requisições bem-sucedidas das que falharam. Erro rápido pode mascarar latência ruim na média.

Tráfego. Requisições por segundo. Sem isso, você não sabe se a queda de erro foi melhora ou foi ninguém usando.

Erro. Taxa, não contagem. E cuidado com o que conta como erro: 4xx do cliente e 5xx do servidor contam histórias diferentes.

Saturação. O quão cheio está o recurso mais limitado. Fila é o indicador mais honesto de saturação, mais do que uso de CPU.

O método USE, para descer um nível#

Quando os quatro sinais apontarem para um problema de recurso, use o método do Brendan Gregg. Para cada recurso (CPU, memória, disco, rede):

Utilização: quanto do tempo ele está ocupado.

Saturação: quanto trabalho está esperando na fila.

Erros: contagem de falhas.

O insight é que utilização alta com saturação baixa está tudo bem: significa que você está usando o que pagou. O problema é saturação. Um disco 90% utilizado sem fila está saudável; um disco 60% utilizado com fila crescente não está.

Alerte em sintoma, não em causa#

Este é o erro mais comum na configuração de alerta.

"A taxa de erro do checkout passou de 1%" é sintoma. Importa, o usuário está sentindo, alguém deve acordar.

"A CPU da máquina 3 está em 80%" é causa possível. Pode não significar nada. Pode ser exatamente o comportamento esperado sob carga.

Alerta de causa gera fadiga. E time com fadiga de alerta ignora o alerta que importava. Isso transforma o seu sistema de alerta em ruído caro.

A regra: alerte no que o usuário percebe. Use as causas como contexto para investigar depois que o alerta disparou.

E amarre isso ao SLO: se você definiu que 99,9% das requisições respondem em menos de 300ms, o alerta deve ser sobre queimar o orçamento de erro rápido demais, não sobre um pico isolado de trinta segundos.

O roteiro de "está lento"#

Método, não palpite:

1. É CPU ou é espera? Olhe a utilização de CPU do processo. Se está baixa e mesmo assim está lento, é espera de I/O, de lock ou de fila.

2. Se é CPU, tire um perfil e olhe o flamegraph. A largura de cada barra é o tempo gasto naquela função e nas que ela chama. Você procura barras largas. Ler um leva trinta segundos depois que você entende o eixo, e é a ferramenta mais eficiente que existe para achar onde o tempo vai.

3. Se é espera, o trace responde de quê.

4. Se é lock, meça o tempo de contenção. Se você adiciona CPU e a vazão não sobe, é aqui.

5. Se é fila, ache qual: do balanceador, do pool de conexões, do executor, da mensageria.

Não pule etapas e não comece otimizando. A intuição sobre desempenho erra com uma frequência humilhante.

Cardinalidade: a armadilha de custo#

Uma métrica com um rótulo por usuário gera uma série temporal por usuário. Com um milhão de usuários, um milhão de séries.

Isso explode o custo e derruba o sistema de métricas. A regra: rótulo de métrica é para dimensão de baixa cardinalidade (rota, status, região, versão). Identificador de usuário, de pedido e de requisição vão para log e trace, nunca para métrica.

É o erro mais caro que se comete em observabilidade, e ele só aparece na fatura.

Por onde começar#

Se você tem pouco hoje, a ordem de maior retorno:

1. Trace id propagado de ponta a ponta, aparecendo em todo log.

2. Log estruturado com campos consistentes.

3. Os quatro sinais dourados por serviço, com latência em percentil.

4. Tracing distribuído nas rotas críticas.

5. Alertas em sintoma, amarrados a SLO.

Um exercício concreto para esta semana: implemente propagação de trace id em uma rota. Provoque um erro. Confirme que você consegue seguir aquele identificador do log da borda até o log do banco.

Se conseguir, você já está à frente da maioria.