Résumé

  • Le bloc facultatif timeQuality décrit l’appréciation de l’émetteur sur son fuseau, sa synchronisation et son décalage possible ; il ne vérifie pas l’horloge.
  • syncAccuracy exprime une limite attendue entre deux synchronisations. Sa crédibilité dépend du service de temps et des réglages que l’opérateur maîtrise.

Une date bien formée ne raconte pas son histoire

Dans un dossier d’incident, les journaux arrivent souvent par des chemins différents et se retrouvent alignés dans un même outil. Le format peut rendre leurs horodatages comparables en apparence. Il ne dit pas, à lui seul, si chaque machine connaissait son fuseau, si elle suivait une source fiable ou si quelqu’un surveillait cette source. La section timeQuality de RFC 5424 sert à conserver cette part de contexte au côté du message.

La norme sépare la représentation de l’heure de la description de son niveau de confiance. En § 6.2.3, elle définit un TIMESTAMP fondé sur une forme restreinte de RFC 3339 et recommande les fractions de seconde lorsque la précision de l’horloge et les performances le permettent. En § 7.1, elle autorise un élément de données structurées qui décrit la notion que l’émetteur a de l’heure système. Le terme désigne un état déclaré par la source, non une vérification du collecteur.

La section 7.1 recommande d’écrire timeQuality lorsque l’émetteur n’est pas correctement synchronisé avec une source externe fiable ou ignore si ses informations de fuseau sont exactes. Les paramètres de l’élément restent facultatifs : l’émetteur peut signaler une limite sans devoir remplir chaque détail.

Cette différence est le cœur du sujet. Le message peut transporter une affirmation utile sur les conditions de son horodatage ; son arrivée ne transforme pas cette affirmation en mesure indépendante.

Le fuseau et la synchronisation ne sont pas la même information

tzKnown répond à une question précise : l’émetteur connaît-il le fuseau qu’il associe à son heure ? Il ne s’agit pas de savoir si l’horodatage est écrit en UTC. RFC 5424 indique qu’un fuseau peut être connu même lorsque le suffixe utilisé est Z. L’annexe A.7 recommande une déclaration prudente et cite la configuration ou la vérification par l’administrateur comme base possible avant d’affirmer que le fuseau est connu.

isSynced indique si la machine se considère synchronisée sur une source externe fiable, par exemple NTP. Le parseur du collecteur ne contacte pas cette source en lisant le champ : la valeur vient de l’émetteur. La télémétrie qui a motivé cette valeur doit donc exister ailleurs, dans l’exploitation de la machine.

syncAccuracy va plus loin, mais uniquement dans les limites de ce que l’émetteur sait. La valeur est un entier en microsecondes qui exprime l’écart maximal auquel l’origine estime que son horloge peut être exposée entre deux intervalles de synchronisation. Elle ne doit pas apparaître avec isSynced="0". L’exemple de RFC 5424 retient 60 000 000 microsecondes, soit une minute, pour montrer qu’une heure de 09 h peut couvrir l’intervalle 08 h 59–09 h 01. Ce calcul illustre l’interprétation de l’affirmation émise ; il ne provient pas d’un laboratoire qui aurait mesuré la machine.

La norme réserve cette valeur aux cas où l’émetteur connaît la fiabilité de sa source de temps. Son annexe explique que cette connaissance relève généralement de la configuration opérateur et met en garde contre une précision trompeuse. Si isSynced="1" est présent sans syncAccuracy, un collecteur ou un relais peut supposer que l’heure est assez exacte pour être considérée correcte. Cette règle d’interprétation ne prouve pas la santé de la source.

Conserver le contexte jusqu’à l’analyse

Le registre IANA des paramètres Syslog marque timeQuality, tzKnown, isSynced et syncAccuracy comme facultatifs. Un pipeline doit donc gérer les messages avec ou sans ces paramètres. Leur absence n’établit pas une erreur d’horloge, mais limite les informations disponibles pour juger l’horodatage.

Le risque apparaît lorsqu’une normalisation conserve l’instant tout en supprimant les données structurées qui l’accompagnaient. Un analyste ultérieur peut alors attribuer une précision excessive à une valeur dont la réserve a disparu. À l’inverse, préserver le bloc ne suffit pas : il faut pouvoir identifier l’émetteur et retrouver la configuration et la surveillance qui ont étayé son affirmation pendant la période considérée.

RFC 8633 recommande de surveiller les sources de temps et les instances NTP, et de détecter les serveurs désynchronisés. C’est un complément opérationnel, pas une preuve que telle installation applique correctement ces recommandations. Les sources examinées ne donnent ni taux d’adoption ni mesure des erreurs en production.

Lire une déclaration comme une déclaration

timeQuality est un élément de preuve sur l’état que l’émetteur attribue à son horloge. Il aide un récepteur à distinguer une valeur accompagnée d’un contexte d’une valeur sans contexte. Il ne prouve ni l’authenticité de l’événement, ni son ordre causal à travers plusieurs systèmes, ni la véracité de l’état déclaré.

La note de Heng Lu sur la primauté du code en fonctionnement fournit ici un angle éditorial limité : un libellé écrit ne remplace pas ce que les systèmes déployés exécutent et vérifient. La RFC spécifie le langage du rapport ; sa base opérationnelle reste la configuration et la surveillance de l’émetteur. Le collecteur peut préserver cette réserve, mais il ne peut pas la créer après coup.

Sources