Métricas, logs e traces: os sinais que explicam sua aplicação

Métricas, logs e traces são os três sinais consultados no diagnóstico de aplicação, e cada um responde a uma pergunta distinta. A métrica indica que algo mudou e quanto, o trace mostra em que ponto do percurso o tempo foi consumido, e o log descreve o que aconteceu ali. A ordem de consulta encurta o diagnóstico porque cada sinal reduz o espaço de busca do seguinte.

Uma equipe que sabe qual sinal consultar primeiro reduz o tempo médio de resolução de um incidente antes mesmo de tocar em qualquer configuração. Uma equipe que abre o repositório de logs como primeiro movimento costuma perder a primeira hora lendo linhas que não têm relação com o problema.

Métricas, logs e traces são os três sinais que uma aplicação instrumentada emite. A métrica responde se alguma coisa mudou e quanto mudou. O trace responde em que ponto do percurso da requisição o tempo foi consumido ou o erro apareceu. O log responde o que exatamente aconteceu naquele ponto, com a mensagem que o código registrou.

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 cada sinal responde numa investigação

Métrica é um valor numérico agregado ao longo do tempo, como latência média de uma transação, taxa de erro por minuto ou número de requisições por segundo. Métricas são o painel do carro: informam velocidade, temperatura e nível de combustível, o suficiente para saber que alguma coisa saiu do comportamento típico. Nenhuma métrica explica por que o valor mudou.

Trace é o registro do percurso completo de uma requisição através de todos os serviços que participaram do atendimento. O trace é o GPS de uma viagem, mostrando cada parada do trajeto e o tempo gasto entre elas, e é o sinal que localiza o ponto exato de acúmulo de tempo dentro de uma cadeia de chamadas.

Log é o registro textual que o código escreveu em um instante específico, com mensagem, nível de severidade e contexto de execução. Logs são o diário de bordo: guardam o relato do que a aplicação estava fazendo, incluindo a exceção lançada, o parâmetro recebido e o estado interno naquele momento.

Os três respondem perguntas encadeadas, e é essa cadeia que sustenta o diagnóstico. A métrica diz que mudou. O trace diz onde mudou. O log diz o quê.

Para o Site Reliability Engineer, ou SRE, em plantão, essa divisão define a sequência de cliques nos primeiros minutos de um incidente. Para o gerente de infraestrutura, define quanto de cada sinal precisa ser retido e a que custo, porque volume de log e volume de trace têm ordens de grandeza distintas.

A ordem de consulta num diagnóstico real

A investigação eficiente segue três movimentos em ordem, e inverter essa ordem é a causa mais comum de tempo perdido em incidente de aplicação.

O primeiro movimento parte da métrica anômala. Alguma coisa disparou o alerta, ou alguém reclamou: a latência do percentil mais alto de uma transação subiu, a taxa de erro de uma rota saltou, o volume de requisições concluídas caiu. A métrica delimita o quê, o quando e a magnitude, e recorta a janela de tempo que interessa.

O segundo movimento salta da métrica para os traces daquela janela. Com o recorte temporal e a transação identificada, a equipe abre os traces das requisições lentas ou com erro e observa a distribuição do tempo entre os serviços envolvidos. É nesse ponto que aparece o serviço responsável pelo acúmulo, a chamada externa que demorou, a consulta de banco que travou.

O terceiro movimento vai do trace ao log do serviço apontado, no mesmo intervalo e no mesmo identificador de requisição. O log entrega a mensagem de exceção, o rastreamento de pilha e o parâmetro que produziu o comportamento, encerrando a cadeia com a evidência textual.

A ordem métrica, trace e log existe porque cada sinal reduz o espaço de busca do seguinte. A métrica reduz o tempo a uma janela de minutos. O trace reduz a arquitetura inteira a um serviço e a uma operação. O log reduz aquele serviço a uma linha. Quem começa pelo log inverte a redução e enfrenta o volume completo sem recorte, o que transforma diagnóstico em leitura.

Existe uma condição para que a cadeia funcione, e ela não é automática: os três sinais precisam compartilhar identificadores. Métrica, trace e log correlacionam quando carregam o mesmo identificador de trace, o mesmo nome de serviço e os mesmos atributos de recurso. Sem esse acordo, cada salto vira uma busca manual por horário aproximado.

