Résumé

  • RFC 3164 limite le paquet syslog historique complet à 1 024 octets et demande au relais d’ajouter une date manquante, avec un nom d’hôte recommandé.
  • Si ces champs font dépasser la limite, le relais doit tronquer le paquet ; le RFC avertit que des informations importantes situées à la fin du message d’origine peuvent disparaître.

La date ajoutée consomme le budget du message

Imaginons un équipement qui envoie un paquet syslog presque plein, sans horodatage exploitable. Le relais vérifie la priorité PRI avant retransmission. Selon la section 4.3.2 de RFC 3164, il doit insérer son heure locale courante après PRI et devrait aussi ajouter le nom d’hôte s’il peut le déterminer. Le reste du contenu reçu devient le CONTENT du message.

Ce complément n’est pas gratuit. La section 4.1 limite le paquet entier, pas seulement le texte de l’événement : PRI, HEADER et MSG partagent 1 024 octets. Si la date, le nom et leurs séparateurs font dépasser la limite, le relais doit vérifier la longueur puis ramener le paquet à 1 024 octets. Le RFC précise que des informations vitales à la fin du paquet original peuvent ainsi être perdues.

Le paquet peut pourtant rester reconnaissable. Le collecteur voit une PRI et un en-tête correctement formé, alors que les derniers octets de l’événement — une précision après « parce que », un résultat de commande, un identifiant d’équipement ou une valeur de diagnostic — ont peut-être disparu. Ce sont des scénarios possibles, pas des incidents allégués. La règle expose la fin du message lorsque l’enrichissement fait dépasser la limite commune.

Une règle normative, pas un recensement des implémentations

RFC 3164 est un mémo Informational d’août 2001 décrivant le protocole BSD syslog ; il ne prouve pas que tous les relais ont appliqué la règle. La section 4.2 accepte tout message syslog valide dans le contenu UDP destiné au port 514 et recommande que l’émetteur fournisse PRI, HEADER et MSG afin d’éviter la modification par le relais. La section 6.1 demande aux récepteurs de ne pas dysfonctionner au-delà de 1 024 octets et décrit des comportements différents. Aucune ne mesure la fréquence des messages longs, des troncations ou la conservation par les collecteurs.

Cette limite applicative ne se confond pas avec le MTU du chemin. Fragmentation IP, traitement UDP et troncation par l’application sont des mécanismes distincts. De même, la date ajoutée correspond à l’heure locale du relais, pas nécessairement à l’heure de l’événement ; son nom d’hôte est celui que le relais connaît, ou l’adresse IP, et n’est pas authentifié par le RFC.

Les formats ultérieurs éclairent la limite sans prouver la migration

RFC 5424 remplace RFC 3164 avec un en-tête plus explicite et des données structurées. RFC 6587 décrit le cadrage TCP et note que la longueur historique de 1 024 octets a été élargie pour le syslog normalisé. RFC 3195 mesure autrement : son profil RAW limite le corps d’un événement à 1 024 octets, hors surcharge du cadrage BEEP. Ces comparaisons montrent que la même valeur peut s’appliquer à des couches différentes ; elles ne prouvent pas que les anciens équipements ont disparu.

L’enseignement historique est précis : en ajoutant du contexte, un relais peut consommer le budget partagé avec le contenu transporté. Réception, analyse syntaxique ou archivage réussi ne prouvent pas que tous les octets d’origine ont survécu. Il faut comparer les octets de la source, les entrées et sorties de chaque relais, puis l’analyse et la relecture côté collecteur.

Sources