Observabilidade

Os 3 pilares da observabilidade na era da AI, postos à prova

Por RIKE IS Comunicação

Os 3 pilares da observabilidade são logs, métricas e traces, e o valor vem da correlação entre eles, nunca da coleta isolada. O OpenTelemetry chama esses pilares de sinais e lista mais de três. Cargas de inteligência artificial acrescentam qualidade da resposta, consumo de token e drift, sinais que nenhum limiar clássico captura.

Um modelo responde em milissegundos, devolve o formato esperado e entrega a resposta errada. Latência normal, código de status normal, nenhum limiar rompido. Os três sinais que a observabilidade coleta há uma década não têm onde registrar esse tipo de falha.

Os 3 pilares da observabilidade são logs, métricas e traces, os três tipos de telemetria que um sistema emite sobre si mesmo. Logs registram eventos discretos, métricas medem o estado do sistema ao longo do tempo e traces reconstroem o percurso de uma requisição entre serviços. Na era da inteligência artificial esse modelo continua correto e deixa de ser suficiente, porque descreve bem software determinístico e um sistema de IA não é determinístico.

O que são os 3 pilares da observabilidade: logs, métricas e traces

Os 3 pilares da observabilidade permitem inferir o estado interno de um sistema pelo que ele mostra para fora, sem prever antes cada falha. O requisito de entrada é instrumentação, as câmeras instaladas na fábrica, porque sem instrumentar não existe sinal para coletar.

SinalO que registraPergunta que responde
LogsEventos discretos com carimbo de tempo e contextoQuais eventos ocorreram
MétricasValores numéricos coletados em intervalos regularesO que está acontecendo no nível do sistema
TracesO percurso de uma requisição entre serviçosOnde na cadeia o problema aconteceu

A correlação entre os três só existe quando eles compartilham identificadores e atributos, e é ela que separa observabilidade full-stack, com aplicações, infraestrutura, cloud e experiência digital no mesmo contexto correlacionado, de uma coleção cara de dashboards.

Logs, o diário de bordo

Log estruturado é o registro de um evento em campos nomeados, em vez de texto livre, que obriga a equipe a caçar padrão com expressão regular durante o incidente. O log entrega a narrativa do evento específico, com a mensagem de erro exata, e cobra volume em troca, o que vira obrigação onde o setor exige retenção longa.

Métricas, o painel do carro

Métrica é a medição numérica gravada em série temporal, barata de armazenar e rápida de consultar. Ela mostra tendência e estado agregado, e quase nunca diz por quê. Rótulo de alta variedade é o que a encarece, assunto tratado adiante sob o nome de cardinality.

Traces, o GPS de uma requisição

Trace é o GPS de uma viagem, mostrando cada parada do trajeto. A unidade do trace é o span, o registro de uma operação única dentro do percurso, com início, fim e atributos próprios. A árvore de spans expõe a latência por nó e dá endereço ao problema em sistemas distribuídos, e depende de propagação de contexto para existir por inteiro.

Observabilidade e monitoramento não são a mesma coisa

Monitoramento responde perguntas definidas antes: alguém configura um limiar e o alerta dispara quando ele é ultrapassado. Observabilidade permite formular perguntas novas sobre dados já coletados, inclusive as que ninguém previu.

Centralizar log e montar dashboard é monitoramento sofisticado, e sem identificador comum entre os sinais continuam sendo três coletas isoladas. No plantão, essa diferença aparece quando a pergunta deixa de ser o que quebrou e passa a ser por que quebrou.

Por que o padrão aberto não fala em três pilares, fala em sinais

A expressão três pilares é uma convenção didática do mercado, útil para ensinar e imprecisa para planejar arquitetura. A documentação do OpenTelemetry não usa essa expressão: ela define sinais, e a lista oficial é maior que três.

O que o OpenTelemetry define como sinal

OpenTelemetry é o padrão aberto e vendor-neutral mantido pela CNCF, que define APIs, SDKs, convenções semânticas e protocolo de transporte de telemetria. É o padrão USB-C da telemetria. A documentação oficial lista como sinais os traces, as métricas, os logs e a baggage, que é a informação contextual propagada entre sinais, e registra eventos e perfilamento como sinais em desenvolvimento.

Existe um quarto pilar da observabilidade?

O candidato mais citado é o sinal de perfis, que responde qual código é responsável pelo consumo de recursos. A documentação do OpenTelemetry classifica esse sinal como experimental e em desenvolvimento ativo, e contar com sinal não estabilizado é assumir risco de retrabalho.

