Ecole Centrale Paris VIA Centrale Reseaux
etRapport d'Etude en Autonomie
Projet de surveillance des serveurs
Encadrant : M. Jean-Philippe Rey
Johannes Kanig
&
Yoann Peronneau
Promotion 2006 10 juin 2004
TABLE DES MATI ERES TABLE DES MATI ERES
Table des matieres
1 Introduction 2
2 Fonctionnement general 2
3 Fonctionnement des scripts 3
3.1 Base des scripts . . . 3
3.2 Les scripts get . . . 3
3.3 Les scripts log . . . 5
3.4 Les scripts graph . . . 5
3.5 Les scripts php . . . 5
4 Mise en place 6 5 Ajouter un module 8 5.1 Ecriture des scripts get, log et graph . . . 8
5.2 Conguration du serveur central . . . 8
5.3 Conguration des serveurs monitores . . . 9
6 L'etape de developpement 9
7 Conclusion 10
2 FONCTIONNEMENT G EN ERAL
1 Introduction
L'association VIA Centrale Reseaux s'est, durant les 15 dernieres annees, enormement develop- pee. Mais avec l'augmentation du nombre de membres et la popularite croissante de certains projets a VIA (notamment VideoLAN), le nombre et la complexite des serveurs (la plupart sous Debian Linux) ont egalement augmente. VIA possede maintenant plus de 5 serveurs, avec des serveurs Apache, FTP, Mail, CVS et SVN ainsi que bien d'autres services. Il devient de plus en plus dicile de maintenir le systeme de maniere manuelle. D'ou la necessite d'un systeme de surveillance automatique du fonctionnement des machines et quelques services.
Quel est l'inter^et direct d'une telle surveillance ? Tout d'abord, il s'agit de reduire le temps de reaction en cas d'erreur ou dysfonctionnement d'une machine. Par exemple, si un disque dur est plein ou la mailqueue du serveur mail commence a deborder, on se rend peut-^etre pas tout de suite compte du probleme et de sa gravite. Avec un syteme de surveillance on est prevenu (par mail, par exemple) avant qu'il ne soit trop tard. Ensuite, si le systeme realise des mesures de valeurs cles du serveur de maniere reguliere, on est dans la position de voir le developpement de l'utilisation d'un service ou, pour prendre un autre exemple, l'evolution de l'occupation d'un disque dur. Enn, avec une telle base de donnees creee on peut se rendre compte de problemes plus sophistiques et caches et analyser la cause eventuelle. Dans un cas, on a pu trouver la cause d'une utilisation reguliere mais etonnante du swap sur un de nos serveurs due a une mauvaise version d'un logiciel installe.
Sans ce syteme de surveillance, baptise RRD , que nous avons mis en place et que l'on va decrire dans ce document, nous aurions s^urement eu du mal a trouver la raison de ce probleme.
Quelles sont les variables a surveiller ? Une des variables centrales d'un systeme comme krishna, le serveur principal de VIA sous Linux, est le nombre de mails dans la mailqueue, mais aussi le debit sur les interfaces reseau, l'espace disque de quelques partitions importantes (/var/mail ou la partition dediee au serveur FTP) et enn quelques valeurs techniques comme le load et l'utilisation de la memoire.
Par la suite, nous allons decrire le fonctionnement (general et plus en detail) du RRD , puis la mise en place et l'extension du fonctionnement. Enn, nous presenterons un petit resume sur le deroulement du developpement et du travail en groupe.
2 Fonctionnement general
Le RRD est installe sur un serveur central sur lequel les graphs et le site web sont generes.
Ce serveur doit ^etre sous le systeme d'exploitation linux. Pour faire simple, le RRD n'est qu'une collection de scripts shell, par defaut dans le repertoire rrd/bin/.
Au centre du systeme se trouve le script principal, execute tous les 5 minutes (par exemple par la cron du systeme linux) et qui execute quelques autres scripts pour logguer toutes les informations.
Il existe trois autres types de scripts : les scripts get, log et graph.
Les scripts get savent recuperer l'information souhaitee et la retournent sur la sortie standard.
Les scripts get sont appeles par les scripts log qui vont enregistrer cette information a l'aide du logiciel rrdtool dans une base de donnees. Ce sont les scripts log qui sont executes par le script principal.
Le troisieme type sont les scripts graph, generant des graphs a partir de la base de donnees, encore une fois a l'aide du logiciel rrdtool, et les enregistrant (par defaut) dans le repertoire public html.
Ces scripts ne sont pas executes directement tous les 5 minutes comme les autres, parce que cela prendrait trop de ressources. La generation d'une quinzaine de graphs dure quelques secondes m^eme sur un systeme a plusieurs processeurs puissants.
Pour eviter que cette operation soit executee toutes les 5 minutes, les scripts graph sont executes lorsque quelqu'un consulte le site web. Grace a un script PHP, les scripts graph sont appeles, generent les graphs et l'utilisateur voit les graphs actuels dans le navigateur internet. Pour des raisons evidentes, le script PHP ne genere les graphs que s'ils sont plus vieux que 5 minutes.
3 FONCTIONNEMENT DES SCRIPTS
Par type d'information, 3 graphs sont crees : un graph sur le dernier jour, un sur la derniere semaine, et un graph sur le dernier mois. Ceci permet a la fois de voir les details actuels et le developpement des valeurs a long terme.
Pour la plupart des donnees recuperees, on a integre un syteme d'alertes par mail. Si la valeur actuelle depasse une limite critique (en general, celle-ci est xee de maniere genereuse pour avoir le temps de reagir), un mail indiquant le probleme exact est envoye a une liste d'adresses que l'on peut determiner. Cependant, on a vu que ca peut ^etre tres enervant d'^etre maile toutes les cinq minutes a cause d'un petit probleme. Pour cette raison, on a augmente l'intervalle des mails a 15 minutes, ce qui divise le nombre de mails par trois.
3 Fonctionnement des scripts
3.1 Base des scripts
Les scripts shell se trouvent tous dans rrd/bin ; seul le script PHP se trouve dans un repertoire accessible via internet. On peut completement changer le comportement des scripts a l'aide des chiers de conguration situes dans rrd/etc , surtout le chier rrd.conf. La, toutes les variables utilisees par les scripts sont denies, par exemple les repertoires dans lesquels se trouvent les dierents chiers :
# Fichier de configuration commun aux scripts MAINPATH= admin/rrd
BINPATH=$MAINPATH/bin CONFPATH=$MAINPATH/etc
LOGPATH=$MAINPATH/log/rrd.$HOSTNAME
GRAPHPATH= /admin/public html/rrd/$HOSTNAME RRDPATH=$CONFPATH/rrd.$HOSTNAME
TOGRAPH=$RRDPATH/graph
Ces lignes s'expliquent toutes seules, comme le reste du chier qui contient des denitions des variables internes telles que le nom des chiers qui contiennent la base de donnees du rrdtool. Dans rrd/bin, il existe un lien symbolique conf qui pointe vers le chier rrd.conf dans etc/rrd. Tous les scripts doivent lire ce chier, et contiennent donc la ligne
. ./conf
(presque) tout au debut. Il en est de m^eme pour le chier de conguration rrdsnmp.conf dont nous detaillerons le principe ulterieurement. Un autre mecanisme est egalement important, il s'agit de la determination de la variable HOSTNAME , qui est surtout utilisee pour le nom du repertoire dans lequel seront crees les graphs. Soit les scripts ont recu le hostname comme parametre et changent le contenu de la variable avant la lecture de rrd.conf, soit, si cette variable est encore vide, sa valeur est alors determinee a l'aide du programme du m^eme nom :
if [ "$HOSTNAME" = '' ] ; then HOSTNAME=$(hostname)
fi
3.2 Les scripts get
A la base du systeme de scripts se trouvent les scripts get, qui mettent a disposition les in- formations que l'on veut surveiller. Quelques scripts get prennent des parametres, par exemple le script get disk.sh, pour specier l'information que l'on veut obtenir (dans ce cas c'est la partition a surveiller). Nous avons deja explique que tous les scripts get prennent un parametre optionnel, a savoir le hostname de la machine a surveiller. S'il n'est pas donne, le script va chercher l'information
3.2 Les scripts get 3 FONCTIONNEMENT DES SCRIPTS
sur la machine locale, sinon le script eectue des requ^etes SNMP vers le serveur a surveiller. Pour que cela fonctionne, il faut avoir installe un serveur SNMP sur cette machine. Cette procedure est decrite dans le chapitre 4.
Localement, l'information est souvent accessible dans le systeme de chiers virtuel /proc ou par des petits programmes comme df et mailq. Detaillons ce mecanisme en prenant un exemple, le script get trac.sh, qui donne le debit d'une interface reseau d'un serveur.
Apres avoir lu les chiers de conguration, on decide avec un \if" si on travaille localement ou avec des requ^etes SNMP :
if [ -z $2 ] ; then
net=$(grep ''$1 :'' /proc/net/dev)
elsenet=$($SNMPWALK -v1 $2 public $SNMPROOT.$SNMP CNET.101 | grep ''$1 :'' | sed -e ''s/.?n''n(.?n)n''/n1/'')
fi
Dans le premier cas, on cherche l'information (ici le debit sur l'interface, stocke dans la variable
$1) dans le le chier /proc/net /dev. Dans le deuxieme cas, on se connecte au serveur SNMP (avec la commande snmpwalk) de la machine a surveiller avec le nom d'h^ote $2.
Les informations dans le systeme SNMP sont stockees dans une structure d'arbre. La racine est une suite de chires separees avec des points, et pour faciliter l'utilisation elle est stockee dans
$SNMPROOT. Pour specier l'information dans l'arbre, on ajoute des chires toujours separees avec des points. Nous ajoutons ici la variable $SNMP CNET (toutes les variables concernant le SNMP sont denies dans rrd/etc/rrdsnmp.conf) et la partie 101 de cette information (c'est la ou est enn l'information cherchee, les autres parties contiennent des informations supplementaires).
Du c^ote du serveur, c'est exactement un
cat /proc/net/dev
qui est execute. La ligne de commande plus complexe, notamment avec la commande sed, est d^u au fait qu'il faut extraire l'information de la sortie plus complexe du snmpwalk.
La variable net n'est qu'une variable intermediaire qui contient toute la ligne de valeurs de /proc/net/dev, par exemple :
eth0 :4168448257 335241331 0 0 0 0 0 5279567 2978489681 372426010 0 0 0 0 0 0
On s'interesse uniquement a la premiere et la neuvieme valeur (debit entrant et sortant). De plus, le nom de l'interface tout au debut de la ligne nous g^ene. Il est donc necessaire de traiter cette variable une nouvelle fois :
net=$(echo $net | cut -d' :' -f2) in=$(echo $net | $AWK ' print
$1 ') out=$(echo $net | $AWK ' print $9 ')
Maintenant, il sut de donner l'information a la sortie standard :
echo $in $out
M^eme si on a pris un exemple concret ici, le fonctionnement des scripts get est toujours similaire et ce sont des details (surtout la maniere d'extraire l'information de la sortie des programmes dierents) qui dierent.
3.3 Les scripts log 3 FONCTIONNEMENT DES SCRIPTS
3.3 Les scripts log
Les scripts log servent a enregistrer l'information mise a disposition par les scripts get dans une base de donnees a l'aide des rrdtools. A partir de cette base, les scripts graph vont plus tard generer les graphs mis a disposition sur un site web.
Appeles par le script rrd aux.sh, avec le nom du serveur a surveiller en parametre, ce sont eux qui lancent les scripts log, avant de stocker le resultat de ces derniers gr^ace a la commande :
rrdtool update $RRDFILE.rrd [donnees]
La base de donnees utilisee est est appelee < Round Robin > en raison de son fonctionnement : la taille de la base est xee a sa creation ; une fois la n du chier atteint, les nouvelles donnees remplacent les plus vielles. Pour notre utilisation, nous avons choisi de logguer les valeurs des parametres toutes les 5 minutes, pendant un an.
3.4 Les scripts graph
Les scripts graph, comme leur nom l'indique, generent les graphs des dierents parametres surveilles par ce systeme. Pour chacun de ces parametres, le script cree 3 graphs correspondant a 3 durees dierentes :
{ une journee : pour etudier l'evolution du systeme sur le court terme ; permet d'avoir une vision temps reel de l'etat du systeme
{ une semaine : permet entre autres de constater l'impact d'un changement de conguration sur une periode signicative
{ un mois : permet par exemple de comparer les consequences d'une release de VideoLAN sur la charge des serveurs (l'eet dure en general plus d'une semaine)
Le fait de garder les donnees pendant un an permet aussi de comparer des phenomenes d'une annee a l'autre. Il est possible aussi de regenerer les graphs d'une journee particuliere, pour etudier plus en details comment les parametres ont evolue juste avant un crash par exemple.
3.5 Les scripts php
Pour generer le site web sur lequel on peut consulter les graphs, on utilise le langage PHP adapte a cette tache. Il existe deux scripts php, le script index.php et le script machine.php. Le premier est execute quand un utilisateur appelle le site web, et son travail consiste a generer une liste de liens des machines surveillees a partir des noms des repertoires dans lesquels se trouvent les graphs. Les liens pointent vers le script machine.php avec des parametres dierents, le nom de la machine et le type d'achage qui est d'abord mis a \init", la ligne correspondante dans le script php est la suivante :
<a href='machine.php ?type=init& ;machine=$file'> $servername
</a>
Le script machine.php est plus complique est plus interessant. Si la variable type est a \init", il ache une liste de choix des types de graphs disponibles : les graphs sur un jour, une semaine ou un mois. Apres avoir fait ce choix en cliquant sur le lien (qui change uniquement le contenu de type a \1J", \7J" ou \1M"), il ache tous les graphs qui correspondent. Regardons le code source :
while ($file=readdir($handle)) f
if ( $file !=``.'' && $file !=``..'' && (strpos($file,$type)===0)) fecho ``<p>'' ;
echo ``<img src='$machine/$file' alt='$file'>'' ; echo ``</p>`` ;
gg
4 MISE EN PLACE
Pour expliquer : la boucle while passe sur toutes les images du repertoire (qui contient tous les graphs generes d'une machine). Si le nom du chier commence par la valeur de type, on l'ajoute au site que l'on est en train de generer. Il faut faire attention aux \chiers" . et .. qui font toujours partie d'un repertoire UNIX.
On a dit que le script php genere les graphs s'ils sont plus vieux que cinq minutes. Pour determiner cela et avant d'acher les graphs, le script regarde donc la date de modication des chiers et le compare avec le temps actuel. Le code source :
$test=FALSE ;
$empty=TRUE ;
while ($file=readdir($handle)) f
if ( $file !="." && $file !=".." && (strpos($file,$type)===0)) f
$empty=FALSE ;
if (time() > filemtime("./$machine/$file") + 300 ) f $test=TRUE ; gg
g
Les deux variables test et empty sont d'abord mises respectivement a false (a priori, on ne regenere pas les graphs) et a true (au debut, le repertoire est considere comme vide). La boucle while nous donne tous les chiers l'un apres l'autre et selectionne ceux qui nous interessent (ceux qui commencent avec type et qui sont des chiers reguliers). Si on trouve au moins un chier correspondant, le repertoire est considere comme non vide ; si en plus on trouve un chier dont le temps de modication date de plus de 300 secondes, on met la variable test a true. Maintenant, on a ramasse toute l'information necessaire an de pouvoir decider s'il faut regenerer les graphs :
if ($test || $empty) f
$tmp=getcwd() ; chdir($rrdbinpath) ;
exec("$gengraph $machine") ; chdir("$tmp") ;
g
Si le repertoire est vide ou si un chier n'est pas assez recent, on va recreer les graphs. D'abord, on sauvegarde le repertoire actuel, on change de repertoire avec les scripts shell, on execute le script gen all graphs.sh (qui genere justement tous les graphs d'une machine) avec le nom de la machine concernee comme parametre et on rechange le repertoire de travail.
Tout cela est execute avant de generer la liste des graphs aches. Pour pouvoir entrer dans la boucle while nous donnant cette liste, il faut encore remettre le pointeur du repertoire :
rewinddir($handle) ;
Toutes les pages generees sont bien s^ur valides selon le standard HTML 4.01 du w3c.
4 Mise en place
La mise en place n'est pas compliquee, par contre il n'existe pas (encore) de script d'automa- tisation du processus. Il faut donc faire une bonne partie de l'installation a la main.
Pour creer l'arborescence necessaire sur le serveur central, il sut de faire un
% svn checkout svn ://serveur-svn/rrd
4 MISE EN PLACE
en tant que l'utilisateur avec les droits duquel les scripts seront executees plus tard. Le sous- repertoire php doit ^etre copie a un endroit accessible par un serveur HTTP. La conguration du serveur HTTP n'est pas decrite ici, mais il peut ^etre utile de creer un nom DNS et un VirtualHost pour ces scripts.
La conguration se fait dans le sous-repertoire etc/. Il faut creer un chier rrd.list (s'il n'existe pas deja), dans lequel on liste tous les noms DNS des machines a surveiller, inclus le serveur lui-m^eme, si on le souhaite. Chaque nom DNS doit occuper une ligne.
Pour la conguration des characteristiques a surveiller pour chaque machine, il faut creer un repertoire rrd.nom de la machine. Le chier principal ici s'appelle rrd.conf, qui liste tout ce qu'il faut surveiller, de nouveau une chose par ligne :
diskloads memtraffic users
Quelques characteristiques demandent plus de specications. Par exemple, il faut preciser la liste des partitions a surveiller. Pour cela, on cree un chier disks dans lequel on liste toutes les partitions souhaitees :
/var/mail /var/lib/mysql /mnt/backup /var/log /usr
Des congurations plus speciques similaires sont egalement necessaires pour d'autres proprietes du systeme, comme par exemple le trac reseau.
C'est tout ce qu'il y a a faire en ce qui concerne la conguration c^ote serveur central. Maintenant, il faut preparer les autres machines a surveiller a distance, pour que le serveur puisse recuperer les informations necessaires pour creer les graphs. Pour ce faire, il faut installer un serveur SNMPD sur ces machines. L'installation elle-m^eme depend du type de systeme utilise est ne sera pas decrite dans ce document.
Une fois le serveur SNMPD installe, il faut le congurer pour qu'il reponde aux requ^etes de nos scripts RRD . Toute conguration a lieu dans le chier de conguration snmpd.conf, qui se trouve (ca depend egalement du systeme utilise) probablement dans le repertoire /etc/snmp. D'abord on restreint l'acces au serveur principal :
com2sec rrd 138.195.130.71 public
C'est une bonne chose a faire, parce que le SNMP est un protocol plut^ot dangereux, m^eme si, dans notre cas, le danger est tres limite. Ce danger provient du fait qu'on fait executer des commandes a distance au serveur, et que le demon snmpd est oblige de tourner en tant qu'utilisateur root.
Dans le m^eme chier, il faut encore ajouter les types de requ^etes autorises. Ce qui s'eectue gr^ace a une ligne du type :
exec .1.3.6.1.4.1.2021.1242.1 uptime /bin/su admin -c uptime
5 AJOUTER UN MODULE
L'exec au debut represente \execute", le nombre avec des points est l'identicateur de la com- mande que va fournir la requ^ete par le serveur principal. Le mot uptime est le nom de la commande, et tout ce qui suit est la commande a executer. En l'occurence c'est la commande uptime qui servira a determiner le load de la machine. L'output de la commande est envoye au client (dans notre cas donc au serveur principal qui genere les graphs).
Pour toute commande souhaitee, il faut ajouter une ligne semblable a celle ci-dessus. Une dernieer remarque : des que la commande a executer devient un peu compliquee, il vaut mieux la placer dans un petit script et apeller ce script a partir du serveur SNMP au lieu de la mettre directement dans le chier de conf. Par exemple :
exec .1.3.6.1.4.1.2021.1242.2 who /root/scripts/rrdwho.sh
5 Ajouter un module
Gr^ace a sa structure modulaire, l'ajout d'un nouveau module se fait de maniere relativement simple :
{ ajout des scripts get, log et graph { conguration c^ote serveur
{ conguration des snmpd.conf sur les serveurs monitores
Prenons l'exemple de l'ajout du module de surveillance du nombre de connexions sur notre serveur IRC.
5.1 Ecriture des scripts get, log et graph
Il ne faut pas oublier, lors de l'ecriture du script get de prevoir les deux types d'acquisition des parametres : acquisition locale ou distante via SNMPD, la distinction etant realisee par une simple comparaison du hostname du serveur a surveiller avec le hostname local.
Enn, le script get doit retourner les valeurs trouvees de facon a ce qu'elles soient facilement utilisables par le script log correspondant, dans lequel elles sont employees sous la forme :
N :donnee1 :donnee2 :... :donneen
Ensuite, en ce qui concerne le script log, il ne faut pas non plus oublier de creer le repertoire et le chier qui contiendra la base de donnees < Round Robin > (en speciant sa taille et les durees d'echantillonnage), si ceux-ci n'existent pas encore.
Il faut aussi choisir le type des variables surveillees. En eet celles-ci peuvent ^etre de type jauge (ie le nombre mesure est stocke tel quel) ou de type moyenne, comme dans le cas du calcul de debit : rrdtool calcule la dierence de donnees transmises entre deux executions du script et en deduit le debit moyen.
Enn le script graph doit aussi prendre garde a l'existence du repertoire contenant les images a generer, et le creer dans le cas contraire.
5.2 Conguration du serveur central
Une fois les trois scripts precedents ecrits, il reste encore a rajouter les options de conguration correspondantes dans les chiers de congurations adaptes.
Tout d'abord, en ce qui concerne le chier rrd.conf qui contient la plupart des parametres de conguration des scripts. A chaque script correspond trois variables : dans le cas de notre exemple, ces variables sont :
5.3 Conguration des serveurs monitores 6 L' ETAPE DE D EVELOPPEMENT
GET IRC=$BINPATH/get irc.sh LOG IRC=log irc
GRAPH IRC=log irc.png
qui correspondent respectivement au script get, au chier contenant la base de donnees < Round Robin >, et au suxe utilise pour le nom des graphs generes.
Ensuite, en ce qui concerne l'acces par SNMP au serveur pour recuperer la valeur du parametre surveille, la n de l'OID utilise doit ^etre ajoute dans le chier de conguration dedie aux acces SNMP, rrdsnmp.conf, tel que suit :
SNMP IRC=10
Ainsi l'acces a cette valeur s'eectuera en utilisant l'OID .1.3.6.1.4.1.2021.1242.10.
Enn, il reste bien evidemment a modier les chiers rrd.conf dans les repertoires rrd.machine an de commencer le monitoring de ce parametre pour les serveurs souhaites.
5.3 Conguration des serveurs monitores
Sur les serveurs sur lesquels on souhaite monitorer ce nouveau parametre, le chier de congura- tion du serveur SNMPD, snmpd.conf, doit ^etre modie en consequence. Ainsi, pour notre exemple, la ligne suivante a ete rajoutee :
exec .1.3.6.1.4.1.2021.1242.10 irc /root/scripts/rrd irc.sh
On a ici choisi de faire appel a un script plut^ot que d'inserer la commande directement dans ce chier de conguration, comme c'est le cas par exemple pour uptime ou loadavg, qui retournent respectivement le resultat de la commande "uptime" et "/bin/su admin -c cat /proc/loadavg", en raison de la relative complexite du script permettant de calculer la valeur desiree.
6 L'etape de developpement
Le developpement du RRD etait un travail en groupe a deux personnes. Cela a necessite quelques precautions pour pouvoir travailler de maniere ecace et rapide. Tout d'abord, beaucoup de com- munication entre nous etait indispensable, mais cela s'est fait de maniere naturelle pratiquement tous les jours pendant le travail sur le projet, ce qui a remplace des reunions dedies au projet.
Le language de script que nous avons utilise pour le RRD est tres pratique et plut^ot facile, mais il ne facilitait pas le travail en equipe sur un projet. La division du travail s'est donc fait par chier voire groupe de chiers (get, log, graph d'un certain type). De toutes facons, chacun etait, pendant tout le projet, capable de manipuler toutes les parties du projet. Il n'y avait jamais des problemes tres diciles a surmonter.
L'utilisation du logiciel de travail en groupe Subversion a permis de partager a la fois les scripts shell, les scripts php et la documentation tres facilement et de gerer le travail (potentiellement simultane) sur les m^eme chiers. On l'a prefere par rapport au logiciel du m^eme type CVS a cause de la simplicite d'utilisation et la facon plus moderne d'organisation interne. En m^eme temps, Subversion permet de suivre le processus de travail sur un site web (dans notre cas, c'est http ://svn-rrd.via.ecp.fr).
Les scripts shell nous semblent tres stables et ables, et ils fonctionnent sans defaut depuis plu- sieurs semaines. Neanmoins, pour l'avenir du projet, il reste beaucoup de choses a ameliorer. D'une part, les possibilites de mesure sont illimitees : a VIA, on prevoit de surveiller les impressions sur wanda, l'imprimante sur laquelle tous les membres de VIA (donc pratiquement tout habitant de la
7 CONCLUSION
residence) peuvent imprimer, mais aussi les temperatures (ou autres variables) des switchs et rou- teurs de VIA qui, surtout en ete, chauent de maniere dangereuse. Apres, on pourrait surveiller le debit par b^atiment, par etage, . . .. Et notre architecture de scripts permet tres facilement d'ajouter des nouvelles functionnalites.
D'autre part, les scripts PHP fonctionnent bien aussi, mais les pages web generees sont encore assez rudimentaires et il serait bien de les presenter de maniere plus agreable aux yeux, par exemple a l'aide de CSS. Malheuresement, nous n'avons pas eu le temps de faire ca pendant notre etude en autonomie.
7 Conclusion
Nous pensons avoir realise un bon systeme de surveillance a l'aide du logiciel rrdtool. De maniere simple, on peut maintenant voir l'etat de plusieurs systemes, leur developpement en fonction du temps, et analyser les raisons d'un probleme eventuel. Il est simple d'ajouter des modules et encore plus simple d'ajouter une machine ou une nouvelle variable a surveiller. Le developpement s'est tres bien passe et sans problemes particuliers.
Cependant, il ne faut pas oublier que les scripts presentes ne peuvent que faire partie d'autres mesures de surveillance et analyse du comportement des serveurs. Par exemple, il serait dicile voire impossible de s'assurer du bon fonctionnement d'un serveur Web avec la methode utilisee.
Dans ce cas, il vaut mieux de mettre en place un analyseur des chiers de log generes par le serveur Web (apache dans le cas de nos serveurs). Et rien ne peut remplacer l'attention d'un bon administrateur qui s'occupe regulierement de ses machines.
