Os 3 pilares da observabilidade: logs, métricas e traces na prática

Os três pilares da observabilidade são logs, métricas e traces. Logs registram eventos discretos com riqueza contextual, métricas medem valores numéricos em intervalos regulares e traces reconstroem o percurso de uma requisição entre serviços. Cada um responde a uma pergunta que os outros dois não respondem, e o valor operacional nasce da correlação automática entre eles.

Métricas respondem se algo mudou. Traces respondem onde a mudança aconteceu. Logs respondem o que exatamente ocorreu naquele ponto. Nenhum dos três responde às três perguntas sozinho, e essa é a razão de serem três.

Os pilares da observabilidade são os três tipos de sinal de telemetria que um sistema em produção emite sobre si mesmo. Log é o registro textual de um evento discreto que aconteceu em um instante determinado. Métrica é um valor numérico agregado, coletado em intervalos regulares. Trace é o rastreamento de uma requisição individual atravessando todos os serviços que participaram do atendimento.

A observabilidade completa não nasce da soma dos sinais coletados, e sim da ligação entre eles. Três repositórios separados produzem três consultas manuais e uma reconstrução mental do incidente feita por uma pessoa sob pressão.

A Rike IS conduz consultoria, implantação, treinamento e governança contínua em observabilidade sobre a plataforma Dynatrace, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte.

O que são os pilares da observabilidade

A palavra pilar descreve aqui uma função de sustentação, não uma hierarquia de importância entre os sinais. Nenhum deles é a versão avançada do outro. Cada um captura uma dimensão distinta do comportamento do sistema, e a ausência de qualquer um deixa um ponto cego previsível.

A divisão em três vem da natureza do dado, não de convenção de mercado.

Um evento discreto acontece uma vez, tem carimbo de tempo próprio e carrega texto de tamanho variável, e esse conjunto de propriedades define o log. Um valor contínuo aceita amostragem em intervalo fixo, ocupa espaço previsível e admite agregação matemática, e isso define a métrica. Uma unidade de trabalho que atravessa processos exige identificador compartilhado para que o outro lado a remonte, e isso define o trace. As três formas exigem armazenamento, indexação e consulta diferentes, e a separação sobreviveu à evolução das ferramentas por causa disso.

Existe uma pergunta que aparece sempre nesse ponto: por que três sinais, e não dois. A resposta está no tipo de sistema que a equipe precisa observar. Em aplicação monolítica rodando em um único servidor, métricas e logs bastavam, porque tudo acontecia dentro de um processo e o log local contava a história inteira.

Arquitetura distribuída rompeu esse arranjo. Quando uma requisição de usuário atravessa muitos serviços, em processos e máquinas distintas, nenhum log local sabe o que aconteceu antes nem depois. O trace surgiu para preencher exatamente essa lacuna, carregando um identificador comum do início ao fim do atendimento.

Para o CIO e o CTO, a leitura relevante é de risco. Sem os três sinais em operação, o tempo médio de resolução de um incidente crítico depende da memória e da intuição de quem está de plantão. Para o gerente de infraestrutura, a leitura é de custo, porque cada sinal tem perfil de volume e de retenção próprio, e aplicar a mesma janela de retenção aos três desperdiça de um lado e falta do outro.

Logs: o diário de bordo

Log é o registro textual de um evento discreto, que a aplicação grava no instante em que o evento acontece. O formato varia de uma linha de texto livre até um objeto estruturado com campos nomeados, e o conteúdo também: erro de conexão recusada, exceção com rastro de execução, decisão de negócio tomada por uma regra, alteração de configuração aplicada em tempo de execução.

O log é o diário de bordo do sistema. Ele não mostra a rota inteira nem a velocidade média, mostra o que a tripulação anotou quando algo mereceu registro.

A força do log está na riqueza contextual. Nenhum outro sinal carrega a mensagem de erro exata do banco de dados, o valor do parâmetro que quebrou a validação ou o identificador do documento que a fila recusou. Quando a equipe de operações precisa saber por que uma transação específica falhou, a resposta está no log e em nenhum outro lugar.

