Observability · 11/06/2026

OpenTelemetry pós-Graduation: Quando Standardização de Sinais Encontra Complexidade Real de Operação em Legado e GenAI

A graduation do OpenTelemetry como projeto CNCF validou a padronização de telemetria, mas expôs um trade-off crítico: quanto mais você tenta medir (legado, GenAI, edge), mais controles operacionais e segurança você precisa reinventar fora do padrão.

O que está acontecendo

A CNCF anunciou a graduation do OpenTelemetry como projeto, marcando a consolidação de um framework que unificou OpenTracing e OpenCensus. Esse passo reflete não apenas aceitação da comunidade, mas também a expansão da observabilidade em três frentes distintas: ambientes legados (manufatura, sistemas industrial), aplicações com modelos de linguagem generativa, e simplificação da curva de adoção através de blueprints de referência.

A realidade operacional, porém, revela que a standardização de como coletar telemetria não elimina a fragmentação de onde e como aplicar segurança, instrumentação e controle em domínios que o padrão não cobriu completamente.

Insights e Riscos

OpenTelemetry graduado consolida a sintaxe, não a semântica operacional:

• A padronização através de Semantic Conventions para GenAI (contagem de tokens, chamadas de modelo, resultado de ferramentas) resolve o problema de formato, não de significado. Um LLM chamado 45 segundos mais lento pode estar preso em retry loops, saturação de I/O ou timeout de API — a telemetria padronizada registra a latência, não a causa arquitetural.

Ambientes legados exigem observabilidade sem instrumentação direta:

• Sistemas que não podem ser modificados (equipamento industrial, mainframes com Long Equipment Life Cycles) precisam de observabilidade deduzida a partir de observação de borda (network taps, proxy camadas, log agregação). OpenTelemetry presume código instrumentável; legado presume observação passiva. A Semantic Convention não cobre esse gap — você implementa ad-hoc ou desiste.

Segurança em legado e GenAI opera em camadas diferentes:

• Legacy: redes planas, PII não típica, políticas de patching medidas em trimestres. GenAI: dados sensíveis em prompts/completions, overhead de sanitização de tokens, rastreamento de chamadas de ferramentas que invocam APIs não observáveis.
• Um único collector OpenTelemetry não consegue aplicar regras de máscaras de PII, sanitização de conteúdo de prompt, ou detecção de exfiltração em ambientes com segmentação de rede diferente.

Blueprints e Reference Implementations reconhecem a complexidade, mas não a resolvem:

• A admissão de que "adoção completa exige entender configurações de SDK, múltiplos collectors, pipelines de dados, instrumentation libraries" é um reconhecimento de que o padrão criou uma camada abstrata que ainda demanda expertise específica de cada contexto de deploy.
• Uma "solução consolidada com telemetria de alta qualidade" em uma organização com 20 microsserviços em Kubernetes + 3 sistemas legados + 2 stacks de GenAI não existe em blueprint — existe em engenharia.

Data volume e retenção explodem sem semântica de relevância:

• Semantic Conventions definem o que registrar (tokens, chamadas, latência), não por quanto tempo reter ou qual dado você realmente precisa para SLO. Um agente GenAI instrumentado pode gerar 10x mais eventos que um serviço síncrono; blueprints não abordam retention policies diferenciadas.

O que muda na prática

Para Arquitetos:

• Graduation não significa "plug-and-play observability". Significa você tem padrão de sintaxe mas ainda precisa desenhar separadamente: (1) where collectors live (centralizados vs edge vs sidecar); (2) qual dado vai para qual backend (observability, compliance, cost chargeback); (3) como mapeiam Semantic Conventions próprias para domínios novos (GenAI, legado, workflows agentic).
• A escolha entre consolidar telemetria em um único stream vs criar pipelines segregados por tipo de carga (legado vs real-time GenAI) não tem resposta padrão — depende de SLO, latência de ingestão e retenção.

Para DevOps/SRE:

• Você não adota "OpenTelemetry". Você adota um subconjunto dele (ex: Traces + Metrics para Kubernetes, Logs apenas de erro para legado). A complexidade operacional está em manter >1 configuração coerente.
• Reference Implementations devem ser avaliadas como "starting point", não como "final topology". Espere reescrever pelo menos a camada de filtragem, agregação e transformação de dados para seu contexto.

Para Engenheiros de Segurança:

• Observability em legado + GenAI significa você precisa de controles fora da cadeia OpenTelemetry: sanitização de prompt antes da ingestão, mascaramento de PII antes do armazenamento, detecção de anomalia em padrões de chamadas de LLM.
• A Semantic Convention para GenAI não inclui "foi esse resultado uma alucinação detectável?" ou "essa chamada de ferramenta tentou acesso não autorizado?". Você escreve processadores customizados ou aceita que esses riscos não são visíveis.

Conclusão direta

A graduation do OpenTelemetry representa vitória em unificar formato de telemetria. Mas a realidade operacional mostra que standardização de sintaxe não elimina fragmentação de semântica: ambientes legados requerem observabilidade sem instrumentação, GenAI requer granularidade em dados sensíveis, e adoção em escala ainda demanda "blueprints" que na verdade são templates parciais, não soluções.

A pergunta real não é mais "qual padrão de observabilidade usar?", mas: em qual camada sua organização está disposta a manter expertise customizada para fazer observabilidade funcionar onde o padrão não cobre — e qual é o custo oculto disso em rotação de engenharia?

Fontes

[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 [Fonte: Blog on OpenTelemetry] Introducing OTel Blueprints and Reference Implementations