O que é observabilidade? Um guia prático para times de dev

São 2 da manhã. O endpoint de checkout está devolvendo erros 500 em cerca de uma requisição a cada vinte, e todos os dashboards aparecem verdes. Essa distância entre "o sistema diz que está tudo bem" e "os usuários dizem que está quebrado" é exatamente o que a observabilidade existe para fechar. O que é observabilidade? É a capacidade de entender o que o seu sistema está fazendo por dentro, olhando para os dados que ele emite (logs, métricas e traces), com clareza suficiente para responder perguntas que você não planejou com antecedência.

Essa última parte é o ponto central. Todo o resto deste artigo são detalhes.

Observabilidade vs monitoramento: a pergunta para a qual você não criou um alerta

O monitoramento responde perguntas que você já sabia fazer. A CPU passou de 90%? A taxa de erro subiu para 2%? A fila está crescendo? Você escolhe as métricas, define os limites, e um alerta dispara quando algum deles é ultrapassado.

A observabilidade responde à pergunta que você não sabia fazer. Por que só as requisições de um tenant específico, numa versão específica do app, depois de determinado deploy, demoram quatro segundos a mais? Ninguém tem um alerta para isso, porque ninguém previu essa situação.

Ou seja, os dois não são rivais. O monitoramento é a camada de alertas. A observabilidade é o que permite investigar quando o alerta dispara, ou quando um cliente escreve reclamando e nenhum alerta disparou. Se a sua única ferramenta é uma parede de dashboards prontos, você tem monitoramento. Se você consegue fatiar os dados de produção por qualquer dimensão e acompanhar uma requisição entre serviços sem subir código novo, você tem observabilidade.

Os três sinais: métricas, logs e traces

A maioria das definições começa falando em "três pilares". O rótulo é meio duro, mas os três tipos de dado são reais, e cada um é bom em um trabalho específico.

• Métricas são números ao longo do tempo: taxa de requisições, latência p95, memória em uso. São baratas de armazenar, rápidas de consultar e ótimas para responder "algo está errado?". Não servem muito para responder "qual requisição, e por quê?".

• Logs são registros com data e hora de eventos discretos: um pagamento falhou, um retry foi disparado, uma feature flag foi ativada. Eles carregam o detalhe, mas logs não estruturados em um serviço movimentado viram um palheiro.

• Traces acompanham uma única requisição enquanto ela atravessa os serviços. Cada salto é um span, com início, duração e alguns atributos. Um trace é o mais próximo que você chega de um stack trace para um sistema distribuído.

A pesquisa de 2025 da Grafana, com 1.255 profissionais, mostra onde as equipes estão de fato. O levantamento de observabilidade da Grafana aponta que 95% dos respondentes usam métricas e 87% usam logs, mas só 57% usam traces. Traces são o sinal com mais chance de ajudar em um bug distribuído, e é justamente o menos configurado pelas equipes.

Pule o atalho que diz que métricas mostram o quê, logs mostram o porquê e traces mostram onde. Ele soa organizado e falha na prática: um bom log estruturado costuma dizer mais sobre o "onde" do que um trace mal instrumentado.

O que torna um sistema observável na prática

Emitir dados é necessário. Não é suficiente. Um sistema é observável quando os dados têm três propriedades.

Alta cardinalidade. Você consegue filtrar por ID de usuário, tenant, SHA do build, região ou feature flag. Se a sua ferramenta obriga a agregar previamente por nome de serviço e código de status, você não consegue encontrar o único tenant no estado ruim.

Contexto que liga os sinais. Um trace ID em cada linha de log permite pular de um span lento para os logs exatos que ele gerou. Sem esse vínculo, você lê duas histórias separadas e adivinha como elas se conectam.

Detalhe suficiente para ser útil, sem ficar caro demais. É aqui que a maioria das equipes tropeça. No mesmo levantamento da Grafana, os respondentes citaram mais de 100 ferramentas, serviços e projetos diferentes, e a equipe média usava oito. O custo era um dos principais critérios na escolha das ferramentas. Coletar tudo é fácil. Pagar por isso é o que as pessoas descobrem depois.

Veja como fica o ponto de partida com OpenTelemetry, o padrão de instrumentação neutro em relação a fornecedor. Este é um exemplo mínimo em Python que cria um span e anexa os atributos que você vai querer às 2 da manhã:

from opentelemetry import trace

tracer = trace.get_tracer("checkout")

def charge(order):
    with tracer.start_as_current_span("charge_card") as span:
        span.set_attribute("order.id", order.id)
        span.set_attribute("tenant.id", order.tenant_id)
        span.set_attribute("app.version", APP_VERSION)
        result = payment_client.charge(order)
        span.set_attribute("payment.provider", result.provider)
        return result

Três atributos fazem a diferença entre "o checkout está lento" e "o checkout está lento para o tenant 4412 na versão 3.8.1". A introdução à observabilidade do OpenTelemetry explica com mais profundidade os conceitos por trás disso, e vale a leitura uma vez, mesmo que o seu fornecedor faça a configuração para você.

Onde as ferramentas de observabilidade diferem (e onde não diferem)

Por trás do marketing, a maioria das plataformas ingere os mesmos três sinais. Elas diferem no modelo de preço, no poder de consulta e em quanta instrumentação fazem por você.

• Plataformas tudo-em-um reúnem métricas, logs, traces, alertas e muito mais. São práticas, com a contrapartida de faturas por uso que crescem junto com o tráfego.

• Stacks de código aberto, como Prometheus, Loki, Tempo e Grafana, dão controle e não cobram licença por host, ao custo de você mesmo operá-las e ajustá-las.

• Backends nativos do OpenTelemetry aceitam o formato padrão diretamente, então trocar de fornecedor não significa reinstrumentar cada serviço.

