Rechercher dans la communauté

as: je crée un nouveau thread pour ne pas interferer avec celui de Lemrid (thread=14816) qui parle d'un sujet similaire, mais pas tout à fait; je modifie une partie de mon contenu pour adapter à la nouvelle situation Vous pouvez lire/telecharger ce document au format pdf à l'adresse suivante : http://www.scribd.com/doc/17262364/appelacontributionmonitoringdistribue Vous avez la possibilité de l'imprimer pour le lire à votre rythme, vous êtes invités à l'envoyer à vos collegues, contacts, amis; vous êtes priés de poser vos remarques et suggestions, pour le bénéfice de tous. Introduction ------------ La qualité constatée par les clients ADSL en algérie, nottament les utilisateurs sur ce forum est sujette à polémique. Afin de pouvoir évaluer de façon objective les performances, et de constituer une base de conaissances, je propose qu'un projet open source soit lancé dans ce sens, et votre aide sera indispensable pour sa réussite. Je vous invite à lire la présente proposition, ou de sauter vers la section qui vous interesse dans le text si vous n'avez pas le temps de tout lire; vous pourrez reprendre plus tard, à votre aise. La problematique ----------------- Dans l'objectif de mettre en place un projet open source pour le suivi des performances du réseau ADSL, je propose d'evaluer la proposition suivante, et je vous prie d'apporter vos commentaires, qui seront plus que bienvenus : Résumé : -------- *Quoi* : une méthode pour collecter, analyser et publier les performances des reseaux ADSL en algérie *Pourquoi* : afin de constituer une base de donnée vivante, sensibiliser les gens, isoler les problemes, avoir une influence eventuellement, faire améliorer les choses *Comment* : en invitant les gens a donner leurs idées, critiques et suggestions, savoir faire, expriences Si dix personnes, par exemple, participent avec une ligne de code chacune chaque jour, le code client et serveur seraient terminés en quatre semaines; ça vaut le coup de tenter l'experience ^^ Qui peut contribuer ------------------- - utilisateur ADSL : en effectuant des tests (en utilisant le futur logiciel), vous aiderez la communauté a detecter les defaillances des fournisseurs, les goulots, isoler votre probleme. Vous pouvez aussi contribuer en donnant votre avis sur la question, en signalant un bug, parler du projet autour de vous. L'outil vous permettra aussi d'identifier la nature de votre probleme, et à terme (pour certains) de les résoudre. - developpeur/chercheur : en ecrivant des bouts de codes, des idées techniques, des analyses eventuellement. Aucun besoin de s'investir lourdement, une fonction ou deux suffiront pour faire avancer l'ensemble - technicien/commercial chez un provider : en parlant de ce projet aux administrateurs de votre entreprise, en lisant la documentation qui l'accompagne, en étant convaincu que cet outil permettra à votre employeur d'améliorer son service, sans débourser un centime en R&D Comment contribuer : -------------------- En proposant des idées, en parler autour de vous, proposer des fonctionnalités (wishlist), en débattre sur le forum, donner son avis, ... Le projet ---------- - L'outil proposé permettra d'afficher les tests en ligne sur un site web, par région, fournisseur d'accès, qualité - La récolte des tests est anonyme et ne concerne que les details techniques - le rapport est envoyé, et une copie est gardée sur le disque dur de l'utilisateur (qu'il pourra utiliser pour réclamer auprés de son fournisseur, ou poster sur un forum afin qu'il soit assisté) - L'outil proposé permettra aux nouveaux clients de choisir, selon la région et le provider, la meilleur configuration selon leurs souhaits - L'outil proposé permet d'avoir une evaluation indépendante des performances globales des fournisseurs d'accès à internet en algérie, constitue une base d'aide à la décision, enrichie les recherches/rapports/articles dans le domaine Les metriques ------------- Les parametres que je vois interessants à evaluer, sont à mon avis : - le debit en download + le temps de lattence : le debit uniquement ne suffit pas, car lui meme est affecté par d'autres parametres (par exemple, la congestion sur le reseau; au moment du test si l'upload du client en question est elevé par rapport aux max alloué, le download en prend un coup pour certains cas, son ping aussi) - le systeme d exploitation : etant donné que les performances dependent beaucoup du stack tcp/ip qui est embarqué sur le systeme; il serait interessant de connaitre la version de l'os (les implementations sur windows par exemple ne sont pas respectueuses des recommandations) - le download en bulk et en raffale : le systeme ayant ses caracteristiques intrinseques (depassement (overshoot), temps de montée (rise time), réponse permanente, d'ailleurs si vous voulez les 'voir' il suffit de voir evoluer le graph de emule ou utorrent : ça commence par monter suivant presque une sigmoide, puis redescend, et oscille autour d'une valeur; c'est le comportement typique, c est pour cette raison que le telechargement d'un fichier de 1Mo est plus rapide en gros que 10 fichiers de 1024 Ko) - l'horaire du test : puisque le systeme dans son ensemble depend de ceci (heure:minutes) - pour la region, je pense qu'il est plus interessant de granulariser en donnant si possible le rattachement par rapport au dslam (car parfois les goulots, sont à ce niveau la, et le decoupage par dslam est plus logique sur un reseau adsl que le decoupage geo. cette information peut etre "sniffée" lors des echanges ppp entre l'hote et le dslam, eventuellement ) Pour les quatre premiers parametres, leur récolte ne constitue pas de problemes majeurs, et une programmation classique est adequate. Orientations du projet --------------------- voici les aspects que j'estime necessaires : 1 - le test devrait etre automatisé (c'est pas tres mechant, sur linux/gnu à la rigueur c est un script shell qui lance un wget et qui grep le temps de download) : + pour que l'utilisateur n'ait à intervenir que peu (human factor) + pour collecter un plus grand nombre de metrics + pour homogeneiser les resultats + pour la collecte automatique (ça va de paire) 2 - si le test est automatisé, il doit etre : + open source (en python, perl, java ou autre) + multiplateforme (tout le monde n'utilise pas linux ^^) 3 - il doit etre open source : + pour garantir l *evolution* : chacun pourra rajouter ses fonctions dans la base de données de code + pour assurer la *confiance* : pas de distribution de logiciels malicieux + pour que ce soit une base de connaissances : quelque chose qui marche en industrie, c est toujours interessant pour les etudiants/demandeurs de savoir + si reussite il y'a, c est un projet qui émule, et qui pousse a voir davantage 4 - le test doit etre propagé chez un grand nombre : voila une bonne occasion pour faire les fameux Fwd sur nos contacts ^^ (le grand nombre garanti la fiabilité/répétabilité des resultats) 5 - les *resultats* doivent etre *publiques* : aucun interet pour l'utilisateur final de participer a un "sondage" automatique s'il n'ya pas de retour d'experience je vois en ça une bonne occasion pour commencer des choses assez sympa autour de problematiques bien reelles, et des objectifs bien palpables Et les tests de debits en ligne ? ---------------------------------- Pourquoi les résultats de tests manuels/semi automatiques ne sont pas pertinents (comme mireadsl, zdnet speedtest, et les autres) : - le resultat produit n'est pas sous forme traitable (dans un tableur, ou sur une base de donnée) - a cause de ça leur richesse est limitée, vous ne pouvez pas faire de statistiques (moyenne, max, min, deviation) - pour qu'il soient utilisables, par exemple classer la qualité par région, par dslam, par debit max, par congestion, ... il faudrait reprendre ces tests et les transcrire en une ecriture traitable. trop contraignant pour un projet qui est basé sur le collectif/collaboratif Méthodologie ------------- En discutant autour de la meilleur façon de deployer un tel systeme, j'ai pensé à la méthodologie suivante : 1 - le choix des metriques : quels sont les elements que le programme devrait collecter chez le client. Bien entendu certains sont evidents, comme le debit en download et le debit en upload, on devrait aussi en determiner d'autres; dans ma vision premiere, je pensais à : + le ping : pour quantifier la congestion du réseau + la qualité du dns (temps de reponse, satisfaction des requetes) + le systeme d'exploitation + la date et heure du systeme (je pensais plutot à un synchro avec un serveur externe, histoire d avoir une pin point accuracy, et surtout etre synchro et eviter les eventuels decalages de l'horloge locale, les données dans leurs ensembles seraient alors homogenes d un point de vue timestamp) + l'adresse ip de la _passerelle_ adsl: pour pouvoir localiser le dslam qui est responsable du raccoredement (un mecanisme plus elaboré pourrait etre ensuite appliqué pour mieux localiser par region) Je pense que ces metriques pourrait etre deja un bon debut 2 - le choix de la façon de distribuer ce software : pour que l'utilisateur soit le plus à l'aise dans son utilisation, et pour qu'il soit utilisable sur un tres grand nombre de plateformes. est-ce que le programme doit etre installable, telechargeable ? doit-on le distribuer sous forme de binaire, ou source ? doit-il demarrer sur un page web ? (mes choix perso : source, telechargeable, terminal) 3 - le choix du langage de developpement : si on utilise un langage populaire, les rajouts se feront plus naturellement. on m'a conseillé java webstart, pour lancer des applications à partir de pages web, parait-il. je pensais pour ma part a un programme en python qui demanderait quand meme de telecharger l'interpreteur pour les plateformes qui n'en sont pas munies, mais l'avantage reste d'avoir du source en main (et donc de la richesse, et un confort), et une idée derriere la tete celle d'utiliser plus tard l'excellent scapy[1] pour performer des tests beaucoup plus en profondeur. 4 - la façon de rapporter les données collectées : renvoyer un rapport automatiquement, ou proposer au client de poster le fichier de rapport lui meme ? (moins automatisé), sous quel format (xml, csv,...) ? (mes choix: automatique (avec confirmation); xml) Pourquoi contribuer ------------------- Aussi, pour les gens qui ne voient pas encore l'utilité d'un tel outil, je vais tenter d'exposer ce qui me parait etre pertinent : - vous etes manager/vous travaillez dans le domaine des tic : impliquez vos ingenieurs pour participer à ce projet ne serait-ce que par une ligne de code par jour; votre retour sur investissement serait de collecter des données réelles sur les comportements d'un réseau de grande taille; une telle base de données : + coute tres cher (si vous arrivez à trouver les gens qui proposent ça) + n'est pas accessible legalement (sauf si ce projet aboutit) + les isp ne peuvent vous fournir de telles données : trop strategiques + l'analyse de ces données constitue une richesse + constitue une pub pour vous - vous etes etudiant/chercheur/developpeur : idem, les données réelles ne sont presque jamais publiées, vous pourrez faire valider vos modeles, voir si vos solutions collent à la réalité, developper des méthodes - vous etes utilisateurs final/futur client : l'analyse de ces données vous permettent de savoir si le probleme est isolé ou global, vous permettent d'avoir un avis informé (pour choisir votre prochain fournisseur selon votre region, vos exigences), vous permet d'avoir de l'aide rapidement puisque l'ensemble des données _utiles_ est recolté Pas encore convaincus ? ----------------------- Le fournisseur d'accès à internet, et d'une façon générale, le prestataire de service sera d'une oreille attentive dès que les clients s'expriment collectivement et d'une façon organisée. Il suffit d'influencer l'évolution du chiffre d'affaire pour que le management ajuste sa politique. Ce n'est pas la raison la plus parlante, mais elle me semble un argument de plus pour convaincre du bien fondé de cette démarche. (Merci à SecDz de m'avoir rappelé d'argumenter sur l'interet des ISP concernant cet outil dans le benefice du client) Les graphs suivants représentent le chiffre d'affaire ainsi que le nombre total des abonnés particuliers ADSL du fournisseur Eepad pour le mois de mai 2009. Remarquez que pendant la durée du mois, ainsi que sur certaines portions, le mouvement massif de clients influe sensiblement sur les performances (baisse de 23.-- % en CA). (Pour les graphs, merci de consulter le pdf, le lien est au debut du post) Quelle est la suite ? --------------------- Pour le moment, les choix à déterminer sont : - Que mesurer - Comment déployer - Avec quel language - Sous quelle forme rapporter les données Vous en pensez quoi les gars ? Portez-vous bien. [1] scapy : logiciel en python pour la manipulation de packets tcp/ip, excellent pour le debug, l'academique ou l'assessment (de firewall, par exemple) http://www.secdev.org/projects/scapy/

Après avoir posté un sujet sur smokeping, voici un autre outil de monitoring réseau dont une entreprise ou FAI aura besoin pour créer de jolies cartes de la météo de son réseau (Bande passante notamment ...). Des cartes qui peuvent servir à re-router le trafic par exemple s'il est saturé sur un chemin. http://www.network-weathermap.com/ ou http://netmon.grnet.gr/weathermap/ Exemple de Weathermaps chez OVH : http://weathermap.ovh.net/ ou encore Weathermap4RRD : http://weathermap4rrd.tropicalex.net/ Salutations amicales

Sahitou, Vous connaissez peut être un bon nombre d'outils de monitoring et pour ceux et celles qui cherchent un outil de monitoring réseau sympa, j'ai installé hier soir smokeping (je suis tombé dessus sur OVH à vrai dire et par curiosité je l'ai installé sur ma Debian). Donc à tester avec un apt-get install smokeping et vous trouverez des tutoriels assez simples pour le configurer alors smokerez-vous du ping ? Site officiel de Smokeping