Resumen

  • qlog permite tiempos relativos al evento anterior, relojes de sistema o monotónicos y formatos distintos dentro de una traza; el orden numérico no equivale por sí solo a tiempo civil ni causalidad global.
  • Si el inicio de la captura, el ancla o un registro intermedio se pierde, una ventana conservada puede seguir pareciendo coherente mientras deja de responder cuándo empezó el incidente.
  • La correlación exige conservar ventana, reloj, error, punto de observación, identidad y política de omisión, además de comprobar el resultado en la aplicación.

El analista recibió una secuencia impecable: 5, 10, 10, 25. Sumó los intervalos, alineó la curva con una alerta de servicio y declaró que el evento decisivo había ocurrido cuarenta y cinco milisegundos después de iniciarse la conexión. Los cálculos eran correctos. El punto de partida no estaba en el archivo.

La captura usaba relative_to_previous_event, una de las representaciones temporales de qlog. El primer evento de una traza se mide contra el tiempo de referencia; los siguientes pueden guardar solo la diferencia respecto del valor anterior. En la ventana extraída, sin embargo, el “primer” registro era simplemente el más antiguo que el búfer aún conservaba. La secuencia describía distancias internas. No conservaba el origen histórico que el informe le atribuyó.

El caso no demuestra un defecto de qlog. Demuestra por qué el proyecto define el tiempo con más cuidado que muchos cuadros de mando. draft-ietf-quic-qlog-main-schema-14, publicado como borrador activo del grupo QUIC en julio de 2026, busca una estructura común para registros de protocolos. Todavía no es un RFC. Sus reglas permiten que herramientas distintas compartan eventos, pero no prometen que una captura haya empezado antes del hecho relevante ni que todos sus registros sobrevivan.

Hay más de una clase de “antes”

Todo evento qlog incluye un campo time, expresado como duración desde algún punto. El reloj de referencia puede ser de sistema o monotónico. El primero suele relacionarse con una época conocida, pero puede saltar hacia adelante o atrás. El segundo normalmente no retrocede, aunque su época debe figurar como desconocida. Puede añadirse una hora de pared aproximada al inicio, pero el borrador advierte que no debe usarse como conversión segura a tiempo de calendario.

El formato de cada evento puede ser relative_to_epoch o relative_to_previous_event. No existe el requisito de que todos los eventos de una traza usen el mismo formato. El orden debería ser creciente, pero los productores multihilo o en flujo pueden necesitar ordenar después. Las herramientas ni siquiera deberían asumir coherencia temporal entre trazas generadas por el mismo extremo.

Por ello conviene distinguir tres afirmaciones. “A aparece antes que B en la serialización” describe el archivo. “La marca reconstruida de A es menor que la de B bajo este reloj” describe una interpretación local. “A ocurrió antes que B en el incidente y pudo causarlo” exige correlación adicional. Una interfaz que muestra las tres como una sola línea de tiempo borra el salto probatorio.

La compresión hereda la integridad de la cadena

El delta respecto del evento anterior reduce caracteres y funciona bien para registradores con estado. Su economía tiene una consecuencia: cada interpretación depende de la cadena retenida. Si una herramienta extrae un segmento, si un proceso omite un evento o si un búfer circular sobreescribe el comienzo, debe conocer dónde reinicia la referencia y qué información se perdió.

No toda omisión rompe necesariamente la suma: el productor puede calcular el siguiente delta conforme a lo que realmente registró. Pero ese detalle refuerza, no elimina, el límite. La cronología reconstruida es la de los eventos registrados, no la de todos los acontecimientos del protocolo. Entre dos puntos separados por diez milisegundos pueden existir operaciones no capturadas, una decisión interna sin evento Base o un paquete excluido por política.

Los niveles Core, Base y Extra tampoco garantizan densidad uniforme. Las herramientas no deben esperar todos los eventos Core en cada traza. Por privacidad o rendimiento, una implementación puede sustituir eventos ricos por otros Base. La misma gráfica puede juntar productos con decisiones de instrumentación incompatibles.

Dos relojes locales no forman automáticamente uno global

qlog declara el punto de observación: cliente, servidor, red o desconocido. Para una captura de red también puede indicar cómo interpretar la dirección. Esa procedencia es indispensable porque un “paquete enviado” cambia de sentido según quién observa.

Supongamos que el cliente usa reloj monotónico, el servidor usa reloj de sistema y una sonda intermedia registra tiempo civil. El cliente ofrece orden estable sin época conocida. El servidor ofrece una fecha, pero su reloj pudo corregirse. La sonda ve tránsito, no decisiones internas. Alinear los tres por la primera forma parecida de paquete puede ser una hipótesis útil; no debe presentarse como una identidad garantizada.

La correlación necesita identificadores y márgenes: conexión o grupo, tupla cuando esté disponible, número de paquete, dirección, ventana de captura, incertidumbre de reloj y política de anonimización. Incluso entonces, que dos sucesos coincidan temporalmente no basta para probar causalidad. El campo opcional trigger, cuando un evento concreto lo define y registra, ofrece una atribución más fuerte que la mera vecindad.

Un archivo válido puede reconocer su propia parcialidad

El borrador recomienda que las herramientas avisen con claridad cuando un archivo no contiene información compatible suficiente para ejecutar su lógica. También les pide tolerar campos desconocidos y ser útiles ante registros incompletos. Cita expresamente dos causas: un búfer circular puede sobrescribir los eventos iniciales y algunos eventos pueden omitirse por privacidad o tamaño.

La madurez del análisis se mide entonces por el modo de presentar límites. En vez de fabricar una hora absoluta, una herramienta puede mostrar “orden local conservado; ancla civil no fiable”. En vez de unir dos líneas, puede ofrecer un corredor de incertidumbre. En vez de llamar al primer registro “inicio de conexión”, puede llamarlo “primer registro retenido”.

Estas etiquetas no son ornamentos. Cambian decisiones. Una contención ejecutada porque A supuestamente precedió a B puede ser injustificada si el margen de reloj supera la separación. Un compromiso contractual basado en “tiempo hasta recuperación” carece de sentido si la captura empezó después del fallo. Un modelo de detección entrenado con ventanas sin comienzo aprende una topología temporal falsa.

El expediente temporal que falta

Una operación que quiera usar qlog para investigar debe conservar junto a cada traza: tipo y procedencia del reloj; valor de referencia; formato temporal por evento o campos comunes; precisión y error estimado; cambios de reloj detectados; momento y motivo de inicio y fin; estado de búfer; conteos de eventos emitidos, descartados y exportados; transformaciones posteriores; y reglas usadas para correlacionar otras fuentes.

Después debe unir la cronología a un resultado. Un paquete enviado no demuestra entrega a la aplicación. Un cierre registrado no demuestra que el usuario recibiera respuesta. Una ráfaga cercana a una alerta no demuestra que la causó. El nivel final necesita métricas de la aplicación, evidencia del par o verificación independiente.

qlog permite representar el tiempo sin imponer una ficción de omnisciencia. La responsabilidad local consiste en conservar las condiciones bajo las que ese tiempo puede leerse. Cuando esas condiciones faltan, la respuesta profesional no es ajustar la gráfica hasta que coincida. Es reducir la afirmación hasta el tamaño de la evidencia.

Fuentes