Announcement

Collapse
No announcement yet.

Besoin de conseil - Monitoring distant multi clients, multi plate formes et multi app

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Besoin de conseil - Monitoring distant multi clients, multi plate formes et multi app

    Bonjour,

    Ma société a un projet ambitieux de monitoring distant multi clients, multi plate formes et multi applicatifs

    Je m'explique...

    Une société comme la notre qui surveille l'infrastructure, le réseaux, et les applications (type SAP, Oracle) de plusieurs clients et ça via un VPN par client.
    Tout la partie monitoring et configuration par exemple pour SAP est déjà faite par mes soins.


    Les données seront hébergées sur un SAN et sauvegardées.

    Ensuite nous voulons monter une plate forme VMware ESX.

    Actuellement nous sommes dans une phase d'industrialisation de la chose et c'est là que j'aurais besoin de conseils :


    Créer une VM nagios par client pour pouvoir faire face facilement à la venue de nouveaux clients avec des spécifications à chaque fois particulières et ainsi garantir un meilleur service et une confidentialité forte.

    L'idéal serait ensuite d'avoir un serveur Nagios qui viendrais fédérer les autres et avoir une vision globale pour les personnes dédiées à la surveillance du monitoring et c'est là que je ne sais pas si Nagios le permet ?
    Peut-on définir un serveur nagios maitre qui va remonter les alertes d'autres serveur nagios "esclaves"?


    Ensuite toutes les données sont stockées dans une base Mysql avec l'outils NDOUtils, mais comment les remonter via une interface graphique...? et donc avoir un historique... Existe-t-il des outils pour le faire... si oui lesquels... ???
    Niveau base de données on est parti sur une VM hébergant un serveur de base de données MySQL pour tous les autre VM. Est-ce la bonne solution ou faut-il plutôt intégrer directement un serveur MySQL dans chaque VM Nagios Client ?

    De plus, nous avons envie et besoin de tracer tous les incidents via une gestion de tickets type GLPI (sans utiliser la partie inventaire mais uniquement la partie helpdesk) et donc pour faire référence à un historique d'alertes (suite aux alertes 1,5,7,9 du tel et tel on a décidé de faire ceci...)

    Parallèlement à ça, je suis entrain de voir pour dimensionner le serveur ESX mais pour cela j'ai besoin de savoir comment je dois dimensionner mes VM Nagios et là j'ai vraiment besoin de conseils...


    Sachant qu'une VM Nagios va monitorer entre 10 et 20 éléments (serveurs, routeurs, switchs, application comme SAP ou oracle...) et en environ une 20ène de services par éléments, comment je dois dimensionner mes VM niveau CPU, RAM et I/O Disques et I/O Réseaux

    Ci-joint un plan de notre future infrastructure... mais celle-ci peut encore évoluer en fonction de vos remarques et de vos conseils.

    Merci d'avance

    TAC


  • #2
    Bonjour,

    Je pense que tu peux regarder du côté d'une solution distribuée http://en.doc.centreon.com/DistributedArchitecure

    Tu va définir une VM poller par Client (au moins tu n'aura pas trop de problème à trovuer des noms ) et vu qu'il n'y a rien de différents entre les poller que leur conf (et leur ip), tu va pouvoir t'en donner a coeur joie avec les clones.

    Je te conseilel d'avoir un nagios central qui va juste monitorer les VM et qui va avoir a côté de lui un petit module ndo2db qui va recevoir les infos des VM et les mettre dans une base mysql. Ici une seule base suffit, pas la peine de t'embéter à en mettre une par VM (et comme ça les vm sont vraiment facilement switchables car il n'y aura que de la conf, pas de data).

    Centreon va ensuite utiliser les infos de la base (qu'on nomme base ndo) pour afficher les états. Tu peux dans l'interface ne voir qu'un poller, et donc qu'un client en particulier (je ne sais pas si au niveau ACL c'est bon, je n'ai pas testé mais ca devrait je pense). Il va aussi récupérer et tracer toutes les données de métrologie.

    Question sizing, 20*20=400 checks, c'ets vraiment pas grand chose tu peux me croire. Surtout que certains check n'on pas besoin d'être très souvent (genre les disques). Donc CPU pas un problème, RAM, ca ne va rien bouffer (aller, je vote pour 20Mo de Nagios pour chaque poller au grand maximum de charge.... on a vu pire...). I/O disques ce qui va bosser c'est princiaplement ta base mysql, ici une physique serait bien (je ne suis pas fan des VM en ce qui concerne les I/O). Reste à voir combien de clients vous allez avoir. S'il faut blinder un élément, c'est les I/O de la base mysql (au pire beaucoup de cache write et ca roule hein). Partie réseau, alors là c'est peanuts. A titre d'exemple, je monitore dans les 6000éléments toutes les 5minutes, et je suis à peu près a 80ko/s .... pas violent donc.

    Concernant GLPI, alors là je ne peux pas t'aider du tout, je n'ai jamais mixé les deux
    Cependant, tu peux lancer une "commande sur événement" lorsqu'un problème arrive avec nagios, donc si tu peux ouvrir un ticket en ligne de commande, c'est bon.

    Bref, pars sur un centreonv2 en mode distribué, avec du Nagios3 au bout, du ndo qui remonte dans uen base commune, un Nagios par VM + un qui monitore les VM. Et hop, c'est réglé
    Auteur de Shinken, outil de supervision compatible avec Nagios et orientée supervision distribuée hautement disponible et mulitplateforme.

    Comment

    Working...
    X