Supervision open source point sur les configurations
Bonjour, Comme à peu près chaque année, je regarde ce que les différents outils open source de supervision ont comme nouveautés. Actuellement je marche avec Nagios et Nconf. Y a plus de 10 ans je faisais des scripts pour générer les configurations Nagios puis il y a 4/5 ans j'ai migré sur Nconf qui est fort pratique mais ce dernier ne semble plus maintenu alors qu'il est assez souple. Comme je vois que Shinken et Icinga par exemple ne proposent pas d'interface de configuration autre que le bon vieux fichier de configuration, je me dis que je dois passer à côté d'un outil fait pour simplifier la vie. Quel est ou sont ces outils pour générer des fichiers de configuration? Vous en connaissez, vous en utilisez? Pour préciser un peu plus ma demande, c'est pour gérer des serveurs tous différents pour des clients différents donc impossible de faire du Chef / Puppet. Les services se recoupent pour les classes comme MySQL / Nginx / ... mais c'est tout après c'est forcément du spécifique. Pas besoin de parler de Centreon je n'aime pas la lourdeur de ce logiciel et sa mauvaise tenue en charge. Merci pour votre retour
Bonjour Je ne suis pas sur de comprendre la question concernant la gestion graphique de la configuration. Toutefois shinken fournit plusieurs interfaces graphiques pour gérer le tout dont webui[1]. Pour gérer son parc, il est possible de surcharger une partie des fichiers de configuration par une autre source comme par exemple glpi[2] qui permet d'alimenter dynamiquement[3] la base shinken. Dans cas on a une interface graphique pour créer ses machines, tags et consorts. Ensuite on peut rajouter la couche inventaire avec fusioninventory qui permet de remonter auto-magiquement dans glpi ses machines. De ce que je comprends de shinken n'importe quel fichier cfg peut être surchargé par une autre source via l'installation ou le développement d'un module (package)[4] [1] http://shinkenlab.io/online-course-2-webui/ [2] http://www.glpi-project.org/ [3] https://forge.indepnet.net/projects/monitoring/ & https://github.com/ddurieux/glpi_monitoring/ [4] http://shinken.io/ Km
C'est pour la partie configuration des hosts et services à superviser que l'on cherche une interface qui gère les dépendances et fasse les fichiers de configurations nécessaires. Je sais bien que chaque outils ont leurs propres interface de lecture / action. GLPI on a testé et il est plus approprié pour gérer un parc bureautique, pas pour gérer des serveurs éphémères ou des serveurs de plusieurs clients. Enfin on avait pas trouvé la personnalisation de l'interface ticket version simple très souple. On voulait certains champs qui n'apparaissaient qu'en version normale et faisait apparaitre des champs internes dont les clients n'avaient que faire. Enfin le client glpi est super lourd en mémoire, on a des micros serveurs avec 256Mo de mémoire, je ne sais plus si c'était du Perl ou Python mais ça mangeait plus de la moitié de la ram. Le 19/01/2015 10:52, cam.lafit@azerttyu.net a écrit :
Bonjour
Je ne suis pas sur de comprendre la question concernant la gestion graphique de la configuration. Toutefois shinken fournit plusieurs interfaces graphiques pour gérer le tout dont webui[1].
Pour gérer son parc, il est possible de surcharger une partie des fichiers de configuration par une autre source comme par exemple glpi[2] qui permet d'alimenter dynamiquement[3] la base shinken. Dans cas on a une interface graphique pour créer ses machines, tags et consorts. Ensuite on peut rajouter la couche inventaire avec fusioninventory qui permet de remonter auto-magiquement dans glpi ses machines.
De ce que je comprends de shinken n'importe quel fichier cfg peut être surchargé par une autre source via l'installation ou le développement d'un module (package)[4]
[1] http://shinkenlab.io/online-course-2-webui/ [2] http://www.glpi-project.org/ [3] https://forge.indepnet.net/projects/monitoring/ & https://github.com/ddurieux/glpi_monitoring/ [4] http://shinken.io/
Km
2015-01-19 10:20 GMT+01:00 Wallace <wallace@morkitu.org>:
Bonjour,
Comme à peu près chaque année, je regarde ce que les différents outils open source de supervision ont comme nouveautés.
Actuellement je marche avec Nagios et Nconf. Y a plus de 10 ans je faisais des scripts pour générer les configurations Nagios puis il y a 4/5 ans j'ai migré sur Nconf qui est fort pratique mais ce dernier ne semble plus maintenu alors qu'il est assez souple.
Comme je vois que Shinken et Icinga par exemple ne proposent pas d'interface de configuration autre que le bon vieux fichier de configuration, je me dis que je dois passer à côté d'un outil fait pour simplifier la vie. Quel est ou sont ces outils pour générer des fichiers de configuration? Vous en connaissez, vous en utilisez?
Pour préciser un peu plus ma demande, c'est pour gérer des serveurs tous différents pour des clients différents donc impossible de faire du Chef / Puppet. Les services se recoupent pour les classes comme MySQL / Nginx / ... mais c'est tout après c'est forcément du spécifique.
Pas besoin de parler de Centreon je n'aime pas la lourdeur de ce logiciel et sa mauvaise tenue en charge.
Merci pour votre retour
Bonjour, Tu as plusieurs possibilités: * nconf fait toujours le boulot, et je crois que la société Savoir Faire Linux commence à coder dessus, donc à voir côté pérennité de l'outil. C'est surtout des patchs pour le faire fonctionner avec shinken (qui rajoute par mal de propriétés et des objets). * icinga de mémoire c'est plutôt avec lconf qu'ils font. Mais je ne sais pas si avec icinga 2 il y a quelque chose (ils ont changés complètement le format de conf dans cette V2) * Shinken tu as un outil de conf mais uniquement en version Enterprise ^^ (disclosure: c'est moi que le code justement) * Tu peux aussi faire avec GLPI. Le module "monitoring" de GLPI est là pour ça. * Tu as aussi le module import_mysql de Shinken. D'une petit base centrale mysql tu peux en tirer toute ta configuration Shinken. Jean
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 ----- Mail original ----- De: "nap" <naparuba@gmail.com> À: "French SysAdmin Group" <frsag@frsag.org> Envoyé: Lundi 19 Janvier 2015 10:53:55 Objet: Re: [FRsAG] Supervision open source point sur les configurations 2015-01-19 10:20 GMT+01:00 Wallace < wallace@morkitu.org > : Bonjour, Comme à peu près chaque année, je regarde ce que les différents outils open source de supervision ont comme nouveautés. Actuellement je marche avec Nagios et Nconf. Y a plus de 10 ans je faisais des scripts pour générer les configurations Nagios puis il y a 4/5 ans j'ai migré sur Nconf qui est fort pratique mais ce dernier ne semble plus maintenu alors qu'il est assez souple. Comme je vois que Shinken et Icinga par exemple ne proposent pas d'interface de configuration autre que le bon vieux fichier de configuration, je me dis que je dois passer à côté d'un outil fait pour simplifier la vie. Quel est ou sont ces outils pour générer des fichiers de configuration? Vous en connaissez, vous en utilisez? Pour préciser un peu plus ma demande, c'est pour gérer des serveurs tous différents pour des clients différents donc impossible de faire du Chef / Puppet. Les services se recoupent pour les classes comme MySQL / Nginx / ... mais c'est tout après c'est forcément du spécifique. Pas besoin de parler de Centreon je n'aime pas la lourdeur de ce logiciel et sa mauvaise tenue en charge. Merci pour votre retour Bonjour, Tu as plusieurs possibilités: * nconf fait toujours le boulot, et je crois que la société Savoir Faire Linux commence à coder dessus, donc à voir côté pérennité de l'outil. C'est surtout des patchs pour le faire fonctionner avec shinken (qui rajoute par mal de propriétés et des objets). * icinga de mémoire c'est plutôt avec lconf qu'ils font. Mais je ne sais pas si avec icinga 2 il y a quelque chose (ils ont changés complètement le format de conf dans cette V2) * Shinken tu as un outil de conf mais uniquement en version Enterprise ^^ (disclosure: c'est moi que le code justement) * Tu peux aussi faire avec GLPI. Le module "monitoring" de GLPI est là pour ça. * Tu as aussi le module import_mysql de Shinken. D'une petit base centrale mysql tu peux en tirer toute ta configuration Shinken. Jean _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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.
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/
Bonjour, Tu cites beaucoup d'outils, mais pas Zabbix. Pas certain qu'il soit adapté à ton besoin, pour des clients différents, mais il semblerait qu'il tienne bien la charge, en tous cas. Bonne journée. Le 01/19/15 10:20, Wallace a écrit :
Bonjour,
Comme à peu près chaque année, je regarde ce que les différents outils open source de supervision ont comme nouveautés.
Actuellement je marche avec Nagios et Nconf. Y a plus de 10 ans je faisais des scripts pour générer les configurations Nagios puis il y a 4/5 ans j'ai migré sur Nconf qui est fort pratique mais ce dernier ne semble plus maintenu alors qu'il est assez souple.
Comme je vois que Shinken et Icinga par exemple ne proposent pas d'interface de configuration autre que le bon vieux fichier de configuration, je me dis que je dois passer à côté d'un outil fait pour simplifier la vie. Quel est ou sont ces outils pour générer des fichiers de configuration? Vous en connaissez, vous en utilisez?
Pour préciser un peu plus ma demande, c'est pour gérer des serveurs tous différents pour des clients différents donc impossible de faire du Chef / Puppet. Les services se recoupent pour les classes comme MySQL / Nginx / ... mais c'est tout après c'est forcément du spécifique.
Pas besoin de parler de Centreon je n'aime pas la lourdeur de ce logiciel et sa mauvaise tenue en charge.
Merci pour votre retour
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 19/01/2015 11:32, Bernard BELLE a écrit :
Bonjour,
Tu cites beaucoup d'outils, mais pas Zabbix. Pas certain qu'il soit adapté à ton besoin, pour des clients différents, mais il semblerait qu'il tienne bien la charge, en tous cas.
Bonne journée. Je connais Zabbix, très bien mais pas apprécié par chez nous sans doute parce qu'on a tous bercé dans Nagios et son système de plugins et qu'on veut continuer avec cela.
2015-01-21 10:17 GMT+01:00 Julien Escario <escario@azylog.net>:
Le 21/01/2015 10:11, Manu a écrit :
Salut
Le 19/01/2015 11:32, Bernard BELLE a écrit :
Tu cites beaucoup d'outils, mais pas Zabbix.
Il n'y a pas d'autres retours sur Zabbix ? M
Baaah, bêêêêĥ, beurk.
Suffisamment explicite comme retour ? ;-)
Julien
Pour être un peu plus constructif je dirais qu'il a quelques soucis sur les très (très) gros parcs (tant sur les perfs que sur les architectures possibles). Ensuite son agent est très pratique, car une fois lancé hop tu as une grosse partie de faite sur ta configuration pour la supervision simple de ton serveur. Ensuite si tu as besoin de corrélation ça va être plus limité qu'un nagios/icinga/shinken (genre les règles de dépendances). Par contre c'est une solution cohérente là où nagios/icinga/shinken sont par exemple plus des outils voir des frameworks. Bref, ça dépends beaucoup de ce que tu veux superviser et des contraintes de tes processus internes :) (genre déploiement possible d'un agent ou pas). Jean
Bonjour, Julien, ton analyse au sujet de zabbix me semble très constructive ;) Mais je ne partage pas ta conclusion ;) J’utilise Zabbix pour superviser nos serveurs et il s’est montré beaucoup plus stable que le vénérable couple Nagios + centreon .. et contrairement à nagios/centreon, une fois la configuration effectuée, plus la peine de s’en soucier... Zabbix, c’est super Cool ;) Ceci étant, ce n’est que mon point de vue…
Le 21 janv. 2015 à 10:17, Julien Escario <escario@azylog.net> a écrit :
Le 21/01/2015 10:11, Manu a écrit :
Salut
Le 19/01/2015 11:32, Bernard BELLE a écrit :
Tu cites beaucoup d'outils, mais pas Zabbix.
Il n'y a pas d'autres retours sur Zabbix ? M
Baaah, bêêêêĥ, beurk.
Suffisamment explicite comme retour ? ;-)
Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 21/01/2015 10:33, guillaume pancak a écrit :
Bonjour,
Julien, ton analyse au sujet de zabbix me semble très constructive ;)
Mais je ne partage pas ta conclusion ;)
J’utilise Zabbix pour superviser nos serveurs et il s’est montré beaucoup plus stable que le vénérable couple Nagios + centreon .. et contrairement à nagios/centreon, une fois la configuration effectuée, plus la peine de s’en soucier...
Zabbix, c’est super Cool ;)
Ceci étant, ce n’est que mon point de vue…
Oui, bon j'avoue, ce n'était pas très argumenté ni productif. Alors pour compléter, j'ai été 2 fois confronté à Zabbix : * Ma propre expérience : la façon d'aborder le truc dans Zabbix est tellement à l'opposé de ma logique que je ne suis jamais parvenu à un setup ne serait-ce que potable. Ensuite, on m'a fait découvrir Nagios. * Chez un client, un informaticien en interne avait monté ça et très rapidement, il n'a plus su le maintenir et le truc envoyait plusieurs centaines d'alertes par jour et plus rien n'était lu/traité. On a cassé et refait en Nagios (parce qu'on connaissait) et depuis les alertes sont lues et traitées. Voilà pour le complément étayé. Julien
Le 21/01/2015 10:58, Julien Escario a écrit :
* Ma propre expérience : la façon d'aborder le truc dans Zabbix est tellement à l'opposé de ma logique que je ne suis jamais parvenu à un setup ne serait-ce que potable.
Je plussoie la façon de fonctionner de Zabbix est à mon sens pas logique, après j'ai vue des parcs supervisés avec et de façon bien faite, ça marche bien mais ça m'a pas convaincu. Ce qui est étonnant dans toutes les réponses que l'on voit c'est ok tout ce qui est Nagios et consorts c'est pratique d'avoir un accès aux fichiers de conf pour scripter autour. Mais personne semble avoir de vrai besoin d'interface simple de configuration, or c'est le rôle de cette interface de contrer les erreurs de configuration, de bloquer des actions illogiques. Je me demande finalement si un accès API serait pas plus judicieux ce qui permettrait de faire rapidement une interface web de configuration.
On Wed, Jan 21, 2015, at 10:58, Julien Escario wrote:
* Chez un client, un informaticien en interne avait monté ça et très rapidement, il n'a plus su le maintenir et le truc envoyait plusieurs centaines d'alertes par jour et plus rien n'était lu/traité. On a cassé et refait en Nagios (parce qu'on connaissait) et depuis les alertes sont lues et traitées.
Il y a tres longtemps on a fait le meme chose, pour les memes raisons, mais a l'inverse (virer nagios et installer Zabbix). Le zabbix a bien tenu les 5 ans que j'ai passe la-bas.
Hello,
Le 21 janv. 2015 à 10:17, Julien Escario <escario@azylog.net> a écrit :
Le 21/01/2015 10:11, Manu a écrit :
Salut
Le 19/01/2015 11:32, Bernard BELLE a écrit :
Tu cites beaucoup d'outils, mais pas Zabbix.
Il n'y a pas d'autres retours sur Zabbix ? M
Baaah, bêêêêĥ, beurk.
Suffisamment explicite comme retour ? ;-)
Je confirme, j'ai butté le zabbix au taf qui faisait en gros un check sur la dispo disk / cpu / ram de l'infra a un observium avec agent local (merci puppet et alien pour le .deb/.rpm) qui fait la même chose en plus simple et mieux. Après pour la gestion des conf des équipements réseaux: rancid + svn qui est aussi bien intégré a observium. Donc pour aller dans le sens de julien: zabbix ne m'as jamais vraiment convaincu... Xavier
Il n'y a pas d'autres retours sur Zabbix ?
Très bien, mais comme toutes solus de ce genre, c'est un peu une religion, il faut un peu de temps pour s’imprégner des concepts... Ensuite, une fois fait, c'est très bien, ça permet de tout faire rapidement via des templates, de consolider des remontées multi-sites... ... c'est une sorte d'intégré de monitoring / supervision, ça peut même servir a déployer, exec auto des scripts déclenché par des triggers sur les machines ayant l'agent d'installé... Les détracteurs diront beurk y'a un agent... ouais, ben pour faire du snmp c'est pareil, donc, que ça soit snmp ou zabbix-agent, je vois pas la différence... J'ai choisi Zabbix pour remplacer ce que j'avais avant à savoir nagios + cacti + munin + des scripts divers et variés et j'en suis content, car ça me fait gagner du temps, beaucoup de temps... Cordialement -- Christophe BAILLON Mobile :: +336 16 400 522 Home :: http://20h.com Twitter :: http://twitter.com/ctof
Le 19/01/2015 10:20, Wallace a écrit :
Bonjour,
Comme à peu près chaque année, je regarde ce que les différents outils open source de supervision ont comme nouveautés.
Actuellement je marche avec Nagios et Nconf. Y a plus de 10 ans je faisais des scripts pour générer les configurations Nagios puis il y a 4/5 ans j'ai migré sur Nconf qui est fort pratique mais ce dernier ne semble plus maintenu alors qu'il est assez souple.
Comme je vois que Shinken et Icinga par exemple ne proposent pas d'interface de configuration autre que le bon vieux fichier de configuration, je me dis que je dois passer à côté d'un outil fait pour simplifier la vie. Quel est ou sont ces outils pour générer des fichiers de configuration? Vous en connaissez, vous en utilisez?
Pour préciser un peu plus ma demande, c'est pour gérer des serveurs tous différents pour des clients différents donc impossible de faire du Chef / Puppet. Les services se recoupent pour les classes comme MySQL / Nginx / ... mais c'est tout après c'est forcément du spécifique.
Salut, Au delà du besoin pour la supervision, pour lesquels les retours seront forcément intéressants, dans un contexte comme celui que tu décris (serveurs / infra / clients différents), je déploie avec "plaisir" ansible du coup, qui me permet de gérer mes rôles sans dépendre forcément d'une architecture que je n'aurais pas choisie chez le client, et qui laisse une empreinte assez minimale sur les systèmes administrés. Et du coup, nif pour configurer agents et maintenir un nagios (ou autre) en se basant sur ton inventaire ansible ;) @+ Gilou
Pas besoin de parler de Centreon je n'aime pas la lourdeur de ce logiciel et sa mauvaise tenue en charge.
Merci pour votre retour
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 19/01/2015 11:45, Gilou a écrit :
Au delà du besoin pour la supervision, pour lesquels les retours seront forcément intéressants, dans un contexte comme celui que tu décris (serveurs / infra / clients différents), je déploie avec "plaisir" ansible du coup, qui me permet de gérer mes rôles sans dépendre forcément d'une architecture que je n'aurais pas choisie chez le client, et qui laisse une empreinte assez minimale sur les systèmes administrés.
Et du coup, nif pour configurer agents et maintenir un nagios (ou autre) en se basant sur ton inventaire ansible ;)
Ha oui bonne idée, j'avais noté dans un coin de penser à regarder Ansible mais je n'avais pas encore pris le temps, effectivement, le agentless et tout faire passer par ssh ça me va très bien. Je vais regarder cela de plus près ça pourrait être une solution de centralisation du parc.
Salut, perso j'ai fait une allergie à Centreon, côté icinga je pense qu'il ne devrait pas passer trop de temps sur les interfaces, ca reste de la cosmétique. On va pas troller au milieu de la semaine avec les forks ... Conclusion, dans mon contexte, mon parc est à 98,5% de la debian. Je passe par un script qui applique des templates sur des groupes de machine. Si un service est spécifique il est prioritaire. A ce groupe de machine j'y indique un poller. Le script génère la conf, push sur le poller et les infos sont remontées via syslog-ng. Le poller central est totalement passif et des scripts injectent le tout dans le nagios.cmd. Il y a pas une facon de faire, mon process est maitrisé et il marche bien. Ca reste aussi valide car la partie disponibilité est géré par VmWare. J'ai pas de bascule auto entre poller mais juste un freshness sur le poller central. C'est un truc que je pourrai faire plus tard. Après tu peux faire des indicateurs globaux avec les "macro on-demand" ou bien passer par mklive status. D'ailleurs ce dernier est bien pour faire des extract pour des rapports. Vu que j'ai les mains dedans, j'ai pu faire un petit webservice pour qu'une appli puisse poller et mettre ca en forme. Dans une grosse boite, tout ne passerait pas, mais d'un autre côté, quand Orange paie des milliers euros pour BMC proactive net et poller Patrol, pourquoi s'embêter avec les moulinettes maison. Dans mon contexte, ce que je fais le maitrise car on me laisse aussi le temps mais c'est pas super user friendly. Après c'est facile de faire un truc maison quand on s'appuie sur Nagios qui est un produit super stable. Autant ca ne me dérange pas de construire autour d'un produit stable, autant j'ai pas envie de mettre du test en prod. Je me suis aussi orienté vers cette solution car j'aime pas trop les bdd. Cependant ca me dérangerai pas de faire des extract et injecter les données dans ElasticSearch et de passer par Kibana pour mettre ca en forme surtout avec logstash et son connecteur syslog-ng, mais ca c'est pour m'amuser. Alex. On 19/01/15 10:20, Wallace wrote:
Bonjour,
Comme à peu près chaque année, je regarde ce que les différents outils open source de supervision ont comme nouveautés.
Actuellement je marche avec Nagios et Nconf. Y a plus de 10 ans je faisais des scripts pour générer les configurations Nagios puis il y a 4/5 ans j'ai migré sur Nconf qui est fort pratique mais ce dernier ne semble plus maintenu alors qu'il est assez souple.
Comme je vois que Shinken et Icinga par exemple ne proposent pas d'interface de configuration autre que le bon vieux fichier de configuration, je me dis que je dois passer à côté d'un outil fait pour simplifier la vie. Quel est ou sont ces outils pour générer des fichiers de configuration? Vous en connaissez, vous en utilisez?
Pour préciser un peu plus ma demande, c'est pour gérer des serveurs tous différents pour des clients différents donc impossible de faire du Chef / Puppet. Les services se recoupent pour les classes comme MySQL / Nginx / ... mais c'est tout après c'est forcément du spécifique.
Pas besoin de parler de Centreon je n'aime pas la lourdeur de ce logiciel et sa mauvaise tenue en charge.
Merci pour votre retour
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
participants (13)
-
Alexandre -
Bernard BELLE -
cam.lafit＠azerttyu.net -
Christophe BAILLON -
Gilou -
gmonne＠free.fr -
guillaume pancak -
Julien Escario -
Manu -
nap -
Radu-Adrian Feurdean -
Wallace -
Xavier Beaudouin