A fraqueza está no volume e na falta de estrutura. Sistemas críticos geram registros em quantidade que nenhuma leitura humana acompanha, e o custo de ingestão cresce junto. Log em texto livre agrava o problema, porque cada consulta vira uma expressão construída às pressas durante o incidente. Log estruturado, com campos nomeados e convenção semântica única entre as equipes, é o que permite filtrar por serviço, por versão de implantação e por identificador de requisição sem improvisar.

Volume sem estrutura é custo sem retorno.

Três decisões definem se o log vai servir durante o incidente, e todas precisam ser tomadas antes da implantação. A primeira é o nível de detalhe por criticidade da transação, porque registrar tudo com a mesma profundidade produz volume que ninguém consulta. A segunda é a convenção de nomes de campo, que decide se as consultas atravessam serviços ou param no limite de cada equipe. A terceira é a política de retenção, que separa o dado consultado na primeira hora do incidente daquele exigido por auditoria meses depois.

A convenção precede a coleta. Quando cada time nomeia o identificador de requisição do seu jeito, o log continua completo e continua inútil durante o incidente, porque nenhuma consulta atravessa os serviços.

Para o profissional de DevOps, log estruturado é o que permite comparar duas versões da mesma aplicação depois de uma implantação e decidir a reversão com evidência em vez de suspeita.

Métricas: o painel do carro

Métrica é um valor numérico coletado em intervalos regulares e associado a um instante no tempo. Latência de resposta, taxa de erro, requisições por segundo, uso de processador, memória ocupada, profundidade de fila: todo indicador que aceite soma, contagem, média ou leitura por percentil pertence a essa categoria.

Métricas são o painel do carro. Velocidade, temperatura e nível de combustível informam o estado atual do veículo em tempo real, com leitura imediata e sem exigir interpretação.

A vantagem está no custo e na velocidade. Um valor numérico com poucos rótulos ocupa espaço mínimo comparado ao texto de um log, tolera retenção longa e permite comparação com o mesmo horário da semana anterior. É o único sinal barato o bastante para ficar ligado o tempo todo, em todos os componentes, sem discussão de orçamento.

Custo baixo e leitura contínua fazem da métrica o sinal de detecção. Alertas se apoiam em métricas porque a avaliação é numérica e contínua, e o Service Level Indicator, ou SLI, é uma métrica por definição.

Existe um cuidado que decide se a métrica descreve a experiência real ou uma média confortável. A média dilui o caso extremo: quando a maioria das transações completa rápido, um subconjunto lento desaparece do indicador. O percentil preserva essa informação e mostra o tempo enfrentado pela fatia de usuários em pior situação, que costuma ser justamente a que abre chamado. Em transação de negócio, a leitura por percentil é a única defensável, e a média fica reservada ao consumo de infraestrutura, onde o comportamento agregado é o que interessa.

O limite da métrica aparece no momento seguinte à detecção. Ela informa que a latência do serviço de pagamento subiu, e não informa qual chamada dentro daquele serviço consumiu o tempo, nem qual usuário sentiu o efeito, nem qual mensagem de erro o banco devolveu. A métrica encerra sua contribuição exatamente onde a investigação começa.

Para o gerente de infraestrutura, métricas sustentam previsão de capacidade, porque a série histórica mostra a tendência de consumo antes que o recurso sature. Para o Site Reliability Engineer, ou SRE, elas alimentam o orçamento de erro, que traduz confiabilidade em número negociável com o time de produto.

Traces: o GPS da requisição

Trace é o rastreamento completo de uma requisição individual percorrendo todos os serviços que participaram do atendimento. Cada etapa registrada dentro desse percurso é um span, com carimbo de tempo de início e de fim, identificador próprio e ligação com a etapa que a chamou. O resultado é a reconstrução ordenada de um atendimento que aconteceu em várias máquinas ao mesmo tempo.

O trace é o GPS de uma viagem, mostrando cada parada do trajeto, quanto tempo o veículo ficou em cada uma e onde exatamente o atraso aconteceu.

