Amostragem de traces: poupar volume sem apagar os erros raros
Uma taxa uniforme reduz custo e também visibilidade. O desenho útil preserva contexto ponta a ponta, erros, caudas de latência e serviços críticos enquanto mede o que perde.
- Natureza
- Guia de rollout para OpenTelemetry Collector
- Quem deve ler
- SRE, plataforma, observabilidade, arquitetura e donos de serviço
- Publicado e verificado
- 5 de agosto de 2026
- Limite
- Taxas e limiares são decisões locais; os exemplos oficiais não constituem baseline universal
Em resumo
Head sampling decide no início e é simples de distribuir, mas ainda não conhece o resultado. Tail sampling espera por spans suficientes para decidir com base em erro, latência, atributos ou criticidade, ao custo de estado, memória e atraso no Collector. O W3C Trace Context torna a decisão propagável; decisões inconsistentes fragmentam traces. A OpenTelemetry oferece exemplos de políticas por criticidade e trabalho em amostragem probabilística consistente, cuja página normativa está marcada Development. A proposta Velqory começa por uma baseline mensurável, protege eventos raros, testa pressão e exportação e só então reduz volume.
- Head sampling é barato e precoce; tail sampling vê o resultado, mas precisa de capacidade e espera.
- Preserve sempre erros relevantes, caudas de latência e serviços críticos antes de aplicar taxas ao tráfego saudável.
- A fila cheia ou o fim da janela de retry pode provocar perda; WAL melhora resiliência, mas não garante perda zero.
- Configurações de demonstração e especificações em Development não são políticas universais: calibre e teste no seu sistema.
A escolha é sobre o momento da decisão e a informação disponível
No head sampling, a biblioteca decide quando o trace começa. A decisão pode usar serviço, operação, parent e probabilidade, mas ainda não sabe se haverá erro ou latência extrema. No tail sampling, o Collector reúne spans e decide mais tarde; consegue preservar o raro, mas precisa de dimensionamento e de uma janela que aceite spans tardios.
Propague traceparent e tracestate corretamente entre serviços. Se componentes ignorarem a decisão do parent ou alterarem contexto, o trace fica parcial e a política deixa de ser reproduzível.
Rollout que mede antes de cortar
- 1 · MAPAClassificar serviços e sinais
Criticidade, volume, erros, caudas, atributos, dados sensíveis e donos.
- 2 · CONTEXTOProvar propagação ponta a ponta
Trace ID, parent, flags e atributos estáveis através de todas as fronteiras.
- 3 · BASELINEMedir ingestão e perda
Volume, custo, spans tardios, filas, retries, drops e tempo de consulta.
- 4 · POLÍTICAProteger o raro primeiro
Erros, latência, criticidade e investigação; depois amostrar tráfego saudável.
- 5 · FALHATestar pressão e recuperação
Backend lento, fila cheia, restart, WAL, duplicação e perda observada.
- 6 · REVISÃOComparar utilidade e custo
Incidentes explicados, cobertura, enviesamento, custo e capacidade do Collector.
A matriz protege primeiro o valor diagnóstico e só depois aplica probabilidade
Defina precedência explícita: uma regra de erro ou criticidade não pode ser anulada por uma taxa posterior. Registe também a razão da amostragem para conseguir auditar se o conjunto guardado representa a política pretendida.
Classe de trace e decisão
| Classe | Decisão inicial | Decisão final | Aceitação |
|---|---|---|---|
| Erro relevante | Manter contexto | Preservar | Cadeia completa e causa investigável |
| Cauda de latência | Manter contexto | Preservar acima do limiar local | Distribuição extrema continua visível |
| Serviço crítico | Taxa conservadora | Preservar sinais definidos | Cobertura acordada pelo dono |
| Tráfego saudável | Probabilidade consistente | Reduzir conforme orçamento | Estimativas e comparação continuam válidas |
| Background ruidoso | Taxa baixa ou exclusão fundamentada | Preservar exceções | Sem ocultar dependência crítica |
| Pressão no Collector | Fila e retry | Degradar de forma observável | Drops, motivo e alarme são medidos |
Uma política de amostragem só é segura quando a perda é visível
O Collector usa sending queues e retry para absorver indisponibilidade temporária; quando a fila enche ou o tempo de retry termina, dados podem ser descartados. Um write-ahead log pode tornar a fila persistente para caminhos críticos, mas não elimina todas as formas de perda. Alarme sobre queue capacity, falhas de exportação, drops e spans demasiado tardios.
A página de consistent probability sampling está identificada como Development. Use-a para compreender o mecanismo e testar interoperabilidade, não para afirmar uma garantia final. Compare regularmente traces guardados com métricas e logs; divergência pode revelar enviesamento ou falha de instrumentação.
- Versionar políticas e guardar a razão de retenção.
- Dimensionar memória pela janela, taxa e tamanho dos traces.
- Separar redução voluntária de perda por pressão.
- Rever após mudança de topologia, tráfego ou backend.
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.- 01OpenTelemetry Collector resiliencyOpenTelemetry · SYS-OTEL
- 02W3C Trace Context RecommendationW3C · SYS-W3C
- 03Tail sampling by service criticalityOpenTelemetry · SYS-OTEL
- 04OpenTelemetry consistent probability samplingOpenTelemetry · SYS-OTEL
- 05OpenTelemetry Go sampling guidanceOpenTelemetry · SYS-OTEL
- 06Practical Alerting from Time-Series DataGoogle SRE · SYS-GOOGLESRE
Participar
Partilhe a análise. Acrescente contexto.
Divulgue a matéria no seu canal ou deixe uma observação ligada ao tema.
Comentários
A carregar a conversa.