Du coup, effectivement, c'est plutot un outil d'inventaire/cmdb etc. qu'il te faut.
Un logiciel de sup sera forcément limité pour ton usage, ne serait-ce que parce qu'il ne gère pas le cycle de vie d'un équipement : en cours de déploiement / en production / décomissioné.... Au passage, ça permet aussi de simplifier la facturation lorsque les serveurs appartiennent à un client :)
Le coup du logiciel de sup en point central est une habitude que je rencontrais pas mal il y a qq années, parce que ça permettait de profiter des mécanismes de découverte auto. (HP OpenView NNM)
----- Mail original ----- De: "Wallace" wallace@morkitu.org À: frsag@frsag.org Envoyé: Lundi 19 Janvier 2015 11:45:32 Objet: Re: [FRsAG] Supervision open source point sur les configurations
Le 19/01/2015 11:39, gmonne@free.fr a écrit :
Bonjour,
C'est la première fois que je poste sur cette ML, mais comme c'est mon métier, je me permet de répondre à cette question :)
Personnellement, plutot que de partir sur un outil, j'utilise du script (PERL pur moi), mais surtout je profite à fond des "nouvelles" possibilités de Nagios/Icinga et consors : le triptique Templates/Héritage/Macros qui est extremement puissant.
Par exemple, pour déployer un nouveau serveur, j'ai juste à ajouter un fichier qui porte le nom du serveur.cfg et une déclaration de hote. Tous les paramètres (communauté snmp, seuils min et max ...) sont passés via des macros associées à cet hôte.
Le type de serveur (window, linux...) est passé par héritage, et les services de sup par défaut sont associés automatiquement via des appartenances au groupes.
Je m'interdis le passage de paramètre à des commandes autrement qu'en passant par des macros, car ça rend la conf indigeste. Enfin, j'essaie de rendre le plus possibles les fichiers de conf 'atomiques' avec des règles de nommages claires.
Pour moi, l'avantage de Nagios est justement la possibilité d'intégration complète dans le SI via un peu de scripting. J'ai toujours été déçu par les générateurs de conf (Monarch, Centreon..) qui développent trop la conf et deviennent eux même un point de faiblesse (allez jeter un coup d'oeuil aux tables de stockage Centréon..). Leur seul avantage étant leur accès facile pour des équipes N1. Mais de toute façon, on se retrouve rapidement avec une conf dégueu et peu maintenable / évolutive/ La seul exception pour laquelle j'en ai déployé était pour un client qui avait un tout petit parc d'une trentaine de serveurs.
Utiliser l'héritage permet au contraire de se poser les bonnes questions, et de factoriser un maximum, même dans le cas d'un parc hétérogène.
Enfin, c'est mon avis.
Guillaume
C'est exactement la vision que l'on a. Nagios est le point central, si un serveur n'est pas déclaré et supervisé par Nagios, nous même sommes incapables de nous y connecter depuis notre gate SSH. Ca permet d'éviter l'oubli de supervision, tellement fréquent dans toutes les boites que j'ai vues. On s'est effectivement branché dessus pour le reste du SI, la sauvegarde des hosts, les graphs métrologies, ...
Ta façon de faire on fait avec nos éléments dans Nagios, on factorise aussi pour éviter un maximum les arguments mais comme on a pas de macro on définit des check meta qui hérite de la commande de base.
Le souci avec ce système c'est que lorsqu'il y a une coquille dans la conf, il n'est pas donné à tous les intervenants d'avoir les compétences pour débuguer l'erreur.
Sinon on est d'accord avec Centreon, la lourdeur de la configuration et des données en base est un gros souci.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/