O que é observabilidade e por que o monitoramento não basta

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.

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.

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, 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.

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:

1. 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ã.

2. 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.

3. 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ê.

4. 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.

5. 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?