O que é observabilidade?

Observabilidade é a capacidade de entender o que acontece dentro de um sistema a partir dos dados que ele emite, sem precisar abri-lo para inspecionar. Ela vai além do monitoramento porque permite perguntas que ninguém formulou antes do incidente. Neste guia você encontra a diferença entre observabilidade e monitoramento, como logs, métricas e traces se encadeiam numa investigação, quanto custa, quando ainda é cedo e o que mudou com o OpenTelemetry e os sistemas de inteligência artificial (IA). Em 30 de outubro de 2026, o OpenTelemetry é projeto graduado da CNCF, e a conversa se deslocou para observar agentes de IA.

• Mais de 12.000 contribuidores de mais de 2.800 empresas participam do OpenTelemetry, segundo o comunicado de graduação da CNCF de 21/05/2026
• Prometheus está em produção em 59% das organizações e o OpenTelemetry em 41%, na pesquisa da Grafana Labs de 2026, com mais de 1.300 respondentes em 76 países
• Custo foi o critério mais citado para escolher ferramentas de observabilidade na mesma pesquisa de 2026, e só 15% apontaram capacidades de IA como prioridade
• 82% das organizações rodam Kubernetes em produção, segundo a pesquisa anual da CNCF de 2025, publicada em janeiro de 2026

O que é observabilidade e como ela se diferencia de monitoramento?

Observabilidade é a capacidade de entender o que acontece dentro de um sistema olhando apenas para os dados que ele emite. Ela se diferencia do monitoramento porque serve para investigar problemas que ninguém previu, enquanto o monitoramento vigia falhas que você já conhecia e para as quais já definiu um limite. A documentação do OpenTelemetry resume observabilidade como “understand a system from the outside”: você investiga o comportamento sem precisar conhecer o funcionamento interno. O dado que o sistema emite tem nome próprio, telemetria.

O termo não nasceu na TI. Rudolf E. Kalman o introduziu em 1960, junto com o conceito irmão de controlabilidade, no trabalho “On the General Theory of Control Systems”, apresentado no primeiro congresso da IFAC. Quem trabalha com sistemas distribuídos pegou a ideia emprestada da teoria de controle e a aplicou a serviços, filas e bancos que ninguém consegue abrir e inspecionar enquanto rodam.

A diferença entre monitoramento e observabilidade está no tipo de pergunta que cada um responde. Monitoramento responde a perguntas que você já sabia fazer: o disco encheu? A fila cresceu além do normal? Você define o limite antes, e o alerta dispara quando o limite estoura. Observabilidade tenta cobrir o resto. São os “desconhecidos desconhecidos”, como a requisição que falha só para clientes de um estado, numa versão específica do app, depois de um deploy que ninguém ligou ao sintoma. Para isso não existe dashboard pronto, porque ninguém sabia que precisava de um.

	Monitoramento	Observabilidade
Pergunta	Definida antes do incidente	Formulada durante a investigação
Tipo de falha	Prevista, com limite conhecido	Imprevista, sem painel pronto
Saída típica	Alerta e gráfico	Hipótese testada contra a telemetria
Dado que usa	Métricas e checks de saúde	Traces, logs e métricas cruzados por requisição
Responde a	“Algo quebrou?”	“Onde quebrou, e por quê?”

O vocabulário de base vem de antes do termo virar moda. O capítulo sobre monitoramento de sistemas distribuídos do livro de SRE do Google, de 2016, nem usa a palavra observabilidade nesse sentido, mas separa duas coisas que até hoje se confundem. Monitoramento white-box se baseia em métricas que o próprio sistema expõe por dentro. Monitoramento black-box testa o comportamento visível de fora, como um usuário veria. E o livro distingue sintoma de causa: “what’s broken” é o sintoma, “why” é a causa, que pode ser só intermediária.

