Context Propagation

Se analizarmos qual é o fluxo de um span até chegar no seu destino temos isso.

A instrumentação não afeta muito a aplicação pois o custo de cpu e memória é muito baixo. Tudo é feito de forma muito rápida e não tem muita coisa que possamos melhorar a não ser evitar a criação de spans indesejados para gerar custos como mensionamos antes.

Na outra ponta temos o backend que é um serviço externo com recursos totalmente separados não interferindo em nada nossa aplicação.

O exporter é responsável por transformar os spans no formato adequado e coordenar seu envio ao backend sendo responsável pela atividade de rede do processo. Ele pode trabalhar com spans individuais ou em lotes.

O processamento (Span Processor) é um componente importante no fluxo do OpenTelemetry que atua como intermediário entre a instrumentação (onde os spans são criados) e o exporter (que envia os dados para o backend). Ele gerencia o ciclo de vida dos spans. O Span Processor é crucial para garantir performance e confiabilidade no processamento dos dados de telemetria, atuando como um buffer inteligente entre a geração e o envio dos dados. Ele atua inteiramente em memória (sem persistência em disco) e mantém uma fila para armazenar os spans. O tamanho dessa fila pode ser configurável, porém se a fila estiver cheia novos spans serão descartados.

Então temos:

• Instrumentação
  • Impacto muito baixo, pois são basicamente interceptações leves
  • Usa recursos mínimos já que apenas coleta dados
  • O overhead principal vem da criação dos spans e seus atributos
  • Em geral não bloqueia o fluxo principal da aplicação
• Processamento (SpanProcessor) -Impacto moderado pois lida com os spans em memória
  • O BatchSpanProcessor pode consumir mais memória devido ao buffer
  • Pode haver contenção se a fila ficar cheia
  • O processamento é assíncrono, então não bloqueia a thread principal
• Exporter
  • Impacto moderado a alto dependendo da configuração
  • O envio de dados pela rede é a operação mais "pesada"
  • Pode haver contenção se o backend estiver lento
  • Problemas de rede podem afetar o processamento dos spans
• Backend
  • Impacto mínimo na aplicação pois é um sistema separado -A única interferência seria se ele começar a rejeitar dados
  • Problemas de latência do backend podem afetar o exporter
  • Em geral não afeta a performance da aplicação diretamente

Sobre o processamento temos dois tipos.

• SimpleSpanProcessor: não mantém fila, cada span é processado imediatamente, usa menos memória mas é menos eficiente.
• BatchSpanProcessor: cria-se um buffer e uma fila para processamento e é o que devemos usar em produção.

Sabendo disso podemos entender que se a aplicação parar tudo que estava em memória também será perdido e o consumo de memória precisa ser monitorado. No caso de não conseguir entregar para o backend a memória pode crescer rapidamente.

Simple vs Batch

O BatchSpanProcessor é significativamente mais eficiente que o SimpleSpanProcessor, especialmente em cenários de alta carga.

Característica	SimpleSpanProcessor	BatchSpanProcessor	Observações
Padrão de Processamento	Processa e exporta cada span individualmente	Agrupa spans em lotes antes de exportar	BatchSpanProcessor reduz significativamente o overhead de rede
Throughput	~100-1000 spans/segundo	~10000-100000 spans/segundo	BatchSpanProcessor pode ser 100x mais eficiente
Chamadas de Rede	Uma chamada por span	Uma chamada por batch (ex: 512 spans)	Redução de até 99.8% nas chamadas de rede com BatchSpanProcessor
Latência	100ms por span (assumindo 100ms de latência de rede)	~0.2ms por span (100ms/512 spans)	BatchSpanProcessor distribui o custo da latência entre todos os spans do batch
Uso de CPU	Alto (overhead por span)	Baixo (overhead compartilhado)	Redução de até 90% no overhead de CPU com BatchSpanProcessor
Uso de Memória	Baixo (sem buffer)	Moderado (buffer configurável)	BatchSpanProcessor usa mais memória mas é controlável via maxQueueSize
Back Pressure	Não possui	Possui (via maxQueueSize)	BatchSpanProcessor pode controlar sobrecarga do sistema
Caso de Uso	Desenvolvimento e Debug	Produção	SimpleSpanProcessor não é recomendado para produção
Confiabilidade	Menor (mais suscetível a falhas de rede)	Maior (melhor tolerância a falhas)	BatchSpanProcessor tem retry e buffer
Configurabilidade	Mínima	Alta (batch size, queue size, delay, etc)	BatchSpanProcessor oferece mais controle
Perda de Dados	Perde apenas o span atual em processamento	Perde o Buffer todo (devido ao buffer)	BatchSpanProcessor pode preservar spans em memória
Debug	Mais fácil (comportamento direto)

Verifique na SDK criada qual o tipo de processor é utilizado e mude se necessário para o batch. É interessante configurar algumas variáveis que definem seus limites.

Podemos configurar passando variáveis de ambiente ou definindo via código.

• OTEL_BSP_MAX_EXPORT_BATCH_SIZE (Default 512): O número máximo de spans que pode ser enviado par ao backend por vez. É bom que seja grande, mas não tão grande pois o tempo de downlaod e upload irá aumentando de acordo com o tamanho. Nesse caso irá enviar até 512 spans por vez..

• OTEL_BSP_MAX_QUEUE_SIZE (Default 2048):

  • É o número máximos de spans na fila. Se ultrapassar 2048 irá descartar.

• OTEL_BSP_SCHEDULE_DELAY (Default 5000, 5s) -A cada 5 segundos o processador tenta exportar os spans acumulados. - Se não tiver spans no buffer, nada é enviado. Se tiver spans, envia até o limite definido em OTEL_BSP_MAX_EXPORT_BATCH_SIZE.

• OTEL_BSP_EXPORTE_TIMEOUT (Default 30000, 30s):

  • O exporter envia os spans para o backend e espera até X milissegundos (ex: 30000ms = 30 segundos) por uma resposta.
  • Se o backend não responder nesse tempo a operação é considerada falha e os spans podem ser descartados ou tentados novamente dependendo da configuração.