Les (petits) secrets du syslog d’ESXi 5.0 (aka vmsyslogd)
Posted by NiTRo | Filed under HowTo, Kb, Tips & Tricks, VMware
Alors que la dernière mouture de note hyperviseur préféré essuie ses premiers plâtres coté stockage avec un bug VAAI (kb 2007427) et un autre sur l’iSCSI software (kb 2007108), nous avons déniché un workaround à un autre problème (concernant le nouveau syslog d’ESXi) pour lequel la solution préconisé par VMware est un reboot. Pas très datacenter-friendly, vous en conviendrez.
Le problème en question concerne l’arrêt du daemon vmsyslogd lorsque le datastore désigné pour accueillir les logs n’est pas accessible (ou a été indisponible trop longtemps). La kb 2003470 fait état du problème lorsque l’ESXi est en boot from SAN mais le problème est identique lorsque le paramètre Syslog.global.logDir pointe vers un datastore NFS qui serait indisponible lors d’une coupure réseau.
Ce problème est d’autant plus fâcheux (mais en même temps évident) que c’est ce même daemon qui transmet les messages au Syslog.global.logHost, ce qui signifie que si vous devez troubleshooter un effet de bord suite à une coupure réseau ou SAN trop longue et que vous redirigiez les logs sur un datastore “remote”, vous n’avez plus de logs pour le faire. Et VMware voudrait vous faire rebooter rien que pour ça !
Heureusement, le reboot peut être facilement évité en faisant un reload du daemon ou (si le process à été tué ou si le watchdog n’a pas réussi à relancer le process) en lançant manuellement le daemon (le reload génère une erreur lorsque le process ne tourne plus) :
esxcli system syslog reload
/usr/lib/vmware/vmsyslog/bin/vmsyslogd
Un petit détail en passant, sur la version embedded d’ESXi 5.0 le daemon syslog n’est pas configuré (/scratch/log par défaut) si la partition scratch est absente :
Autre petit détail intéressant, contrairement aux précédentes versions d’ESXi, vous pouvez maintenant utiliser le même chemin pour tous vos ESXi et activer le paramètre Syslog.global.logDirUnique qui créera automatiquement un sous répertoire au nom FQDN du serveur pour y placer les logs.
Dernier point qui a également son importance, le “format syslog” d’ESXi est nettement mieux respecté dans cette nouvelle version ce qui permet d’améliorer le filtrage lorsqu’on redirige vers une plateforme type rsyslog+loganalyzer :
Tags: syslog