A frase “monitoramento diz o quê, observabilidade explica o porquê” circula em material de fornecedor. Trate como atalho didático, e só isso. Um monitoramento white-box bem feito também aponta causas, e uma plataforma de observabilidade com instrumentação ruim não explica nada. O que separa as duas práticas é se você consegue fazer uma pergunta nova sem precisar de um novo deploy para respondê-la.

Como funciona a observabilidade na prática: logs, métricas e traces

Na prática, a observabilidade funciona cruzando três tipos de telemetria, logs, métricas e traces, para reconstruir o que o sistema fez a partir do que ele emitiu. Cada sinal responde a uma parte da pergunta. Nenhum deles fecha uma investigação sozinho.

As definições do OpenTelemetry são curtas e vale guardá-las:

• Trace: registra o caminho de uma única requisição entre serviços. É formado por spans, cada um cobrindo uma operação (a chamada HTTP, a consulta ao banco, a publicação na fila), com início, fim e os atributos daquela etapa.
• Métrica: agregação de dados numéricos ao longo de um período. Requisições por segundo, percentil 99 de latência, uso de CPU. Barata de guardar, boa para alertar, inútil para explicar um caso individual.
• Log: mensagem com timestamp emitida por um serviço ou componente. Não está necessariamente ligada a uma requisição específica, e é aí que mora a dor de quem investiga.

Uma investigação real costuma andar nesta ordem. A métrica dispara o alerta: a taxa de erro do checkout subiu. O trace mostra em qual span a requisição morreu, digamos na chamada ao serviço de frete. O log daquele span, naquele instante, traz a exceção com a mensagem que explica o caso. Para a sequência funcionar, os três precisam compartilhar um identificador: o ID do trace tem de aparecer no log. Sem ele você fica com três silos e um grep na madrugada.

Os três não são o fim da lista. O OpenTelemetry lista também o baggage como sinal suportado, eventos e profiles aparecem como sinais em desenvolvimento, e o suporte a profiles estava oficialmente em alpha em maio de 2026.

Agora a parte incômoda. Os “três pilares” são o modelo mais ensinado de observabilidade e também o mais criticado. Charity Majors, da Honeycomb, defende que observabilidade é poder perguntar qualquer coisa a um sistema de fora, com dados de alta cardinalidade (campos com muitos valores distintos, como o ID do cliente) e alta dimensionalidade (muitos atributos por evento). Na plenária da SREcon24 Americas, em 2024, ela enquadrou a virada como uma quebra de compatibilidade, no espírito do versionamento semântico: uma “Observability 2.0” em que logs, métricas e traces colapsam num único evento estruturado largo por requisição. Ela mesma passou depois a evitar o rótulo. A crítica, porém, ficou: separar os sinais em três seria uma taxonomia herdada de ferramentas que guardam cada um em um banco diferente, e não uma propriedade do problema.

A documentação do OpenTelemetry segue tratando os sinais como complementares. Na minha leitura, as duas visões convergem no que importa para quem opera sistema: você precisa conseguir cruzar os dados por requisição, com atributos suficientes para filtrar por cliente, versão e região. Se consegue, chame de pilares ou de eventos. Se não consegue, o nome que você dá à ferramenta não vai te salvar às 3h da manhã.

Para que serve observabilidade em sistemas distribuídos e aplicações de IA

Observabilidade serve para diagnosticar requisições que atravessam dezenas de serviços, sustentar metas de confiabilidade com medição em vez de promessa e, em aplicações de inteligência artificial (IA), entender o que cada chamada a um modelo fez e quanto custou. Os três usos têm a mesma raiz: ninguém consegue abrir o sistema para olhar, então a telemetria precisa contar a história.

O primeiro uso nasceu com os sistemas distribuídos. Quando uma requisição passa por dezenas de microsserviços, o log de cada um conta só um pedaço, e ninguém sabe de antemão qual pedaço importa. O Dapper, a infraestrutura de tracing do Google descrita em 2010, é o marco dessa virada. Suas metas eram overhead baixo, transparência para a aplicação (o desenvolvedor não precisava mexer no próprio código) e implantação em grande escala. Para caber nesse orçamento, usava amostragem e instrumentava poucas bibliotecas comuns a todos os serviços. Começou como ferramenta de tracing e evoluiu para uma plataforma de monitoramento, o mesmo caminho que boa parte das ferramentas de observabilidade percorreu depois.