Na plataforma Dynatrace, o OneAgent sustenta a correlação por instalação única no host, contêiner ou ambiente cloud, com descoberta automática da stack sem configuração manual por componente. Quando a instrumentação vem de OpenTelemetry, a correlação depende das semantic conventions aplicadas com disciplina, com service.name e cloud.region preenchidos de forma consistente em todos os serviços.

Para o profissional de DevOps, essa correlação é o que permite avaliar uma implantação por evidência e reverter com critério. Para o CIO, o CTO e o CEO, é o que separa um incidente resolvido em minutos de um incidente que consome um turno inteiro de equipe especializada.

Span: a unidade que compõe o trace

Span é o registro de uma operação individual dentro de um trace, com nome, marca de tempo de início, duração, atributos e estado de conclusão. Consultar um banco é um span. Processar um pagamento é um span. Chamar um serviço de autenticação é um span.

O trace é a árvore formada por esses spans. Cada span carrega o identificador do trace a que pertence e o identificador do span que o originou, e é essa relação de origem que reconstrói a hierarquia de chamadas. O span raiz representa a entrada da requisição, e os spans filhos representam tudo que aconteceu por consequência.

A leitura de um trace começa pela duração do span raiz e desce pela árvore procurando onde o tempo se concentra.

Existem dois padrões que a equipe aprende a reconhecer de imediato. O primeiro é o span único que domina a duração total, indicando uma operação lenta específica, quase sempre consulta de banco sem índice ou chamada externa sem limite de tempo adequado. O segundo é o tempo distribuído em dezenas de spans curtos e repetidos, indicando chamada em laço, o padrão em que uma requisição dispara uma consulta por item de uma lista.

Para que o span emitido por um serviço se ligue ao trace iniciado em outro, é preciso propagação de contexto. Os cabeçalhos padronizados pelo W3C Trace Context, com os campos traceparent e tracestate, funcionam como o carimbo no passaporte que acompanha o viajante entre fronteiras, levando o identificador do trace de um serviço ao seguinte.

Quando alguma camada não repassa esses cabeçalhos, aparece o span órfão: uma operação registrada sem ligação com o trace a que pertence. Em ambientes com sistemas legados, o span órfão é recorrente e exige instrumentação manual deliberada nos pontos de entrada e de saída de cada serviço. O efeito no diagnóstico é direto, porque o trecho que some da árvore costuma ser justamente o de menor visibilidade.

Quando o log é o sinal certo

O log é o sinal certo quando a pergunta é sobre conteúdo, não sobre tempo.

Existem quatro situações em que a investigação começa ou termina no log, e todas envolvem informação que métrica e trace não carregam por natureza. A primeira é exceção com rastreamento de pilha, quando a equipe precisa da linha de código que falhou. A segunda é validação de regra de negócio, quando a requisição foi recusada por decisão da aplicação e não por falha técnica.

A terceira é a auditoria interna de operação. Instituições financeiras, cooperativas e órgãos públicos costumam manter, por política própria de governança, o registro do que o sistema fez, para qual usuário e em qual instante. Esse registro se sustenta no texto íntegro da linha, não no valor agregado da métrica.

A quarta é o comportamento intermitente que não produz erro. A requisição completa com sucesso, a latência permanece dentro do previsto e mesmo assim o resultado sai incorreto. Nenhuma métrica registra resultado incorreto com tempo normal, e o trace mostra um percurso saudável. Só o log guarda o valor que foi calculado.

Há um requisito que decide se o log serve ou atrapalha nessas quatro situações: ele precisa ser estruturado e carregar o identificador do trace. Log em texto livre, sem campos nomeados e sem identificador de correlação, obriga a busca por palavra e horário aproximado. Log estruturado com identificador permite abrir, a partir de um span específico, exatamente as linhas escritas durante aquela execução.

Definir esse acordo de formato e de atributos antes de instrumentar poupa retrabalho que, depois, implica reprocessar dado e refazer painel. A Rike IS conduz esse desenho junto às equipes de operações e de desenvolvimento, com governança de atributos definida desde o início do projeto. Quem já está com o log em produção e a correlação quebrada não precisa recomeçar do zero, porque o desenho de atributos pode ser refeito por etapas, serviço a serviço, começando pelas transações de maior criticidade.

