São 2h da manhã, o alerta dispara: "API lenta". A pergunta que define quanto vai durar a sua madrugada é uma só: seu sistema consegue te contar o que está acontecendo, ou você vai ter que adivinhar?

Essa capacidade de responder perguntas sobre o estado interno do sistema a partir do que ele emite tem nome: observabilidade. E ela se apoia em três tipos de sinal, cada um respondendo uma pergunta diferente. Confundi-los custa dinheiro; combiná-los resolve incidentes em minutos.

Métricas: "COMO o sistema está?"

Números agregados ao longo do tempo: requisições por segundo, latência média e de pico, taxa de erro, uso de CPU, pedidos por minuto. São baratas de armazenar e perfeitas para duas coisas: tendências (dashboards) e alertas ("taxa de erro acima de 2% por 5 minutos").

A limitação embutida: métrica agrega, portanto esconde o indivíduo. Ela grita que algo está errado, mas raramente diz o quê. Latência média ótima convive com 1% dos usuários sofrendo, por isso times maduros olham percentis (p95, p99), não médias.

Logs: "O QUE aconteceu?"

O diário de bordo: eventos discretos com contexto. "Pagamento 4193 recusado: cartão expirado". É onde mora o detalhe que a métrica escondeu.

O que separa log útil de ruído caro:

• Estruturado (JSON com campos, não frase solta): pesquisável por máquina, não só por olho.
• Com contexto de correlação: IDs de requisição, de usuário, de pedido. Log órfão é quase inútil.
• Com política de retenção: logs guardados para sempre são a fatura de nuvem crescendo em silêncio.

Traces: "ONDE está o problema?"

O rastro de uma única requisição atravessando o sistema: chegou no gateway, passou pela autenticação (12ms), consultou o serviço de estoque (8ms), esperou o banco (1.400ms 🔴), respondeu. Cada etapa é um span; o conjunto é o trace.

Em arquiteturas distribuídas, o tracing deixa de ser luxo: quando uma requisição toca seis serviços, "está lento" sem trace é uma acusação sem endereço. O padrão da indústria para instrumentar tudo isso é o OpenTelemetry, projeto da CNCF adotado por praticamente todos os fornecedores (opentelemetry.io), o que evita casar a instrumentação com uma ferramenta.

A mágica está na correlação

Os três pilares valem pouco isolados e muito juntos, costurados pelo mesmo fio: o ID de correlação. O fluxo de um incidente bem instrumentado:

1. A métrica alerta: p99 de latência estourou às 2h04.
2. O trace aponta: as requisições lentas gastam 90% do tempo no serviço de estoque, na chamada ao banco.
3. O log explica: "lock timeout na tabela X", com o ID do job de importação que segurava o lock.

Três minutos, causa encontrada. Sem os três sinais: uma madrugada de SSH e chute. O livro de SRE do Google descreve exatamente essa disciplina de instrumentação como fundação da operação confiável (sre.google/books).

Os erros de quem está montando isso agora

• Logar tudo "por garantia": custo alto, sinal baixo. Logue eventos de negócio e erros com contexto; o resto é métrica.
• Alertar sobre log: alerta bom nasce de métrica (quantificável, com limiar); log é para investigar depois que o alerta soou.
• Instrumentar só a borda: medir apenas o load balancer esconde tudo que acontece dentro. O valor está na visão fim a fim.
• Cada serviço num padrão: sem convenção de nomes e IDs, a correlação morre. OpenTelemetry resolve isso por contrato.

Do "achismo às 2h" para o diagnóstico em minutos

Instrumentar um sistema existente com os três pilares (OpenTelemetry, logs estruturados, dashboards e a correlação entre eles) é o primeiro passo do nosso serviço de Observabilidade e Monitoramento. Os próximos artigos da série cobrem o que vem depois: alertas que fazem sentido e as métricas que o negócio entende.

Seu sistema conta a própria história ou você adivinha? Descreva sua stack para a IA da Rabelo Digital, aqui no canto da tela, e ela indica por onde começar a instrumentação. Sem formulário, sem espera.

---

Leia também

• Alertas que fazem sentido, e como configurar
• Dashboard de negócio vs dashboard técnico
• MTTR e MTBF: como medir a saúde do seu sistema