iSup Dveloppement dune plate-forme de supervision complte et homogne pour les rseaux Lorrains

Sbastien Morosi
CIRIL - Centre Interuniversitaire de Ressources Informatiques de Lorraine Rue du Doyen Roubault 54500 VANDOEUVRE-LS-NANCY - FRANCE Sebastien.Morosi ciril.fr

Vincent Delove
CIRIL - Centre Interuniversitaire de Ressources Informatiques de Lorraine Rue du Doyen Roubault 54500 VANDOEUVRE-LS-NANCY - FRANCE Vincent.Delove ciril.fr

Rsum
Fort dune grande exprience dans ladministration et la supervision des rseaux, le CIRIL a entrepris en 2006 le dveloppement dune nouvelle plate-forme afin de superviser dune faon plus homogne les rseaux quil administre ainsi que les services associs. De la conception du systme dinformation jusqu la prsentation des statistiques collectes, nous nous sommes efforcs de mettre en uvre une solution de supervision sinscrivant dans une dmarche dunification, dautomatisation et de dlgation des tches dexploitation dans laquelle sest engag le CIRIL. Par ailleurs, la diversit des technologies et des quipements surveiller nous a pouss apporter une attention particulire aux aspects de flexibilit et d'extensibilit de cette solution. Lapplication iSup, ne de ce travail, permet de remplacer la quasi-totalit des outils prcdemment utiliss afin de remplir les diverses fonctions de supervision des rseaux StanNet, Lothaire et eLorraine.

Au CIRIL (Centre Interuniversitaire de Ressources Informatiques de Lorraine), la multiplicit des outils couple la volont de disposer d'un niveau de fonctionnalits homogne sur l'ensemble des rseaux oprs, nous ont amens en 2006 repenser entirement le systme de supervision en place. Lexprience acquise dans ce domaine travers divers projets nous a permis de considrer le dveloppement dune nouvelle plate-forme comme une alternative envisageable, face la mise en uvre dune solution commerciale ou libre. L'intgration aux diffrentes bases de donnes existantes impose dans tous les cas des dveloppements importants. Les lments que nous prsentons dans cet article sont pour la plupart oprationnels depuis quelques mois ce qui nous permet davoir un recul suffisant pour valuer les bnfices du travail accompli ainsi que les possibilits restant explorer. Aprs avoir expos brivement le contexte, nous prsenterons les choix raliss afin de rpondre au mieux aux contraintes prcdemment cites. En premier lieu, nous prsenterons les bases de la plate-forme mise en uvre. Par la suite nous dtaillerons successivement les fonctionnalits avances que nous avons pu construire sur ce noyau solide.

Mots clefs
Supervision, statistiques, mtriques, alertes, cricket, RRD

Contexte et besoins

Introduction

La demande toujours plus importante en matire de fiabilit, de disponibilit et de scurit a plac depuis maintenant plusieurs annes la mtrologie et la supervision au cur du mtier dingnieur rseau. La connaissance et la surveillance du comportement de systmes de plus en plus complexes passent aujourd'hui par l'utilisation d'outils parfaitement adapts. Une bonne solution de supervision doit ce titre permettre aux ingnieurs de veiller au bon fonctionnement des services au quotidien (rapports dactivit, alertes sur dtection de problmes) et aux dcideurs de faire les bons choix en terme de pilotage (dimensionnement, volutions).

