Resumen

  • timeQuality permite que el origen describa su conocimiento de zona horaria, sincronización y posible desfase; el receptor no obtiene con ello una medición independiente.
  • syncAccuracy es el máximo desfase que el emisor espera entre sincronizaciones, por lo que depende de la fuente de tiempo y de una configuración operativa que debe poder justificarse.

UTC no responde por el reloj de origen

Los equipos de respuesta suelen normalizar los registros para compararlos en una misma línea temporal. Expresar un evento en UTC ayuda a evitar una conversión, pero no demuestra que el reloj del host estuviera bien configurado. Tampoco demuestra que el emisor supiera cuál era su zona horaria local. RFC 5424 conserva esa distinción con timeQuality: un bloque opcional de datos estructurados donde el origen puede describir su propia lectura del tiempo del sistema.

La sección 6.2.3 define TIMESTAMP mediante una forma restringida de RFC 3339 y recomienda fracciones de segundo cuando la precisión y el rendimiento del reloj lo permiten. La sección 7.1 añade otra capa: qué condiciones declara el originador sobre el tiempo que ha escrito. No es una segunda marca horaria ni una firma de veracidad. Es contexto producido por el mismo sistema cuya hora se interpreta.

La sección 7.1 recomienda incluir timeQuality cuando el origen no está correctamente sincronizado con una fuente externa fiable o no sabe si la información de zona horaria es correcta. Sus parámetros siguen siendo opcionales: el emisor puede señalar una limitación sin tener que completar cada detalle.

Por eso conviene separar dos preguntas que suelen mezclarse: cómo se representa el instante y qué sabe el emisor sobre la calidad de su reloj.

Zona conocida, sincronización y tolerancia

tzKnown responde si el originador conoce la información de zona horaria que usa. La respuesta no se deduce del sufijo UTC. RFC 5424 dice que la zona puede ser conocida aun cuando la marca esté expresada en UTC, y su apéndice A.7 aconseja declarar ese conocimiento con prudencia, apoyándolo en configuración o comprobación del administrador.

isSynced indica si el emisor considera que su reloj está sincronizado con una fuente externa fiable, por ejemplo NTP. El protocolo transporta el valor, pero no realiza una consulta a esa fuente cuando un colector recibe el mensaje. En consecuencia, el campo acredita una declaración del origen, no una observación realizada por la infraestructura receptora.

syncAccuracy expresa en microsegundos el máximo desfase que el originador cree posible entre intervalos de sincronización. Es un entero y no debe acompañar a isSynced="0". El ejemplo normativo emplea 60 000 000 microsegundos: un minuto. Para un evento marcado a las 09:00, ilustra un intervalo posible de 08:59 a 09:01. No presenta una medición externa del error; muestra cómo interpretar la expectativa declarada.

RFC 5424 recomienda incluir la cifra solo si el emisor conoce la fiabilidad de su fuente de tiempo. El apéndice indica que esa información suele proceder de la configuración del operador y advierte que una cifra sin base puede dar una impresión falsa de precisión. Hay además una regla para el receptor: si isSynced="1" está presente y falta syncAccuracy, un colector o retransmisor puede asumir que la hora es suficientemente exacta para considerarla correcta. La regla no elimina la dependencia de la configuración que originó el valor.

La cadena de observabilidad también forma parte de la evidencia

El registro de parámetros Syslog de IANA clasifica estos cuatro elementos como opcionales. Por tanto, una plataforma de análisis debe admitir que algunos mensajes no los incluyan. La ausencia no demuestra que la hora sea incorrecta; significa que el registro aporta menos información explícita para valorar su fiabilidad.

La decisión importante en una canalización es conservar el bloque junto con la marca temporal. Si un proceso de normalización guarda el instante pero descarta timeQuality, una consulta posterior puede mostrar precisión decimal sin mostrar las condiciones que la acompañaban. Si el bloque sobrevive, todavía hace falta relacionarlo con la configuración y la supervisión del origen durante el periodo relevante.

RFC 8633, las mejores prácticas actuales para NTP, recomienda supervisar las fuentes y las instancias NTP y detectar servidores fuera de sincronía. Esa recomendación ofrece una forma de corroborar la operación; no prueba cómo trabaja un emisor concreto. Los documentos consultados tampoco permiten afirmar una tasa de despliegue, una frecuencia de errores o una práctica de proveedor.

Qué prueba el campo y qué queda fuera

timeQuality aporta evidencia sobre lo que el origen declaraba respecto de su hora. Permite que el receptor trate con cuidado los registros que llevan una advertencia de calidad y mantenga visible la incertidumbre. No autentica el evento, no resuelve por sí solo el orden causal entre sistemas y no convierte una afirmación en una medición.

La nota de Heng Lu sobre la primacía del código en ejecución aporta aquí una lente editorial acotada: las etiquetas escritas no sustituyen lo que un sistema desplegado verifica y ejecuta. RFC 5424 define el formato de la declaración; su base real está en la configuración y monitorización del emisor. El colector puede preservar esa diferencia, pero no puede repararla si el origen nunca la estableció.

Fuentes