Le 23/10/2013 08:24, nap a écrit : > > > > 2013/10/22 Wallace <[email protected] <mailto:[email protected]>> > > [...] > Du coup en partant de notre Nagios (Centréon no way, Shinken > l'interface > est pas mature, Zabbix on a pas aimé la façon dont c'est architecturé) > on a branché tous nos outils dessus, ce qui impose donc que les > équipements soient déclarés et supervisés pour pouvoir utiliser les > outils. [...] > > > Salut, > > j'avoue avoir un avis un peu opposé sur ce point justement. La > supervision devrait plutôt être banchées sur la (ou les) source(s) > d'informations du parc (CMDB évidement, mais aussi vmware, active dir > ou encore le range ip) et créer sa configuration à partir de ça (être > quasi-complète et quasi-automatique dans l'idéal). Bon par contre je > reconnais que pour l'instant ce n'est juste pas faisable facilement, > mais ça va arriver dans les prochains mois (ainsi qu'une UI plus > mature pour Shinken justement, je cherche des courageux testeurs > justement :) ). > > Par curiosité, comment tu branches les autres outils dessus > exactement, car parser la conf de nagios est loin d'être trivial, et > parser le objects.dat c'est lourd :( > >
Notre cas vient du fait qu'après avoir testé FusionInventory couplé à GLPI on arrivait pas à ce que l'on souhaitait. Déjà GLPI n'est pas aussi souple qu'il le prétend, on voulait une vue simplifiée pour les tickets clients MAIS avec le champs équipement concerné. Nos clients savent sur quel serveurs sont leurs applicatifs dans chaque environnement, les docs qu'on fournit sont très claires là dessus. Sur GLPI tu ne peux pas avoir ce champs en vue simplifiée. Si en vue normale on enlève tous les champs dont on ne veut pas que le client ait accès genre les SLA qui doivent être automatiques, cela implique que nous non plus on est pas accès à ces champs. Bref pas adapté, la notion GLPI de client est à mon avis plus orienté pour un technicien / admin qui doit créer le ticket pour l'utilisateur final par téléphone ou autre. On utilise pas VMWare mais du Xen over Debian et on a toutes nos informations sur l'état des machines, possibilités de les piloter en cli. Du coup le branchement se fait par un script qui parse le status.dat de Nagios et qui nous le renvoie en json. De là le résultat est utilisé dans l'intranet on a l'état de supervision, les graphs récupéré des serveurs Munin, l'état des sauvegardes sur chaque robot, ... Pour être plus précis notre système est fait pour que chaque serveur ait une nomenclature stricte sur son nom avec un FQDN derrière. Ce fqdn est déclaré au minimum en ip v6 (on fait plus de réseaux privés v4 chez nous), en v4 en plus si services publics. De là notre déploiement de vm s'appuie sur ce fqdn, donc faut déjà que la machine ait été déclarée dans le dns et l'ipam. Quand la vm est déployée, la gate ssh ne connait que les machines présentes dans la supervision, impossible de se connecter à un autre serveur ou à des ressources externes par ip ou fqdn. Donc pour pouvoir se connecter en ssh au nouveau serveur, ce dernier doit être dans la supervision avec son type d'OS qui va mettre les sondes de base en place. Ce qui fait que lorsqu'on se connecte à un nouveau serveur, il est déjà référencé en supervision et déclenche tout seul : la métrologie, la présence sur l'intranet, les robots de sauvegarde, les config ssh, ... Après pour ce qui est de la gestion de parc, FusionInventory remonte des infos sympas mais au final on remonte les mêmes avec la supervision. On a dans les 20 checks par défaut pour un Linux qui nous remonte tout ce dont on a besoin comme indicateurs.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
