Você já conhece o padrão agente → gateway. Agora a decisão que separa arquitetura de configuração: onde aplicar sampling. O painel ao lado é uma infraestrutura simulada reagindo às suas escolhas — nada aqui é vídeo.
Sua zona on-premises tem milhares de hosts (ajuste no painel), cada um com um agente enxuto enviando traces pro gateway. O backend de APM cobra por evento ingerido, e o link de saída cobra por GB. Sem sampling, você paga fidelidade total — em dobro.
Sampling probabilístico descarta uma fração dos traces. A pergunta desta lição não é "quanto" — é "onde". E o onde muda tudo: custo, governança e o que você consegue fazer depois.
Head-based sampling de 25%. Você é o arquiteto da zona. Onde aplica?
Troque de resposta à vontade — observe os contadores, a espessura dos fluxos no diagrama e o badge de configuração. Errar aqui é grátis; em produção, não.
Esta é a config do gateway (OTel Collector). Mexa e rode: mude o sampling_percentage, remova o filter do pipeline, quebre a indentação de propósito. A infraestrutura simulada interpreta o que você escreveu.
Só conta o que está dentro do pipeline — declarar um processor e esquecer de listá-lo em service.pipelines.traces.processors é o erro nº 1 de OTel em produção. Teste.
No agente: alivia rede e gateway, mas a política vive em milhares de hosts — atualização vira campanha, drift vira rotina, e o corte acontece antes de qualquer visão agregada (adeus tail-based no futuro).
No gateway: um lugar pra mudar, visão agregada preservada, caminho aberto pra tail-based sampling. Preço: o gateway processa 100% do ingest — CPU e dimensionamento viram responsabilidade sua.
Em lugar nenhum: fidelidade máxima e a fatura mostra. Válido em zonas pequenas ou dados regulatórios — como decisão consciente, não como default por omissão.
Regra da casa: agente burro, gateway inteligente — política de dados pertence ao ponto de agregação, salvo restrição de rede ou custo que force o corte na origem.