A contribuição do trace é única entre os três sinais: ele preserva a relação de causa entre serviços. Métricas de dois serviços podem subir ao mesmo tempo sem que exista relação alguma entre os dois. O trace mostra que o serviço de pedidos chamou o serviço de estoque, que esperou por ele e que o tempo total do usuário foi consumido nessa espera.

A relação de causa entre serviços separa correlação estatística de causa observada.

Em arquitetura distribuída, o trace deixou de ser recurso avançado e virou requisito de operação. O Application Performance Monitoring, ou APM, é a disciplina que consome traces para explicar o comportamento de uma transação de negócio. Sem trace, a análise de um atendimento lento depende de comparar horários entre painéis de equipes diferentes, procedimento que consome as horas mais caras do incidente.

O custo do trace é o mais alto dos três, porque cada requisição observada gera múltiplos spans com atributos. Esse volume é a razão de existir do sampling, ou amostragem, que funciona como a pesquisa eleitoral, observando uma parte para inferir o comportamento do todo. No tail-based sampling, a decisão sobre o que preservar ocorre após informações adicionais da transação estarem disponíveis, permitindo aplicar políticas de amostragem com base no resultado observado.

A Rike IS conduz o desenho de instrumentação com as equipes de operações e de desenvolvimento antes da primeira coleta, porque decisão tomada depois da implantação implica reprocessar dado e refazer painel.

O que cada sinal não responde sozinho

O limite de cada sinal é o que separa quem coleta telemetria de quem opera com observabilidade. Cada limite vem do formato do dado, não da qualidade da coleta, e nenhum dos três é dispensável.

A métrica não explica o caso individual. Ela informa que o percentil de latência da aplicação de crédito saiu do padrão, e não informa qual proposta demorou nem qual serviço da cadeia consumiu o tempo. Agregar é a natureza da métrica, e agregar significa descartar o particular.

O log não mostra o percurso. Cada serviço registra sua própria versão dos fatos, sem saber o que o serviço anterior fez nem o que o seguinte fará. Reunir logs de vários serviços por horário aproximado é um exercício de inferência, e a inferência falha quando a mesma janela de tempo concentra um grande número de requisições simultâneas.

O trace não guarda o detalhe do erro. Uma chamada ao serviço de autenticação aparece no percurso como etapa lenta que retornou falha, sem a mensagem que o provedor devolveu, sem o parâmetro recusado e sem o estado da configuração naquele instante. Forma do percurso é o que o trace descreve, não conteúdo de cada parada.

Existe ainda um quarto limite, comum aos três: nenhum deles conhece o estado da infraestrutura por baixo. Um contêiner reiniciado por falta de memória, um nó removido do balanceador ou uma regra de rede alterada aparecem nos três sinais apenas como consequência, nunca como origem. A observabilidade full-stack fecha essa lacuna ao trazer infraestrutura, cloud e experiência digital do usuário para o mesmo conjunto de dados, e o Digital Experience Monitoring, ou DEM, cobre o último trecho: do navegador do usuário até a primeira chamada de serviço.

Nas avaliações que a Rike IS conduz, o ponto cego mais frequente aparece justamente abaixo dos três sinais, no estado da infraestrutura que nenhum deles registra.

Por que a correlação é o que importa

O valor dos três sinais aparece no salto entre eles, não na soma deles. Uma equipe que dispõe de logs, métricas e traces em repositórios separados ainda precisa executar três consultas manuais, e juntar os resultados sobra para a cabeça de alguém, durante um incidente, sob pressão de tempo.

O percurso de diagnóstico que interessa vai da métrica anômala ao trace daquela janela, e do trace ao log do serviço identificado. O que decide se esse percurso leva segundos ou turnos é a existência dos saltos automáticos entre os três.

A condição técnica para que os saltos existam é a governança de atributos. Serviço, ambiente, versão de implantação e identificador de requisição precisam ter o mesmo nome em todos os sinais e em todas as equipes. Quando cada time nomeia o mesmo componente de forma própria, o salto quebra, e a correlação vira trabalho manual outra vez.

Nome igual em todo lugar.

