Observability · 15/06/2026

Arrow como Representação Interna em OTel: O Trade-off Real Entre Eficiência de Transporte e Complexidade de Pipeline

OTel-Arrow Phase 2 amplia a otimização além da rede: Arrow agora atua como formato interno do pipeline de telemetria. O ganho em overhead reduzido enfrenta trade-offs reais em compatibilidade, complexidade operacional e segurança em ambientes legados — áreas que ainda não têm resposta padronizada.

O que está acontecendo

A CNCF formalizou a graduação do OpenTelemetry como projeto consolidated, marcando transição de experimental para production-ready. Paralelamente, a fase 2 do OTel-Arrow evolui a otimização além do transporte de dados: Arrow, formato columnar em memória do Apache, agora funciona como representação interna dos pipelines de telemetria — não apenas como protocolo de fio (OTAP, Phase 1).

Phase 1 demonstrou redução de overhead de rede mantendo compatibilidade com o data model OpenTelemetry. Phase 2 questiona o cenário inverso: se Arrow passa a ser o formato de trabalho interno do pipeline, qual é o impacto real em compatibilidade, performance de transformação, e complexidade operacional em ambientes com constraints distintos?

Simultaneamente, a adoção de OpenTelemetry em ambientes legados (manufacturing, industrial systems) revela fricções de segurança não endereçadas pela especificação padrão. Sistemas que não podem ser modificados, redes planas, ciclos de vida longos e dados operacionais sensíveis criam um novo contexto de risco — incompatível com os modelos de controle assumidos pela observability moderna.

Insights e Riscos

• Arrow interno reduz overhead mas introduce overhead de conversão: A representação columnar é otimizada para agregação e transporte em lote. Transformações granulares por evento (filtering, sampling, enriquecimento) podem exigir deserialização e re-serialização, anulando ganho de transporte.

• Compatibilidade com exporters legados enfrenta decisão arquitetural: Se Arrow passa a representação interna, exporters que esperam formato JSON/Protobuf precisam conversão. Adapters criam camada extra; forçar migração impõe adoção cumulativa em ecossistema heterogêneo.

• Segurança em legado não cabe no modelo vendor-neutral: Ambientes industriais com redes planas exigem controles em camadas diferentes (DLP em rede, masking de payload em pipeline, auditoria local). OpenTelemetry assume segurança em foco — não operação degradada. Não há convenção semântica para dados redacted ou PII-aware sampling.

• GenAI Observability exacerba trade-off token/visibilidade: Convenções semânticas para GenAI (prompt tokens, completion tokens, tool calls) requerem captura de conteúdo — que é exatamente o que segurança legacy quer bloquear. Sampling determinístico em Arrow columnar é mais eficiente que em eventos dispersos, mas reduz precisão em problemas de latência onde causa raiz está em retry loops específicos.

• Complexidade operacional cresce com Phase 2, não diminui: Operadores precisam entender não só OTAP/Arrow em rede, mas transformações internas. Otimizador de coluna Arrow pode não ser óbvio ao debugar por que aplicação telemetry está slow. Traces com latência de processamento do pipeline tornam-se sinal de ruído.

O que muda na prática

Para Arquiteto de Observability: Avaliação de OTel-Arrow Phase 2 exige benchmark específico de seu pipeline: qual percentual de transformações é batch-friendly vs event-driven? Se sampling, filtering, correlação de contexto acontecem por evento, Arrow interno oferece ganho < 10%. Se pipeline é passthrough + agregação em backend, ganho é real (30-50% menos CPU em desserialização). A decisão de upgrade não é binária — é comparação de TCO atual (Protobuf + exporter) vs (Arrow + conversão ou novo exporter Arrow-native).

Para Engenheiro de Segurança: Legacy environments exigem strategy antes de adoptar OTel Phase 2. Defina: (1) Onde controle de acesso a telemetry reside? Se em agent OTel local, Arrow interno não importa — use JSON. Se em backend, Arrow columnar oferece granularidade para aplicar masking por campo em batch. (2) Auditoria de modificação de telemetry é requisito? Arrow em memória é mais opaco que JSON serializado — rastreabilidade decresce. (3) Compliance exige sampling determinístico + provenance? Arrow columnar permite sampling eficiente, mas provenance (qual agente gerou qual span) é mais complexo de extrair em formato columnar.

Para DevOps/SRE: Migração incremental é obrigatória. Phase 2 não é drop-in replacement — é revisão de collector stack. Passos: (1) Deploy Phase 1 (OTAP transporte) em canário — mede redução de bandwidth real seu caso. (2) Após estabilização, avaliar Phase 2 (Arrow interno) em subset de pipeline (ex: apenas metrics, não traces). (3) Monitor CPU/memory em collector durante conversão Arrow ↔ exporters legados. (4) Estabeleça SLA: se P99 latência de pipeline degrada > 10%, rollback. Arrow phase 2 vence apenas se overhead de conversão < overhead de transporte — hipótese que não é universal.

Conclusão direta

OTel-Arrow Phase 2 resolve problema específico (transporte de telemetry em rede com saturação de bandwidth) empurrando complexidade para pipeline interno — onde trade-offs não são ainda explícitos. Graduação do OpenTelemetry à CNCF reforça adoção, mas mascara heterogeneidade real: environments legados, GenAI avec constraints de privacidade, e pipelines event-driven têm resposta diferente para "Arrow como representação interna". A narrativa de "eficiência" ocorre em espaço de design assumido — não universal.

Pergunta provocativa: Seu pipeline gasta mais CPU em desserialização de Protobuf ou em transformação de eventos? Resposta honesta determina se Arrow Phase 2 é otimização ou migração custosa disfarçada.

Fontes

[Fonte: Blog on OpenTelemetry] OTel-Arrow Phase 2: From Efficient Transport to Efficient Telemetry Pipelines

[Fonte: Blog on OpenTelemetry] OpenTelemetry is a CNCF Graduated Project

[Fonte: Blog on OpenTelemetry] Applying OpenTelemetry Security Practices in Legacy Environments

[Fonte: Blog on OpenTelemetry] Inside the LLM Call: GenAI Observability with OpenTelemetry