Le 09/10/2012 12:01, Wallace a écrit :
Bonjour à tous,
Je voulais savoir si des gens par ici utilisent Shinken ou le test?
La version 1.2 sorti il y a un bon mois promettait pas mal de choses mais il s'avère difficile de mettre cela en production.
Si l'installation avec le script shell est super efficace, la configuration des différents modules n'est pas évidente. Chose toute bête tous les daemons écoutent sur localhost par défaut, c'est bien pour la sécurité, hop un petit reverse proxy avec Nginx mais l'application ne permet pas de modifier l'url absolue et force du localhost ... Du coup je bind sur une ip et là c'est le jeu des ports différents pour chaque module qui pose problème.
Bref j'arrive à faire marcher le tout et je met en place une configuration pour quelques machines. Au final la métrologie me révèle que la machine mange pas mal de cpu et de mémoire pour quelques checks. Je suis assez surpris car il me semblait que la performance était le crédo de Shinken. Or j'ai un Nagios (seul sans surcouche) qui tient plus de 300 hosts avec tous leurs checks depuis une VM avec juste 512Mo de ram et peu de cpu.
Du coup j'hésite vraiment à continuer à tenter une transition. La direction des logiciels en ce moment à tout faire en interpréter (perl, python, ruby, ...) fait consommer des ressources hallucinantes pour pas grand chose. Autre exemple Puppetmaster ou CFEngine qui prennent une quantité de ram importante surtout pour des petites vm avec 128 ou 256M de ram.
Si vous avez un avis, je suis preneur.
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
j'ai en place un shinken, pour superviser 4909 equipements pour 5894 services , loadbalancé sur 4VM parce que le broker a du mal a gérer beaucoup d'équipement sur un seul hote.
Coté IHM, j'ai un nagvis/thruk pour afficher mes cartographies/détails. Le nagvis n'est pas fait pour aller chercher les information selon le mode LB automatique de shinken (ou en tout ca j'ai pas trouvé), de fait je force des realms a la main pour chaque poller et j'indique a nagvis où aller chercher l'info. Je n'ai donc pas de haute dispo sur le cluster dans le cas de perte d'un des noeuds (ce qui est arrivé une fois, reboot de l'arbiter et du broker défaillant obligatoire).
Cette solution a été mise en place parce qu'il fallait un POC de supervision opensource et que shinken montait, on s'est fié a la plaquette et donc on a pas testé les perfs de nagios en parallèle, et c'est tombé en prod. Pas de retour sur les écarts de perfs nagios/shinken donc.
on a fait la version 0.6 et la 1.01, pas encore testé la 1.02
L'installation/configuration s'est faite sans difficulté particulière.
Les vms ont 2go de RAM sauf l'arbiter qui en a 4 (mais qui sers aussi de broker) et 2core d'un Opteron 2435 (connu via cpuinfo)
Cordialement,
Thomas Dubois