# O que é observabilidade e por que o monitoramento não basta URL: https://upstreamapi.com/pt/journal/o-que-e-observabilidade Type: blog Locale: pt Published: 2026-11-14 Updated: 2026-11-14 --- > Observabilidade explica por que um sistema falha usando a telemetria que ele já emite. Veja a diferença para o monitoramento, os três sinais e como começar sem reescrever tudo. ## O que é observabilidade e por que o monitoramento não basta O que é observabilidade? É a capacidade de explicar por que um sistema se comporta mal usando apenas a telemetria que ele já emite, inclusive para falhas que ninguém previu. O monitoramento avisa que a latência do checkout passou de 800 ms. A observabilidade permite descobrir qual cliente, qual dependência e qual deploy causaram o problema, sem subir código novo às 3 da manhã para descobrir. Veja a cena que deixa a diferença concreta. O alerta dispara: o p99 da API de pagamentos subiu de 180 ms para 1.4 s. O dashboard de CPU, memória e taxa de erro está verde. Todo painel pré-construído diz que o serviço está bem, e todo cliente diz que não está. O que você faz nos próximos dez minutos é o assunto inteiro deste artigo. ## Por que a definição importa antes da ferramenta? O termo vem da teoria de controle: um sistema é observável quando você consegue inferir seu estado interno a partir das saídas externas. O software tomou o conceito emprestado, e depois os fornecedores o esticaram até ele significar "um produto de dashboard". Ignore essa extensão. A definição de trabalho para uma equipe de engenharia é mais estreita e mais útil. Um sistema é observável quando você consegue responder a uma pergunta nova sobre o seu comportamento, em produção, sem implantar nova instrumentação. A palavra que importa é "nova". Um alerta de limite responde a uma pergunta que alguém escreveu no trimestre passado. Um sistema observável responde à que você está fazendo agora. Isso não é um teste de pureza. Ninguém tem um sistema perfeitamente observável, e o objetivo não é uma nota. O objetivo é um caminho mais curto de "algo está errado" até "esta é a mudança que causou isso". Tempo médio para detectar e tempo médio para entender são números diferentes, e a maioria das equipes acompanha só o primeiro. ![Esboço em quadro branco de serviços conectados por setas](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/3a5d62-i1.webp) ## Em que a observabilidade difere do monitoramento? O monitoramento é um conjunto de verificações contra modos de falha que você já conhece. CPU acima de 90% por cinco minutos, taxa de erro acima de 1%, fila com mais de 10,000 mensagens. É barato, confiável, e você continua precisando dele. A observabilidade não o substitui. A diferença aparece quando a falha é nova. O monitoramento é construído a partir dos seus incidentes passados. A observabilidade é construída para o próximo, que, por definição, você ainda não viu. Um teste útil: olhe os seus últimos três incidentes e pergunte como a causa raiz foi encontrada. - Se alguém leu um dashboard pré-construído e a resposta estava ali, o monitoramento fez o trabalho dele. - Se alguém pesquisou logs em seis hosts, formulou uma hipótese, adicionou uma linha de log e fez um novo deploy para confirmar, havia uma lacuna de observabilidade. - Se a resposta real veio da captura de tela de um cliente, você tem os dois problemas. Deixe de lado o debate sobre se os dois são rivais. Eles são camadas. O monitoramento é o detector de fumaça. A observabilidade é a capacidade de percorrer o prédio depois e descobrir qual circuito começou o incêndio. ## Quais são os três sinais, e onde cada um falha? Logs, métricas e traces formam o trio padrão. Cada um responde a uma pergunta diferente, e cada um tem um modo de falha que os guias dos fornecedores costumam pular. **Métricas** são medições numéricas agregadas ao longo do tempo: taxa de requisições, taxa de erro, percentis de latência, saturação. São baratas de armazenar e rápidas de consultar, por isso os alertas vivem nelas. O modo de falha é a agregação. Um p99 de 1.4 s diz que algo está lento. Não diz que todas as requisições lentas pertencem a um cliente em um shard específico. **Logs** são registros com carimbo de tempo de eventos discretos. Carregam o maior detalhe e a menor estrutura, a menos que você force estrutura sobre eles. O modo de falha é volume e custo. Logs não estruturados só são pesquisáveis por quem já sabe qual texto procurar, o que faz deles uma ferramenta de monitoramento com fantasia de depuração. **Traces** acompanham uma única requisição através das fronteiras de serviço, com um span para cada salto e o seu tempo. São o único sinal que mostra o formato de uma requisição: esta chamada esperou 900 ms por uma dependência downstream que tentou três vezes de novo. O modo de falha é a cobertura. Um serviço que descarta o contexto do trace quebra a cadeia, e um trace com buraco é pior do que inútil, porque parece autoritativo. Ter os três não é o mesmo que ser observável. O ponto é a correlação. Você precisa ir de um pico de métrica até os traces que contribuíram para ele, e de um trace até os logs daquela requisição exata. Se os três vivem em ferramentas separadas, sem um identificador compartilhado, você tem três sistemas de monitoramento e um engenheiro fazendo o papel de junção. ## Por que a cardinalidade decide se você consegue depurar alguma coisa? Cardinalidade é o número de valores distintos que um campo pode assumir. `status_code` tem talvez vinte. `customer_id` tem centenas de milhares. `request_id` tem um por requisição. Os campos de que você mais precisa durante um incidente são os de alta cardinalidade. "Qual cliente está afetado" é uma pergunta de `customer_id`. "Qual build está servindo as requisições lentas" é uma pergunta de `deploy_version`. Se o seu modelo de armazenamento penaliza campos de alta cardinalidade, seja cobrando por série única, seja descartando-os em silêncio, você não consegue fazer a pergunta que resolve o incidente. Esta é a verdadeira linha arquitetural entre uma configuração só de métricas e uma configuração observável. Métricas pré-agregadas descartam as dimensões que você vai querer depois. Eventos largos e estruturados as mantêm, e você fatia os dados depois do fato. Veja como é um evento útil na borda de um serviço. Um registro estruturado por requisição, com contexto suficiente para fatiar por qualquer coisa que você vá precisar depois: `logger.info("request.completed", { trace_id: span.traceId, route: "/v1/payments", customer_id: ctx.customerId, deploy_version: process.env.BUILD_SHA, flag_variant: flags.get("new-ledger-path"), db_ms: timings.db, upstream_ms: timings.upstream, status: res.statusCode, duration_ms: elapsed, });`Repare na variante da feature flag ali. Metade dos incidentes em post-mortems públicos começa com uma mudança, e a avaliação de uma flag é uma mudança. Se a variante não está no evento, você não consegue perguntar se as requisições lentas são justamente as que passam pelo novo caminho. ![Mesa com notebook exibindo um dashboard de latência](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/c95a59-i2.webp) ## Como é um incidente com e sem observabilidade? Pegue de novo o cenário de pagamentos. Mesmo alerta, mesmo p99 de 1.4 s. Sem observabilidade, o ciclo é: abrir o dashboard do serviço, não encontrar nada, abrir o dashboard do banco, não encontrar nada, perguntar no canal do incidente se algo foi implantado. Alguém lembra de uma mudança de configuração. Outra pessoa discorda. Quarenta minutos depois, você reverte o último deploy para ver se ajuda. Não ajuda, porque a causa era um rollout de flag para um subconjunto de tenants. Com observabilidade, o ciclo é: agrupar as requisições lentas por `flag_variant`, ver que 100% delas estão em `new-ledger-path`, agrupar por `customer_id`, ver que três tenants grandes concentram a maior parte do volume, abrir um trace e ver a chamada ao ledger se abrir em 40 consultas sequenciais. Tempo total: poucos minutos. Você desliga a flag, não o deploy. Repare no que o segundo ciclo não precisou. Não precisou de um dashboard preparado. Não precisou que alguém tivesse previsto de antemão que "variante de flag" era uma dimensão interessante. Precisou que o dado estivesse ali, largo e consultável. Esse é o argumento da Honeycomb em um parágrafo, e ele se sustenta. O que ele não diz é que isso é de graça. ## Quanto custa, e quem deveria pular a versão cara? Telemetria é um problema de volume de dados antes de ser um problema de ferramenta. Segundo a [pesquisa de observabilidade de 2025 da Grafana Labs, com 1,255 profissionais](https://grafana.com/blog/2025/03/25/observability-survey-takeaways), a organização média usa oito ferramentas de observabilidade diferentes, e custo é o critério mais citado na hora de escolher novas. Esses dois fatos estão ligados. As equipes acumulam ferramentas porque cada uma resolve uma fatia, e depois pagam pela ingestão sobreposta em todas elas. Regras práticas que valem para a maioria dos tamanhos de equipe: - **Instrumente com OpenTelemetry, não com um agente proprietário.** O collector dá um único lugar para amostrar, filtrar e rotear. Trocar de backend vira uma mudança de configuração, e não um projeto de reinstrumentação. - **Amostre traces com intenção.** Guarde todo erro e toda requisição lenta, e amostre as requisições saudáveis e rápidas. Amostragem head-based fixa em 1% descarta justamente o trace de que você precisa. - **Coloque estrutura nos logs na hora da escrita.** Interpretar texto livre na hora da consulta é a forma cara de obter campos. - **Defina uma política de retenção por sinal.** Métricas por um ano, eventos largos por duas semanas, logs de debug por três dias. Ninguém nunca precisou dos logs de debug do trimestre passado. Evite a abordagem de plataforma completa se você roda um punhado de serviços e um único rodízio de on-call. Uma equipe pequena obtém a maior parte do benefício com logs estruturados, métricas RED e traces nos dois ou três caminhos mais quentes. O contrato caro, que faz tudo, se paga quando há serviços suficientes para que ninguém mantenha a topologia inteira na cabeça, o que, na nossa experiência, acontece a partir de 30 ou 40 serviços. ## Quais ferramentas valem a pena avaliar? A escolha depende de quanto você quer operar sozinho, de como é a sua cardinalidade e do que a sua fatura aguenta. Um tour curto e opinativo: Datadog é a opção comercial mais ampla: métricas, logs, traces e profiling sob o mesmo teto, com forte correlação entre eles. O preço dessa integração é uma fatura que escala com hosts, métricas customizadas e volume de logs ingeridos. Vale a pena quando você quer um único fornecedor e tem orçamento para isso. Confira o item de métricas customizadas antes de fechar. Grafana é a escolha padrão quando você quer componentes abertos, que podem ser auto-hospedados ou comprados como stack gerenciada. Combina bem com métricas no estilo Prometheus e com pipelines OpenTelemetry. O trade-off é operacional: você passa a ser dono de mais da montagem, e a dispersão de ferramentas apontada na pesquisa acima também se aplica a você. SigNoz é uma opção open source, nativa em OpenTelemetry, que coloca logs, métricas e traces em um único datastore. Isso importa para o ponto de correlação de antes, porque um armazenamento compartilhado transforma o salto de métrica para trace, e de trace para log, em uma consulta, e não em uma troca de abas. É uma opção razoável para equipes que querem auto-hospedar sem costurar quatro projetos diferentes. Better Stack reúne monitoramento de uptime, alertas de incidentes e gestão de logs, com preço pensado para equipes menores. É um primeiro passo sensato para quem está saindo de "descobrimos pelos clientes" para algo estruturado, e menos adequado para uma service mesh grande com requisitos pesados de trace. ![Corredor de data center com luzes de status](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/63d34b-i3.webp) ## Como começar sem tentar resolver tudo de uma vez? Não comece com uma avaliação de ferramentas. Comece pelos três últimos incidentes e por uma pergunta honesta: o que gostaríamos de ter conseguido perguntar? Uma sequência que funciona para uma equipe de 50 a 200 engenheiros: - **Escolha um caminho crítico de requisição** e instrumente-o de ponta a ponta com OpenTelemetry. Checkout, login, o que for que acorda você às 3 da manhã. - **Emita um evento estruturado e largo por requisição** na borda do serviço, com cliente, versão, variantes de flag e tempos das dependências downstream. - **Defina um SLO nesse caminho** e alerte pela taxa de consumo do orçamento de erro, e não por limites brutos. Alertas de burn rate acionam por impacto no usuário, e a telemetria do passo 2 explica o porquê. - **Faça um game day.** Injete uma falha para a qual você não tem alerta e veja quanto tempo leva para alguém que não escreveu o código encontrá-la. Esse número é a sua linha de base. - **Expanda um caminho por vez**, somente depois que o primeiro tiver se pago em um incidente real. Observabilidade é comprada como plataforma e adotada como hábito. O hábito é perguntar "o que eu precisaria saber para explicar isto?" na revisão de código, antes do incidente, e não durante ele. Abra a sua última revisão de incidente. Encontre a frase que diz "depois adicionamos logging para confirmar". Cada uma delas é uma pergunta que o seu sistema não conseguiu responder em produção. Quantas você tem registradas, e quais delas ainda seriam impossíveis de responder hoje? ## FAQ ### O que é observabilidade em termos simples? É a capacidade de entender por que um sistema se comporta de determinada forma usando os dados que ele já emite, mesmo para falhas inesperadas, sem precisar implantar código novo para investigar. ### Qual a diferença entre observabilidade e monitoramento? O monitoramento verifica modos de falha conhecidos com alertas e limites. A observabilidade permite investigar falhas novas, que ainda não foram previstas. Os dois são complementares. ### Quais são os três sinais da observabilidade? Logs, métricas e traces. Métricas medem tendências agregadas, logs registram eventos discretos e traces acompanham uma requisição entre serviços. O valor aparece quando os três estão correlacionados por um identificador comum. ### Por que a cardinalidade importa? Campos de alta cardinalidade, como o ID do cliente ou a versão do build, são os que mais ajudam a isolar um incidente. Sistemas que cobram por série ou descartam esses campos impedem essas perguntas. ### Uma equipe pequena precisa de observabilidade completa? Normalmente não. Logs estruturados, métricas RED e traces nos caminhos mais críticos já trazem a maior parte do benefício. Plataformas completas costumam compensar quando há dezenas de serviços. ### Por onde começar? Escolha um caminho crítico de requisição, instrumente com OpenTelemetry, emita um evento estruturado por requisição, defina um SLO e faça um game day para medir o tempo de diagnóstico.