Logs con marca de tiempo y fáciles de analizar: RFC 5424 frente a RFC 3164, plantillas JSON y por qué usar UTC

Qué es

RFC 3164 describe el protocolo syslog BSD heredado, que muchos dispositivos siguen emitiendo. Define un mensaje como una parte PRI seguida de un HEADER y un MSG; su marca de tiempo no incluye año ni zona horaria, y su precisión es de un segundo. RFC 5424 lo reemplazó con un formato estructurado cuyo HEADER siempre contiene PRI, VERSION y un campo TIMESTAMP, definido como el NILVALUE - o bien FULL-DATE "T" FULL-TIME, derivado explícitamente de RFC 3339, que añade el año, las fracciones de segundo y un desfase de zona horaria explícito (o Z para UTC). El propio RFC 5424 afirma que la marca de tiempo descrita en RFC 3164 "offers less precision than the timestamp specified in this document" y "also lacks the year and time zone information" (ofrece menos precisión que la marca de tiempo especificada en este documento y tampoco contiene el año ni la zona horaria). Por eso los mensajes que pasan de un formato a otro requieren un tratamiento especial: convertir de 5424 a 3164 implica descartar el año y la zona, y convertir de 3164 a 5424 implica adivinar ambos.

rsyslog puede emitir cualquiera de los dos estilos con plantillas integradas (RSYSLOG_SyslogProtocol23Format para el estilo 5424 y RSYSLOG_TraditionalForwardFormat para el estilo 3164), o bien una estructura totalmente personalizada: una plantilla de tipo list con option.jsonf="on" y campos property(... format="jsonf") genera las propiedades seleccionadas, incluidas las marcas de tiempo, como un objeto JSON con el escape correcto. Para un analizador posterior o un agente, este objeto es mucho más fácil de consumir de forma fiable que el texto libre.

Por qué importa

Un agente o un script que busca con grep o analiza con expresiones regulares las marcas de tiempo de los logs necesita saber, sin adivinar, qué formato tiene delante, qué precisión ofrece y qué zona horaria se aplica. Una marca de tiempo de estilo 3164 no tiene año, así que un mensaje registrado en torno al Año Nuevo resulta realmente ambiguo de reconstruir meses después. Una marca de estilo 5424 con desfase explícito, o un campo JSON con una cadena ISO 8601/RFC 3339, elimina esa ambigüedad por construcción.

Cómo aplicarlo

• Dar preferencia a orígenes y reenviadores configurados para emitir RFC 5424 frente al RFC 3164 heredado, cuando se pueda elegir.
• Al crear una plantilla personalizada de rsyslog para un pipeline de análisis de logs, emitir las marcas de tiempo en formato RFC 3339 con una Z o un desfase explícitos, y considerar una plantilla basada en jsonf para que los límites entre campos sean inequívocos.
• Configurar la zona horaria de los servidores en UTC (timedatectl set-timezone UTC, como root), o al menos registrar un desfase UTC explícito en cada marca de tiempo, de modo que correlacionar eventos entre hosts de distintas zonas horarias locales no requiera ningún paso de conversión.
• Al analizar logs de terceros, detectar primero el formato (un año de 4 dígitos junto con un desfase o Z sugiere 5424/RFC 3339; un mes de 3 letras sin año sugiere 3164) en lugar de dar uno por supuesto.

Trampas

• Suponer que todos los mensajes "syslog" comparten un mismo formato de marca de tiempo; los dispositivos con RFC 3164 siguen siendo habituales en producción.
• Almacenar los logs en hora local sin desfase, lo que hace imposible ordenarlos correctamente a posteriori ante un cambio de horario de verano o en un despliegue multirregión.
• Eliminar los ceros iniciales de las fracciones de segundo al reformatear, algo que el apéndice A.4 de RFC 5424 califica de error de codificación muy común: .003 escrito como .3 convierte 3 ms en 300 ms.