Cloudflare Traces: encontrar dónde una solicitud se ralentiza

Una página de seguimiento de pedidos tarda mucho en responder. Su aplicación no indica ningún error, pero el usuario sigue esperando. ¿El retraso proviene del servidor, de una decisión de caché o de un paso intermedio? Cloudflare Traces, anunciado en beta el 2 de octubre de 2026, permite examinar más pasos. Para obtener un diagnóstico, todavía debe vincular las observaciones con la ruta correcta.

Comenzar con una solicitud que pueda reconocer

Tomemos una aplicación ficticia detrás de Cloudflare. Un navegador solicita una página, la petición atraviesa la plataforma y luego llega al servidor de la aplicación, llamado el origen. Este servidor puede consultar una base de datos o un servicio externo antes de responder. Cada capa solo ve una parte del trabajo.

Un registro de aplicación puede indicar que se ha servido una página sin explicar una espera ocurrida antes de su llegada. Por el contrario, un indicador de red no necesariamente muestra qué operación de la aplicación tomó tiempo. Una traza reúne pasos relacionados con la misma solicitud. Cada paso observado, a menudo llamado un span, especifica una operación y su lugar en el recorrido.

Para razonar, empiece con una solicitud sintética cuyo contenido domine. Anote la ruta utilizada, la hora de emisión y los elementos que permiten localizarla. Separe las observaciones de las hipótesis: «el origen recibió la solicitud» es una observación; «la base ralentiza la página» sigue siendo una hipótesis mientras nada lo demuestre.

Su ficha de diagnóstico debe poder contener casillas vacías. Una capa ausente puede corresponder a una parte no instrumentada o no conservada. No prueba que no se haya realizado ninguna operación en ella. Este principio es útil incluso con una herramienta de supervisión ya instalada: el nombre de una vista nunca garantiza la extensión de la prueba.

Los anuncios del 2 de octubre, con sus estados

Cloudflare Traces fue anunciado en beta abierta el 2 de octubre. El editor describe un recorrido que abarca las operaciones soportadas de seguridad, transformación, caché, enrutamiento, de Workers y del tratamiento del origen. Anuncia la propagación del contexto W3C traceparent, el muestreo y una exportación compatible con OTLP, el protocolo de transmisión de OpenTelemetry. La cobertura no debe extenderse a todos los productos por deducción. Anuncio Cloudflare Traces.

El mismo día, Cloudflare presentó ocho evoluciones de Observabilidad, incluyendo un espacio común para los registros, una API SQL unificada y alertas en beta. Las consultas cruzadas entre varios conjuntos de datos aún se anuncian para más adelante. El nuevo modelo tarifario está previsto a partir del 1 de diciembre de 2026, aplicándose a la renovación para Enterprise. Anuncio de Observabilidad.

Esta tabla resume los estados anunciados, no un inventario probado en una cuenta Partitech. Se utiliza para elegir lo que su piloto deberá confirmar. Evite construir un procedimiento de incidente en torno a una funcionalidad que aún está por venir.

Relacionar las capas sin inventar lo que no muestran

El contexto de traza es una información transmitida entre servicios para reconocer un recorrido común. OpenTelemetry proporciona un conjunto de convenciones y herramientas para instrumentar una aplicación, es decir, hacer que describa sus operaciones. Un formato común facilita la correlación; no crea automáticamente las observaciones que faltan dentro de su código.

Para una aplicación Symfony o Laravel, busque primero lo que ya está instrumentado: entrada de solicitud, acceso a la base de datos, llamada externa, cola asíncrona. Haga un mapa sencillo de las fronteras: navegador hacia la plataforma, plataforma hacia la aplicación, aplicación hacia las dependencias. Para cada paso, identifique quién acepta, transmite o renueva el contexto. No agregue un segundo colector antes de haber comprendido el camino existente.

Un identificador proporcionado por un llamante no es una identidad autenticada. En nuestro protocolo, nunca se utiliza para autorizar una acción ni para seleccionar el expediente de un cliente. Defina los límites donde se puede retomar un contexto externo, los formatos admitidos y las condiciones en las que se retoma un contexto interno. Esta recomendación de arquitectura debe adaptarse a su instrumentación real.

