Nous vous recommandons donc vivement de vous rendre sur sexilog.fr pour y télécharger la dernière version de l’appliance et la déployer sur votre infra, envoyer vos logs ESXi dessus et profitez des dashboards intégrés

Rock n’ Log!

Ah tiens, on a oublié de parler de Splunk.

Et voici le oneliner PowerCLI pour le faire vite et bien :

Get-View -ViewType HostSystem|?{$_.Runtime.ConnectionState -eq "connected" -and $_.config.product.ProductLineId -eq "embeddedEsx" -and ($_.Config.Option|?{$_.Key -eq "Misc.SIOControlLogLevel"}).Value -ne "1"}|%{(Get-View $_.ConfigManager.AdvancedOption).UpdateOptions((New-Object VMware.Vim.OptionValue -Property @{Key="Misc.SIOControlLogLevel";Value=[Int64]1}))}

Que ce soit pour créer de nouvelles alarmes dans le vCenter ou parce que certains messages d’alerte ne sont visible que dans les logs d’ESXi, nous avions autrefois recours à la page vCenter Events de Veeam pour trouver l’inspiration. Cette page n’étant plus mise à jour depuis fin 2011, nous avons chercher à produire un page similaire pour nos propres besoins et l’avons, depuis quelques temps, mise à dispo dans la rubrique “Links”. Voici la commande PowerCLI qui vous permettra de générer la votre depuis votre vCenter (et plugins) :

(Get-View EventManager).Description.EventInfo|select @{n="event";e={if ($_.key -match "^EventEx$|^ExtendedEvent$") {$_.FullFormat.split("|")[0]} else {$_.key}}},category,description,FullFormat|Out-GridView

Nous nous sommes très largement inspiré d’un post de Luc pour ce oneliner

Récemment, William à posté une liste similaire issue d’un fichier disponible en clair dans les librairies d’ESXi mais nous avons remarqué qu’il ne contenait pas les événements vob.* que nous pouvions trouver dans les logs. Après quelques recherches, nous avons fini par faire un coup de strings sur le binaire /usr/lib/vmware/vob/bin/vobd (issue d’un ESXi 5.5 1331820) pour en extraire les précieux messages. Nous avons ensuite “dédoublonné” la liste obtenue (vob.vmfs.heartbeat.timedout == esx.problem.vmfs.heartbeat.timedout par exemple) pour ne garder que le différentiel :

vob.net.fence.port.fail
vob.net.pg.uplink.transition.down
vob.net.pg.uplink.transition.up
vob.net.dvport.uplink.transition.down
vob.net.dvport.uplink.transition.up
vob.net.uplink.watchdog.timeout
vob.net.migrate.bindtovmk.failed
vob.net.portset.port.connect.fail
vob.net.lacp.uplink.peer.noresponse
vob.scsi.scsipath.add
vob.scsi.scsipath.remove
vob.scsi.scsipath.por
vob.scsi.scsipath.badpath.unsafepe
vob.scsi.scsipath.badpath.unreachpe
vob.scsi.scsipath.pathstate.dead
vob.scsi.scsipath.pathstate.off
vob.scsi.scsipath.pathstate.on
vob.scsi.scsipath.pathstate.standby
vob.iscsi.connection.started
vob.iscsi.connection.stopped
vob.iscsi.connection.error
vob.iscsi.target.async.event
vob.iscsi.session.recovery.timeout
vob.iscsi.target.permanently.removed
vob.iscsi.isns.discovery.error
vob.vmfs.lock.corruptondisk.v2
vob.user.dcui.factory.network.restored
vob.user.dcui.restarting.hostagents
vob.user.dcui.restore.factory.defaults
vob.user.dhclient.lease.offered.noexpiry
vob.user.coredump.unconfigured2
vob.user.coredump.capacity.insufficient
vob.user.scratch.partition.size.small
vob.user.scratch.partition.unconfigured
vob.user.dcui.reboot.host
vob.user.dcui.shutdown.host
vob.user.esxcli.host.reboot
vob.user.coredump.configured2
vob.cpu.mce.log
vob.cpu.nmi.ipi.vmkcs
vob.cpu.nmi.ipi.unknowncs
vob.cpu.nmi.ipi.halt
vob.cpu.nmi.ipi.savebt
vob.uw.core.dumped
vob.external.warning
vob.external.error
vob.external.info
vob.user.external.warning
vob.user.external.error
vob.user.external.info
vob.visorfs.tardisk.readonlyfile
vob.vsan.pdl.offline
vob.vsan.pdl.online
vob.vsan.net.gotip
vob.vsan.net.noip
vob.vsan.rdt.noip
vob.vsan.net.no.connectivity
vob.vsan.net.created
vob.vsan.net.reconfigured
vob.vsan.cmmds.disabled
vob.vsan.cmmds.unloaded
vob.vsan.cmmds.enabled
vob.vsan.lsom.diskerror

Pour les curieux, voici la liste originale.

La seule référence que nous ayons pu trouver à ce sujet est une kb d’un path pour ESXi 5.0, dommage.

En passant, nous vous rappelons qu’il est possible de rediriger le log d’une VM vers le syslog d’ESXi pour vous éviter de fouiller dans le fichier vmware.log et c’est bien sûr faisable à chaud en PowerCLI (comme d’hab, vmotion pour appliquer le setting) :

Get-VM toto|Get-View|?{-not $_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="vmx.log.destination"; Value="syslog-and-disk"}))}))}

