Sampling de Telemetria: O que é e como funciona?

Em ambientes distribuídos modernos, cada requisição pode gerar dezenas de spans, centenas de linhas de log e milhares de pontos de métrica. Multiplique isso pela taxa de tráfego de produção e o resultado é um volume de telemetria que cresce mais rápido que o orçamento disponível para armazená-lo.

É nesse ponto que o sampling de telemetria entra como decisão arquitetural. Em vez de ingerir absolutamente tudo, você seleciona quais traces, spans e eventos realmente importam para diagnosticar incidentes e tomar decisões. Feito com critério, preserva o sinal. Feito sem planejamento, esconde justamente os eventos que você precisaria ver.

Este guia explica o que é sampling de telemetria, compara as abordagens head-based e tail-based, mostra como configurar no OpenTelemetry Collector e traz heurísticas para definir a taxa de amostragem ideal sem comprometer a capacidade de resposta a incidentes.

O que é sampling de telemetria

Sampling de telemetria é a técnica de selecionar, de forma representativa, um subconjunto dos dados gerados pelas aplicações instrumentadas para enviar ao backend de observabilidade. Os dados que entram no pipeline são classificados como sampled (mantidos) ou unsampled (descartados), com base em políticas definidas no código ou no coletor.

O objetivo não é “enxergar menos”, mas enxergar o que importa com custo controlado. Em sistemas com milhares de transações por segundo, guardar 100% dos traces é inviável em storage e processamento. Uma amostra bem construída preserva a distribuição estatística de latência, taxa de erro e comportamento das dependências.

O termo costuma aparecer associado a traces por causa do impacto direto em volumes, mas vale também para logs (via filtros e samplers) e métricas (via agregações e cardinalidade reduzida). O princípio é o mesmo: priorizar o sinal de maior valor diagnóstico e reduzir redundância.

Por que fazer sampling em observabilidade

Há três motivações claras para aplicar amostragem em pipelines de telemetria. A primeira é custo: backends de traces costumam cobrar por span ingerido ou por GB armazenado. Em aplicações de alto tráfego, 100% de retenção multiplica o custo por volume e por cardinalidade de atributos.

A segunda é sinal versus ruído. A maior parte do tráfego de produção é saudável e repetitivo. Guardar 100% dos sucessos dilui a visibilidade dos 1% de requisições com erro ou latência anômala, que são as que realmente precisam de análise.

A terceira é capacidade do pipeline. Coletor, fila e backend têm limites de ingestão. Sem sampling, picos de tráfego podem derrubar exporters, causar perda aleatória de dados e gerar justamente o pior cenário: traces incompletos sem reprodutibilidade.

Há, porém, situações em que sampling não é recomendado. Ambientes de baixo volume (poucas centenas de spans por minuto) podem reter 100% sem estresse financeiro. Sistemas regulados por compliance ou auditoria podem exigir retenção integral de determinados fluxos. E, em qualquer caso, sampling deve ser decisão deliberada dentro de uma estratégia de observabilidade formalizada, não configuração padrão aplicada cegamente.

Head-based sampling: decisão no início do trace

Na amostragem pela cabeça, a decisão de amostrar ou descartar é tomada logo que o root span é criado, normalmente dentro do SDK da aplicação. A decisão se propaga para todos os spans filhos via contexto, garantindo consistência: ou o trace inteiro é mantido, ou ele inteiro é descartado.

O mecanismo mais comum é probabilístico por Trace ID. O sampler aplica um hash determinístico ao identificador do trace e compara com uma porcentagem configurada, por exemplo 10%. O resultado é estável entre serviços: se o serviço A decide manter um trace, o serviço B chegará à mesma conclusão usando o mesmo Trace ID.

Head sampling tem duas grandes vantagens. É barato em processamento, pois a decisão acontece no próprio cliente, sem exigir buffer de spans. E é previsível, porque a taxa de retenção é constante e fácil de dimensionar contra o orçamento de ingestão.

A desvantagem é crucial: o sampler não sabe, no início do trace, se aquela requisição vai terminar em erro, em timeout ou em latência crítica. Como resultado, head sampling puro descarta aleatoriamente a maioria dos traces e, por acaso, também descarta parte dos que seriam interessantes. Em ambientes onde detectar falhas raras importa mais que reduzir ruído, essa limitação vira um problema real de diagnóstico.

