Rediriger les logs d’ESX/ESXi vers un serveur syslog – MAJ
Posted by NiTRo | Filed under Tips & Tricks, VMware
MAJ 16/10/2011 : php-syslog-ng (aka logzilla) étant devenu payant, nous vous recommandons maintenant rsyslog + loganalyzer
Thomas Ackerson de mainesysadmin.com à posté sur son blog un article pour configurer le syslog d’ESX et permettre de regrouper les logs de tous vos ESX vers un serveur syslog.
C’est evidement la meme méthode que pour un syslog standard puisque la COS d’ESX est une RHEL 3 :
- vi /etc/syslog.conf
- *.* @syslog.domaine.com à ajouter à la fin du fichier
- esxcfg-firewall -o 514,udp,out,syslog pour ouvrir le firewall
- esxcfg-firewall -l pour relancer le firewall
- service syslog restart pour relancer le service syslog
Pour ESXi c’est encore plus simple, il suffit d’aller dans les Advanced Settings du serveur (ou d’utiliser la commande powershell Set-VMHostSysLogServer du VI Toolkit) :
Avec syslog-ng et php-syslog-ng, on obtient un outil indispensable :
Tags: ESX, ESXi, Tips & Tricks
Loading ...
February 14th, 2009 at 6:29
Comme dit, un outil indispensable pour administrer et suivre une batterie ESX/ESXi serveurs. A mes favoris… -:)
February 14th, 2009 at 13:50
Et surtout, j’ai remarqué que générallement lorsque le service aam ou vpx ne répond pas, le service syslog continue à envoyer les logs. parfait pour le troubleshooting
September 28th, 2010 at 19:02
Bonjour,
Je me permet de ressortir ce sujet car j’aimerais savoir comment rediriger les logs de mon serveur ESXi vers un serveur de log installé sur une des machines virtuelles hébergés dans ESXi lui-même.
Merci d’avance.
September 28th, 2010 at 19:11
En fait le problème est plus simple que ça.
La question pourrait se résumer à :
Comment pinger l’IP d’une machine hebergée dans un serveur ESXi depuis la console du serveur ESXi ?
Ou alors :
Comment router de ESXi vers une machine hébergée dans ESXi ?
September 28th, 2010 at 20:03
Soit votre VM est dans le même subnet que votre ESXi donc se passera au niveau du vswitch (si VM et vmk sur le même vswitch), soit le traffic de votre VM sera routé à l’extérieur de votre ESXi par votre réseau et acheminé jusqu’à l’ip de management de l’ESXi.
September 28th, 2010 at 20:21
Bonjour, je n’ai pas bien compris votre réponse. Je n’ai peut-être pas été assez clair.
Alors comme un dessin vaut mieux qu’un long discours, voici le shéma actuel du réseau (je ne sais pas si on peut intégrer des images dans un post alors je mets un lien):
http://www.imagup.com/pics/1285701320.html
[URL=http://www.imagup.com/pics/1285701320.html][IMG]http://ups.imagup.com/ano1/1285701320.jpg[/IMG][/URL]
Donc le but est d’acheminer du trafic depuis ESXi vers ALASKA.
Merci
September 28th, 2010 at 20:39
il faut que sur la VM NOMANSLAND tu autorise le trafic entre 192.168.2.100 vers 192.168.3.4 et évidement que ca route entre les 2
September 28th, 2010 at 20:42
Comment sais-tu que le trafic syslog viendra de Managment Network 0 et non de Managment Network 1 ?
Merci
September 28th, 2010 at 20:45
j’avais pas vu, c’est quoi la default getaway de ton ESXi ?
September 28th, 2010 at 20:50
Bonne question ! Tu connais la commande pour avoir cette info via ssh ? Je n’ai pas d’accès physique au serveur.
September 28th, 2010 at 20:51
esxcfg-route -l
September 28th, 2010 at 20:55
esxcfg-route : Command not found
esxcfg : Command not found
September 28th, 2010 at 20:56
vmware -v
ou
uname -a
September 28th, 2010 at 20:59
VMware ESXi 4.0.0 build-208167
September 28th, 2010 at 21:01
Alors désolé, je ne sais pas ce qui s’est passé, je me suis reloggé en ssh et la commande fonctionne.
Alors :
esxcfg-route
VMkernel default gateway is 192.168.1.254
September 28th, 2010 at 21:01
esxcfg-route -l
VMkernel Routes:
Network Netmask Gateway
192.168.1.0 255.255.255.0 Local Subnet
192.168.2.0 255.255.255.0 Local Subnet
default 0.0.0.0 192.168.1.254
September 28th, 2010 at 21:04
Ce serait donc 192.168.1.100 mais fait l’essai avec l’autre au cas où…
September 28th, 2010 at 21:14
Alors j’ai autorisé le trafic de Network Managment 0 vers Alaska et de Network Managment Network 1 vers Alaska mais ca n’a pas l’air de passer.
Tu as une autre idée ?
September 28th, 2010 at 22:07
Il faut que ca route aussi. T’as configuré ton firewall pour ca ?
September 28th, 2010 at 22:12
Oui, je suis sûr que les règles que j’ai créées sont sensées fonctionner.
Mon besoin de récupérer les logs ESXi n’est pas primordial donc si tu n’as pas d’idée à me proposer, ce n’est pas grave, je me repencherai sur la question un autre jour.
September 28th, 2010 at 22:21
Je te parles pas des regles de firewall mais de la table de routage, on est d’accord ? C’est quoi cette VM ?
September 28th, 2010 at 22:37
Je n’ai jamais modifié manuellement la table de routage. Elle s’est alimentée automatiquement en fonction de la config des interfaces réseau.
La politique de filtrage par défaut est de tout bloquer dans n’importe quel sens que ce soit. Puis, en fonction des besoins, je rajoute des règles pour autoriser du trafic en entrée ou en sortie.
Les 24 règles de NAT et la cinquantaine de règles de filtrage fonctionnent parfaitement. Aucune bidouille !
La VM est une FreeBSD avec PFSense.
September 28th, 2010 at 22:51
Je viens de capter sur ton schéma, c’est sur l’esxi que tu dois ajouter une route pour acceder à 192.168.3.4 via 192.168.1.2
September 28th, 2010 at 22:56
Ca m’à l’air pas mal !
Par contre je flippe un peu, j’ai peur de perdre la main sur le parc… Le serveur se trouve à 300Km de chez moi et il est en production dans une entreprise… J’ai pas intérêt à faire une connerie…
September 28th, 2010 at 22:58
Pour info, voici la table de routage de la VM qui fait office de firewall :
Destination Gateway Netif
default 192.168.1.254 le1
localhost localhost lo0
192.168.1.0 link#2 le1
192.168.2.0 link#1 le0
192.168.3.0 link#3 le2
September 28th, 2010 at 22:59
Fait une test sur une maquette avant !
September 28th, 2010 at 23:02
hmmm… mais je n’ai pas de maquette sous la main… et franchement pas vraiment le courage de monter un serveur ESXi, lui-même virtualisé dans un VMWare Player/Workstation/Server
September 28th, 2010 at 23:08
En tout cas, je te remercie vraiment de m’avoir consacré du temps !
September 28th, 2010 at 23:15
De rien
Si tes VM sont en stockage local ou SAN, au pire tu perdra la main sur le ssh mais c’est tout vu que le reste c’est du bridge. Et tu pourras tjs passer par ton pfsense pour t’y reconnecter !
September 28th, 2010 at 23:23
C’est vrai mais comme il n’y as pas d’urgence, j’attendrai la veille de me rendre à Paris pour faire la manip. J’ai vraiment pas envie de mettre tout le monde dans la mouise juste parce que je “m’amuse” avec un serveur syslog (et Php-Syslog-NG au passage).
Merci encore.
September 28th, 2010 at 23:35
Dommage
Tiens nous au parf !
September 28th, 2010 at 23:47
T’inquiet’, tu seras au courant dès que ca fonctionnera
Par contre j’ai quand même un doute sur ta solution car je viens d’ajouter une règle à mon firewall pour autoriser le trafic venant de 192.168.1.100 en direction de 192.168.1.2. Et le ping ne passe pas.
Là il me semble qu’on est d’accord sur le fait qu’il n’y a pas de route à ajouter où que ce soit pour un tel trafic ?
September 29th, 2010 at 0:05
Pas de route puisque ton trafic reste au sein du meme subnet, t’as bien autorisé l’icmp sur l’ip du firewall ?
September 29th, 2010 at 0:06
oui, j’ai autorisé tous les protocoles.
September 29th, 2010 at 0:13
Essaie la commande vmkping pour voir
September 29th, 2010 at 0:15
Aucune réponse…
September 29th, 2010 at 0:17
J’ai l’impression que le firewall intégré à ESXi bloque tout trafic entre les VM et les Network Managment.
Le ping d’un VM Managment à l’autre fonctionne.
September 29th, 2010 at 0:27
Non non ya pas de firewall dans esxi.
September 29th, 2010 at 0:54
Vraiment étrange quand même… le ping fonctionne aussi vers une IP publique
September 29th, 2010 at 10:50
et depuis pfsense tu peux pinger les ip vmk0 et vmk1 ?
September 30th, 2010 at 3:35
De plus en plus incompréhensible…
Depuis pfsense :
je ping 192.168.1.100(vmk1)
je ping 192.168.2.100 (vmk0)
Depuis 192.168.1.100 :
je ping 192.168.2.100 (vmk0)
je ne ping pas 192.168.1.2
je ne ping pas 192.168.3.254
je ping 192.168.2.254 alors qu’aucune règle de pare-feu ne m’y autorise…
Depuis 192.168.2.100 :
je ping 192.168.1.100 (vmk1)
je ne ping pas 192.168.1.2
je ne ping pas 192.168.3.254
je ping 192.168.2.254 alors qu’aucune règle de pare-feu ne m’y autorise…
Ca devient difficile…
September 30th, 2010 at 4:11
Etant donné qu’une communication a lieu entre les vmk et 192.168.2.254, sous ESXi, j’ai déclaré le serveur syslog sur 192.168.2.254. Puis, sur pfsense, j’ai créé une règle NAT pour rediriger le trafic syslog (udp 514) vers alaska. Pour l’instant, je ne constate pas de nouvelle entrée dans mon serveur syslog. Je ne sais pas trop ce que ESXi log. J’ai redémarré le service ntp sur ESXi car sur une ditrib linux, je sais que cela génère des logs. Mais pour l’instant, les dernières lignes de log générées en local par ESXi datent de 2 jours. Je vais donc attendre de voir si alaska reçoit des logs.
September 30th, 2010 at 16:45
Ca fonctionne.
Le serveur syslog a reçu des données de la part de 192.168.2.100 (vmk0).
Par contre j’aimerais bien comprendre pourquoi la communication depuis ESXi ne peut se faire que sur 192.168.2.254 et pourquoi cette IP répond aux pings alors qu’aucune règle de filtrage du firewall n’autorise ceci.
September 30th, 2010 at 16:48
j’avoue que ta config routage/firewall me dépasse là
September 30th, 2010 at 16:56
Je comprend que tu puisse avoir du mal à cerner l’ensemble de ma config étant donné que tu n’y a pas accès. En tout cas tu m’as bien aidé. Merci.
September 30th, 2010 at 17:12
J’ai bien cerné le fonctionnement mais je vois surtout que ca ne se comporte pas comme prévu
September 30th, 2010 at 17:15
Oui, je vais continuer à essayer de comprendre le pourquoi du comment…
March 25th, 2015 at 22:50
[...] l’argumentaire En l’occurrence, notre recherche de solution de gestion de logs pour ESXi remonte à bien avant Graylog2 avec le fameux php-syslog-ng (devenu le très payant LogZilla), puis LogAnalyzer. Ensuite il y a eu [...]