# O que é observabilidade? Um guia prático para times de dev URL: https://codebasechat.com/pt/journal/o-que-e-observabilidade Type: blog Locale: pt Published: 2026-10-27 Updated: 2026-10-28 --- > O que é observabilidade? É a capacidade de entender o que um sistema faz por dentro a partir de logs, métricas e traces. Este guia mostra a diferença para o monitoramento e como começar. 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. ![Logs impressos ao lado de um diagrama desenhado à mão de serviços conectados](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/f0aa73-i1.webp) A pesquisa de 2025 da Grafana, com 1.255 profissionais, mostra onde as equipes estão de fato. O [levantamento de observabilidade da Grafana](https://grafana.com/blog/2025/03/25/observability-survey-takeaways) 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](https://opentelemetry.io/docs/concepts/observability-primer/) 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. ![Visualização de uma waterfall de trace distribuído em uma tela de notebook](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/fb03e7-i2.webp) 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: - A observabilidade diz **onde** no runtime: qual serviço, qual span, qual tenant. - 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. ![Desenvolvedor trabalhando com um editor de código e um dashboard de métricas lado a lado](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/5fe138-i3.webp) ## 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: - **Escolha um fluxo crítico do usuário.** Checkout, cadastro, a principal chamada de API. Não o sistema inteiro. - **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. - **Instrumente esse fluxo com traces do OpenTelemetry.** Inclua os atributos de tenant, versão e flag do exemplo acima. - **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. - **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. ## FAQ ### O que é observabilidade, em termos simples? Observabilidade é o quanto você consegue entender o que acontece dentro de um sistema a partir dos dados que ele produz. Se você consegue encontrar a causa de um problema que não previu, usando logs, métricas e traces, sem subir código novo, o sistema é observável. ### Qual é a diferença entre observabilidade e monitoramento? O monitoramento vigia problemas conhecidos usando métricas predefinidas e limites. A observabilidade permite investigar problemas desconhecidos explorando telemetria detalhada. O monitoramento é a camada de alertas, e a observabilidade é o que você usa para achar a causa depois que um alerta dispara. ### Quais são os três pilares da observabilidade? Métricas, logs e traces. Métricas são números ao longo do tempo, logs são registros de eventos discretos e traces acompanham uma única requisição entre serviços. Eles são mais úteis quando ligados entre si por IDs compartilhados. ### Preciso do OpenTelemetry para ser observável? Não, mas ele ajuda. O OpenTelemetry é um padrão neutro em relação a fornecedor para emitir logs, métricas e traces. Instrumentar com ele permite trocar de backend de observabilidade depois sem reinstrumentar seus serviços. ### Observabilidade é só para microsserviços? Não. Sistemas distribuídos são os que mais se beneficiam, porque uma única requisição passa por vários serviços, mas um monólito com banco de dados, fila e algumas APIs de terceiros também ganha com logs estruturados e traces. ### Quanto custa a observabilidade? Depende do volume de dados e da ferramenta. Plataformas hospedadas normalmente cobram por uso, então a fatura cresce com o tráfego, enquanto stacks de código aberto trocam custo de licença por tempo de engenharia. Descartar logs não usados e amostrar traces são as duas formas mais comuns de controlar gastos.