Après on peut faire des belles requêtes dans son Graylog2 :

Un grand merci à William pour cette pépite.

su - -c 'cd /usr/share/graylog2-web;rake RAILS_ENV=production streamalarms:send>>/var/log/graylog.log'
su - -c 'cd /usr/share/graylog2-web;rake RAILS_ENV=production subscriptions:send>>/var/log/graylog.log'

Ceux qui connaissent Graylog2 savent à quel point c’est un serveur syslog surpuissant mais pas vraiment simple à installer. De plus, ceux qui s’en servent pour des ESXi ont eu la douloureuse surprise de constater que graylog2 ne supportait pas le format syslog d’ESXi 5.x alors que celui de 4.x était parfaitement géré. Nous allons donc faire d’une pierre deux coups.

En ce qui concerne la simplicité, Mick Pollard a posté cet été comment utiliser ses packages sur un Ubuntu 12.04, ce à quoi nous ajouterons des morceaux d’un autre how-to pour faire tourner l’interface web de graylog2 sous apache.

Et pour la compatibilité, nous configurerons graylog2 pour écouter sur un port “alternatif” (10514 dans notre exemple) car le port 514 sera pour rsyslog qui réécrira tout ce qui passe au bon format et le forwardera (non, ce mot n’existe pas) à graylog2. Attention ca va aller très vite :

echo 'deb http://ppa.lunix.com.au/ubuntu/ precise main' | sudo tee /etc/apt/sources.list.d/aussielunix.list
apt-key adv --keyserver keyserver.ubuntu.com --recv D77A4DCC
apt-get update
apt-get install mongodb elasticsearch graylog2-server graylog2-web apache2 libapache2-mod-passenger

Vous pouvez aller boire un café, ya ~500Mo à downloader/installer. Ensuite il faut configurer quelques trucs :

/etc/graylog2.conf
syslog_listen_port = 10514

/etc/rsyslog.conf
$ModLoad immark
$ModLoad imudp
$UDPServerRun 514
$ModLoad imtcp
$InputTCPServerRun 514

/etc/rsyslog.d/50-default.conf
#*.*;auth,authpriv.none -/var/log/syslog

/etc/apache2/sites-available/default

<VirtualHost *:80>
    DocumentRoot /usr/share/graylog2-web/public/
        RailsEnv 'production'
    <Directory /usr/share/graylog2-web/public/>
        Allow from all
        Options -MultiViews
    </Directory>

    ErrorLog /var/log/apache2/error.log
    LogLevel warn
    CustomLog /var/log/apache2/access.log combined
</VirtualHost>

/etc/rsyslog.d/32-graylog2.conf

$template GRAYLOG2,"<%PRI%>1 %timegenerated:::date-rfc3339% %HOSTNAME% %syslogtag% - %APP-NAME%: %msg:::drop-last-lf%\n"
$ActionForwardDefaultTemplate GRAYLOG2
$PreserveFQDN on
*.*     @localhost:10514

/etc/security/limits.conf
root – nofile 64000
root – memlock unlimited

/etc/pam.d/su
session required pam_limits.so

Après, on secoue bien :

service elasticsearch start
service mongodb restart
service graylog2-server start
service rsyslog restart
service apache2 restart

Selon le formatage des messages, il est parfois nécessaire d’avoir un reverse DNS pour que le hostname remonte bien (au lieu de l’ip). Sur le screenshot suivant vous pourrez constater la présence de log provenant d’ESXi 5, de pfSense et d’Astaro/UTM mais nous avons pu également valider que cette solution était fonctionnelle pour ESXi 4, FreeNAS, NTsyslog, Snare/Epilog et nxlog.

On vous laisse découvrir les joyeusetés des streams et des analytics de Graylog2

Plutôt que de monter une usine à gaz comme notre ami William (qui ne semble pas porter windows dans son coeur – just kidding William ), nous avons fait le tour des agents capables de forwarder des fichiers log vers du syslog, gratos évidement. Le plus satisfaisant semble être Epilog for Windows qui reconnait par défaut plusieurs formats de log (IIS, Exchange, Apache, etc…) et qui dispose même de sa propre interface web (comme tous les agents snare) :

Nous avons toute fois du faire face à un petit problème concernant le patern de fichier à fournir à Epilog car “vpxd-*.log” correspond à plusieurs types de log dans le répertoire logs du vcenter (vpxd-, vpxd-alert- et vpxd-profiler-) et, contrairement à linux, il n’existe pas de fichier vpxd.log pour simplifier la chose. Heureusement, VMware semble avoir quand même prévu le coup car il est possible de changer le prefix du log en rajoutant une ligne dans le vpxd.cfg (nous avons choisi “vpxdsvc”) :

<name>vpxdsvc</name>

Il suffit ensuite de configurer le serveur de destination et de sélectionner le format syslog :

On obtient alors quelque chose de pas trop mal dans notre appliance Graylog2 (Partylog2) de test (pour celui de prod nous nous sommes inspiré de ce howto sans oublier le trick pour le “too many open files”) :

]]> http://www.hypervisor.fr/?feed=rss2&p=3997 4 http://www.hypervisor.fr/?p=3387 http://www.hypervisor.fr/?p=3387#comments Sun, 16 Oct 2011 00:22:51 +0000 NiTRo http://www.hypervisor.fr/?p=3387 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 :

]]> http://www.hypervisor.fr/?feed=rss2&p=3387 0