OTel Collector: O que é e como usar em observabilidade?

Adotar OpenTelemetry como padrão aberto de instrumentação resolve metade do problema. A outra metade aparece quando a telemetria começa a fluir: como roteá-la para múltiplos backends sem reconfigurar cada aplicação? Como filtrar dados sensíveis antes que saiam do ambiente? Como reduzir o custo de ingestão em ferramentas pagas? A resposta quase sempre passa por um componente específico do ecossistema: o OTel Collector.

O Collector é o ponto de passagem de todo o dado de telemetria que sai das aplicações instrumentadas. Ele recebe logs, métricas e traces em formatos diversos, aplica processamento leve ou pesado conforme sua configuração e encaminha o resultado para um ou mais backends, comerciais ou open source. É o que permite desacoplar quem gera a telemetria de quem a consome.

Este guia explica o que é o OTel Collector, como sua arquitetura interna funciona, quando usar cada padrão de deployment e como configurá-lo em produção, com foco em times brasileiros de SRE, DevOps e operações que estão migrando de stacks proprietárias ou consolidando pipelines de dados de telemetria.

O que é o OTel Collector e onde ele entra no pipeline OpenTelemetry

O OTel Collector é um executável agnóstico de fornecedor que recebe, processa e exporta dados de telemetria. Ele é distribuído como binário único (em Go) ou como imagem de container e funciona tanto em hosts tradicionais quanto em orquestradores como Kubernetes. Sua função dentro do OpenTelemetry é separar a responsabilidade de instrumentar aplicações da responsabilidade de operar um pipeline de telemetria.

Na prática, existe uma divisão clara: a aplicação, via SDK do OpenTelemetry, gera spans, métricas e logs e envia tudo via OTLP para o Collector. O Collector então decide o que fazer com aqueles dados. Essa separação é o que permite trocar backends sem mexer em código de aplicação e aplicar políticas centralizadas de sampling, enriquecimento ou mascaramento de informações sensíveis.

Vale diferenciar duas camadas que costumam ser confundidas. A instrumentação acontece no nível da aplicação, com bibliotecas que capturam traces e métricas em runtime. O Collector acontece no nível de infraestrutura, operado pelo time de observabilidade ou SRE. Os três sinais fundamentais logs, métricas e traces passam pelas duas camadas e se encontram no pipeline do Collector antes de seguir para os backends.

Outra característica importante é que o Collector é stateless por padrão. Cada instância processa os dados que recebe e repassa adiante, sem armazenar informação localmente além de buffers temporários. Isso facilita escalar horizontalmente, aplicar load balancing e operar em ambientes efêmeros como pods de Kubernetes.

Arquitetura do Collector: receivers, processors, exporters e extensions

A arquitetura interna do Collector é organizada em quatro tipos de componentes que se combinam para formar pipelines. Entender cada tipo é pré-requisito para escrever uma configuração funcional.

Receivers são a porta de entrada. Eles aceitam dados de telemetria em algum formato específico e os convertem para o formato interno do Collector. Existem receivers baseados em push, que esperam conexões de aplicações instrumentadas (o mais comum é o otlp receiver, que escuta nas portas 4317 para gRPC e 4318 para HTTP), e receivers baseados em pull, que fazem scraping de endpoints periodicamente (o prometheus receiver é o exemplo clássico).

Processors transformam os dados enquanto eles atravessam o pipeline. Aqui mora boa parte do valor operacional do Collector. O batch processor agrupa dados em lotes para reduzir chamadas aos backends. O memory_limiter previne estouro de memória descartando dados quando os limites são ultrapassados. O attributes processor adiciona, modifica ou remove atributos, útil para mascarar informações sensíveis antes que a telemetria saia do ambiente. O tail_sampling processor descarta traces inteiros conforme regras de negócio, permitindo manter apenas spans relevantes.

Exporters são a porta de saída. Eles traduzem os dados do formato interno para o protocolo esperado pelo backend de destino. É comum um mesmo pipeline ter múltiplos exporters em paralelo, por exemplo enviando traces para Jaeger e métricas para Prometheus simultaneamente.

Extensions são componentes auxiliares que não participam do fluxo de dados mas adicionam funcionalidades operacionais, como health check endpoints, zPages para debug em runtime e autenticação.