Para o arquiteto, perfis entram como aposta acompanhada, com camada de atributos isolada para que uma renomeação futura seja alteração de configuração e não de código. Para o Site Reliability Engineer, ou SRE, em plantão, o trio clássico resolve o chamado desta madrugada.

O que a IA colocou à prova nos três pilares

No State of Observability 2025 da Dynatrace, que ouviu 842 líderes de tecnologia em seis países e não inclui o Brasil na amostra, 100% dos pesquisados já usam inteligência artificial em alguma frente da operação. Quando um modelo entra na cadeia observada, quatro coisas mudam nos 3 pilares da observabilidade.

O que mudaPor que o sinal clássico não captura
Não determinismoA mesma solicitação pode produzir respostas diferentes, o que torna insuficiente o alerta por limiar
Custo por tokenO gasto de cada chamada acompanha o volume de tokens, e não o tempo de processador
Qualidade da respostaLatência e código de status seguem normais enquanto o conteúdo entregue piora
DriftO comportamento do modelo se deteriora ao longo do tempo sem estourar limiar

Não determinismo quebra o alerta por limiar

Em software tradicional, a mesma entrada produz a mesma saída, e o alerta por limiar funciona. Modelos de inteligência artificial operam em ambiente não determinístico e falham em silêncio, respondendo dentro do formato e do tempo esperados com resultado enviesado.

Quando a equipe diz que o modelo alucinou, descreve resposta plausível e incorreta, que nenhum dos três sinais clássicos registra. Qualidade da resposta precisa virar sinal coletado, em vez de impressão relatada dias depois.

O token virou unidade observável de custo

O custo de uma chamada de modelo está atrelado ao volume de tokens processados, e sem visibilidade por chamada ninguém aponta onde a operação encareceu. As convenções semânticas de GenAI do OpenTelemetry padronizam esse consumo em atributos como gen_ai.usage.input_tokens e gen_ai.usage.output_tokens, ainda em desenvolvimento ativo. Para o gerente de infraestrutura, token é métrica nova com dimensão de custo.

Drift, a falha que não gera alerta

Drift de modelo é a deterioração do comportamento ao longo do tempo, causada por mudança na relação entre os dados e o resultado esperado. Drift de dados é a mudança no perfil das entradas, e costuma ser a origem do primeiro.

Nenhum dos dois estoura limiar, porque o sistema segue respondendo dentro do formato previsto. Detectá-los exige registrar a distribuição das entradas e a avaliação das saídas, e ler a série temporal dessa avaliação, que é o que separa alucinação pontual de curva descendente.

Explicabilidade e trilha auditável de uma decisão automatizada

Quando um agente de IA participa de uma decisão com efeito sobre o cliente, a pergunta que chega trata do critério, e não da disponibilidade. Em concessão de crédito, decisões apoiadas por inteligência artificial precisam ser auditadas e ajustadas, o que exige trace com contexto propagado, log com identificador e retenção suficiente para consultar período passado.

Como instrumentar os três sinais quando há IA no caminho

Instrumentar é decidir quatro coisas, e a ordem delas pesa mais que a escolha de produto. A governança de atributos vem primeiro, para que o mesmo serviço tenha um nome só. Depois vem a estratégia de instrumentação, entre agente unificado, padrão aberto ou modelo híbrido.

A terceira decisão é a política de sampling, que define qual telemetria sobrevive e qual se perde. A quarta é tratar o custo de ingestão como métrica acompanhada, em vez de surpresa de fatura.

Convenções semânticas, o acordo sobre o nome do atributo

Convenção semântica é o acordo sobre como cada atributo se chama, e sem ele o mesmo serviço aparece com nomes diferentes e o dashboard não agrupa nada. Dois erros de campo se repetem: app.name no lugar de service.name, e region no lugar de cloud.region. Para carga de inteligência artificial, o vocabulário se estende com os atributos do namespace gen_ai.

OneAgent, OpenTelemetry ou modelo híbrido

Três abordagens de instrumentação convivem. OneAgent é o agente unificado da plataforma Dynatrace: uma instalação descobre automaticamente toda a stack de um host, contêiner ou ambiente cloud, incluindo linguagens, frameworks, bancos e filas, sem configuração manual por componente.

OpenTelemetry cobre a instrumentação manual e específica de domínio, incluindo o vocabulário de inteligência artificial, com o Collector filtrando e reduzindo a telemetria antes do destino. O modelo híbrido combina as duas e é a arquitetura adotada pela Rike IS na maior parte dos projetos, com o critério de divisão dado pelo inventário real de cargas.