Quando a métrica basta

Existem investigações que terminam na métrica, e reconhecê-las evita esforço desnecessário.

A métrica basta quando a pergunta é sobre tendência. Consumo de memória de um serviço crescendo ao longo de dias, taxa de utilização de um pool de conexões se aproximando do limite, volume de transações subindo de forma sustentada mês a mês. Nenhuma dessas perguntas tem um instante específico para investigar, porque o objeto é a curva, não o evento.

A métrica também basta em previsão de capacidade. Projetar quanto recurso um sistema crítico vai exigir no próximo pico sazonal depende de série histórica agregada, e abrir traces individuais não acrescenta nada à projeção.

O terceiro caso é a verificação pós-implantação. Depois de subir uma versão, a pergunta imediata é se latência e taxa de erro mantiveram o comportamento anterior, e a métrica responde em segundos.

Uma ressalva decide a qualidade dessa leitura: latência medida por média engana. A média dilui o caso extremo, e o subconjunto de usuários que enfrenta tempo muito superior ao típico praticamente desaparece do indicador. O percentil elevado preserva essa informação e mostra o tempo enfrentado pela fatia em pior situação, que costuma ser a mesma fatia que abre chamado.

Para o gerente de infraestrutura, a métrica é o sinal de planejamento, porque responde perguntas de capacidade e de custo com custo de armazenamento baixo. Para o SRE, a métrica é o gatilho, porque define quando vale a pena descer para o trace.

O custo de cada sinal

Os três sinais têm custos de coleta, transporte e retenção muito diferentes, e ignorar essa assimetria produz conta de ingestão sem retorno proporcional.

Métrica é o sinal mais barato. Um valor numérico agregado por intervalo ocupa pouco espaço e permite retenção longa, o que sustenta análise de tendência por meses sem custo relevante. O limite da métrica não é volume, é cardinality: cada combinação distinta de rótulos cria uma série temporal nova, e rótulos com valores ilimitados, como identificador de usuário, multiplicam séries até inviabilizar a consulta.

Trace é o sinal mais caro por requisição. Uma única transação em arquitetura distribuída gera dezenas de spans, e guardar todos os traces de todas as requisições de um sistema crítico produz volume que raramente se justifica.

Por isso existe sampling, a decisão sobre quais traces preservar. Sampling é a pesquisa eleitoral da telemetria, que observa uma parte para inferir o todo. A decisão relevante é quando amostrar: a amostragem no início do percurso escolhe antes de saber o desfecho da requisição, enquanto o sampling tail-based decide depois de conhecer o resultado, o que permite preservar justamente os traces com erro ou com latência alta. Em sistemas críticos, o tail-based é geralmente preferido por esse motivo.

Log é o sinal de maior volume bruto e de maior variação de utilidade. Uma aplicação em nível de depuração produz volume que ninguém consulta, e a mesma aplicação em nível de erro pode omitir o contexto necessário para entender a exceção. A governança útil define nível por criticidade de serviço, com retenção curta e detalhada para depuração e retenção longa apenas para o que a política de auditoria da organização determinar.

Onde o dado repousa também decide o custo da consulta. Na plataforma Dynatrace, o Grail retém métrica, log e trace em volume massivo, com períodos de retenção que variam conforme o tipo de dado e a configuração adotada, com consulta rápida sobre todo o histórico, e o Dynatrace Query Language, ou DQL, consulta os três no mesmo lugar. Ler log e trace na mesma linguagem elimina o salto entre repositórios separados, que na prática é o ponto em que a investigação esfria.

Para a diretoria, a leitura é de previsibilidade de custo: definir política de sampling e de retenção por criticidade transforma ingestão em item planejado. Para o profissional de DevOps, a mesma política precisa preservar detalhe suficiente na janela de implantação, quando a chance de regressão é maior.

Como sustentar a correlação dos três sinais na operação

A cadeia de diagnóstico descrita acima depende de três decisões tomadas antes da primeira instrumentação, e nenhuma delas é técnica no sentido estrito.