Tail-based sampling: decisão depois do trace completo

A amostragem pela cauda inverte a ordem. O coletor recebe todos os spans, mantém-nos em memória por um período curto, espera o trace fechar e só então decide se guarda ou descarta. O critério pode inspecionar qualquer parte do trace completo: duração total, presença de erro, atributos de rota, status HTTP, serviço específico no caminho.

A grande vantagem é retenção guiada por valor diagnóstico. Você pode definir políticas como “manter 100% dos traces com erro”, “manter 100% dos traces acima de 800ms” e “amostrar 5% do tráfego saudável”. O resultado é uma amostra enriquecida com justamente os casos que mais importam para o time de operações.

A contrapartida é operacional. O coletor precisa bufferizar spans por alguns segundos até que o trace esteja completo, o que consome memória proporcional ao volume. Além disso, há um requisito arquitetural pouco óbvio: todos os spans de um mesmo trace precisam chegar ao mesmo coletor. Em ambientes com múltiplos coletores atrás de um load balancer, isso exige um load-balancing exporter que roteie spans por Trace ID.

Para aplicações modernas que rodam em monitoramento de APIs e microsserviços, tail sampling costuma ser a escolha técnica preferida, apesar do custo operacional mais alto.

Tipos e estratégias de sampling

Dentro das duas abordagens há várias estratégias. Conhecer cada uma ajuda a desenhar políticas compostas, que é o padrão recomendado em produção.

Sampling probabilístico

É o modelo clássico. Uma taxa fixa (por exemplo 5%) decide, via hash determinístico do Trace ID, se o trace é retido. Simples de operar e de prever em orçamento. Implementações incluem TraceIDRatioBased no SDK e probabilistic_sampler no Collector.

Sampling determinístico por atributo

A decisão depende de um atributo conhecido: nome do serviço, rota, região, cliente. Útil para manter 100% de tráfego de serviços críticos e reduzir agressivamente serviços secundários. Combinado com probabilístico, permite políticas como “100% dos spans do serviço de pagamento, 1% dos demais”.

Sampling adaptativo

A taxa se ajusta dinamicamente conforme o volume observado. Se o coletor começa a receber mais que o limite configurado, o sampler reduz a taxa automaticamente. Evita picos de ingestão e protege o backend, mas exige monitorar a taxa efetiva para entender o que foi amostrado em cada janela.

Rate-limiting sampling

Garante um teto absoluto: por exemplo, “no máximo 100 traces por segundo, independentemente do volume gerado”. Útil para contratos com backend ou SLAs de ingestão. Difere do probabilístico porque não depende de porcentagem e sim de quantidade fixa.

Sampling por prioridade

A aplicação marca traces específicos como “prioridade alta” via atributo, forçando retenção. Padrão comum em jornadas críticas (checkout, login) ou em requisições de clientes premium. Pode ser implementado via sampling.priority em OpenTelemetry ou regras equivalentes no coletor.

Como configurar sampling no OpenTelemetry Collector

O OpenTelemetry Collector tem processors dedicados para amostragem, todos configurados em YAML. O padrão moderno recomendado é combinar head sampling no SDK (para proteger o pipeline em volumes muito altos) com tail sampling no coletor (para enriquecer a amostra com sinais valiosos). Se a sua base de instrumentação já usa o OpenTelemetry como protocolo padrão, a mudança envolve apenas ajustar processors e rearranjar pipelines.

O exemplo abaixo mostra um pipeline com probabilistic_sampler em conjunto com tail_sampling, cobrindo três políticas clássicas: sempre manter erros, sempre manter traces lentos acima de 800ms e amostrar uma fração do tráfego saudável.

processors:
  probabilistic_sampler:
    sampling_percentage: 25
  tail_sampling:
    decision_wait: 10s
    num_traces: 50000
    expected_new_traces_per_sec: 500
    policies:
      - name: errors-policy
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: slow-traces-policy
        type: latency
        latency: { threshold_ms: 800 }
      - name: probabilistic-policy
        type: probabilistic
        probabilistic: { sampling_percentage: 10 }
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [probabilistic_sampler, tail_sampling, batch]
      exporters: [otlp]

 