O segundo uso é dar número à confiabilidade. Na definição do OpenTelemetry, confiabilidade é a pergunta “o serviço está fazendo o que os usuários esperam?”. Um SLI é a medida do comportamento do serviço. Um SLO é a forma de comunicar a meta de confiabilidade a quem depende dele. Sem telemetria, SLO é um parágrafo no contrato. Os quatro sinais de ouro do SRE são o ponto de partida mais comum para escolher os SLIs:

1. Latência: quanto tempo a requisição leva, separando as que deram certo das que falharam
2. Tráfego: quanta demanda o sistema recebe
3. Erros: que fração das requisições falha
4. Saturação: quão perto do limite o recurso mais apertado está

O terceiro uso é encurtar o caminho entre o alerta e a causa. O mecanismo é simples de descrever: se o trace já mostra o span que falhou e o log daquele span já carrega o contexto, o engenheiro de plantão pula a etapa de reproduzir o erro e vai direto para a hipótese. Quanto menos ele precisa adivinhar, menos tempo o incidente dura.

Em aplicações de IA generativa o problema muda de forma, mas o raciocínio é o mesmo. Uma chamada a um LLM não é determinística, custa por token e, num agente, encadeia várias chamadas, ferramentas e consultas a bases de conhecimento antes de devolver uma resposta. Sem trace, você não sabe qual passo da cadeia alucinou nem qual ferramenta travou. Sem métrica de tokens por requisição, a fatura do provedor chega sem explicação, e ninguém consegue dizer qual fluxo a inflou. Quem coloca agentes de IA em produção aprende isso no primeiro mês de conta: cada prompt vira um “serviço” na cadeia, e observar essa cadeia é o que separa um agente que você consegue operar de uma demo que só funciona na apresentação.

Quando a observabilidade falha: alertas ruidosos, custo de ingestão e dados sem contexto

A observabilidade falha quando a equipe tem telemetria de sobra e resposta de menos: alertas que ninguém atende, logs que não se ligam a nenhuma requisição, métricas com tantos rótulos que o banco engasga e uma amostragem que descarta justamente o erro que você procurava. Nenhum desses problemas é falta de ferramenta. São erros de desenho que a ferramenta esconde até o primeiro incidente sério.

Os antipadrões se repetem de empresa para empresa, e quase todos têm a mesma cura: decidir antes o que cada dado precisa responder.

• Alerta sem ação: dispara, alguém olha, ninguém faz nada. Em poucas semanas o canal vira ruído e o alerta que importava passa despercebido no meio dos outros. Todo alerta precisa de um dono e de uma ação esperada. Se não tem, vira painel ou some.
• Log sem estrutura nem correlação: a mensagem existe, em texto livre, sem o ID do trace nem o do cliente. Para achar o erro, alguém precisa adivinhar a palavra certa para buscar. Logs com campos nomeados e o identificador da requisição resolvem isso na origem, e custam uma linha de configuração.
• Cardinalidade descontrolada: alguém põe o ID do usuário como rótulo de uma métrica, e cada usuário vira uma série temporal nova. O armazenamento de métricas foi feito para agregar. Detalhe individual pertence ao trace e ao evento, em que cada registro é um caso.
• Amostragem cega: para conter volume, o pipeline guarda, digamos, um em cada cem traces, escolhido ao acaso. A falha que atinge uma fração pequena das requisições de um cliente específico some antes de chegar ao backend. Decidir o que guardar depois de saber se a requisição falhou preserva os casos que interessam.
• Retenção uniforme: o log de debug e o trace do incidente guardados pelo mesmo prazo. Um deles é lixo em 48 horas.

