Introducción
Historicamente, la instrumentación de aplicaciones detrás de un proxy inverso o CDN presentaba un punto ciego significativo. Los equipos de ingeniería veían el span del cliente y el del backend, pero el tiempo transcurrido en la red de borde permanecía oculto, inferido mediante logs dispersos o correlación temporal manual. Esta falta de visibilidad impedía diagnosticar con precisión si una latencia elevada provenía de la evaluación de reglas de seguridad, una transformación de URL, un fallo en la caché o la lógica del propio Worker.
La situación cambia con el lanzamiento de la beta abierta de Cloudflare Traces. Esta funcionalidad extiende la trazabilidad automática más allá de los Workers de JavaScript, cubriendo ahora reglas de seguridad, transformaciones, decisiones de caché, enrutamiento y manejo del origen. Todo esto se materializa como spans estándar de OpenTelemetry (OTel) en una línea de tiempo única por solicitud. Para los arquitectos de nube y equipos de SRE, esto elimina la necesidad de escribir código de instrumentación manual para la infraestructura de red, pero introduce una nueva complejidad en la gestión de costos y el muestreo debido a su modelo de precios basado en volumen.
Qué ocurrió
Cloudflare ha integrado su capa de procesamiento de solicitudes con los estándares abiertos de observabilidad. A partir de esta versión beta, cada paso del ciclo de vida de una solicitud que atraviesa la red de Cloudflare genera un span OTel. Esto incluye componentes críticos como la evaluación de reglas de WAF (Web Application Firewall), la aplicación de reglas de transformación (Transform Rules), la resolución de rutas (Page Rules/Snippets) y la ejecución de Workers.
El sistema propaga el contexto mediante el estándar W3C Traceparent. Si una solicitud entrante ya posee un encabezado de trazabilidad, Cloudflare continúa esa traza existente, añadiendo sus propios spans intermedios. Además, es capaz de generar y enviar un nuevo traceparent hacia el servidor de origen, permitiendo que servicios instrumentados con SDKs de OTel (en Python, Rust, Java, etc.) continúen la misma traza distribuida. Esto crea un puente transparente entre el cliente, la red de borde y la aplicación backend.
La configuración no requiere cambios en el código de la aplicación para la generación básica de spans, aunque sí requiere configuración a nivel de cuenta para habilitar la exportación y definir las políticas de muestreo. La integración se gestiona a través de un destino de nivel de cuenta compatible con OTLP (OpenTelemetry Protocol), permitiendo enviar los datos a backends como Jaeger, Tempo, Datadog o New Relic sin intermediarios propietarios adicionales.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de seguridad, esta herramienta reduce drásticamente el tiempo medio de detección (MTTD) de incidentes relacionados con falsos positivos o bloqueos inesperados. Anteriormente, determinar qué regla específica de una lista de cientos detuvo una solicitud requería revisar logs de auditoría con tiempos de espera considerables. Ahora, el span de la regla de seguridad muestra explícitamente el ID de la regla, la acción tomada y la duración de la evaluación, todo alineado cronológicamente con el resto de la solicitud.
En el ámbito de infraestructura y rendimiento, la capacidad de desglosar la latencia permite identificar cuellos de botella específicos. Un ejemplo citado en la documentación muestra una solicitud de 539ms donde 527ms correspondían a la obtención de respuesta del origen debido a un fallo de caché (cache miss). Sin esta visibilidad granular, el equipo podría haber optimizado erróneamente el código del Worker mientras el problema real residía en la configuración de TTL de la caché o en la lógica de invalidación.
Sin embargo, el impacto financiero es inmediato y requiere atención. El cambio de modelo de precios, efectivo desde el 1 de diciembre de 2026, pasa de cobrar por evento (span) a cobrar por volumen de datos ingeridos y almacenamiento. Esto obliga a los equipos a reevaluar sus estrategias de muestreo. Una estrategia de muestreo agresivo (100% de trazas) en entornos de alto tráfico podría generar costos exponenciales si no se ajusta la tasa de ingesta. La planificación de capacidad ahora debe incluir métricas de bytes generados por traza, no solo el conteo de solicitudes.
Detalles técnicos
Cloudflare Traces exporta los datos mediante OTLP, el protocolo estándar de la industria para OpenTelemetry. Esto garantiza la portabilidad de los datos y evita el bloqueo de proveedor (vendor lock-in). Los spans generados incluyen atributos específicos de la red de borde, como el ID de la regla de firewall, el estado de la caché (HIT/MISS), el tiempo de espera en la cola de Worker y la dirección IP del origen.
La funcionalidad de muestreo se integra con el motor de reglas existente de Cloudflare. Los administradores pueden definir una tasa base (por ejemplo, 1%) y crear reglas condicionales que sobrescriban esa tasa para tráfico específico. Estas reglas pueden filtrar por hostname, IP de origen, encabezados HTTP personalizados, método HTTP o geografía. Por ejemplo, una regla puede forzar el muestreo al 100% para todas las solicitudes que contengan el encabezado X-Debug-Trace: true, facilitando la depuración de incidencias críticas sin impactar el volumen general de datos.
Actualmente, la cobertura automática es parcial. Cloudflare ha confirmado que la instrumentación automática para reglas DDoS, Cloudflare Access, Workflows, Queues y Pipelines está planificada pero no disponible en la beta actual. Además, la propagación de contexto autenticado (para evitar que clientes no confiables inyecten IDs de traza maliciosos) aún está en desarrollo, lo que representa un riesgo de seguridad menor si no se configuran adecuadamente las políticas de aceptación de contexto entrante.
Qué deberían hacer los administradores y equipos técnicos
Conclusión
Cloudflare Traces representa un avance significativo en la observabilidad distribuida al cerrar la brecha de visibilidad en la capa de proxy. Al adoptar OpenTelemetry nativo, facilita la integración con el ecosistema estándar de herramientas de monitoreo y permite a los equipos correlacionar eventos de red con eventos de aplicación de manera precisa.
No obstante, la adopción requiere una gestión activa de los costos debido al nuevo modelo de facturación por volumen. Los equipos técnicos deben equilibrar la necesidad de alta fidelidad en los datos con la sostenibilidad financiera, utilizando las reglas de muestreo para capturar solo la información relevante. Para entornos de alto tráfico, esta funcionalidad no es un «plug and play», sino una herramienta que debe calibrarse cuidadosamente para evitar sorpresas en la factura mensual.
Fuentes
https://www.infoq.com/news/2026/10/cloudflare-traces-open-beta/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global