Dois detalhes merecem atenção. O parâmetro decision_wait define por quanto tempo o coletor segura os spans antes de fechar o trace, e costuma ficar entre 5s e 30s. Valores muito baixos podem fechar traces incompletos; valores altos aumentam o consumo de memória. Para entender o dimensionamento na prática, a documentação oficial em português do projeto traz guias por linguagem e contexto.

O segundo é a ordem dos processors. O probabilistic_sampler atua primeiro, reduz volume em nível de Trace ID e entrega um conjunto menor ao tail_sampling, que aplica as políticas avançadas. Inverter essa ordem elimina o benefício de proteção de pipeline.

Como definir a taxa de amostragem ideal

Não existe taxa universal. A decisão deriva de três variáveis: volume gerado pela aplicação, capacidade de ingestão do backend e valor diagnóstico esperado. Uma heurística prática: se o backend suporta X spans por segundo e o tráfego gera Y, a taxa mínima é X/Y. A partir desse piso, regras específicas (erros, latência, prioridade) elevam a taxa para subconjuntos de interesse.

Alguns pontos de partida por cenário:

➡️ APIs de alto volume e tráfego saudável dominante: 5% a 10% com reforço de 100% em erros e latência elevada.

➡️ Aplicações críticas de negócio (pagamentos, autenticação): 25% a 50%, com prioridade automática por jornada.

➡️ Ambientes de baixo tráfego (até 100 req/s): considerar 100% e revisar quando o volume crescer.

➡️ Debug e staging: 100% enquanto durar a janela de investigação, sem ligar head sampling.

A taxa escolhida deve ser revisada pelo menos a cada trimestre ou sempre que houver mudança relevante de tráfego, release ou arquitetura. Alinhar esse ciclo com a revisão dos pilares de uma plataforma de observabilidade mantém a amostragem consistente com os sinais que o time realmente consome.

Armadilhas comuns e boas práticas

Mesmo com política bem desenhada, alguns erros recorrentes reduzem o valor da amostragem. O primeiro é sampling enviesado: aplicar taxas diferentes em serviços do mesmo trace sem usar decisão baseada em Trace ID. O resultado são traces “buracados”, com spans faltando no meio do caminho.

Outro é perder traces de erro por usar head sampling puro. Se erros são eventos raros, uma taxa fixa de 5% descarta 19 em cada 20 falhas. A correção é obrigatória: combinar head sampling com política de tail sampling que garanta retenção de 100% dos erros.

Um terceiro é superdimensionar o decision_wait. Esperar 60s por traces longos consome memória linear com o volume. Se sua aplicação tem traces com duração acima do decision_wait, considere ajustar timeouts de spans antes de esticar a janela.

Por fim, não monitorar o próprio sampling. O coletor exporta métricas sobre spans recebidos, descartados e decididos por cada política. Instrumentar esses valores em um dashboard evita surpresas quando a taxa efetiva divergir da pretendida. Para operações maduras, o guia de observabilidade em ambientes modernos ajuda a integrar essas métricas à rotina de revisão do NOC. Fontes complementares, como o repositório do processor no GitHub, documentam todas as políticas disponíveis e seus parâmetros.

Conclusão

Sampling bem feito não é sobre guardar menos dados. É sobre guardar os dados certos, no volume que o orçamento e o pipeline suportam, sem sacrificar a capacidade de responder a incidentes. Head-based e tail-based não são alternativas excludentes: em produção, as duas abordagens combinadas entregam proteção de pipeline e qualidade diagnóstica ao mesmo tempo.

Começar é menos complexo do que parece. Um piso probabilístico, uma política de tail para erros e latência, métricas sobre o próprio coletor e revisão trimestral já resolvem a maior parte dos cenários de alto tráfego. A partir daí, ajustes finos vêm do aprendizado real da operação.

Se o seu time está estruturando a plataforma de telemetria ou precisa revisar a estratégia atual de amostragem, converse com a OpServices: nosso time consultivo desenha serviços de observabilidade fim a fim, do pipeline ao dashboard. Fale com um especialista para desenhar o modelo certo para o seu ambiente.