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.
| Sinal | O que registra | Pergunta que responde |
|---|---|---|
| Logs | Eventos discretos com carimbo de tempo e contexto | Quais eventos ocorreram |
| Métricas | Valores numéricos coletados em intervalos regulares | O que está acontecendo no nível do sistema |
| Traces | O percurso de uma requisição entre serviços | Onde 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 muda | Por que o sinal clássico não captura |
|---|---|
| Não determinismo | A mesma solicitação pode produzir respostas diferentes, o que torna insuficiente o alerta por limiar |
| Custo por token | O gasto de cada chamada acompanha o volume de tokens, e não o tempo de processador |
| Qualidade da resposta | Latência e código de status seguem normais enquanto o conteúdo entregue piora |
| Drift | O 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.
Compartilhe esse conteúdo
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