Estratégias de Sampling em Escala

Primeiro decida quais perguntas os traces precisam responder, porque isso é o que direciona a estratégia. O head sampling decide na raiz do trace, antes de qualquer coisa acontecer: um sampler baseado em proporção do pai mantém, digamos, 1% dos traces, e a decisão viaja junto no bit sampled do traceparent, para que todos os serviços downstream concordem. É barato e simples, mas é cego: a requisição lenta e o erro 500 são descartados com a mesma probabilidade que a resposta 200 tranquila. O tail sampling inverte isso. Todo span é exportado, armazenado em buffer no gateway do Collector, e a decisão de manter ou descartar acontece depois que o trace termina, com conhecimento completo: mantém 100% dos traces com erros, 100% dos traces mais lentos que dois segundos, e 1% de tudo o mais como uma linha de base saudável. Isso é exatamente o que você quer para depuração, mas tem um custo: o gateway armazena em buffer todo trace em andamento na memória, e todos os spans de um determinado trace precisam cair na mesma instância do Collector, o que exige uma camada de balanceamento de carga que roteia por trace ID na frente da sua camada de sampling. A 50 mil rps, esse buffer é memória real e o exporter de balanceamento de carga não é opcional. Na prática, eu combino os dois: um head sampling leve ou rate limiting no SDK para tirar o excesso de volume, e tail sampling no gateway para a lógica de manter os interessantes. Duas coisas que as pessoas esquecem: qualquer métrica derivada de spans, como dashboards RED vindos do connector spanmetrics, precisa ser gerada antes do sampling, ou seus percentis de latência viram ficção, e você deve deixar registrado que o alerta baseado em traces agora vê dados amostrados, então a ausência de um trace não prova mais a ausência de um problema.