A primeira decisão é a convenção de nomes. Quando cada equipe nomeia o mesmo serviço de forma diferente, a métrica de um painel não encontra o trace do outro, e o salto entre sinais quebra no ponto em que mais importa. Convenção semântica é pré-requisito de correlação, não formalidade de documentação.

A segunda decisão é a política de sampling e retenção por criticidade de transação. Cobertura uniforme parece prudente e produz custo alto com retorno baixo, porque preserva o irrelevante na mesma profundidade do que sustenta receita.

A terceira decisão é onde a inteligência de correlação vai operar. Essa camada tem nome próprio: Artificial Intelligence for IT Operations, ou AIOps. O Davis, que dentro do Dynatrace Intelligence é responsável pela análise causal da plataforma Dynatrace, opera sobre o mapa de dependências em tempo real do Smartscape e identifica o evento gerador da cadeia de falhas em vez de apresentar uma lista de anomalias por horário. 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.

A análise causal automatizada separa equipes que percorrem sinais manualmente das que recebem a causa raiz já apontada.

Para o SRE, o efeito é a redução expressiva do tempo médio de resolução em plantão. O gerente de infraestrutura ganha previsibilidade sobre a conta de ingestão. Para o profissional de DevOps, o efeito é o retorno rápido sobre cada implantação. A diretoria recebe redução do risco de indisponibilidade em sistemas críticos, com evidência auditável do que aconteceu.

Perguntas frequentes

Existe caso em que a investigação não deve começar pela métrica?

Existe: quando o problema atinge um usuário isolado e não move a curva agregada. Uma reclamação individual sobre um pedido específico não aparece na taxa de erro por minuto de uma rota. A entrada, nesse cenário, é o identificador da requisição ou da sessão informado por quem reclamou, e esse identificador abre o trace direto. A métrica volta a servir depois, apenas para verificar se o caso é isolado ou se é a ponta de um padrão em formação.

Como instrumentar processamento assíncrono, em que não existe requisição de ponta a ponta?

Fila e processamento em lote também produzem trace, desde que o contexto viaje junto com a mensagem. O serviço que publica grava o identificador do trace nos cabeçalhos da mensagem, e o serviço que consome lê esse identificador ao processar. Sem o repasse, cada consumo abre um trace novo, e a ligação entre o que foi publicado e o que foi processado se perde. Em execução em lote, a prática usual é abrir um span raiz por execução, com spans filhos por bloco de itens.

Span órfão e trace ausente por amostragem são o mesmo problema?

Não são. O span órfão é falha de propagação de contexto: o span foi coletado e não encontra o trace de origem, porque alguma camada não repassou os cabeçalhos. O trace ausente por amostragem é decisão de política: aquela requisição não foi preservada, e o restante da árvore também não existe no repositório. A instrumentação corrige o primeiro caso, e a regra de amostragem resolve o segundo.

Adotar log estruturado exige mudar o código da aplicação?

Depende de onde o log nasce. Bibliotecas de log atuais emitem em formato estruturado por configuração, sem tocar em cada chamada do código. O identificador do trace, porém, precisa entrar no contexto de log, e isso costuma exigir um interceptador no ponto de entrada de cada serviço. Em aplicação legada que escreve texto livre em arquivo, o caminho mais curto passa pelo Collector do OpenTelemetry, a peça intermediária que recebe, processa e converte a linha em campos nomeados antes do reenvio.

Métrica de negócio entra na mesma investigação que métrica técnica?

Entra, e costuma ser o sinal que qualifica a gravidade do incidente. Volume de pedidos concluídos por minuto e taxa de aprovação de pagamento respondem se a degradação técnica chegou ao resultado. A diferença está na fonte: a métrica técnica vem da instrumentação, enquanto a métrica de negócio vem do evento que a aplicação registra. As duas só aparecem no mesmo painel quando compartilham os mesmos atributos de recurso, e essa sobreposição é o que traduz incidente técnico em impacto de negócio.

Sustentar métricas, logs e traces correlacionados em ambiente distribuído exige diagnóstico do estado atual, convenção de atributos, instrumentação consistente e governança de performance continuada. A Rike IS conduz esse trabalho 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 percurso de diagnóstico do seu ambiente para uma conversa técnica com os especialistas da Rike IS.