Effectivement :) Merci à tous pour vos conseils !
Cdt, Thin-Hinen Le 1 juil. 2017 3:01 AM, "David Ponzone" <david.ponz...@gmail.com> a écrit : > Oui mais tes sondes, elle voit comment le traffic ? > Soit tu en as une en coupure de chaque PC, soit tu en as une sur chaque > switch sur un port où le mirroring est activé. > > David Ponzone > > > > Le 30 juin 2017 à 19:21, Thin-hinen Hedli <thinhinenhe...@gmail.com> a > écrit : > > Je pensais à un ensemble de sondes dispatchées pour "retranscrire", > envoyer des infos sur le trafic vers le collecteur plutôt que du mirroring > !? > > Le 30 juin 2017 à 19:11, David Ponzone <david.ponz...@gmail.com> a écrit : > >> Hmm t’as plutôt intérêt à faire ça avec un port du switch en >> monitoring/mirroring :) >> Par définition, le routeur ne voit pas le traffic entre les machines dans >> le même LAN (ou alors, faut sérieusement t’inquiéter). >> Le switch est le seul équipement qui voit tout passer (et bien entendu, >> l’usage de petit switch dans les bureaux à la mode low-cost n’est plus >> possible). >> Donc si tes switchs ne savent pas faire ça (c’est assez banal >> maintenant), faut les changer. >> >> >> >> Le 30 juin 2017 à 19:07, Thin-hinen Hedli <thinhinenhe...@gmail.com> a >> écrit : >> >> Pas dans la "conversation publique" mais en échangeant avec une personne >> après avoir précisé mes besoins. >> En effet, je n'étais pas assez précise sur ma problématique, ce qui >> peut sûrement restreindre les solutions proposées, je vais essayer alors de >> détailler mon architecture et mes besoins. >> >> >> Mon objectif est de savoir depuis n'importe quel poste ( si possible), >> ce que reçoit et envoie un poste X , de savoir quel est le type de flux >> reçu ( vidéo ...) et sa source ( dans le cas de la vidéo, quelle adresse >> ip multicast, le port ...). Et encore mieux si je peux avoir certaines >> statistiques comme le débit du flux( pas primordial). >> En plus de cette vision globale au niveau des flux, il me faudrait >> connaître l'état ( en cours d'exécution, arrêté ...) de toutes les >> applications et services développés par l'entreprise en temps réel sur >> un poste x depuis un autre poste y. >> Je suis en fait dans le cas d'un LAN totalement fermé où je n'ai pas un >> point où convergerait tous les flux. >> Mon architecture est telle que schématisée et je voudrais si possible >> avoir un "superviseur" branché à un des routeurs et que toutes les infos du >> trafic soient envoyées à ce "superviseur-serveur" pour savoir ce qui se >> passe sur la machine host sachant que la plupart de son trafic ne passe >> naturellement pas par cette machine ni même le routeur (R2) . Est ce que >> ces solutions proposées engendrent beaucoup de trafic, peuvent elles être >> source de congestion ? >> >> superviseur >> SW + >> + + >> ++++++++++++++++ >> +Routeur R1 + >> ++++++++++++++++ >> + >> + >> + >> ++++++++++++ >> +Routeur R2+ >> ++++++++++++ >> + + >> SW SW >> + >> + >> host >> >> >> Merci pour tous conseils, >> >> Cdt, >> >> Thin-Hinen >> >> >> Le 30 juin 2017 à 18:45, David Ponzone <david.ponz...@gmail.com> a écrit >> : >> >>> Quelqu’un t’avait suggéré ntop pour de la supervision réseau ? >>> >>> >>> > Le 30 juin 2017 à 18:40, Thin-hinen Hedli <thinhinenhe...@gmail.com> >>> a écrit : >>> > >>> > Chère liste, >>> > >>> > Je vous remercie pour toutes vos réponses, diverses, cela me permet >>> > d'aiguiller mes recherches et de découvrir plein d'outils ! >>> > Je pense être en bonne voie. Avec les nouvelles demandes de mes chefs >>> je me >>> > réoriente sur ntop. >>> > >>> > Je me permettrais de revenir vers vous si besoin, >>> > Bonne soirée à vous ! >>> > >>> > Le 8 juin 2017 à 23:54, Raphael Mazelier <r...@futomaki.net> a écrit : >>> > >>> >> >>> >> >>> >> On 07/06/2017 17:41, Jean-Henri Antunes wrote: >>> >> >>> >>> Bonjour a tous, >>> >>> >>> >>> ayant débuté sur Nagios, What's UP Gold et un outil maison on a >>> testé un >>> >>> peu d'autre trucs, Zabbix, Centreon, shinken, puis on est resté sur >>> >>> Check_mk. >>> >>> >>> >>> Check Mk se pose comme bonne alternative... a essayer >>> >>> y a du graph de l'alerting, on peu y adjoindre nagvis pour des cartes >>> >>> etc... >>> >>> >>> >>> >>> >>> >>> >> Oui alors attention check_mk c'est plus un ensemble d'outils qui >>> gravitent >>> >> autour de nagios plus qu'une solution complète à mon sens. >>> >> On doit toujours utiliser un core nagios like (nagios, naemon, icinga, >>> >> shinken, ou meme le core light proposé) pour lancer les checks >>> générés par >>> >> l'auto discover check_mk. >>> >> >>> >> Ceci étant check_mk (que je vois comme un framework de check pour >>> nagios >>> >> like) est extrêmement intéressant. Je l'ai longtemps utilisé avec >>> succès et >>> >> plaisir. Livestatus est aussi quasi indispensable à toute gui au >>> dessus de >>> >> nagios (ou l'alternative dans icinga2). Je suis beaucoup moins >>> convaincu >>> >> par la gui mulisites. >>> >> >>> >> En revanche pour tout ce qui est graphing je ne me passerai plus de >>> >> grafana (et donc d'une vraie base tsdb graphites, influxdb ou mieux >>> >> prometheus). Cela demande certes des agents ou exporters divers, un >>> peu de >>> >> temps de setup mais après c'est un bonheur. >>> >> >>> >> Ça c'était pour la partie monitoring/graphing infra/métier quand on a >>> du >>> >> temps. Pour surveiller rapidement un réseau Obersvium ou LibreNMS >>> font bien >>> >> le taff, malgré tout le mal que j'en pense. Attention à ne pas avoir >>> des >>> >> switchs trop sensible aux requêtes snmp (toute série de switchs en >>> deux >>> >> lettres d'un constructeur commençant par J au pif). >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Raphael Mazelier >>> >> >>> >> >>> >> >>> >> --------------------------- >>> >> Liste de diffusion du FRnOG >>> >> http://www.frnog.org/ >>> >> >>> > >>> > --------------------------- >>> > Liste de diffusion du FRnOG >>> > http://www.frnog.org/ >>> >>> >> >> > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
