O que são logs, métricas e traces e como eles explicam uma falha?

Como os três sinais se encaixam em uma investigação?

Pense em uma loja virtual em que parte dos clientes não consegue finalizar a compra. A taxa de erro na finalização de pedidos sobe e dispara o alerta. Ela mostra o tamanho do problema e quando ele começou, mas não explica a causa.

O passo seguinte é abrir os traces das compras que falharam. Cada trace é formado por etapas chamadas spans, e cada span registra uma operação específica, como a consulta ao estoque ou a chamada ao serviço de frete, com horário de início e duração. Ali aparece que o erro acontece sempre na chamada à API da transportadora, a interface que conecta os dois sistemas.

Por fim, os logs desse serviço trazem a mensagem exata: a transportadora passou a recusar as requisições porque a credencial de acesso expirou. Esse salto entre sinais fica mais rápido quando os logs registram o identificador do trace (trace ID). Com ele, a equipe sai de uma solicitação com problema direto para os eventos que ela gerou, sem procurar manualmente por horário.

O que muda quando o log é estruturado?

Um log em texto livre, como “erro ao processar pedido do cliente”, é fácil de ler por uma pessoa e difícil de pesquisar em grande volume. O log estruturado organiza o evento em campos nomeados, como serviço, nível de severidade, código do pedido, versão da aplicação e identificador do trace. O formato mais comum é o JSON, um padrão de texto para dados estruturados.

Com campos padronizados, a equipe consegue filtrar todos os erros de uma versão específica ou contar quantos pedidos de uma região falharam, sem depender de buscas por palavras soltas.

Logs também exigem cuidado com privacidade. Senhas, tokens de acesso e dados completos de cartão não devem ser registrados, e dados pessoais precisam ser mascarados ou reduzidos ao mínimo necessário, em linha com a Lei Geral de Proteção de Dados (LGPD). O prazo de retenção deve considerar a necessidade de investigação, eventuais obrigações legais e o custo de armazenamento.

Quanto custa coletar esses sinais?

Cada sinal tem um comportamento de custo diferente. Ignorar essa diferença costuma resultar em faturas inesperadas nas ferramentas de observabilidade.

• Logs crescem com o volume de eventos. Deixar o nível de depuração ligado em produção pode multiplicar o volume sem ajudar na maior parte das investigações.
• Métricas são compactas, porque resumem muitos eventos em números, mas o custo sobe com a cardinalidade, isto é, com o número de combinações de rótulos. Usar o identificador de cada usuário como rótulo é um exemplo clássico de excesso.
• Traces podem ser amostrados. Em vez de guardar todas as solicitações, a ferramenta guarda uma parte representativa. Algumas estratégias de amostragem preservam com prioridade as solicitações que tiveram erro ou lentidão.

Definir retenções diferentes por tipo de dado e por ambiente também ajuda. Dados de homologação raramente precisam ficar guardados pelo mesmo período que os de produção.

Perguntas frequentes

Logs de segurança e logs de operação são a mesma coisa?

Muitas vezes vêm da mesma fonte, mas servem a objetivos diferentes. Logs de autenticação, por exemplo, ajudam a operação a entender falhas de login e também alimentam o SIEM, a plataforma que correlaciona eventos em busca de sinais de ataque. Retenção e controle de acesso podem variar conforme o uso.

É preciso trocar de ferramenta para ter traces?

Nem sempre. Padrões abertos como o OpenTelemetry permitem instrumentar a aplicação uma vez e enviar os dados para diferentes plataformas compatíveis. O esforço maior costuma estar na instrumentação do código e na padronização dos nomes de serviços e operações, mais do que na escolha da ferramenta.