Os quatro tipos se combinam em pipelines declarativos. Um pipeline é uma lista ordenada que parte de receivers, passa por processors e termina em exporters. Cada sinal (traces, métricas, logs) tem seu próprio pipeline, o que permite aplicar políticas distintas para cada tipo de dado dentro do mesmo Collector.

Agent, Gateway ou ambos? Padrões de deployment do OTel Collector

Existem três padrões principais de deployment, cada um com vantagens e cenários ideais. A escolha afeta custo, complexidade operacional e controle sobre os dados.

Modo Agent

No modo Agent o Collector roda próximo da fonte de dados, geralmente como processo no mesmo host da aplicação ou como DaemonSet em clusters Kubernetes. A telemetria viaja um caminho curto até ele, o que reduz latência e permite enriquecer dados com metadados locais (nome do host, região, cluster) antes de enviá-los adiante.

Esse modo é ideal quando o time quer coletar métricas do próprio host, como uso de CPU e disco, ou quando existe preocupação com perda de dados em caso de falha de rede, já que cada agent acumula buffers independentes. A desvantagem é o custo operacional: muitos agents significam mais instâncias para atualizar, monitorar e auditar.

Modo Gateway

No modo Gateway uma ou poucas instâncias do Collector operam como serviço autônomo, recebendo telemetria de múltiplas aplicações e agents via endpoint OTLP central. Isso concentra o processamento pesado em um lugar só, facilita aplicar políticas globais (como sampling coordenado) e reduz a quantidade de conexões TCP abertas com os backends.

É o formato preferido quando o pipeline precisa consolidar telemetria de dezenas ou centenas de fontes antes de exportar. Por outro lado, o Gateway é um ponto central que precisa ser escalado e monitorado com atenção. Perder o Gateway pode significar perder telemetria.

Padrão híbrido

O padrão mais comum em produção combina os dois modos: agents leves em cada host ou pod fazem coleta local e enriquecimento, e encaminham os dados para um Gateway central que aplica sampling, processamento pesado e roteamento para os backends. Esse desenho equilibra resiliência na borda com controle central e é recomendado para ambientes com monitoramento em clusters Kubernetes de porte médio a grande.

Como configurar o OTel Collector na prática

A configuração do Collector é feita inteiramente em YAML. O arquivo define quais componentes estão habilitados e como eles se combinam em pipelines. Abaixo um exemplo representativo de um Gateway recebendo OTLP, aplicando três processors e exportando para dois backends simultaneamente.

# Recebe telemetria via OTLP (gRPC e HTTP)
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

# Processors: limite de memoria, remocao de PII e agrupamento em lotes
processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
  attributes/sanitize:
    actions:
      - key: user.email
        action: delete
      - key: user.cpf
        action: delete
  batch:
    send_batch_size: 1024
    timeout: 10s

# Exporters: traces para Jaeger e metricas para Prometheus
exporters:
  otlp/jaeger:
    endpoint: jaeger:4317
    tls:
      insecure: true
  prometheus:
    endpoint: 0.0.0.0:8889

# Pipelines separados por sinal
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, attributes/sanitize, batch]
      exporters: [otlp/jaeger]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [prometheus]

O arquivo acima cobre um cenário típico: aplicações enviam traces e métricas via OTLP, o Collector aplica limite de memória (500 MB), remove atributos com informações pessoais antes de agrupar em lotes de 1024 itens ou 10 segundos e exporta para Jaeger e Prometheus em paralelo. Note que traces e métricas têm pipelines independentes: só os traces passam pelo processor de sanitização, já que só eles costumam carregar dados de usuário.

Para subir o Collector com essa configuração em um container local, o comando é direto:

docker run -d \
  --name otel-collector \
  -p 4317:4317 -p 4318:4318 -p 8889:8889 \
  -v $(pwd)/config.yaml:/etc/otelcol-contrib/config.yaml \
  otel/opentelemetry-collector-contrib:latest

Use sempre a imagem otel/opentelemetry-collector-contrib quando precisar de componentes fora do core, como exporters para Datadog, New Relic ou backends brasileiros específicos. O core traz só o básico.

Casos de uso que justificam adotar o Collector

O Collector não é obrigatório. Aplicações instrumentadas com OpenTelemetry podem enviar dados diretamente para backends compatíveis com OTLP. Mas alguns cenários tornam o Collector praticamente indispensável e valem o investimento operacional.