Existe uma falha mais sutil, e ela irrita porque atinge quem fez tudo certo. Ter os dados não garante o diagnóstico. Um artigo de pesquisadores da IBM publicado no arXiv em fevereiro de 2025 questiona a crença de que o tracing distribuído basta para achar a causa-raiz e traz exemplos de atribuição errada em produção: o trace aponta o serviço em que a latência apareceu, e a equipe conserta ali, enquanto a origem estava dois saltos antes, numa fila saturada que só se manifestou no vizinho. Trace mostra onde o sintoma apareceu. A causa ainda exige hipótese e teste.

A lista de erros já virou objeto de estudo. Uma tese de doutorado defendida na Universidade Federal do Ceará em 2026 revisou 84 estudos publicados de 2019 a 2025 sobre observabilidade em microsserviços e propôs uma taxonomia e um catálogo de antipadrões. Se você vai instrumentar um sistema grande, ler o catálogo antes custa menos que descobrir cada item no plantão.

Quanto custa implementar observabilidade e o que define o preço

Observabilidade não tem preço de tabela: o custo é função do volume de telemetria que você ingere por dia, de quanto tempo guarda, da cardinalidade das métricas, do número de hosts e serviços instrumentados e de quem opera a stack. Não existe dado público consolidado sobre quanto empresas brasileiras gastam com isso, e qualquer cifra em reais que circule por aí é estimativa de fornecedor. O que dá para fazer é entender os fatores e controlar cada um.

Fator	O que faz a conta subir	Como segurar
Volume ingerido (GB/dia)	Log em nível debug em produção, traces sem amostragem	Nível de log por ambiente, amostragem com critério
Retenção	Tudo guardado pelo mesmo prazo	Prazo por tipo de dado, arquivo frio para auditoria
Cardinalidade de métricas	Rótulo com ID de usuário ou de requisição	Rótulo só para dimensão agregável, detalhe vai ao trace
Hosts e serviços	Cobrança por host, container ou usuário, conforme o fornecedor	Instrumentar primeiro o que entra no SLO
Equipe	Stack própria exige quem opere Prometheus, Grafana, Jaeger e o Collector	Comparar salário com fatura antes de decidir

O modelo de cobrança muda de fornecedor para fornecedor (por host, por GB ingerido, por usuário), então o mesmo sistema custa caro num plano e barato em outro, dependendo de onde ele é grande. Um cluster com poucos nós e muitos logs sofre na cobrança por volume. Um parque com centenas de containers pequenos sofre na cobrança por host.

A escolha entre SaaS e stack própria não elimina custo, só muda de linha no orçamento. Prometheus, Grafana, Jaeger e o OpenTelemetry Collector não cobram licença, mas alguém precisa dimensionar o armazenamento, cuidar da retenção, atualizar versão e acordar quando o próprio sistema de observabilidade cair. Esse alguém custa salário. Na fatura SaaS, o preço é visível e cresce com o uso. Na stack própria, ele fica diluído na folha e aparece como atraso em outros projetos. Quem precisa decidir entre operar e contratar, ou dimensionar a infraestrutura de coleta, costuma resolver isso com consultoria DevOps antes de assinar contrato de dois anos.

O que ninguém descobre até ver a primeira fatura é que o custo não acompanha o número de usuários. Ele acompanha o número de deploys descuidados. Um log em loop num único pod consome a cota do mês numa tarde, e a equipe só percebe quando o fornecedor corta a ingestão ou manda a conta.

O mercado sabe disso. Na pesquisa anual da Grafana Labs de 2026, com mais de 1.300 respondentes em 76 países, o custo foi o critério mais citado para escolher novas ferramentas de observabilidade, e só 15% apontaram capacidades de IA como prioridade. Vale a ressalva: é pesquisa de fornecedor, com amostra que se inscreveu por conta própria. Mesmo assim, o recado bate com o que se vê em qualquer renegociação de contrato: a conta de telemetria virou item de orçamento que o diretor financeiro lê linha por linha.

