Howdy, journal !
Peut-être te souviens-tu que j'aime jouer avec les conteneurs [1], qui me permettent d'avoir une certaine forme de virtualisation, sans pour autant devoir jeter mes braves Athlon-XP, qui jouent vaillamment le rôle de serveurs depuis déjà quelques années.
Oui mais voilà : qui dit conteneurs, dit multiplication du nombre de machines à maintenir... et donc dit trouver des solutions pour faciliter la chose. C'est donc ainsi que je me suis mis à jouer avec puppet [2] depuis quelque temps... problème : puppet me bouffe pas mal de RAM, dans les 25Mo de mémoire virtuelle par conteneur, le chargement de Ruby oblige. Or les Athlon-XP sont de "vieilles" machines 32 bits, plutôt limitées quant à la RAM qu'elles peuvent embarquer (respectivement 2 et 3Go maximum sur mes serveurs).
La RAM m'est donc une denrée précieuse que je dois économiser, sous peine de devoir limiter le nombre de mes conteneurs. Or, depuis Lenny, Debian a décidé de passer de sysklogd, par défaut, apparemment plus vraiment maintenu, à rsyslog [3]. Sauf que ça a un méchant coût. Prenons un conteneur sous Lenny que j'ai basiquement "debootstrapé", en lui rajoutant juste exim4-daemon-light, sshd et puppet. Avec rsyslog, un "free -m" m'indique 58Mo de mémoire occupée. Avec syslogkd, la même chose m'indique 32Mo. J'ai aussi voulu comparer avec syslog-ng, déclaré comme "seul autre acteur majeur dans les solutions de log", par le développeur principal de rsyslog [4] : 33Mo.
Alors, j'en vois sourire : "Tu joues ta mijorée pour 25Mo de RAM ? En 2008 ?" ... bah, oui... à choisir, je préfère un système de logs un peu moins évolué, mais avoir puppet installé... Je fais déjà presque tourner une vingtaine de conteneurs dans la machine qui a le plus de RAM, et je prévois d'en faire tourner entre 30 et 40 à terme (un service : un conteneur... ça va vite : par exemple, comme j'ai lourdé bind, en faveur de NSD et unbound [plus parce que c'est infiniment plus simple à configurer que pour une autre raison, l'argument de la légèreté étant balayé par la démultiplication que j'en fais], pour reproduire le système de vues [views], ça bouffe forcément de la resource - 2 conteneurs par DNS, un autoritaire, et un récursif ; sur 3 vues ["DMZ" pour mes invités, DMZ pour les serveurs publics et les serveurs dont ils ont besoin, et DMZ plus réseau, ces deux derniers, internes], en rajoutant le conteneur pour no-ip, vu que je suis avec Orange en cambrousse, ça me fait déjà 7 conteneurs pour gérer DNS). 25Mo de RAM sur un tel nombre potentiel de conteneurs, ça fait environ 1Go de RAM bouffé par les logs (vous me direz que ça en fait autant de bouffé par puppet : certes - mais il m'apporte une valeur ajoutée bigrement considérable)...
... et la machine ne disposant que de 2,5Go de RAM pour les conteneurs, ça fait une différence de presque la moitié de la RAM totale entre rsyslog et le reste (ce qui fait que, avec puppet, il ne me resterait presque plus rien pour les services... et encore, là, j'ai mesuré la RAM occupée au démarrage du conteneur ; m'enfin, même si l'occupation monte un peu dans le temps, ça reste quand même dans ces eaux-là).
Bon, rsyslog a l'air plus puissant que syslog-ng [5], notamment au niveau des capacités à "loguer" à distance, et à gérer les bases de données... Mais même si j'y jette un œil de temps en temps, et que, à l'occasion, je leur ai déjà dû de fières bretelles, je ne suis pas non plus un gros maniaque des logs : c'est probablement un tort, mais je les regarde surtout quand quelque chose me tracasse ; au pire, pour les machines publiques, j'en garde quand même des archives.
Du coup, quitte à choisir un système de log maintenu, et même reconnu comme bon par ses concurrents, même s'il l'est un peu moins que rsyslog, je pense que je vais migrer vers syslog-ng, pour mes conteneurs, au moins, vu les resources dont je dispose. Et toi, multitude du journal : qu'utilises-tu comme système de logs, et pourquoi ?
Et log, tu le traduis comment ? Journal, consigne, archive, mémojournél, ... ?
[1] http://linuxfr.org/~Aefron/27379.html
[2] http://reductivelabs.com/trac/puppet
[3] http://wiki.debian.org/Rsyslog
[4] http://blog.gerhards.net/2007/08/why-does-world-need-another(...)
[5] http://www.rsyslog.com/doc-rsyslog_ng_comparison.html
Journal Debian Lenny, rsyslog et les conteneurs : de mes maniaquerie, radinerie et indigence
14
nov.
2008
# syslog-ng
Posté par SLMitch . Évalué à 2.
Sur nos systèmes en production, c'est toujours du syslogd de base (centos), mais un syslog-ng pour récolter les logs et les trier.
Syslog-ng se débrouille très bien quand même pour récupérer les logs en udp/tcp des autres machines, et par les filtres tu peux faire plein d'autres trucs rigolos.
Je n'ai jamais voulu les stocker en base de données, donc je n'ai jamais trouvé de limitation à syslog-ng.
[^] # Re: syslog-ng
Posté par Aefron . Évalué à 3.
... en fait, selon ce que j'ai lu sur le blog de Rainer Gerhards, principal auteur de rsyslog, il y a deux syslog-ng : un libre, et un autre purement commercial, avec plus de fonctionnalités... ce qui serait l'une des raisons du fork de sysklogd par Rainer (ne pas toucher à syslog-ng, pour ne pas empiéter sur son modèle de rémunération, sans pour autant partir de zéro, dans sa démarche de développer de l'alternative aux logueurs puissants, ou syslog-ng est en situation de monoculture, d'après lui).
Bon, quant à moi, je l'ai dit : mes besoins sont très modestes, voire artisanaux - je ne centralise même pas encore mes logs (je m'amuse avec mes serveurs à titre purement personnel : disons que je fais du lego :p)... Du coup, le passage à rsyslog m'ennuie un peu, surtout du fait que je le trouve obèse, tout aussi bien qu'il puisse être (je n'ai clairement pas les compétences pour remettre ça en cause).
Après, avec la multiplication de mes conteneurs, et des services que je vais ouvrir à l'extérieur, j'y réfléchis... va falloir que je vois comment faire ça avec syslog-ng... Apparemment, à ce niveau, rsyslog est meilleur, puisqu'il semble que depuis sa version 3.19.0, il n'ait pas besoin de stunnel pour déporter les logs en TLS, contrairement à syslog-ng (sauf à prendre l'édition commerciale)... enfin, à voir.
# Et rendre rsyslog plus leger ?
Posté par Misc (site web personnel) . Évalué à 2.
[^] # Re: Et rendre rsyslog plus leger ?
Posté par Aefron . Évalué à 2.
Par contre, je n'ai pas vraiment vu comment gagner plus, et sa surconsommation par rapport à syslog-ng reste toujours trop importante pour moi, pour la différence qu'il m'apporte, pour mon usage...
Pour ce qui est du support du reste, par défaut, il ne semble pas que TLS et cie soient activés dans la conf de base... quant à la gestion des bases de données, il faut faire venir des paquets disjoints pour mysql et pgsql...
# Serveur de logs centralisé
Posté par monsieurw . Évalué à 2.
Personnellement, j'essaie toujours d'avoir un serveur syslog qui reçoit les logs de tous les équipements (autres Unix, Windows -avec NTSyslog-, switchs, routeurs)
Vu la quantité de conteneurs utilisés, l'un d'entre eux pourrait faire office de serveur syslog centralisé. Ça permet d'utiliser un démon syslog minimal dans les autres conteneurs (sysklogd ou le syslog de Busybox fonctionnent très bien, par exemple). Bien sûr, ce n'est que de l'UDP et il n'y a pas de chiffrement, mais bon...
--
Jérôme
[^] # Re: Serveur de logs centralisé
Posté par Aefron . Évalué à 2.
Cette histoire m'y a fait penser, du coup ;)
À voir : je pense que ce serait une bonne idée que de s'y mettre, au moins pour les services que j'ouvre sur l'extérieur (mail et cie).
D'autant que j'ai deux serveurs à conteneurs, mais que tous les services externes sont sur la même machine : aussi, le fait que la centralisation des logs ne soit pas chiffrée ne serait pas franchement catastrophique...
# Conso de rsyslog
Posté par Pinaraf . Évalué à 2.
J'ai beau chercher, je ne trouve pas comment tu peux faire pour avoir un rsyslog qui consomme tant de mémoire.
Chez moi sa conso est invisible sur un free -m.
# free -m ; /etc/init.d/rsyslog stop ; free -m ; /etc/init.d/rsyslog start ; free -m
total used free shared buffers cached
Mem: 1009 977 31 0 19 237
-/+ buffers/cache: 721 287
Swap: 2588 238 2350
* Stopping enhanced syslogd rsyslogd [ OK ]
total used free shared buffers cached
Mem: 1009 977 31 0 19 237
-/+ buffers/cache: 721 287
Swap: 2588 238 2350
* Starting enhanced syslogd rsyslogd [ OK ]
total used free shared buffers cached
Mem: 1009 978 31 0 19 237
-/+ buffers/cache: 721 287
Swap: 2588 238 2350
[^] # Re: Conso de rsyslog
Posté par Pinaraf . Évalué à 1.
[^] # Re: Conso de rsyslog
Posté par Aefron . Évalué à 3.
Niveau mémoire résidente (RSZ, à un "ps aux"), rsyslogd est bien tout petit (~1Mio)...
Pour les buffers et les caches, ils ne sont pas virtualisés à la vue de la VM, et restent à "0" tout le temps, à un "free -m".
Sur une machine "normale", ça me fait comme toi : ~1Mio de différence... mais dans le conteneur, j'obtiens :
$ echo && free -m && echo ; sudo invoke-rc.d rsyslog stop && echo ; free -m && echo ; sudo invoke-rc.d rsyslog start && echo ; free -m
total used free shared buffers cached
Mem: 256 45 210 0 0 0
-/+ buffers/cache: 45 210
Swap: 0 0 0
Stopping enhanced syslogd: rsyslogd.
total used free shared buffers cached
Mem: 256 28 227 0 0 0
-/+ buffers/cache: 28 227
Swap: 0 0 0
Starting enhanced syslogd: rsyslogd.
total used free shared buffers cached
Mem: 256 45 210 0 0 0
-/+ buffers/cache: 45 210
Swap: 0 0 0
En fait, dans un conteneur OpenVZ, le "used" d'un "free -m" va correspondre au "privvmpages", qui est la quantité de mémoire allouée (en pages de 4Kio), sans pour autant être nécessairement utilisée (la mémoire physique utilisée en pratique va plutôt être indiquée par oomguardpages [quantité de mémoire physique utilisée qui va faire que, au delà d'un certain seuil, les processus vont commencer à être tués] ou physmpages, qui ne vont en effet même pas varier d'1Mo en arrêtant rsyslog... pour une VM telle que je l'ai décrite, exim4-light, sshd, puppet et rsyslog, il y a ~19Mio de RAM physique occupée... mais significativement plus qui a été allouée). Les buffers et les caches ne sont pas virtualisés en tant que tels dans la VM : ils n'apparaissent "qu'en gros", sur l'hôte, lorsqu'on y fait un "free -m" (enfin, une partie apparaît aussi dans les beancounters, pour ce qui est des buffers de sockets et caches de système de fichiers, mais je ne pense pas que ça recouvre tout ceux qu'on trouve dans la mémoire de la machine).
Le souci étant qu'à allouer moins de ressources de l'hôte à la VM que ce qui est alloué par un "privvmpages", si une application se met à utiliser cette mémoire, elle peut planter lamentablement... À ce sujet, la doc d'OpenVZ conseille d'allouer du "privvmpages" en accord avec les ressources réelles de la machine.
Aussi, à partir du moment où une application commence à allouer beaucoup de mémoire, dans un conteneur, c'est gênant, quand bien même elle ne l'utilise pas en pratique... D'où mon désarroi face à rsyslog... Si je l'utilise, soit je réserve trop de RAM pour les VM, soit je joue avec le feu...
[^] # Re: Conso de rsyslog
Posté par Pinaraf . Évalué à 2.
En fait le problème de rsyslog c'est juste qu'il alloue puis libère de la mémoire donc (peut être à son lancement)...
À mon avis tu devrais signaler le problème sur le forum de rsyslog, ils sont en général très réactifs.
[^] # Re: Conso de rsyslog
Posté par Aefron . Évalué à 1.
Clairement, il faudra que je parle du problème aux devs (que je passe par Debian en tant qu'intermédiaire ou pas... cela dit, vu que je ne suis qu'un pauvre mortel, ie j'ai quelques notions, mais je suis un amateur bien loin d'être capable de coder à ce niveau, passer par le "bugreport" de Debian pourrait ne pas être du luxe :p ... d'autant que rsyslog a été choisi entre autres parce qu'il semble y avoir une bonne entente entre devs Debian et Rainer)...
... m'enfin, pour Lenny, c'est de toute façon trop tard, je pense ('me suis déjà fait envoyer bouler quand j'ai rappelé que lcdproc n'avait pas été mis à jour depuis au moins Sarge, et que pour acheter des LCD supportés par la version qui sera dans Lenny, faut se lever tôt - et tout ça juste parce que le paquet pour s390 est trop vieux par rapport aux autres - le seul bug RC ayant été corrigé il y a plus d'un mois) - donc, en attendant, faudra bien que je me satisfasse de syslog-ng...
[^] # Re: Conso de rsyslog
Posté par Pinaraf . Évalué à 1.
J'vois pas du tout ce qui fait que tu n'aies pas le droit de signaler un bug sur le forum de rsyslog.
Par contre en passant par Debian, tu pourrais avoir un backport d'un éventuel correctif dans Lenny peut être. Même si j'ai des doutes que, si backport il y a, il se passe avant la sortie de Lenny.
[^] # Re: Conso de rsyslog
Posté par Aefron . Évalué à 2.
Ce n'est pas une question de droit, mais plus une question de compétences et de côté pratique.
Je pense que le mainteneur a déjà plus le nez dans le guidon que moi sur ces questions (je rencontre certes le problème... de là à le résoudre, ou à bien l'expliquer à ceux qui codent...)...
... en outre, comme tu le fais remarquer, ça crée une entrée pour le bug dans Debian, et ça me permettra de mieux identifier quand le problème sera résolu, vu que c'est dans cette distro (que j'utilise majoritairement), que je le rencontre principalement, suite à la décision de faire de rsyslog le logueur par défaut.
Je suis souvent passé par le rapport de bugs chez Debian, pour des problèmes qui concernaient le développement en amont, et en général, l'info suit bien ;)
[^] # Re: Conso de rsyslog
Posté par Pinaraf . Évalué à 1.
[^] # Re: Conso de rsyslog
Posté par Bruno Muller . Évalué à 4.
$ grep ^Vm /proc/`pidof syslogd`/statusVmPeak: 1892 kB
VmSize: 1816 kB
VmLck: 0 kB
VmHWM: 624 kB
VmRSS: 620 kB
VmData: 164 kB
VmStk: 84 kB
VmExe: 28 kB
VmLib: 1508 kB
VmPTE: 16 kB
grep ^Vm /proc/`pidof rsyslogd`/statusVmPeak: 29136 kB
VmSize: 28268 kB
VmLck: 0 kB
VmHWM: 1484 kB
VmRSS: 1252 kB
VmData: 25912 kB
VmStk: 84 kB
VmExe: 208 kB
VmLib: 1956 kB
VmPTE: 28 kB
[^] # Re: Conso de rsyslog
Posté par Pinaraf . Évalué à 0.
VmData c'est ce qui a été alloué sur la pile, mais cette valeur ne diminue jamais (sauf chez les fous qui recodent malloc peut être) quand le programme libère de la mémoire.
Malheureusement, je n'arrive pas à faire fonctionner des outils comme memrank (évoqués là http://lwn.net/Articles/230975/ ) pour avoir de vraies mesures de la consommation mémoire d'un processus, et pas des données à la signification hasardeuse.
[^] # Re: Conso de rsyslog
Posté par Bruno Muller . Évalué à 4.
- Si VmData concerne la pile, à quoi correspond VmStk ?
- VmData diminue à chaque free() (vérifiable en maxi 20 ligne de C)...
Sur ce, bon appétit.
[^] # Re: Conso de rsyslog
Posté par Pinaraf . Évalué à 1.
# quantite de ram ?? faux probleme
Posté par Nico C. . Évalué à 0.
Utilise un noyau "bigmem" et bourre ta machine d'autant de ram que peut supporter ta carte mere (qui est le seul reel facteur limitant en fait)
[^] # Re: quantite de ram ?? faux probleme
Posté par Aefron . Évalué à 3.
Voilà... l'est là, le problème :(
Niveau RAM, c'est blindé : je ne peux pas mettre plus de 3*1Gio sur mon A7N8X-E... quant à la KT4AV, elle a bien trois emplacements, mais ça bloque au BIOS si je mets une troisième barette de 1Gio (tu crois que je n'ai pas essayé, peut-être :p ?)...
Donc... Voilà... l'est là, le problème... Quand ça décédera, évidemment, je prendrais quelque chose qui ne sera pas autant intrinsèquement limité, que j'utilise un noyau 32bits bigmem, ou un 64 bits : en attendant, je fais avec ce que j'ai (quoique : plus tard ça arrive, mieux c'est - les mobos récentes avec 4 ports PCI, pour mes cartes DVB-T, ça ne court plus les rues).
Mes serveurs sont des vieilles machines de récup... ie, mes anciens desktops. Certes, on pourrait me reprocher que ça consomme sa race vis à vis de la puissance que ça a... d'un autre côté, les envoyer dans une décharge d'un quelconque pays du tiers-monde, pour que ça y pollue les nappes phréatiques et intoxique les ouvriers, est-ce fondamentalement mieux ?
# tu utilises sandy ?
Posté par manatlan (site web personnel) . Évalué à 2.
[^] # Re: tu utilises sandy ?
Posté par Aefron . Évalué à 2.
"Sandy, il faut toujours que tu dramatises : cet affreux Youri est mort. Youri n'est plus qu'un affreux souvenir, maintenant. Cet affreux CAU-chemar est terminé !"
???
... sinon, en googlant, iwantsandy a l'air d'un assistant en webmail, ou un truc du genre... mais... c'est quoi le rapport ?
[^] # Re: tu utilises sandy ?
Posté par manatlan (site web personnel) . Évalué à 2.
mais quand elle m'ecrit, elle commence toujours sa lettre par un "howdy", "hello", "guten abend", "Bonjour" (au hasard), ... et le "howdy" la première fois que je l'ai vu, c'était via ma sandy à moi ;-) ... avant je connaissais pas du tout.
Voilà le rapport, je me disais que tu étais peut être un utilisateur de sandy
[^] # Re: tu utilises sandy ?
Posté par Aefron . Évalué à 2.
... non, en fait, plutôt un fan de Mr Hankey, le Petit Caca Noël de South Park : howdy-hooooo ! :D
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.