O padrão aberto preserva a portabilidade da instrumentação, o que responde à preocupação com aprisionamento. O OTLP transporta a telemetria por gRPC na porta 4317 ou por HTTP com protobuf na porta 4318, e a plataforma Dynatrace aceita as duas formas.

Cardinality, o que faz o custo explodir

Cardinality é o número de combinações distintas de rótulos de uma métrica. Usar identificador único de requisição como rótulo multiplica séries em ordens de magnitude, o que traz consulta lenta, alerta atrasado e custo de ingestão fora de controle. O problema não está em coletar, está em coletar sem propósito.

Sampling, o que sobrevive e o que se perde

Sampling é a pesquisa eleitoral. O sampling head-based decide no início da requisição, custa pouco e perde o evento raro. O sampling tail-based decide depois que a requisição termina, e em sistemas críticos é geralmente preferido, porque preserva justamente os traces com erro e com latência alta.

O que uma carga de IA acrescenta à coleta

A documentação de observabilidade de IA da Dynatrace registra o que entra na coleta quando existe modelo no caminho: traces e spans do fluxo de prompt, consumo de token, custo, latência e taxa de sucesso. É a extensão concreta dos 3 pilares da observabilidade, apoiada nas mesmas decisões de atributo, de sampling e de custo que valem para qualquer outra carga.

O que transforma três sinais em uma resposta só

A investigação madura segue quatro passos: a métrica avisa que algo mudou, o trace mostra onde, o log mostra o quê e a análise causal diz por quê.

Propagação de contexto e o span órfão

Propagação de contexto é o carimbo no passaporte. Os cabeçalhos do W3C Trace Context transportam os campos traceparent e tracestate entre serviços. Quando essa propagação quebra, aparece o span órfão, e aquele trecho do percurso some do trace. Ambiente legado concentra o problema, o que exige instrumentação manual nos pontos de fronteira.

Guardar não basta, precisa continuar consultável

Em setores regulados, o Grail, motor de armazenamento e consulta da plataforma Dynatrace, permite armazenar logs, métricas, traces e eventos com períodos de retenção definidos conforme o tipo de dado e a configuração adotada, possibilitando consultas e análises sobre o histórico armazenado. O Dynatrace Query Language, ou DQL, sustenta a pergunta exploratória sobre esse acervo.

Correlação por horário não é causalidade

Olhar o gráfico e adivinhar é correlação temporal, e ela aponta o culpado errado com frequência. A IA causal atua na identificação da causa e do contexto do problema, enquanto os dashboards organizam e tornam exploráveis os sinais operacionais. Davis, dentro do Dynatrace Intelligence, é responsável pela análise causal da plataforma Dynatrace: analisa causalidade com base no mapa de dependências, aponta causa raiz e descreve impacto no negócio. Agrupar dezenas de sintomas em um problema é o que reduz a fadiga de alertas.

O mapa que dá endereço ao impacto

Esse mapa é o Smartscape, a representação visual e dinâmica de todas as dependências do ambiente, atualizada em tempo real. Para o arquiteto, é registro de território que a documentação nunca acompanhou. Para o SRE em plantão, é o atalho que mostra o caminho do impacto.

Topologia e análise causal formam o Artificial Intelligence for IT Operations, ou AIOps, uma das cinco capacidades essenciais de uma plataforma de observabilidade. As outras quatro são Application Performance Monitoring, ou APM, monitoramento de infraestrutura e cloud, Digital Experience Monitoring, ou DEM, e compliance e governança de performance.

O que muda por setor crítico

Em órgãos públicos, um portal de tributos municipal concentra o acesso anual em poucos dias, perto do vencimento. A métrica de disponibilidade pode seguir verde enquanto a emissão da guia falha para parte dos contribuintes, por uma integração intermediária. A indisponibilidade cobra preço social e político antes do técnico.

Em instituições financeiras, a abertura de conta digital atravessa dezenas de serviços e costuma incluir um passo de decisão apoiada por agente de IA. Demonstrar resiliência operacional e manter trilha auditável completa da transação sustenta a conversa com o Banco Central e com a Lei Geral de Proteção de Dados, ou LGPD.

Em cooperativas, uma plataforma multi-praça precisa provar que a qualidade de serviço é comparável entre a capital e a cidade pequena, e sem métricas por praça a média nacional esconde a diferença que a governança regional quer ver.

Em empresas privadas de grande porte, uma regressão de experiência pode não gerar erro nenhum, apenas lentidão que reduz a conversão. Para o profissional DevOps, é a métrica de negócio derivada da telemetria que liga a mudança publicada ao efeito comercial, sem depender de alguém cruzar horários à mão.