Qual a diferença entre observabilidade, APM e telemetria

Telemetria é o dado, APM é uma categoria de produto, e observabilidade é a propriedade do sistema (e a prática) que usa esse dado para responder perguntas. Os três aparecem juntos em qualquer proposta comercial, e por isso se misturam, mas moram em camadas diferentes.

Telemetria é o termo mais simples. A documentação do OpenTelemetry a define como “data emitted from a system and its behavior”: logs, métricas, traces e baggage são telemetria. Ela é matéria-prima. Telemetria sem alguém formulando uma pergunta é só armazenamento pago.

APM (application performance monitoring) é um produto. Ele mede o desempenho de aplicações: tempo de resposta por endpoint, transações lentas, taxa de erro, consumo de recursos. O formato clássico instala um agente do fornecedor dentro do processo da aplicação, e esse agente coleta e envia tudo para o backend do mesmo fornecedor. Funciona bem para as perguntas que o produto já previu. Para trocar de fornecedor, você reinstrumenta o sistema inteiro, porque o agente só fala com a casa dele.

Observabilidade é o que você consegue fazer com tudo isso. Dá para ter um APM caro e não ser observável, quando as perguntas possíveis são só as do painel. E dá para ser observável sem APM nenhum, com traces, métricas e logs correlacionados numa stack aberta que responde a uma pergunta nova sem precisar de deploy.

O OpenTelemetry entra como camada de coleta e transporte, e só. A documentação do projeto o descreve como agnóstico de fornecedor e de ferramenta e afirma que ele não é um backend de observabilidade: não armazena nem visualiza dados. Na prática, isso significa que você instrumenta o código uma vez e escolhe depois para onde mandar a telemetria, seja um APM comercial, seja Prometheus com Jaeger e Grafana. É essa separação que tira o agente proprietário do centro da decisão e devolve a escolha de backend para quem paga a conta.

Para quem observabilidade vale a pena e quando ainda é cedo

Observabilidade vale a pena para quem opera sistemas que ninguém consegue depurar abrindo um único processo: microsserviços em Kubernetes, produtos com SLO no contrato e aplicações que encadeiam chamadas a LLMs. Para um monólito pequeno tocado por uma equipe só, ainda é cedo. Monitoramento básico e logs estruturados resolvem a maior parte dos incidentes por uma fração do esforço.

O corte não é por tamanho de empresa. É por quantas fronteiras uma requisição cruza antes de voltar ao usuário.

• Monólito com uma equipe: o stack trace já mostra o caminho inteiro. Métricas dos quatro sinais de ouro, logs com campos nomeados e um alerta por SLI bastam. Instalar tracing distribuído aqui é pagar por um problema que você ainda não tem.
• Microsserviços e Kubernetes: o uso de Kubernetes em produção chegou a 82% na pesquisa anual da CNCF de 2025, publicada em janeiro de 2026. Nesse cenário, o log de um pod conta um pedaço da história, e o pod pode nem existir mais quando alguém for ler. Sem trace, o diagnóstico vira arqueologia.
• Produto com SLO contratual: se a disponibilidade está num contrato, você precisa medir do jeito que o cliente enxerga e precisa provar. Telemetria por requisição é a única forma de dizer quais clientes foram afetados e por quanto tempo.
• Aplicações com LLMs e agentes: cada passo da cadeia é não determinístico e cobrado por token. Sem trace por chamada, você não sabe qual etapa falhou nem qual fluxo inflou a fatura.

Sinais de que ainda é cedo: a equipe cabe numa sala, o sistema roda em poucos processos, e o último incidente foi resolvido em minutos lendo o log. Nesse caso, gaste o tempo em logs com ID de requisição. É a parte da instrumentação que não envelhece e que você aproveita inteira quando o sistema crescer.