O Datadog é a referência da categoria tudo-em-um: cobertura ampla, interface bem acabada e uma fatura que merece revisão mensal. Vale a pena se você quer um único fornecedor e tem orçamento. Pule se previsibilidade de custo é a sua principal restrição.

O Grafana é a escolha pragmática de código aberto. Você pode começar com dashboards sobre os dados que já tem e depois adicionar logs e traces conforme precisar. Conte com algum investimento de engenharia.

O SigNoz nasceu centrado no OpenTelemetry e reúne métricas, logs e traces numa única interface de código aberto. É uma escolha razoável para equipes que querem a experiência de uma tela só sem o preço de um pacote tudo-em-um.

O New Relic fica entre os dois mundos, com uma plataforma hospedada e um plano gratuito generoso o bastante para fazer uma avaliação real. Julgue pela capacidade da sua própria equipe de responder a uma pergunta real de produção dentro dele, e não pela demonstração.

Nenhuma dessas ferramentas vai torná-lo observável sozinha. A ferramenta é uma interface de consulta. A instrumentação é o que realmente importa.

A parte que a maioria dos guias pula: a observabilidade para na fronteira do código

Aqui está uma lacuna que você vai notar na primeira vez que usar qualquer uma dessas ferramentas a sério. Um trace diz que charge_card levou 3,9 segundos e que a parte lenta foi uma chamada ao payment_client. Ele não diz o que o payment_client realmente faz, quem o escreveu, nem por que ele tenta de novo três vezes sem backoff.

Para isso, você sai da ferramenta de observabilidade e vai ler código. Em um serviço pequeno, isso leva dez minutos. Em um repositório de 100 mil linhas, com quatro times donos, a leitura costuma ser a parte mais longa do incidente. Você sabe exatamente qual span está lento e, mesmo assim, gasta uma hora descobrindo como o código por trás dele está ligado.

É o problema de passagem entre dados de runtime e código-fonte, e é por isso que pensamos em observabilidade e entendimento de código como duas metades de um mesmo fluxo de trabalho:

1. A observabilidade diz onde no runtime: qual serviço, qual span, qual tenant.

2. O entendimento de código diz por quê no código-fonte: qual função, qual política de retry, qual configuração.

Times que fecham esse ciclo (o nome do span aponta para um arquivo, o arquivo aponta para um dono e uma explicação) reduzem o tempo entre "alerta disparou" e "correção entendida". Em grande parte, é uma questão de disciplina. Dê nomes aos spans a partir das funções, coloque o caminho do repositório em um atributo do span e mantenha uma nota curta de arquitetura para cada serviço. Um assistente de IA que responde perguntas sobre o seu repositório, como "onde está definida a política de retry das chamadas de pagamento?", passa a ter algo concreto onde se apoiar.

Três erros que fazem a equipe achar que a observabilidade não funciona

Tratar dashboards como objetivo. Um dashboard é uma resposta salva para uma pergunta antiga. Equipes que criam quarenta deles e nunca praticam consultas ad hoc acabam com monitoramento numa embalagem mais bonita. Em cada incidente, pergunte: respondemos isso a partir de um dashboard ou explorando os dados brutos?

Amostrar cedo demais, ou nunca. Manter 100% dos traces num serviço movimentado fica caro rápido, e manter 1% aleatório descarta justamente a requisição rara que falhou e que você quer ver. A amostragem baseada na cauda, que mantém os traces lentos e com erro e descarta a maioria dos saudáveis, costuma ser o meio-termo. Decida isso antes da primeira fatura, não depois.

Deixar os nomes de atributos divergirem. Um serviço escreve user_id, outro userId, um terceiro uid. Agora a consulta que deveria cobrir os três retorna um terço do quadro. Combine uma pequena convenção de nomes para atributos de tenant, usuário, versão e flag, e escreva-a no repositório, onde as pessoas vão encontrá-la.

Nenhum desses erros é problema de ferramenta. São hábitos, e hábitos custam menos para corrigir do que trocar de fornecedor.

Um jeito realista de começar sem tentar resolver tudo de uma vez

Se hoje você não tem nada, resista à vontade de instrumentar tudo na primeira semana. Uma sequência que funciona para equipes de 5 a 50 engenheiros:

1. Escolha um fluxo crítico do usuário. Checkout, cadastro, a principal chamada de API. Não o sistema inteiro.

2. Adicione logs estruturados com um ID de requisição. JSON, um evento por linha, com ID de trace ou de requisição em cada linha.

3. Instrumente esse fluxo com traces do OpenTelemetry. Inclua os atributos de tenant, versão e flag do exemplo acima.

4. Defina dois ou três SLOs. Por exemplo, 99,5% das requisições de checkout com sucesso em menos de 800 ms. Os alertas devem depender deles, e não de CPU.

5. Revise um incidente real contra os dados. Você teria encontrado a causa sem subir código novo? Se não, a lacuna que apareceu é a sua próxima tarefa de instrumentação.

O passo 5 é o que costuma ser pulado, e é o único que diz se você é observável de verdade. O resto é encanamento.

O que faríamos na prática

Se a sua equipe tem menos de 20 engenheiros, comece com instrumentação OpenTelemetry e com um backend cujo preço você consiga prever. A instrumentação é portátil, então a escolha do backend é reversível. Resista a comprar a maior plataforma só porque um concorrente comprou.

Se você já paga por uma ferramenta tudo-em-um, não a arranque. Audite o que está ingerindo, descarte os logs que ninguém consulta e invista a economia na instrumentação dos fluxos que importam.

E, qualquer que seja o caminho, anote como um span se mapeia de volta para o código. O dashboard mostra o incêndio. Alguém ainda precisa ler o código-fonte para descobrir por que ele começou.