Le 19/01/2015 11:39, gmo...@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.


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

Répondre à