Sinais de que já está atrasado: o incidente da semana passada levou horas porque ninguém sabia em qual serviço a latência nasceu. Ou alguém precisou fazer deploy de um log novo de madrugada só para enxergar o que estava acontecendo. Ou a fatura do provedor de LLM subiu, e ninguém soube explicar qual fluxo foi o responsável. Se você toca a plataforma de uma fintech em São Paulo, com dezenas de serviços e um SLA assinado com o banco parceiro, esse ponto ficou para trás há tempo.

O que mudou em observabilidade com OpenTelemetry e sistemas de IA

O que mudou é que a instrumentação deixou de ser propriedade do fornecedor: o OpenTelemetry virou o padrão de fato para coletar telemetria, graduou na CNCF em 21 de maio de 2026 e agora tenta repetir o feito com chamadas a modelos e agentes de IA, um terreno em que ainda disputa espaço com esquemas concorrentes.

A linha do tempo é curta:

1. 2010: o Google publica o Dapper e mostra que tracing distribuído funciona em escala, com amostragem e overhead baixo.
2. 2019: OpenTracing e OpenCensus, dois projetos que atacavam a falta de padrão para instrumentar código, se fundem e formam o OpenTelemetry.
3. 21 de maio de 2026: a CNCF gradua o projeto, depois de auditoria de segurança independente e revisão de governança.

Os números do comunicado de graduação dão a dimensão. O projeto soma mais de 12.000 contribuidores de mais de 2.800 empresas e tem a segunda maior velocidade de desenvolvimento entre os mais de 240 projetos da fundação, atrás só do Kubernetes. Entre os adotantes citados estão Alibaba, Anthropic, Bloomberg, Capital One, eBay, FICO e Heroku.

Em produção, o padrão mais antigo ainda lidera. Na pesquisa da Grafana Labs de 2026, o Prometheus estava em produção em 59% das organizações e o OpenTelemetry em 41%. Os dois não competem: 65% dos respondentes investem nos dois ao mesmo tempo, e 77% dizem que padrões abertos ou código aberto pesam na estratégia de observabilidade. A expectativa sobre o OpenTelemetry é concreta: 41% acham que ele facilita adoção e gestão, e 37% que facilita trocar de fornecedor. A pesquisa do próprio projeto sobre interoperabilidade com o Prometheus, de 2026, tem a mesma inclinação para empresa grande (42% dos respondentes com 1.000 ou mais funcionários, 31% entre 100 e 999), então leia os percentuais como retrato de quem já opera em escala.

A parte de IA é a mais nova e a menos assentada. As convenções semânticas de GenAI do OpenTelemetry definem como nomear spans de agentes, métricas, eventos e exceções, cobrem o MCP e trazem atributos específicos de provedores: Anthropic, AWS Bedrock, Azure AI Inference e OpenAI. O conteúdo migrou para um repositório próprio, e a página de referência não exibe versão nem status. Um resumo de maio de 2026 ainda descrevia as convenções como em desenvolvimento, enquanto um texto de junho de 2026 afirmava que a versão estável tinha saído. Antes de instrumentar um agente com base nelas, confira o status no repositório oficial, porque atributo que muda de nome quebra dashboard e alerta no deploy seguinte.

E existe concorrência. O OpenInference, da Arize, e os atributos próprios de cada fornecedor coexistem com as convenções do OpenTelemetry, e o resultado é dado fragmentado: a mesma chamada a um modelo aparece com nomes de campo diferentes dependendo de qual SDK a instrumentou. Quem está escolhendo em 2026 faz bem em instrumentar pelas convenções do OpenTelemetry e mapear o resto, em vez de apostar num esquema que o fornecedor pode abandonar.

Perguntas frequentes sobre o que é observabilidade

As dúvidas mais comuns sobre o que é observabilidade giram em torno da diferença para monitoramento, dos três pilares, do OpenTelemetry e de quais ferramentas escolher. As respostas abaixo vão direto ao ponto.