Na plataforma Dynatrace, quatro componentes sustentam essa ligação operando sobre o mesmo conjunto de dados. O OneAgent é o agente unificado que descobre a stack em execução no host, no contêiner e no ambiente cloud, aplicando contexto consistente aos sinais na origem. O Smartscape mantém o mapa de dependências em tempo real, que dá ao dado correlacionado a topologia por onde ele se move. O Grail retém logs, métricas e traces em volume massivo, com períodos de retenção que variam conforme o tipo de dado e a configuração adotada, sem separá-los em silos, e o Dynatrace Query Language, ou DQL, atravessa os três em uma única consulta.

O Davis, que dentro do Dynatrace Intelligence é responsável pela análise causal da plataforma, opera sobre os sinais já correlacionados. Em vez de listar anomalias por horário, ele aponta o evento que gerou a cadeia de falhas e descreve o impacto no negócio. 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, e é nesse ponto que a disciplina de Artificial Intelligence for IT Operations, ou AIOps, se distingue do alerta estatístico comum.

Para o CEO, a correlação se traduz em previsibilidade: incidentes deixam de depender do conhecimento tácito de uma pessoa específica e passam a seguir um procedimento reproduzível. O gerente de infraestrutura ganha a economia de uma expansão de capacidade que não resolveria o problema, porque a causa raiz fica visível antes da decisão de investimento. No lado DevOps, a correlação fecha o ciclo de entrega, com cada implantação mostrando seu impacto em latência e erro enquanto a reversão ainda é simples.

Para o SRE em plantão, a diferença aparece em horas de trabalho. Encontrar a causa raiz em minutos, com o percurso pronto, substitui a reconstrução manual do incidente a partir de painéis separados.

A correlação entre logs, métricas e traces separa equipes que apagam incêndios das que previnem incêndios.

Perguntas frequentes

Preciso implantar os três pilares ao mesmo tempo?

A ordem de implantação segue a pergunta que a operação hoje não consegue responder. Ambiente sem base de detecção começa por métricas. Ambiente que detecta e trava na investigação começa por log estruturado. Ambiente cuja transação crítica atravessa muitos serviços começa por trace, porque nenhum dos outros dois reconstrói o percurso.

Existe um quarto pilar da observabilidade?

A discussão existe no mercado, com candidatos como eventos de mudança e perfis de execução, e três continua sendo a resposta operacional. Evento de implantação e alteração de configuração funcionam melhor como contexto que atravessa os três sinais do que como categoria própria. O critério é prático: um quarto sinal só se justifica quando exige armazenamento e consulta que os três atuais não atendem.

Trace coletado por amostragem serve como registro de auditoria?

Não serve. Amostragem descarta parte dos atendimentos por definição, e registro de auditoria exige a série completa dos eventos relevantes. Auditoria se apoia em log com retenção declarada e campos estáveis. Quem precisa dos dois usa amostragem no trace para diagnóstico e mantém o log íntegro para prestação de contas.

Os três pilares valem para processamento em lote, sem usuário esperando?

Valem, com leitura diferente. O trace passa a descrever cada execução do lote como unidade de trabalho, do início ao encerramento. A métrica troca latência de resposta por duração da execução e volume processado por janela. O log deixa de ser detalhe de uma transação e vira o registro de quais itens o lote aceitou, recusou ou repetiu.

Métrica calculada a partir de log conta como métrica?

O formato final é de métrica e o custo continua sendo de log. Contar ocorrências de erro em uma linha de registro produz uma série numérica que aceita alerta e comparação histórica. A ingestão, porém, segue pagando o volume textual completo, e a série existe apenas enquanto aquele log for coletado com a mesma estrutura.

Correlacionar logs, métricas e traces em sistemas críticos depende de diagnóstico do estado atual, de convenção de atributos acordada entre as equipes e de governança de performance continuada. A Rike IS assume esse trabalho do primeiro diagnóstico à operação do dia a dia sobre a plataforma Dynatrace, com consultoria, implantação, treinamento e governança, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte. Leve o estado atual do seu ambiente para uma conversa técnica com os especialistas da Rike IS.