Erros comuns na adoção dos três pilares na era da IA

Cinco erros se repetem nos projetos, e nenhum é erro de ferramenta. O primeiro é coletar tudo sem propósito, e o custo dispara, a consulta fica lenta e a equipe perde confiança no dado. O segundo é a falta de governança de atributos, com o mesmo serviço ganhando nomes diferentes até o dashboard não agrupar nada.

O terceiro é o sampling mal calibrado: agressivo demais perde o evento raro, permissivo demais transforma o volume no problema. O quarto é misturar contas de desenvolvimento e produção, o que corrompe a linha de base aprendida antes de qualquer incidente real.

O quinto é subestimar a curva de aprendizagem, e a implantação termina com a equipe sem operar a plataforma. O mesmo State of Observability 2025, com 842 líderes de seis países e sem Brasil na amostra, registra 81% dizendo que gerenciar ferramentas e preparar dados reduz o espaço para inovação.

Do diagnóstico à governança contínua

Os 3 pilares da observabilidade são a base e não o destino. A distância entre uma coleção cara de dashboards e um programa de observabilidade está na correlação, na governança de atributos e na decisão sobre sampling e custo.

Esse trabalho se estrutura em cinco frentes. A avaliação inicial mapeia maturidade e desenha o roadmap. A implantação em ondas entrega valor visível em poucas semanas. A arquitetura padrão é o modelo híbrido de OneAgent com OpenTelemetry. Os treinamentos seguem o perfil profissional de cada equipe, de fundamentos de OpenTelemetry e configuração de Collector até análise avançada com o Dynatrace Query Language e Davis. A governança de performance continuada mantém revisões periódicas depois da entrega.

Para o CIO, o CTO e o CEO, essas cinco frentes traduzem observabilidade de item de custo em capacidade de explicar ao conselho de administração o que aconteceu e o que impede a reincidência.

Perguntas frequentes sobre os 3 pilares da observabilidade

A observabilidade tem três pilares ou mais?

Três pilares é convenção didática de mercado. O OpenTelemetry define sinais, e a lista oficial inclui traces, métricas, logs e baggage, com eventos e perfilamento em desenvolvimento. Para ensinar, três funciona. Para planejar arquitetura, a lista de sinais é a referência correta, porque é ela que define o que o padrão suporta.

Existe um quarto pilar da observabilidade?

O candidato mais citado é o sinal de perfis, que responde qual código consome os recursos. A documentação do OpenTelemetry o classifica como experimental e em desenvolvimento ativo, o que significa que adotá-lo hoje implica risco de retrabalho quando a especificação estabilizar.

Logs, métricas e traces bastam para observar uma aplicação com IA?

Não. Os três seguem necessários e deixam de ser suficientes, porque a falha típica de um modelo acontece sem erro, sem latência e sem limiar rompido. Qualidade da resposta, consumo de token e drift precisam virar sinais coletados, com os mesmos cuidados de atributo e de retenção dos três clássicos.

Qual dos três sinais instrumentar primeiro?

Traces, quando o ambiente é distribuído. Eles carregam o identificador que depois correlaciona os outros dois, e sem essa espinha as métricas e os logs continuam sendo coletas paralelas. Em ambiente monolítico e estável, a ordem se inverte e a métrica entrega retorno mais rápido.

Coletar os três sinais já é observabilidade?

Não. Sem identificador comum e sem convenção de atributo, três coletas isoladas produzem três dashboards que não conversam. O que separa observabilidade de monitoramento sofisticado é a possibilidade de fazer, sobre o dado retido, a pergunta que ninguém previu ao instrumentar.

Ambientes onde falhar não é opção pedem mais que ferramenta: pedem quem já implantou, treinou e sustentou observabilidade em sistemas críticos. A Rike IS atua em consultoria, implantação, treinamento e governança contínua de observabilidade sobre a plataforma Dynatrace, junto a órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte, começando sempre por um diagnóstico do ambiente atual que mapeia maturidade, identifica as dores prioritárias e desenha o roadmap.

A responsabilidade pela operação, pelas decisões apoiadas na telemetria e pelo cumprimento das obrigações regulatórias de cada setor é da organização contratante.

RIKE IS Comunicação

Time de comunicação da RIKE IS. Publicamos análises técnicas sobre observabilidade, performance de aplicações e conformidade em ambientes críticos, a partir da experiência em projetos com órgãos públicos e empresas privadas.

Todas as publicações