Roteamento para múltiplos backends sem mudar código: equipes que querem enviar traces para uma ferramenta de APM paga e simultaneamente guardar cópia em Jaeger open source para auditoria conseguem isso configurando dois exporters no mesmo pipeline. A aplicação continua enviando tudo para um único endpoint, sem se preocupar com os destinos.

Redução de custo de ingestão: backends cobram por volume de dados. Aplicar tail-based sampling no Collector para manter 100% dos traces com erro mas apenas 10% dos traces bem-sucedidos pode reduzir o custo mensal em uma ordem de grandeza, mantendo o que realmente interessa para troubleshooting.

Conformidade com LGPD: times que trabalham com dados pessoais precisam garantir que nomes, e-mails, CPFs e outros identificadores não cheguem a ferramentas externas. O attributes processor combinado com transform permite remover ou ofuscar esses campos antes que os dados saiam do perímetro da empresa.

Consolidação de pipelines legados: empresas que já operam Prometheus, Zabbix ou coletores proprietários podem usar o Collector como ponte para migrar gradualmente. Um mesmo pipeline pode fazer scraping de endpoints Prometheus existentes e receber OTLP de aplicações novas, unificando destinos sem forçar big bang. É uma forma prática de construir pipelines de dados escaláveis sem descartar investimento anterior.

Enriquecimento centralizado: adicionar tags de ambiente, time responsável, classificação de criticidade e outras dimensões é muito mais fácil em um único ponto do pipeline do que replicar a mesma lógica em cada aplicação instrumentada.

Boas práticas de produção e observabilidade do próprio Collector

Operar o Collector em produção exige cuidado com alguns pontos que aparecem pouco em tutoriais introdutórios.

Sempre habilite o memory_limiter como primeiro processor do pipeline. Ele protege contra picos de telemetria que poderiam derrubar a instância. Dimensione o limite em torno de 75% da memória disponível para o container ou processo.

Ative o endpoint de métricas internas do Collector. Ele expõe sinais de saúde do próprio pipeline: taxa de itens recebidos, descartados, lotes exportados e erros por exporter. Esses sinais alimentam alertas que seguem o método RED e evitam que o Collector vire uma caixa-preta.

Use o batch processor sempre como último processor antes dos exporters. Lotes grandes demais aumentam latência; lotes pequenos demais aumentam custo de chamadas aos backends. Valores iniciais razoáveis são 10 segundos de timeout e 1024 itens por lote.

Em deployments Gateway, coloque um balanceador na frente. Múltiplas réplicas garantem disponibilidade mas exigem atenção a sampling coordenado: estratégias tail-based precisam de consistência para não descartar spans relacionados em réplicas diferentes.

Mantenha a configuração versionada em Git e aplique mudanças via pipeline de CI/CD, nunca editando o YAML diretamente no servidor. Revisões de configuração do Collector afetam toda a telemetria e merecem o mesmo cuidado que código de aplicação crítica.

Por fim, acompanhe releases com atenção. O projeto tem ciclo de atualização rápido, com novos componentes chegando a cada poucas semanas. Ler as release notes antes de subir versão evita surpresas com breaking changes em receivers ou exporters que seu time usa.

Conclusão

O OTel Collector é o componente que transforma OpenTelemetry de um conjunto de bibliotecas de instrumentação em um pipeline de observabilidade operacional. Ele desacopla aplicações dos backends, permite aplicar políticas centralizadas de sampling, privacidade e enriquecimento e abre caminho para migrações graduais entre ferramentas de monitoramento.

Times que ainda enviam telemetria direto das aplicações para backends proprietários deixam em cima da mesa flexibilidade, controle e economia que o Collector entrega com relativamente pouco esforço operacional. Começar com um Gateway simples, um pipeline por sinal e dois ou três processors bem escolhidos resolve a maioria dos casos de uso reais.

Se sua empresa está revisando arquitetura de monitoramento, consolidando ferramentas ou precisa enquadrar telemetria em políticas de privacidade, a consultoria em observabilidade da OpServices pode ajudar a desenhar o pipeline certo. Para discutir como adequar o Collector à sua stack e definir um plano de observabilidade, fale com um especialista da nossa equipe.

Consulte também a documentação oficial do projeto, a especificação de arquitetura e o projeto graduado pela CNCF para aprofundar conceitos.