Observabilidade é a mesma coisa que monitoramento?

Não. Monitoramento vigia falhas que você já previu, com limites definidos antes e alertas que disparam quando o limite estoura. Observabilidade é a capacidade de investigar um problema que ninguém previu, formulando perguntas novas sobre a telemetria que o sistema já emitiu, sem precisar de um deploy para respondê-las. Monitoramento e observabilidade se complementam: o alerta vem do primeiro, e a investigação depende da segunda.

Quais são os três pilares da observabilidade?

Logs, métricas e traces. O log é uma mensagem com timestamp, a métrica é uma agregação numérica ao longo do tempo, e o trace registra o caminho de uma única requisição entre serviços. O OpenTelemetry lista ainda o baggage como sinal suportado e mantém profiles em alpha desde maio de 2026. A Honeycomb critica a divisão em três e defende um único evento estruturado largo por requisição, com alta cardinalidade.

O que é OpenTelemetry?

OpenTelemetry é um projeto de código aberto da CNCF que padroniza como instrumentar código e coletar telemetria. Nasceu em 2019 da fusão de OpenTracing e OpenCensus e graduou na fundação em 21 de maio de 2026. Ele é agnóstico de fornecedor e de ferramenta e não é um backend: coleta e transporta os dados, mas não armazena nem visualiza nada.

Quais são as ferramentas de observabilidade mais usadas?

Na pesquisa da Grafana Labs de 2026, o Prometheus estava em produção em 59% das organizações e o OpenTelemetry em 41%. A stack aberta mais comum combina Prometheus para métricas, Jaeger para traces, Grafana para visualização e o OpenTelemetry Collector para coleta. Produtos comerciais de APM cobrem as mesmas funções com agente próprio e cobrança por uso. Não existe levantamento público sobre quais ferramentas de observabilidade dominam no Brasil.

O que é observabilidade em DevOps e SRE?

Em SRE, observabilidade é a base para medir confiabilidade: os quatro sinais de ouro (latência, tráfego, erros e saturação) viram SLIs, e os SLIs sustentam o SLO que você comunica a quem depende do serviço. Em DevOps, ela fecha o ciclo entre quem faz o deploy e quem investiga o incidente, porque a mesma equipe que publicou a mudança consegue ver o efeito dela por requisição. Nos dois casos, a telemetria substitui a adivinhação no plantão.

Como medir se um sistema é observável?

Não há métrica pública padronizada para isso, então o teste é prático. Pegue o último incidente e verifique três coisas: dá para seguir uma requisição de ponta a ponta pelo mesmo ID, dá para filtrar a telemetria por cliente, versão e região sem gerar um log novo, e o log traz o ID do trace. Se qualquer uma das três falha, o sistema emite dados, mas não é observável.

Por onde começar a observar seus sistemas

Comece por instrumentar o código com OpenTelemetry e por colocar o ID da requisição em todo log. Essas duas decisões sobrevivem a qualquer troca de ferramenta, e tudo o que vem depois depende delas.

A sequência que funciona na prática tem cinco passos:

1. Instrumente com OpenTelemetry, de preferência pelas bibliotecas automáticas da sua linguagem, para gerar traces sem reescrever o código
2. Estruture os logs com campos nomeados e inclua o ID do trace em cada linha
3. Defina dois ou três SLIs para o fluxo que mais dói quando falha, e escreva o SLO que você consegue sustentar
4. Crie um alerta por SLI, com dono e ação esperada. Alerta sem resposta prevista vira ruído em semanas
5. Revise a conta de ingestão todo mês e corte o log que ninguém consultou

Não tente cobrir o sistema inteiro na primeira semana. Escolha o fluxo que entra no SLO, instrumente-o de ponta a ponta e espere o primeiro incidente provar o que falta. Se o seu caso envolve agentes ou pipelines de RAG em produção, o time da AlphaCorp AI monta essa instrumentação junto com o deploy, e não depois da primeira fatura inexplicável.