Protocoles, formats et trames des messages Syslog ESXi

À partir de ESXi 8.0, le service Syslog utilise trois paramètres pour définir les messages et les enregistrements d'audit : protocole, formatage et trame.

Les protocoles pris en charge sont UDP, TCP et TLS (SSL). La mise en forme des messages Syslog est définie par RFC 3164 ou RFC 5424. La trame spécifie la façon dont un message est encapsulé. La trame des messages encapsulés est définie comme transparente, également appelée octet_counting, ou non transparente si un message n'est pas encapsulé. Une trame transparente garantit que les nouvelles lignes intégrées dans un message ne soient pas confondues par un collecteur syslog. Les messages syslog envoyés à l'aide du protocole UDP sont considérés comme transparents. Un collecteur syslog doit comprendre cela et accepter la transmission sous la forme d'un message unique.

La norme RFC 3164 définit la longueur totale maximale d'un message syslog sur 1024 octets tandis que la norme RFC 5424 étend cette longueur maximale à 2048 octets.

La longueur maximale par défaut des messages de l'hôte distant dans ESXi est de 1 Kio. Vous pouvez augmenter la longueur maximale du message jusqu'à 16 Kio. Cependant, l'augmentation de cette valeur au-dessus de 1 Kio ne garantit pas que les transmissions longues parviennent non tronquées à un collecteur Syslog. Par exemple, lorsque l'infrastructure Syslog qui émet un message est externe à ESXi.

Les messages syslog transmis par vmsyslogd se composent de données structurées, d'une liste de propriétés formatée conformément à la norme RFC 5424 et de données au format libre ou non structurées.

Lorsqu'un message dépasse la longueur maximale, ESXi 8.0 limite le message en essayant de conserver autant de données structurées que possible.

Lorsqu'un message est atténué, trois paramètres sont ajoutés aux données structurées existantes ou des données structurées sont créées pour contenir ces paramètres : msgModified, remoteHostMaxMsgLen et originalLen.

Le paramètre msgModified indique l'impact de l'atténuation sur le message : données structurées uniquement, données non structurées uniquement ou les deux.

Le paramètre remoteHostMaxMsgLen spécifie la longueur maximale du message que ESXi peut gérer.

Le paramètre originalLen spécifie la longueur du message avant d'être atténué.

Options prises en charge pour les protocoles, le formatage et les trames des messages syslog d'ESXi :

Formatage	Trame	UDP	TCP	SSL	Commentaires
Non spécifié	Non spécifié	Pris en charge RFC 5426	Pris en charge	Pris en charge	La mise en forme des messages est conforme à la norme RFC 3164. Seuls les horodatages sont au format RFC 3339. Les données structurées sont ajoutées à chaque e-mail. Les trames sont non transparentes par défaut avec TCP ou SSL (TLS) et les nouvelles lignes intégrées dans les données structurées peuvent corrompre les messages. Pour UDP, les paquets utilisent les trames.
Non spécifié	Non_transparent	Interdit	Pris en charge	Pris en charge	La mise en forme des messages est conforme à la norme RFC 3164. Seuls les horodatages sont au format RFC 3339. Les données structurées sont ajoutées à chaque e-mail. Les trames sont non transparentes par défaut avec TCP ou SSL (TLS) et les nouvelles lignes intégrées dans les données structurées peuvent corrompre les messages.
Non spécifié	Octet_counting	Interdit	Pris en charge RFC 6587	Pris en charge RFC 6587	La mise en forme des messages est conforme à la norme RFC 3164. Seuls les horodatages sont au format RFC 3339. Les données structurées sont ajoutées à chaque e-mail.
RFC 5424	Non spécifié	Pris en charge RFC 5426	Pris en charge RFC 5425	Pris en charge RFC 5424	La mise en forme des messages est conforme à la norme RFC 5424. Les trames sont définies sur octet_counting par défaut avec TCP ou SSL (TLS). Avec UDP, les trames peuvent ne pas être explicitement spécifiées.
RFC 5424	Non_transparent	Interdit	Non pris en charge	Non pris en charge	Non pris en charge, car les nouvelles lignes intégrées dans les données structurées peuvent créer des messages corrompus.
RFC 5424	Octet_counting	Interdit	Pris en charge RFC 5425	Pris en charge RFC 5425	La mise en forme des messages est conforme à la norme RFC 5424.
RFC 3164	Non spécifié	Pris en charge RFC 5426	Pris en charge	Pris en charge	La mise en forme des messages est conforme à la norme RFC 3164. Seuls les horodatages sont au format RFC 3339. Les données structurées sont ajoutées à chaque e-mail. Les trames sont non transparentes par défaut avec TCP ou SSL (TLS) et les nouvelles lignes intégrées dans les données structurées peuvent corrompre les messages. Pour UDP, les paquets utilisent les trames.
RFC 3164	Non_transparent	Interdit	Pris en charge	Pris en charge	La mise en forme des messages est conforme à la norme RFC 3164. Seuls les horodatages sont au format RFC 3339. Les données structurées sont ajoutées à chaque e-mail. Les trames sont non transparentes par défaut avec TCP ou SSL (TLS) et les nouvelles lignes intégrées dans les données structurées peuvent corrompre les messages.
RFC 3164	Octet_counting	Interdit	Pris en charge RFC 6587	Pris en charge RFC 6587	La mise en forme des messages est conforme à la norme RFC 3164. Seuls les horodatages sont au format RFC 3339. Les données structurées sont ajoutées à chaque e-mail.