Journaux horodatés et analysables : RFC 5424 contre RFC 3164, modèles JSON et intérêt de l'UTC

Ce que c'est

La RFC 3164 décrit l'ancien protocole syslog BSD, que de nombreux équipements émettent encore. Elle définit un message comme une partie PRI suivie d'un HEADER et d'un MSG ; son horodatage ne comporte ni année ni fuseau horaire, et sa précision est d'une seconde. La RFC 5424 l'a remplacée par un format structuré dont le HEADER contient toujours PRI, VERSION et un champ TIMESTAMP, défini soit comme la valeur nulle NILVALUE -, soit comme FULL-DATE "T" FULL-TIME, explicitement dérivé de la RFC 3339. Ce format ajoute l'année, les fractions de seconde et un décalage de fuseau horaire explicite (ou Z pour UTC). La RFC 5424 indique elle-même que l'horodatage décrit dans la RFC 3164 "offers less precision than the timestamp specified in this document" et "also lacks the year and time zone information". C'est précisément pour cela que les messages qui passent d'un format à l'autre exigent un traitement particulier : convertir du 5424 vers le 3164 revient à supprimer l'année et le fuseau, et convertir du 3164 vers le 5424 oblige à deviner les deux.

rsyslog peut produire l'un ou l'autre style grâce à des modèles intégrés (RSYSLOG_SyslogProtocol23Format pour le style 5424, RSYSLOG_TraditionalForwardFormat pour le style 3164), ou bien une structure entièrement personnalisée : un modèle de type list avec option.jsonf="on" et des champs property(... format="jsonf") restitue les propriétés choisies, horodatages compris, sous forme d'un objet JSON correctement échappé. Un analyseur en aval ou un agent le consomme de façon bien plus fiable que du texte libre.

Pourquoi c'est important

Un agent ou un script qui recherche les horodatages des journaux par grep ou par expression régulière doit savoir, sans deviner, à quel format il a affaire, quelle précision il porte et quel fuseau horaire s'applique. Un horodatage de style 3164 n'a pas d'année : un message journalisé autour du Nouvel An est donc réellement ambigu à reconstituer plusieurs mois plus tard. Un horodatage de style 5424 avec décalage explicite, ou un champ JSON contenant une chaîne ISO 8601/RFC 3339, lève cette ambiguïté par construction.

Comment l'appliquer

• Privilégier les sources et les relais configurés pour une sortie RFC 5424 plutôt que l'ancienne RFC 3164 lorsque le choix existe.
• Lors de la création d'un modèle rsyslog personnalisé pour une chaîne d'analyse de journaux, émettre les horodatages au format RFC 3339 avec un Z ou un décalage explicite, et envisager un modèle basé sur jsonf afin que les limites des champs soient sans équivoque.
• Régler le fuseau horaire des serveurs sur UTC (timedatectl set-timezone UTC, en root), ou au moins consigner un décalage UTC explicite dans chaque horodatage, afin que la corrélation d'événements entre des hôtes situés dans des fuseaux locaux différents ne nécessite aucune étape de conversion.
• Lors de l'analyse de journaux tiers, détecter d'abord le format (la présence d'une année à 4 chiffres et d'un décalage ou d'un Z suggère du 5424/RFC 3339 ; un mois en 3 lettres sans année suggère du 3164) plutôt que d'en supposer un.

Pièges

• Supposer que tous les messages « syslog » partagent un même format d'horodatage ; les équipements RFC 3164 sont encore courants sur le terrain.
• Stocker les journaux en heure locale sans décalage, ce qui rend impossible de les ordonner correctement après coup en cas de changement d'heure ou de déploiement multirégional.
• Supprimer les zéros initiaux des fractions de seconde lors d'une remise en forme, ce que l'annexe A.4 de la RFC 5424 qualifie d'erreur de codage très courante : .003 écrit .3 transforme 3 ms en 300 ms.