La mission principale de la cellule rseau du CIRIL est d'assurer lexploitation et ladministration des rseaux StanNet1, Lothaire2 et eLorraine3. Ces trois rseaux forment un ensemble regroupant un nombre important d'quipements (de l'ordre du millier), de
1 Rseau mtropolitain nancien de l'Enseignement Suprieur et de la Recherche 2

Rseau Lorrain de Tlcommunication Haut dbit pour les Applications Informatiques de la Recherche et de l'Enseignement Suprieur Rseau haut-dbit des lyces de Lorraine

technologies, de services mais aussi d'interlocuteurs. Ces dimensions justifient la dmarche dautomatisation et de dlgation des tches dexploitation dans laquelle sest engag le CIRIL depuis plusieurs annes. Dans ce contexte et tant donnes les volutions de plus en plus rapides apportes aux infrastructures administres, la supervision tait devenue une tche fastidieuse en terme de maintenance. Afin de couvrir l'ensemble des besoins, de nombreux outils avaient t dploys au cours du temps : netup, MRTG, Nagios, Cricket, Cacti et des scripts maison. Ces outils tant tous indpendants, leur configuration lors des modifications de l'infrastructure engendrait un travail manuel fastidieux et invitablement source d'erreurs. Par consquent, la cohrence entre les outils et les quipements tait galement de plus en plus difficile assurer et vrifier. De plus, les outils en place ne permettaient ni d'offrir un accs authentifi et personnalis nos correspondants, ni de s'interfacer avec notre systme d'informations. Conscient du travail que reprsente le dveloppement complet dune nouvelle solution, nous avons choisi de rutiliser un certain nombre de composants disponibles et dj prouvs. Lessentiel de notre travail sest ainsi concentr sur l'intgration de logiciels libres, l'automatisation des tches et le dveloppement de fonctionnalits valeurs ajoutes.

dfinition d'une mtrique4 comme le trafic sur une interface se dcompose en plusieurs lments : les dbits entrant et sortant la vitesse du support physique associ A partir de ces informations il sera alors possible de dterminer les pourcentages d'utilisation d'une ligne et d'en suivre l'volution au cours du temps. Toutes les informations de mme nature (dfinissant une mtrique) seront ainsi accessibles simultanment. En outre, la dfinition d'une mtrique spcifie galement les modles de graphes qui seront utiliss pour raliser l'analyse visuelle des donnes. La diversit des technologies et des quipements entrane un support variable dans l'implmentation des sources de donnes accessibles. A titre d'exemple, certaines interfaces ne permettent pas la collecte de compteurs SNMP 64 bits pour la mesure de leur trafic. Il est alors obligatoire d'interroger les compteurs SNMP 32 bits. Cela conduit donc crer deux dfinitions pour une mme mtrique. Le choix entre ces dfinitions sera ensuite ralis de faon automatise en fonction du type d'quipement supervis. Ce fonctionnement vite de multiplier inutilement les mtriques. Les paramtres ncessaires l'instanciation d'une mtrique sont associs chacune de ces dfinitions. En reprenant toujours le mme exemple, la collecte SNMP du trafic d'une interface requiert la connaissance de l'entre ifDescr correspondante. Au final, une mtrique est donc entirement dfinie par : les sources de donnes qui la composent le type d'quipement auquel elle se rattache les paramtres ncessaires son instanciation

Systme d'information centralis

Dans le souci de concevoir une plate-forme flexible, l'ensemble des lments participant la configuration et la gestion de la plate-forme est runi en un emplacement unique : une base de donne MySQL. Nous allons dcrire ici les notions principales constituant ce systme d'information.

3.1

Les mtriques

3.2

Les services

La collecte des informations est la premire tape dans l'laboration d'un systme de supervision. Un objet identifiant une source de donnes a donc t dfini. Nous entendons ici par source de donnes la description d'une localisation permettant d'obtenir une valeur caractristique comme une charge CPU, un dbit ou encore une temprature. Chacun des OIDs pouvant tre dcrit l'aide du protocole SNMP constitue ainsi une source de donnes distincte. Il existe naturellement bien d'autres faons de collecter des informations (interrogations LDAP ou SQL, rsultat d'excution d'un programme...) qui doivent tre supportes. La plupart du temps un certain nombre de paramtres devra tre fourni cet objet pour rellement accder aux donnes. Etant donn qu'une simple source de donnes est souvent insuffisante pour dcrire un comportement global, il nous a fallu regrouper plusieurs de ces objets pour dfinir une structure de donnes plus significative. Par exemple, la

L'ensemble des quipements superviss est renseign dans la base en prcisant pour chacun d'eux le nom, le domaine DNS, le type, l'adresse IP d'administration, et les paramtres SNMP (version, communaut) si ncessaire. En utilisant le type d'un quipement et conformment la dmarche prsente dans la partie prcdente, on sera capable de retrouver la totalit des mtriques accessibles pour ce dernier. En marge de la supervision, les informations de noms et de domaines pourront galement tre utilises afin de vrifier les enregistrements DNS pour les domaines concerns. Un service reprsente une instance de mtrique pour un quipement donn. A ce titre, il constitue l'lment de base de la supervision dans notre systme. Chaque service est associ un quipement et une mtrique dfinissant eux deux l'ensemble des sources de donnes collectes. Par exemple, le service associant la mtrique cpu au routeur gw1.nancy entranera la collecte de trois OIDs SNMP une frquence donne.
4

Ensemble de mesures caractrisant un comportement

Chaque service associ une mtrique qui ncessite le passage de paramtres doit dfinir des attributs qui fixeront les valeurs utiliser pour ces paramtres. Le service charg de la mesure du trafic d'une interface via SNMP devra, dans ces conditions, dfinir un attribut renseignant le nom de celle-ci (entre ifDescr). Ces attributs peuvent galement servir stocker d'autres types d'informations. En effet, l'obtention des dbits (max) d'une interface par interrogation SNMP n'tant pas toujours possible, ces attributs peuvent constituer un moyen astucieux de stockage de ces valeurs. Elles seront ensuite rcupres chaque collecte conformment aux explications dj fournies dans ce document. Un service peut finalement tre un service dit compos auquel cas il constitue uniquement une runion de services pouvant eux-mmes tre composs. Ce type d'agrgation est utilis pour superviser des fonctions plus abstraites dans leur globalit.

une liste d'tats : seuls ces tats conduiront l'excution du traitement. une plage horaire qui restreint l'activation du traitement une priode dfinie

Collecte et stockage des donnes

La fonction de collecte consiste rcuprer les valeurs pour l'ensemble des services de la plate-forme. La ralisation d'un nouveau collecteur n'a pas sembl ncessaire pour rpondre aux besoins attendus. En effet, le collecteur Cricket5, dj utilis par le pass, est apparu comme trs adapt en terme de flexibilit de configuration et de rapidit d'excution. L'utilisation de bases RRDs6 comme systme de stockage des donnes a galement constitu un lment de choix. La configuration de Cricket repose sur un ensemble de fichiers rpartis dans une structure arborescente. Chaque branche peut ainsi tre collecte sparment. Etant donn le trs grand nombre de donnes collecter sur Lothaire, nous avons choisi de parallliser la collecte en divisant la configuration dans plusieurs de ces branches. Leur taille est dtermine de telle sorte que le temps total de traitement de la branche ne puisse pas dpasser la priode de collecte (gnralement fixe 5 minutes) mme dans le cas o chaque rcupration de valeur conduit un chec par expiration. La configuration du collecteur est gnre entirement partir de la base de donnes dcrite dans la partie prcdente. Une modification de la base, telle que l'ajout d'un nouveau service, entranera automatiquement la reconstruction de la configuration. Ce fonctionnement permet d'assurer la collecte mme si la base de donne devient momentanment indisponible. A l'issue de la collecte, les valeurs rcupres sont stockes dans des bases RRDs spcifiques chaque service. Le fonctionnement de ces bases repose comme leurs noms l'indiquent sur le principe de Round Robin. Les bases de la plate-forme renferment quatre niveaux de dtails diffrents pour permettre d'tablir des vues trs dtailles court terme et plus globales long terme. Pour un service collect toutes les cinq minutes, l'intgralit des chantillons sera par exemple conserve pendant une semaine, les moyennes sur 30 minutes pendant un mois, les moyennes sur deux heures pendant un an et finalement les moyennes sur une journe pendant 3 ans. Conjointement toutes ces moyennes sont galement sauvegardes les valeurs minimum et maximum pour chacun des intervalles cits. Au final, cette solution offre un niveau de dtail trs intressant pour un cot de stockage (volume) relativement faible. La volont de conserver les informations sur de longues priodes oblige mener un effort particulier sur la
5

3.3

Les tats

A chaque service est associ un tat qui joue le rle d'indicateur de surveillance. Dans la pratique cet tat est matrialis par une valeur entire qui voluera en fonction de seuils dfinis par l'administrateur. Les seuils sont associs aux sources de donnes qui dfinissent la mtrique du service en question. Par exemple, les sources de donnes nommes par convention cpu5sec, cpu1min, cpu5min qui sont associes la mtrique CPU d'un routeur peuvent dfinir les seuils suivants : cpu1min : Si suprieur 90 alors tat = 1 cpu5min : Si suprieur 80 alors tat = 1 cpu5min : Si suprieur 90 alors tat = 2 Dans ces conditions, chaque service sera par dfaut supervis par les seuils lis aux sources de donnes dfinissant sa mtrique. Dans un souci de flexibilit, il est galement possible de surcharger les seuils par dfaut pour un service en particulier. Si un routeur particulirement charg entrane un nombre jug trop important de changements d'tats, alors les seuils peuvent tre adapts plus spcifiquement pour ce service. Chaque changement d'tat conduit la cration ou la modification d'un vnement enregistr dans la base. Ces enregistrements dcrivent donc l'historique de supervision et permettront par exemple la gnration de graphes d'tats. Des modles d'actions sont galement associs aux services pour permettre l'excution de traitements en rponse aux diffrents vnements gnrs par la plate-forme. Un modle est caractris par : un type d'action : envoi d'un SMS ou d'un courriel, excution d'une commande... un paramtre d'action servant reprsenter par exemple l'adresse du destinataire de la notification envoyer ou la commande excuter.

Utilisation du collecteur de Cricket : http://cricket.sourceforge.net/ Round Robin Database : http://oss.oetiker.ch/rrdtool/

prennit des donnes. C'est pourquoi la convention de nommage des services repose sur leur smantique plutt que sur la ralit technique. La modification d'un paramtre li un service ne doit donc pas conduire la perte o l'altration des donnes dj collectes. Par exemple, dans le cas d'un service charg de superviser le trafic sur une interface, une volution de dbit ou mme le changement de l'interface doit tre ralis en assurant la continuit des informations.

iSup a donc t conu pour que des moteurs d'analyse puissent tre dvelopps puis associs des services. Nous avons ce jour implment plusieurs algorithmes afin de dtecter les pannes et prvenir les dgradations de service : un mode basique, dterminant l'tat d'un service en comparant les dernires valeurs collectes des seuils, un mode plus volu bas sur des dpassement de seuils sur une priode glissante Le mode volu consiste dterminer si un indicateur a dpass un seuil trop longtemps pendant une priode donne, comme illustr sur la Figure 1. Prenons un exemple pour bien apprhender ce concept : Si la CPU de mon routeur a t suprieure 80% pendant plus de 30 minutes sur une priode de 60 minutes, alors il y a un problme . Cela revient donc additionner les priodes pendant lesquelles un service a dpass un seuil (les fentres grises t1, t2, t3 de la Figure 1) et cela sur une dure dtermine (la fentre glissante bleue de la Figure 1). Si cette somme est suprieure ce qui est tolr, alors il y a alerte.

Mtriques supervises

Notre projet initial de plate-forme de supervision comportait deux grands axes : disposer d'un outil robuste et polyvalent, mais galement des bonnes informations au bon moment. Nous avons vu jusqu' prsent que iSup est une plate-forme hautement configurable construite sur des bases robustes. Un travail important dans la mise en place de la supervision a consist dterminer les donnes collecter pour chaque type d'quipement ou de service. Nous avons essay de toujours nous tenir au ncessaire et suffisant . En effet, il faut toujours disposer des informations permettant de dterminer le bon fonctionnement d'un service, mais il ne faut pas pour autant s'encombrer d'informations inutiles. Trop d'information nuit la comprhension et la synthse rapide. Nous avons donc dtermin pour chaque service ou quipement les valeurs que nous souhaitions superviser et avons renseign la base iSup. Nous avons cr des modles de supervision afin de pouvoir appliquer automatiquement chaque quipement les paramtres par dfaut. De plus, afin de faciliter cette tche, des scripts d'auto-dcouverte ont t dvelopps et permettent en un temps minimum d'ajouter un nouvel quipement au parc supervis. A ce jour nous supervisons via iSup nos serveurs, routeurs, commutateurs, liaisons et interfaces. Nous envisageons cours terme d'y intgrer la supervision des services (VPN, DNS, messagerie...). A ce jour, environ 2000 services sont configurs dans notre plate-forme de supervision.

Figure 1: Dtection d'alerte avec fentre glissante Ces deux modes sont complmentaires : le mode basique nous renseigne sur l'tat d'un service en temps rel et va plutt tre utilis pour un rsultat binaire du type a marche ou a ne marche pas ; le mode volu a pour objectif de prvenir les dgradations de service en liminant naturellement les fausses alarmes.

6.2

L'exprience humaine

6
6.1

Analyse et alertes
La dtection de problme

L'interprtation des informations collectes est un point essentiel dans le mtier d'administrateur de rseaux et de systmes. Il est indispensable de savoir analyser les informations recueillies afin de dtecter et de prvenir les potentielles anomalies. Cette tche devient rapidement fastidieuse et consommatrice en temps si elle ne peut tre automatise et systmatise. Ainsi, une plate-forme de supervision doit tre en mesure d'analyser les informations collectes afin de prvenir les administrateurs en cas de dysfonctionnement.

L'analyse par l'oeil humain des mtriques supervises fait gnralement intervenir un paramtre qui n'est pas pris en compte par les deux modes prcdemment cits : l'exprience. Un administrateur va gnralement tre capable de dtecter une anomalie si une courbe n'est pas comme d'habitude . Afin de pouvoir reproduire cette analyse, nous envisageons de dvelopper un moteur capable de vrifier la dviation d'un paramtre par rapport une moyenne sur une priode passe. Il sera ainsi possible pour la plate-forme de supervision de dterminer si un paramtre se comporte comme d'habitude ou non. A titre d'exemple, un pic de charge rseau tous les soirs l'heure des sauvegardes n'est certainement pas problmatique. Par contre, le soir o ce pic n'est pas observ, il y a certainement eu un dysfonctionnement.

routeur rgional est gnralement plus sensible qu'une borne wifi. Nous avons identifi deux besoins bien distincts : l'alerte via message lectronique et l'alerte par SMS. L'alerte par SMS est destine aux administrateurs des services critiques. Ce type d'alerte est plus particulirement ncessaire en dehors des heures ouvrables afin d'alerter la personne d'astreinte. Ces alertes tant de la plus grande priorit, nous avons connect la plate-forme de supervision un botier permettant directement l'envoi de SMS. Les alertes via messagerie lectronique permettent de couvrir un ensemble plus large de services et surtout d'informer les quipes de permanence et/ou de support des dysfonctionnements observs. Comme l'ensemble des fonctionnalits de la plate-forme iSup, les alertes sont configures via des modles, chaque service pouvant par la suite tre associ un ou plusieurs de ces modles. Les vnements gnrs simultanment sont agrgs afin de gnrer une seule notification. A titre d'exemple, nous avons aujourd'hui un modle nous avertissant par messagerie de tous les changements d'tat d'un service, et un modle nous permettant d'envoyer un SMS la personne d'astreinte en dehors des heures ouvrables. Alerter est une chose, agir en est une autre. Nous avons tendu la notion d'alerte de iSup afin de pourvoir lancer une action de la mme faon qu'une alerte. Finalement une alerte n'est qu'une action particulire prise par la plateforme et nous pouvons associer un script un vnement. A ce jour, nous n'avons pas encore configur d'actions agissant directement sur les quipements afin de tenter de rsoudre automatiquement un problme, mais nous l'envisageons pour l'avenir.

Figure 2: Dtection d'alerte sur cart de la moyenne Comme l'illustre la Figure 2, le moteur va dterminer le profil du service supervis, puis il va appliquer l'algorithme de la fentre glissante pour dterminer si la valeur mesure s'carte trop de ce profil. Ce type d'analyse permettra de dtecter les comportements anormaux et devrait automatiser un peu plus encore le travail de l'administrateur qui ne peut se concentrer que sur les indicateurs les plus importants. Chaque service supervis par iSup va pouvoir tre analys par un ou plusieurs moteurs, l'administrateur ayant en charge l'association moteur/service et le paramtrage du moteur pour chaque service.

6.3

L'tat d'un service

L'objectif des analyses dcrites prcdemment tant de dterminer l'tat d'un service, nous avons souhait simplifier au maximum la comprhension du rsultat, et avons opt pour un code couleur : rouge/orange/vert. En effet, l'analyse de chaque service par un moteur va retourner l'un de ces trois tats, sachant que la smantique que nous y avons associe est la suivante : rouge : le service est indisponible orange : le service fonctionne, mais de faon dgrade vert : le service fonctionne correctement Notons galement que, parfois, l'tat d'un service ne peut tre dtermin (collecte impossible par exemple), nous avons donc introduit la couleur grise pour le reprsenter. Une fois l'tat de chaque service dtermin, nous pouvons passer l'tape suivante : la gnration d'alertes.

6.5

Journalisation

Il ne faut pas oublier que chaque changement d'tat d'un service ne fait pas obligatoirement l'objet d'une alerte, ou encore que les alertes peuvent se perdre. Nous avons donc souhait conserver l'historique de l'tat de chaque service. Il nous est ainsi possible de consulter tout moment l'historique d'un service et de connatre a posteriori le rsultat des analyses. Enfin, tout vnement gnr par la plate-forme est automatiquement archiv dans des fichiers (syslog).

6.4

Les alertes

Une plate-forme de supervision doit tre en mesure de prvenir les administrateurs en cas de dysfonctionnement important, ou en cas de potentiel problme. Les alertes n'ont pas toutes le mme niveau de criticit en fonction du service concern et du type de problme. Un

7.2.1

Tableau de bord

La vue synthtique de premier niveau a t rendue possible grce la mise en place d'un tableau de bord : eBoard (Figure 4). Cette vue consiste rassembler sur une mme page les services souhaits en les symbolisant par des ronds prenant les couleurs vert/orange/rouge en fonction de leur tat. Figure 3: historique de l'tat d'un service Cette vue a t rendue interactive par l'utilisation du format SVG. Ainsi, l'utilisateur obtient les informations contextuelles au service en le slectionnant.

7
7.1

La prsentation des informations

Pour qui ?

La prsentation des donnes est un point trs important pour une plate-forme de supervision, c'est en quelque sorte la partie visible de l'iceberg. La reprsentation des informations dpend en grande partie de la personne qui elles sont destines. Le besoin de personnalisation de cette prsentation a galement t trs dterminant dans notre dcision de dveloppement maison. Nous avons identifi dans le panel des utilisateurs de la plate-forme de supervision trois grandes catgories : le support de premier niveau : typiquement une hotline ncessitant une vue en temps rel de la disponibilit des services, afin d'orienter au mieux leurs investigations lors des appels d'utilisateurs les administrateurs : des personnes trs techniques ayant besoin d'informations dtailles avec un historique prcis mais court des dcideurs/investisseurs ayant besoin d'une analyse sur de longues priodes, afin de connatre les tendances et surtout prvoir les volutions De plus, le CIRIL administre/opre les rseaux pour de nombreux tablissements et essaye de toujours fournir aux administrateurs de ces tablissements des outils permettant de leur dlguer les oprations courantes. Respectant cette dmarche, iSup avait pour objectif de fournir aux administrateurs locaux l'accs aux informations concernant les quipements et services dont ils dpendent. Une des contraintes tait donc de proposer un accs authentifi permettant un utilisateur de ne visualiser que les services les concernant.

Figure 4: Tableau de bord eBoard La vue initiale a t ralise manuellement, les informations contextuelles et de statut sont contenues dans un fichier de donnes mis jour automatiquement par iSup. Ce tableau de bord t initialement mis en place pour la hotline du rseau eLorraine7. Un tel outil permet de limiter les demandes de la hotline vers les ingnieurs en charge des services. Le projet eLorraine faisant intervenir de nombreux prestataires, eBoard permet galement la hotline de rapidement identifier l'origine d'un problme lors d'un appel en provenance d'un lyce. 7.2.2 Rapports dtaills et personnalisation

7.2

Comment ?

Toutes les donnes collectes sont accessibles via une interface web. Chaque utilisateur est en mesure de consulter les donnes le concernant et a la possibilit de personnaliser son interface. Les droits des utilisateurs sont directement stocks dans la base de donnes de iSup.

Au quotidien, les ingnieurs rseau et systme ont besoin d'accder des informations techniques concernant les quipements administrs. Des donnes de type nombre de broadcast , niveau de remplissage des partitions ou pourcentage d'utilisation de la CPU sont des donnes permettant d'ajuster la configuration des quipements afin d'optimiser les services. Les donnes consultes doivent gnralement tre brutes (pas de moyenne), avec une priode d'chantillonnage

Rseau des Lyces lorrains, l'initiative du Conseil Rgional de Lorraine. eLorraine reprsente 215 tablissements relis via des liaisons xDSL une plate-forme rgionale de collecte et de services localise au CIRIL.

courte (au minimum de cinq minutes, voir de la minute), et enfin sur une dure relativement courte (quelques jours). Nous avons donc dvelopp une interface permettant de visualiser toutes les informations collectes, tout en choisissant la priode afficher. Tous les graphiques sont gnrs l'aide de l'outil RRDtool comme l'illustre la Figure 5.

rseaux distants (WAN) les liaisons restent trs coteuses et leur optimisation permet une rpartition intelligente des ressources. Un graphique de dbit ne permet pas de dterminer simplement si une liaison est sature ou non. Il faut coupler l'information de dbit la valeur de la bande passante pour en dduire le taux d'occupation. Des graphiques sont donc construits en temps rel par la plate-forme de supervision pour faciliter la comprhension des donnes collectes. Reprenons notre exemple : un dbit (habituellement exprim en bit/s) est transform en un pourcentage d'occupation de la bande passante, comme le montre la Figure 7.

Figure 5: Graphique dtaill Figure Pour tre totalement exploitables, ces donnes doivent gnralement tre prsentes en groupe, afin de dterminer s'il y a corrlation entre elles. iSup propose entre autre la notion de service compos pour pouvoir afficher sur une mme vue des donnes mettre en relation. Il est par exemple gnralement ncessaire de visualiser sur une mme page les graphiques reprsentant la CPU d'un routeur, le trafic et les temps de rponse sur ses liaisons afin de dterminer s'il y a une corrlation. iSup a galement pour vocation de donner aux correspondants du CIRIL la vue des informations les concernant. Tout utilisateur a gnralement des centres d'intrt varis et consulte quotidiennement les mmes donnes. Nous avons donc donn la possibilit un utilisateur de composer sa page d'accueil ; il peut y disposer ses graphiques favoris et ainsi les consulter trs rapidement.

Il est plus facile pour un nophyte de comprendre qu'une liaison est charge 80% et que cette charge augmente de 2 % tous les mois, plutt que de parler sDSL et bits par seconde. Dans le contexte des utilisations de ligne, il est surtout important de savoir si une ligne est sature ou non pendant les heures ouvres. Pour reprsenter cela, nous avons mis au point un graphique reprsentant le taux d'utilisation, comme le montre la Figure 8.

Figure 6: Page personnalise 7.2.3 Graphiques valeur ajoute

Figure 8: Graphique de rpartition de charge Sur ce graphique (histogramme empil), chaque barre de couleur reprsente la part de temps pour un niveau d'utilisation donne. De cette faon, une barre rouge (utilisation comprise entre 70 et 100%) de 50% pour un

Les donnes brutes ne sont pas toujours directement interprtables. Il est parfois ncessaire de les coupler d'autres informations pour en tirer une information facilement exploitable. A titre d'exemple, dans le cadre des

graphique couvrant 24 heures sera interprte de la faon suivante : pendant 12 heures sur 24, la bande passante utilise tait comprise entre 70 et 100% . Ce type de graphique, cumul sur plusieurs mois et ne tenant compte que des heures ouvres, permet de rapidement identifier les liaisons satures ou sous-utilises. Une demande prdominante de la part des institutions finanant les rseaux consiste optimiser le budget disponible afin de rendre le meilleur service chacun. Dans le cadre du projet eLorraine, le Conseil Rgional redistribue la bande passante aux tablissements les plus consommateurs, alors que les lignes les moins utilises sont redescendues des dbit plus faibles. 7.2.4 Golocalisation

permet la mise jour de l'ensemble des configurations. iSup va permettre de remplacer les nombreuses applications devenues trop lourdes maintenir. Nous disposons ce jour d'un outil flexible, modulaire et robuste qui nous permettra de continuer apporter de la valeur ajoute aux rapports et analyses mis en uvre. Nous travaillons galement l'intgration de la supervision dans les outils d'administration que nous avons dvelopps, afin de proposer nos correspondants un ensemble homogne. Par exemple, il sera bientt possible de choisir les interfaces superviser depuis l'outil d'administration des commutateurs. De plus, la base de donnes des quipements tant maintenant ralise, nous pouvons l'utiliser pour d'autres tches de maintenance, comme la sauvegarde automatique des configurations.

La golocalisation est presque devenue un phnomne de mode et prsente - il faut en convenir - un attrait indniable. La mise disposition d'outils simples par google a permis de banaliser cette fonctionnalit et nous a fortement incit ne pas nous en priver.

Figure 9: Golocalisation Il est donc possible pour chaque service de iSup de renseigner ses coordonnes GPS. Nous avons ainsi donn la possibilit aux administrateurs de construire des cartes sur lesquelles ils peuvent choisir les services reprsenter. Comme illustr par la Figure 9, chaque service y est alors reprsent par un point de couleur contenant des informations contextuelles directement accessibles.

Conclusion

L'objectif initial de ce projet est maintenant en grande partie atteint : nous disposons d'un outil central de supervision. Une simple action sur la base de donnes