Logs, métricas e traces: qual sinal responde a qual pergunta

O que é

A observabilidade (observability) se apoia em três tipos de sinal, que o OpenTelemetry define de forma unificada. Um log é um registro com carimbo de data e hora sobre um evento, com campos arbitrários; o modelo de dados do OpenTelemetry prevê nele, entre outros, os campos TraceId e SpanId, para que uma entrada de log possa ser associada à requisição em que foi gerada. Uma métrica é uma série temporal numérica; a documentação distingue instrumentos como Counter (só aumenta, como um hodômetro), UpDownCounter (aumenta e diminui, por exemplo o tamanho de uma fila), Gauge (valor atual no momento da leitura) e Histogram (distribuição, por exemplo dos tempos de resposta). Um trace representa uma requisição como uma árvore de spans, cada um com início, duração, atributos e span pai; a Context Propagation transporta o identificador do trace por cabeçalhos até os serviços seguintes.

Por que importa

Cada sinal responde a uma pergunta diferente, e nenhum substitui os outros. Métricas são baratas de armazenar e consultar e servem para alertas: «taxa de erro acima de dois por cento há cinco minutos.» Mas não dizem qual requisição foi afetada. Traces mostram, para uma requisição, onde o tempo foi gasto: no banco de dados, em um serviço externo, em uma chamada sequencial que poderia ser paralela. Logs contêm o texto exato do erro e os valores que o causaram. Só o identificador compartilhado transforma três ferramentas em uma única investigação: do alerta à requisição de exemplo e dela à entrada de log.

Como aplicar

• Começar pela pergunta, não pela ferramenta: para «o serviço está saudável?», poucas métricas bastam (requisições, erros, duração, saturação); para «por que esta requisição está lenta?», são necessários traces; para «o que havia na entrada?», logs.
• Instrumentar primeiro as fronteiras: requisições HTTP de entrada, chamadas de saída e acessos ao banco de dados; as bibliotecas costumam fazer isso automaticamente.
• Limitar os rótulos (labels) das métricas a poucos valores (endpoint, classe de status) e nunca usar identificadores de usuário ou de objeto: cada combinação é uma série temporal própria.
• Gravar o identificador do trace em cada registro de log e repassá-lo aos serviços seguintes; sem a propagação, o trace termina na primeira fronteira de serviço.
• Em cenários de alto volume, manter apenas uma amostra dos traces: se a decisão é tomada no início, a amostragem é barata; se é tomada após a conclusão, é possível reter por completo as requisições com erro e as lentas.
• Definir a retenção por sinal: métricas por muito tempo e agregadas, logs por menos tempo, traces pelo menor tempo.

Armadilhas

Logs de alta frequência usados no lugar de métricas («uma linha por requisição, depois contamos») não escalam e custam a cada consulta. Um histograma que exporta apenas médias perde os valores extremos que os usuários sentem. Traces sem atributos (código de status, número de linhas, acerto de cache) respondem apenas ao «onde», não ao «por quê». Coletar tudo sem ter uma pergunta gera custo, não conhecimento.