Examine también las ramas asincrónicas. Si la página inicia un trabajo después de haber respondido, su duración no debe confundirse con la del tiempo de espera en el navegador. La relación entre ambas operaciones puede seguir siendo útil, pero hay que explicar lo que se está midiendo. Sin esta distinción, una tarea secundaria prolongada corre el riesgo de convertirse en una falsa explicación de la lentitud de la página.

Elegir los datos antes de elegir el volumen

Una traza rico puede contener información que el diagnóstico no necesita. Para nuestra página ficticia, conservar una ruta normalizada como «seguimiento de pedido» suele ser más útil que conservar una URL completa con identificador personal y parámetros. El nombre de la operación puede ser suficiente sin su contenido de negocio.

Escriba una lista de campos permitidos y una lista de exclusiones: secretos, cookies, encabezados de autenticación, contenido de formularios y cuerpos de respuestas. Verifique lo que se recopila automáticamente, lo que se agrega mediante su código y lo que se envía al destino de exportación. La limpieza en la pantalla no garantiza que la exportación también esté limpia.

El muestreo consiste en retener una parte de las solicitudes. Usted busca un compromiso entre observaciones útiles, volúmenes y costo. En régimen normal, establezca una regla comprensible. Durante una investigación, puede proponer una recopilación más focalizada en una ruta sintética o un tráfico de prueba. Cloudflare anuncia precisamente reglas que permiten modificar la selección de las solicitudes rastreadas. Muestreo y Reglas de Rastreo.

Una regla temporal debe tener un propietario, una fecha de retiro y una justificación. De lo contrario, el incidente termina, pero la recolección ampliada continúa. También defina quién puede leer las trazas, cuánto tiempo permanecen accesibles y quién puede activar una exportación. Estas son decisiones de operación; ningún nivel de cumplimiento se deduce aquí de la adopción de un formato técnico.

Tres recorridos sintéticos para comparar

Nuestra propuesta de calificación comienza con tres solicitudes en una aplicación de demostración. La primera utiliza una respuesta que usted diseñó para provenir del caché. La segunda se conecta al origen. La tercera desencadena una operación interna deliberadamente distinta, por ejemplo, una llamada a un servicio simulado. Ninguna cuenta de cliente, ningún pedido real y ninguna latencia medida se proporcionan en este artículo.

Para cada recorrido, verifique que el comportamiento esperado realmente haya ocurrido: no nombre una solicitud « caché » únicamente porque lo haya deseado. Luego, encuentre su rastro, los pasos visibles y las observaciones de la aplicación asociadas. Un recorrido no encontrado debe explicarse por la configuración, la cobertura o una investigación adicional; no lo cuente automáticamente como un éxito.

Repita los recorridos con la regla normal y luego con la regla dirigida. Anote los volúmenes generados y la proporción de recorridos encontrados en las condiciones de la prueba. Inspeccione algunas exportaciones para confirmar la ausencia de los campos excluidos. Estas medidas permitirán decidir; la simple visualización de una traza no será suficiente para calificar el diagnóstico.

Pasar del esquema a un procedimiento operativo

El siguiente paso es una ficha utilizable durante un incidente: dónde buscar la solicitud, qué capas comparar y quién puede ampliar temporalmente la recopilación. Haga que la revise una persona que no haya preparado el piloto. Si no puede encontrar una solicitud de prueba con estas instrucciones, mejore el procedimiento antes de ampliar el alcance.

Prepare también la reversibilidad. Sepa retirar una regla, desactivar una exportación y conservar solo las pruebas necesarias para el análisis. Estime la conservación y los volúmenes a partir del uso observado, luego reexamine esta estimación al acercarse la fecha límite tarifaria anunciada. Las condiciones de la oferta pueden evolucionar durante la beta.

La elección favorable a Cloudflare Traces se basa en una correlación demostrada entre las capas útiles a su aplicación, una recolección controlada y un procedimiento comprensible. Si las operaciones decisivas siguen ausentes, mejore la instrumentación antes de esperar un mejor diagnóstico. La herramienta aporta un nuevo perímetro de observación; su equipo transforma estas observaciones en pruebas útiles para actuar.

Fuentes y fecha de verificación

Fuentes primarias abiertas el 6 de octubre de 2026: Cloudflare Observabilidad y Cloudflare Traces, publicadas el 2 de octubre. El recorrido ficticio, la ficha y las reglas propuestas constituyen un método original, sin ensayo ejecutado ni ganancia de resolución medida.