Cloudflare Traces: o proxy precisa aparecer no diagnóstico de latência

O Cloudflare Traces entrou em beta aberto e passou a representar etapas do proxy, como regras de segurança, transformações, cache e acesso à origem, em spans OpenTelemetry.[5] O recurso amplia a visão além da execução de Workers e permite acompanhar essas etapas na linha do tempo de uma requisição.[5]

Para quem desenvolve, o valor não está em acumular mais gráficos. Está em reduzir a distância entre uma reclamação de lentidão e a identificação de qual componente consumiu o tempo ou mudou a chamada.

O que muda para quem desenvolve

Um exemplo da matéria mostra uma requisição de 539 ms com 527 ms de espera pela origem depois de um cache miss.[5] É um caso ilustrativo, não uma distribuição de latência de todos os clientes. Ainda assim, demonstra o tipo de pergunta que um trace integrado pode ajudar a responder: a demora aconteceu na borda ou depois dela?

O serviço pode aceitar traceparent recebido e propagar contexto à origem, com uma política para decidir se o contexto enviado pelo cliente será aceito.[5] Os spans podem ser exportados por OTLP para backends compatíveis.[5]

Minha leitura arquitetural é que a correlação precisa ser desenhada junto com a confiança. Antes de conectar identificadores externos aos traces internos, defina quem pode estabelecer esse contexto e como investigar valores inesperados. A integração não deve transformar qualquer cabeçalho recebido em uma identidade operacional confiável.

Como aplicar

Escolha um endpoint de homologação e uma pergunta específica, como distinguir uma regra de bloqueio de uma demora na origem. Instrumente a aplicação, configure a exportação para um destino OTLP e gere chamadas controladas. Compare o trace com os registros do serviço e confirme se as etapas esperadas aparecem na mesma investigação.

As Trace Rules permitem direcionar a amostragem por condições como hostname, caminho, método ou cabeçalho.[5] Use uma coleta básica pequena e aumente a captura apenas para o tráfego do experimento. Defina também quem poderá ativar um modo de depuração e quando a configuração será revertida.

A mudança de preços anunciada para 1º de dezembro de 2026 troca cobrança por span por ingestão e armazenamento, inclusive em Workers Tracing.[5] O plano gratuito inclui 0,5 GB por dia e retenção de sete dias, sem consumo adicional; os planos pagos e Enterprise incluem 50 GB de ingestão e 10 GB-mês de armazenamento por ciclo.[5] Os excedentes anunciados custam US$ 0,25 por GB ingerido e US$ 0,10 por GB-mês armazenado.[5]

No piloto, meça o volume produzido pelo tráfego selecionado antes de ampliar a coleta. Revise atributos e tratamento de dados sensíveis. Se um agente consultar a telemetria, dê a ele acesso de leitura e mantenha a alteração de produção numa autorização separada.

Cuidados e limites

A cobertura ainda é incompleta: regras DDoS, Access e partes do ecossistema Workers aparecem como evoluções planejadas.[5] Propagação autenticada de contexto e retenção de até um ano também são itens futuros, não recursos disponíveis demonstrados na matéria.[5]

Trate o beta como um piloto com critérios de aceite e saída, não como substituição automática da observabilidade existente. Amostragem reduz custo, mas também limita o que será preservado. O ganho operacional precisa ser medido pela capacidade de responder perguntas reais, e não pelo número de spans armazenados.

Fonte

[5] Fonte: InfoQ | Publicação: 10/10/2026 às 04:12:00