Por Que Rodar um OpenTelemetry Collector

A exportação direta acopla cada aplicação ao seu backend. Trocar de fornecedor, rotacionar uma chave de API ou adicionar redação de spans significa reimplantar 40 serviços. Com um Collector no meio, as aplicações exportam OTLP simples para um endpoint local e tudo o mais vira configuração de pipeline: receivers recebem os dados, processors os transformam, exporters os distribuem. Os processors são onde está o verdadeiro valor. O batch processor reduz a sobrecarga de exportação, o memory_limiter evita que o Collector entre em OOM sob uma enxurrada de spans, os processors de attributes e redação removem PII antes que ela saia do seu cluster, e o tail sampling só pode acontecer aqui porque nenhuma aplicação isolada vê o trace inteiro. O Collector também armazena em buffer e tenta novamente quando o backend está fora do ar, então uma queda do backend não significa telemetria perdida nem contrapressão sobre suas aplicações. No Kubernetes, o layout padrão tem duas camadas. Um agente DaemonSet em cada nó dá às aplicações um endpoint local ao nó, adiciona metadados do k8s como pod e namespace, e faz trabalho barato como o batching. Um gateway central, um Deployment atrás de um Service, cuida do trabalho caro e stateful: tail sampling, filtragem, autenticação com backends externos, e ser o único ponto de saída que suas regras de firewall permitem. Clusters pequenos podem dispensar o gateway e rodar só o DaemonSet apontando direto para o backend. Você adiciona o gateway quando precisa de tail sampling ou quer um único lugar para controlar saída e credenciais.