1. Les outils d’administration et de
supervision r´ seau
e
L’exemple de Nagios
Compte rendu
Thierry Briche
Matthieu Voland
Document r´ alis´ sous LTEX
e e A
Version 1.00
D´ cembre 2004
e

2. `
TABLE DES MATIERES `
TABLE DES MATIERES
Table des mati` res
e
1 Introduction 4
1.1 Etat des lieux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Probl´ matique . . . . . . . . . . . . . . . . . . . . . . . . . . . .
e 4
2 La supervision / administration r´ seau
e 5
2.1 Le concept de supervision r´ seau . . . . . . . . . . . . . . . . . .
e 5
2.2 La norme ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Gestion des performances (Performance Management) . . 6
2.2.2 Gestion des configurations (Management Configuration) . 6
2.2.3 Gestion de la comptabilit´ (Accounting Management) . .
e 6
2.2.4 Gestion des anomalies (Fault Management) . . . . . . . . 7
2.2.5 Gestion de la s´ curit´ (Security Management) . . . . . . .
e e 7
2.2.6 Structure de gestion des r´ seaux (Network Management System)
e 7
2.3 Le protocole SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Les logiciels de supervision . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 D´ ploiement des logiciels de supervision : . . . . . . . . . 11
e
2.4.2 Quelques outils de la supervision . . . . . . . . . . . . . 12
3 Supervision : l’exemple de Nagios 14
3.1 Pr´ sentation g´ n´ rale . . . . . . . . . .
e e e . . . . . . . . . . . . . . 14
3.1.1 Le concept . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.2 Le fonctionnement . . . . . . . . . . . . . . . . . . . . . 14
3.1.3 mode de licence . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.4 P´ rim` tre de l’outils . . . . . .
e e . . . . . . . . . . . . . . 14
3.1.5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Les greffons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Principe de base . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Fonctionnalit´ s avanc´ es . . . .
e e . . . . . . . . . . . . . . 16
3.2.3 Ecriture de greffons . . . . . . . . . . . . . . . . . . . . . 17
3.3 Configuration des composants . . . . . . . . . . . . . . . . . . . 17
3.3.1 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2 Authentification . . . . . . . . . . . . . . . . . . . . . . 17
3.3.3 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.1 L’interface d’administration . . . . . . . . . . . . . . . . 18
3.4.2 Des alarmes aux administrateurs . . . . . . . . . . . . . . 19
3.4.3 Les statistiques et l’anticipation . . . . . . . . . . . . . . 19
4 Conclusion 20
4.1 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Quel avenir ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2

3. `
TABLE DES MATIERES `
TABLE DES MATIERES
5 Ressources 21
5.1 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.1 Ouvrages . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.2 R´ f´ rences de sites internet .
ee . . . . . . . . . . . . . . . . 21
5.2 Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6 ANNEXES 25
6.1 SNMP : D´ tail du Packet Data Unit
e . . . . . . . . . . . . . . . . 25
6.1.1 PDU Type . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.2 Request ID . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.3 Error Status . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.4 Error Index . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.5 Variable Binding List . . . . . . . . . . . . . . . . . . . . 26
6.1.6 Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.7 Agent-addr . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.8 Generic-Trap . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.9 Specific-Trap . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.10 Time-Stamp . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Quelques outils et leur interface . . . . . . . . . . . . . . . . . . 27
6.2.1 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.2 HP Open View . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.3 Big Brother . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2.4 CiscoWorks . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2.5 MRTG . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3

4. 1 Introduction
1 Introduction
1.1 Etat des lieux
La taille des r´ seaux ne cessant de grandir de jour en jour et l’importance de
e
ceux-ci dans le monde de l’entreprise prenant une place pr´ pond´ rante, le besoin
e e
o e e ´
de contrˆ ler en temps r´ el leur qualit´ et leur etat est rapidement devenu une prio-
rit´ . C’est dans ce but qu’est apparu, il y a maintenant une vingtaine d’ann´ es, le
e e
concept de supervision de r´ seaux.
e
Nous pr´ senterons dans ce document ce qu’est la supervision de r´ seaux ainsi que
e e
e ´e
l’impl´ mentation qui en a et´ faite. Pour ce faire nous d´ finirons en premier lieu les
e
concepts et les notions de la supervision de r´ seaux et nous pr´ senterons ce que la
e e
normalisation a apport´ en r´ ponse a
e e ` ces probl´ matiques et plus particuli` rement
e e
´
dans le monde IP. Nous etudierons ensuite l’exemple du plus en plus populaire
e e`
Nagios, un logiciel libre d´ di´ a la supervision de r´ seaux .
e
1.2 Probl´ matique
e
Les r´ seaux ont vu un essor rapide accompagn´ par la d´ couverte de nouvelles
e e e
technologies. Les entreprises entrevoyant les possibilit´ s offertes par ces nouveaux
e
´e e `
apports ont et´ amen´ es a les assimiler tr` s vite, ce qui implique donc la cohexis-
e
tence de milieux tr` s h´ t´ rog` nes aux divers niveaux de l’architecture d’intercon-
e ee e
nexion des syst` mes ouverts (OSI : Open System Interconnection), aussi bien au
e
niveau des protocoles de transports que des infrastructures physiques supportant
ces r´ seaux.
e
e e `
Un des principaux enjeux de la supervision de r´ seaux est ainsi de r´ ussir a of-
frir une solution unique permettant de g´ rer son r´ seau dans un milieu h´ t´ rog` ne
e e ee e
ind´ pendamment des contraintes physiques et techniques ; l’ampleur de ces r´ seaux
e e
pouvant varier grandement : que l’on parle d’un r´ seau d’un op´ rateur et fournis-
e e
seur ou bien que l’on parle du r´ seau interne d’une petite entreprise, la supervision
e
`
doit pouvoir apporter des outils performants, adaptables aussi bien a la taille des
r´ seaux qu’` leur grande diversit´ technologique.
e a e
Un autre enjeu est l’automatisation du traitement de l’information. En effet, face
`
a l’importance (taille et criticit´ ) des r´ seaux dans tous les milieux professionnels,
e e
il reste difficile de prendre connaissance de toutes les informations et de r´ agir e
proactivement. D` s lors, l’automatisation de l’analyse des informations remont´ es
e e
par la supervision permet la mise en place de statistiques et de proc´ dures pour la
e
e e e ´
r´ solution des probl` mes r´ cursifs ou etendus.
4

5. 2 La supervision / administration r´ seau
e
2 La supervision / administration r´ seau
e
´
Avant de presenter le principal protocole ainsi que les outils actuels
´ ´ ´ ´
permettant de superviser un reseau, il paraˆt bon de definir precisement
ı
le concept de supervision et la maniere dont il a ete normalise par l’ISO1 .
` ´ ´ ´
´
La normalisation ISO etant identique pour la supervision et l’administration,
nous ne parlerons que de supervision.
2.1 Le concept de supervision r´ seau
e
La supervision r´ seau a pour but de surveiller le bon fonctionnement des r´ seaux.
e e
Ce concept est n´ au d´ but des ann´ es 1980, lors de l’explosion de la mise
e e e
en place de r´ seaux informatiques dans les entreprises. La taille grandissante de
e
ceux-ci ainsi que leur h´ t´ rog´ n´ it´ posaient un r´ el probl` me de gestion et d’ad-
ee e e e e e
ministration, multipliant les besoins en main d’oeuvre d’experts administrateurs.
` ´ ´e
C’est donc a cette epoque qu’ont et´ men´ es les premi` res r´ flexions sur un nou-
e e e
veau concept, celui de la supervision.
ˆ `
La supervision devait etre capable de s’adapter a des milieux h´ t´ rog` nes, d’au-
ee e
tomatiser le contrˆ le des r´ seaux et de g´ n´ rer un ensemble de statistiques donnant
o e e e
une meilleure vision du r´ seau, permettant par l` -mˆ me d’anticiper les besoins de
e a e
celui-ci.
´
La supervision peut ainsi se d´ finir comme etant l’utilisation de ressources
e
r´ seaux adapt´ es (mat´ rielles ou logicielles) afin d’obtenir des informations sur
e e e
l’utilisation et sur l’´ tat des r´ seaux et de leurs composants (logiciels, mat´ riels).
e e e
Ces informations peuvent alors servir d’outils pour g´ rer de mani` re optimale (au-
e e
tomatique si possible) le traitement des pannes ainsi que la qualit´ des r´ seaux
e e
´ ´
(probl` mes de surcharge). Elles permettent egalement de pr´ voir toute future evolution
e e
n´ cessaire.
e
La supervision est capable de diagnostiquer et bien souvent de r´ parer seule les
e
pannes. Si ce n’est pas le cas, elle se charge d’alerter imm´ diatement les personnes
e
concern´ es par l’incident. Elle est donc extrˆ mement r´ active et repr´ sente un gain
e e e e
important en temps. De plus, par sa vision continue du r´ seau, elle anticipe souvent
e
sur des probl` mes ult´ rieurs. On parle alors de proactivit´ .
e e e
`
Ainsi, la supervision est a la fois r´ active et proactive. C’est pourquoi, petit
e
`
a petit, la supervision s’impose dans la plupart des entreprises poss` dant un parc
e
informatique cons´ quent.
e
1
International Organization for Standardisation.
5

6. 2.2 La norme ISO 2 La supervision / administration r´ seau
e
2.2 La norme ISO
e e `
L’ISO s’int´ resse de pr` s a la supervision. Et, d` s 1988, l’organisme publie la
e
norme ISO7498/4 2 d´ finissant les principales fonctions que doivent impl´ menter
e e
les syst` mes de supervision et d’administration. Ces fonctions sont les suivantes :
e
2.2.1 Gestion des performances (Performance Management)
La gestion des performances analyse de mani` re continue les performances du
e
´
r´ seau afin de le maintenir dans un etat de performance acceptable. Cette gestion
e
´
s’op` re en trois etapes. Tout d’abord, des variables contenant des informations si-
e
gnificatives quant aux performances du r´ seau sont r´ cup´ r´ es. Parmi celles-ci on
e e ee
peut citer le temps de r´ ponse d’une station utilisateur ou encore le taux d’occu-
e
pation d’un segment r´ seau. Une fois ces variables obtenues, elles sont analys´ es.
e e
Si elles d´ passent un seuil de performance fix´ pr´ alablement, une alarme est tout
e e e
e `
de suite envoy´ e a l’administrateur du r´ seau, pour r` gler le probl` me au plus vite.
e e e
e `
Ces variables de gestion de performances sont r´ actualis´ es a court intervalle de
e
temps dans le but d’ˆ tre le plus r´ actif possible au moindre embryon de baisse de
e e
performance.
´
La gestion des performances permet donc une evaluation du comportement des
ressources et un contrˆ le de l’efficacit´ des activit´ s de communication.
o e e
2.2.2 Gestion des configurations (Management Configuration)
La gestion des configurations effectue un suivi des diff´ rentes configurations
e
´e
des el´ ments pr´ sents sur le r´ seau. Elle stocke dans une base de donn´ es les ver-
e e e
sions des syst` mes d’exploitation et des logiciels install´ s sur chaque machine du
e e
parc r´ seau. Par exemple pour un ordinateur du r´ seau, la base contiendra la ver-
e e
sion de son OS, du protocole TCP/IP, etc ...
La gestion des configurations permet donc une identification et un contrˆ le o
des syst` mes ouverts. Elle collecte et fournit des informations sur les diff´ rents
e e
syst` mes du r´ seau.
e e
2.2.3 Gestion de la comptabilit´ (Accounting Management)
e
La gestion de la comptabilit´ a pour but de mesurer l’utilisation des ressources
e
e e ´
afin de r´ guler les acc` s et d’instaurer une certaine equit´ entre les utilisateurs du
e
e ˆ
r´ seau. Ainsi des quotas d’utilisation peuvent etre fix´ s temporairement ou non sur
e
chacune des ressources r´ seaux. De plus, la gestion de la comptabilit´ autorise la
e e
mise en place de syst` mes de facturation en fonction de l’utilisation pour chaque
e
utilisateur.
2
aussi connue sous le nom de OSI management Framework.
6

7. 2.2 La norme ISO 2 La supervision / administration r´ seau
e
e ´
La gestion de la comptabilit´ permet donc un etablissement des coˆ ts d’utili-
u
sation ainsi qu’une facturation de l’utilisation des ressources.
2.2.4 Gestion des anomalies (Fault Management)
La gestion des anomalies d´ tecte les probl` mes r´ seaux (logiciels ou mat´ riels).
e e e e
Elle essaie d’isoler le plus pr´ cis´ ment le probl` me en effectuant divers tests.
e e e
Quand cel` est possible, elle r` gle elle-mˆ me automatiquement l’anomalie. Sinon,
a e e
elle alerte les personnes concern´ es par le type du probl` me afin de solliciter leur
e e
intervention. La gestion des anomalies garde dans une base de donn´ es l’ensemble
e
e `ˆ
des probl` mes survenus ainsi que leur solution, de mani` re a etre encore plus effi-
e
`
cace face a un incident r´ ccurrent. Cette fonction de la norme ISO7498/4 demeure
e
e `
de loin la fonction la plus impl´ ment´ e a ce jour.
e
La gestion des anomalies d´ tecte donc et corrige les fonctionnements anor-
e
´e
maux des el´ ments du r´ seau.
e
2.2.5 Gestion de la s´ curit´ (Security Management)
e e
La gestion de la s´ curit´ contrˆ le l’acc` s aux ressources en fonction des poli-
e e o e
´ `
tiques de droits d’utilisation etablies. Elle veille a ce que les utilisateurs non auto-
e e `
ris´ s ne puissent acc` der a certaines ressources prot´ g´ es.
e e
La gestion de la s´ curit´ met donc en application les politiques de s´ curit´ .
e e e e
2.2.6 Structure de gestion des r´ seaux (Network Management System)
e
Apr` s avoir d´ fini les fonctionnalit´ s de la supervision r´ seau, l’ISO s’est at-
e e e e
e` e
tach´ a d´ crire la structure de la gestion des r´ seaux (Network Management Sys-
e
tem).
L’ISO propose d’installer un agent de gestion sur chaque machine supervis´ e,
e
comme le montre la figure suivante :
7

8. 2.2 La norme ISO 2 La supervision / administration r´ seau
e
F IG . 1 – Network Management System (MNS).
Cet agent r´ cup` re p´ riodiquement et stocke localement des informations sur
e e e
la machine sur laquelle il tourne. Quand il d´ tecte un probl` me, il le signale au ser-
e e
vice de gestion centralis´ (install´ sur le serveur de supervision). Le service de su-
e e
pervision, en fonction de la nature de l’anomalie, prend un ensemble de d´ cisions
e
`
(actions) dont une bonne partie est transmise a l’agent de gestion pr´ sent sur la
e
machine en difficult´ . L’agent ex´ cute alors l’ensemble des actions r´ paratrices de-
e e e
´
mand´ es par le superviseur afin de remettre la machine en etat.
e
Toutefois, le service central de supervision ne reste pas inactif en attendant que
ses agents lui rapportent des probl` mes. Il peut en effet questionner r´ guli` rement
e e e
ses agents, par le biais de requˆ tes, pour connaˆtre l’´ tat complet d’une machine, et
e ı e
par addition, l’´ tat de l’ensemble du r´ seau.
e e
Les objets stock´ s dans les bases de donn´ es des agents sont normalis´ s au for-
e e e
e ´e
mat ASN.1. Ces bases de donn´ es ont aussi et´ normalis´ es par l’ISO. Elles sont
e
appel´ es bases de donn´ es MIB 3 . Nous ne d´ taillerons ni le format ASN.1, ni les
e e e
bases de donn´ es MIB.
e
e ´
Pour transmettre les diff´ rents messages echang´ s entre l’agent de supervision
e
´e e
et le superviseur, un protocole r´ seau de couche OSI 7 a et´ d´ fini par l’ISO : le pro-
e
3
Management Information Base.
8

9. 2.3 Le protocole SNMP 2 La supervision / administration r´ seau
e
tocole CMIP 4 . Nous ne d´ taillerons pas ce protocole, puisqu’aucune impl´ mentation
e e
´e `
n’en a et´ faite a ce jour. En effet, les travaux de l’ISO sur la supervision restent
`
trop complets et complexes a mettre en oeuvre. Ils ont toutefois eu le m´ rite de
e
`
poser un cadre clair a la supervision r´ seau.
e
2.3 Le protocole SNMP
Jugeant les sp´ cifications du protocole de transport CMIP propos´ par l’ISO
e e
`
trop lourdes a mettre en oeuvre, l’IETF 5 a d´ fini son propre protocole de gestion
e
des r´ seaux : SGMP 6 . Celui-ci ne fut jamais r´ ellement d´ ploy´ mais donna nais-
e e e e
sance en 1988 au protocole SNMP 7.
ˆ
Comme son nom l’indique, SNMP se veut etre le plus simple possible. L’IETF
estime en effet que le transport des donn´ es de supervision ne doit pas nuire aux
e
performances du r´ seau. SNMP ne permet de superviser que les r´ seaux TCP/IP.
e e
Il est donc totalement adapt´ aux r´ seaux informatiques utilisant majoritairement
e e
cette technologie. D’ailleurs, SNMP s’est impos´ , ces derni` res ann´ es, comme
e e e
´
etant le standard incontournable de la supervision pour l’ensemble des r´ seaux non
e
t´ l´ phoniques.
ee
Depuis 1988, SNMP a beaucoup evolu´ en passant de sa premi` re version 8 ,
´ e e
e e e `
compl` tement d´ pourvue de s´ curit´ , a sa version num´ ro trois combinant une
e e
s´ curit´ bas´ e sur les usagers et sur le type des op´ rations. Toutefois, actuelle-
e e e e
ment, SNMPv1 reste la version la plus employ´ e, SNMPv3 n’´ tant en cours de
e e
d´ ploiement que depuis 1999.
e
Dans un soucis de rapidit´ , le protocole SNMP ne transporte que des variables
e
`
par le biais du protocole de transport UDP. Il sert a instaurer le dialogue entre
les agents install´ s sur les machines supervis´ es et le serveur de supervision (voir
e e
structure NMS 9 2.2.6 FIG.1). L’agent recoit les requˆ tes sur le port 161 et le su-
¸ e
perviseur recoit les alarmes sur le port 162. Le mod` le d’´ change entre le serveur
¸ e e
et l’agent est bas´ sur deux types d’op´ rations, les requˆ tes et les alarmes :
e e e
`
– Lorsque le serveur veut demander quelque chose a l’agent ou lui imposer
´
un ordre, il emet une requˆ te en direction de l’agent. Celui-ci la traite et lui
e
retourne une r´ ponse.
e
´ e
– Lorsqu’un ev´ nement survient sur l’´ l´ ment du r´ seau monitor´ par l’agent,
ee e e
4
Common Management Information Protocol
5
Internet Engineering Task Force.
6
Simple Gateway Monitoring Protocol.
7
Simple Network Management Protocol.
8
RFC 1157.
9
Network Management System.
9

10. 2.3 Le protocole SNMP 2 La supervision / administration r´ seau
e
ce dernier en informe imm´ diatement le superviseur par le biais d’une alarme
e
de type trap ou inform. Dans le cas d’un inform, le serveur retourne une
` ´
r´ ponse a l’agent emetteur.
e
Ainsi, il existe trois messages SNMP diff´ rents : les requˆ tes, les r´ ponses et
e e e
les alarmes. Les requˆ tes SNMP sont les suivantes :
e
– GetRequest : recherche d’une variable sur un agent.
– GetNextRequest : recherche la variable suivante.
– GetBulk : recherche un ensemble de variables regroup´ es.
e
– SetRequest : change la valeur d’une variable sur un agent.
L’agent r´ pond aux requˆ tes par un message GetResponse. En cas d’erreur, le
e e
message sera accompagn´ d’un des codes d’erreurs suivants :
e
– NoAccess : acc` s non autoris´ .
e e
– WrongLength : erreur de longueur.
– WrongValue : erreur de valeur.
– WrongType : erreur de type.
– WrongEncoding : erreur d’encodage.
– NoCreation : objet inexistant.
– ReadOnly : seule la lecture est autoris´ e.
e
– NoWritable : interdiction d’´ crire.
e
– AuthorisationError : erreur d’authorisation.
´
Les alarmes sont envoy´ es par l’agent lorsqu’un evenment survient sur la res-
e
source monitor´ e. Elles peuvent prendre les formes suivantes :
e
e e `
– ColdStart (0) : red´ marrage du syst` me a froid.
e e `
– WarmStart (1) : red´ marrage du syst` me a chaud.
– LinkDown (2) : le lien n’est plus op´ rationnel.
e
`
– LinkUp (3) : le lien est a nouveau op´ rationnel.
e
e `
– AuthentificationFailure (4) : Tentative d’acc` s a l’agent avec un mauvais
nom de communaut´ . e
– EgpNeighborLoss (5) : la passerelle adjacente ne r´ pond plus.
e
– EntrepriseSpecific (6) : alarme sp´ cifique aux entreprises.
e
Le paquet SNMP, tel qu’il est d´ finit dans la RFC 1157 (SNMPv1), est encod´
e e
au format ASN.1. Il poss` de les champs suivants :
e
Version SNMP - Communaut´ - PDU 10
e
La communaut´ d´ finit le domaine de gestion. Agents et superviseurs doivent
e e
ˆ e e ´
etre dans la mˆ me communaut´ pour pouvoir echanger. Le PDU contient les donn´ es e
du protocole de supervision. Il est construit de mani` re identique pour les requˆ tes
e e
10
Packet Data Unit.
10

11. 2.4 Les logiciels de supervision 2 La supervision / administration r´ seau
e
et les r´ ponses. Il diff` re l´ g` rement pour les alarmes (voir annexe 1).
e e e e
Comme nous l’avons vu, le protocole SNMP permet l’´ change de donn´ es de
e e
gestion entre un agent et un superviseur dans un r´ seau TCP/IP. Toutefois, il est
e
´
aussi possible de monitorer des equipements n’utilisant pas TCP/IP ou n’ayant
a ˆ
pas d’agent SNMP. Pour cel` , un proxy SNMP doit etre install´ sur une machine
e
TCP/IP. Ce proxy se charge de faire la translation entre les donn´ es d’un agent de
e
e `
supervision priv´ e et SNMP. Il est ensuite capable de transmettre ces donn´ es a un
e
`
superviseur SNMP. L’utilisation de ces proxies permet ainsi a SNMP de s’adapter
`
facilement a des r´ seaux tr` s h´ t´ rog` nes et prouve la grande flexibilit´ de ce pro-
e e ee e e
tocole.
En plus des proxies SNMP, l’IETF a aussi d´ fini des sondes capables de collec-
e
ter des informations de gestion sur un segment de r´ seau. Ces sondes font tampon
e
entre les agents d’un segment et un superviseur en centralisant les donn´ es relatives
e
`
a un segment r´ seau dans une base de donn´ es MIB. Les superviseurs ne dialoguent
e e
alors plus qu’avec les sondes. Celles-ci ajoutent donc un niveau hi´ rarchique a la
e `
supervision. Chaque sonde dite RMON 11 peut ecouter des segments r´ seaux de
´ e
type Ethernet, TokenRing, ATM ou encore FDDI.
2.4 Les logiciels de supervision
Les logiciels de supervision sont des solutions applicatives r´ pondant au concept
e
´e e
de supervision tel qu’il a et´ d´ fini pr´ c´ dement. Ils s’appuient, pour la plupart, sur
e e
le protocole SNMP.
ı `
Ces outils ont principalement pour objectif de connaˆtre a tout instant l’´ tat des
e
noeuds critiques (serveurs, switchs, routeurs) et l’´ tat des services tournant sur les
e
´ ˆ
diff´ rents serveurs. Ils doivent egalement etre capable d’analyser le trafic r´ seau
e e
afin de permettre une meilleure r´ partition des ressources r´ seaux. Pour cel` , ils
e e a
ˆ
peuvent etre d´ ploy´ s de diff´ rentes mani` res.
e e e e
2.4.1 D´ ploiement des logiciels de supervision :
e
ˆ
Ces outils peuvent etre d´ ploy´ s de trois mani` res diff´ rentes : centralis´ e,
e e e e e
hi´ rarchique ou distribu´ e.
e e
D´ ploiement centralis´ La supervision n’est assur´ e que par un seul ordinateur,
e e e
´
avec eventuellement une ou plusieurs machines mirroir synchronis´ es. La visuali-
e
´e ´
sation des el´ ments du r´ seau (alarmes, etat des noeuds, etc...) est alors centralis´ e
e e
en un point unique.
11
Remote Monitoring.
11

12. 2.4 Les logiciels de supervision 2 La supervision / administration r´ seau
e
Ce type de supervision reste tout de mˆ me sensible, car toute la gestion repose
e
`
sur une seule station. Si celle-ci vient a tomber en panne, tout le processus de
´
supervision est alors compromis. De plus la machine etant seule, elle doit etre ˆ
suffisament robuste pour pouvoir traiter l’ensemble des donn´ es de supervision du
e
r´ seau. Enfin, la machine effectue la totalit´ des requˆ tes de supervision, ce qui a
e e e
pour cons´ quence d’augmenter fortement le trafic r´ seau en provenance de cette
e e
machine.
D´ ploiement hi´ rarchique La supervision est assur´ e ici de mani` re hi´ rarchique.
e e e e e
Un serveur de supervision central dialogue avec d’autres serveurs de supervision
ne s’occupant chacun que d’un segment de r´ seau. Ces mˆ mes serveurs peuvent
e e
`
aussi avoir d’autres serveurs sous leur responsabilit´ . Ils sont a la fois clients et
e
serveurs de supervision.
e e `
Ce type de d´ ploiement est bien plus d´ licat a mettre en oeuvre qu’un simple
e e e ´e e
d´ ploiement centralis´ mais offre une tol´ rance aux pannes bien plus el´ v´ e. En ef-
fet, si un serveur supervisant un segment tombe en panne, seul le segment concern´ e
ne sera plus supervis´ . De plus un tel d´ ploiement permet d’avoir plusieurs visions
e e
du r´ seau : une vision globale, depuis le serveur central, une vision d’un segment
e
depuis un serveur supervisant un segment, etc...
Toutefois, il ne faut pas occulter le fait qu’un d´ ploiement hi´ rarchique reste
e e
plus coˆ teux en temps de r´ ponse qu’un d´ ploiement centralis´ , les diff´ rents
u e e e e
serveurs devant se synchroniser pour faire remonter les informations au niveau
hi´ rarchique le plus haut.
e
D´ ploiement distribu´ Ce d´ ploiement combine l’approche centralis´ e et l’ap-
e e e e
e `
proche hi´ rarchique. Chaque station de supervision tient a jour une base de donn´ es
e
e ´
compl` te. Toutes les stations echangent donc entre elles les donn´ es de supervi-
e
sion, sans restriction. Cel` permet mˆ me de sp´ cialiser certaines machines sur un
a e e
traitement de supervision pr´ cis (alarme, s´ curit´ , performances, etc...). Toutefois,
e e e
il convient de bien d´ finir le degr´ de responsabilit´ et de coop´ ration entre les
e e e e
machines.
2.4.2 Quelques outils de la supervision
Les plateformes compl` tes de supervision reposent toutes sur le protocole SNMP.
e
En voici une liste non exhaustive :
– HP Open View : solution de supervision modulaire tr` s compl` te d´ velopp´ e
e e e e
par HP. Elle permet globalement de cartographier automatiquement et dyna-
miquement le r´ seau, de collecter les informations de supervision, de les
e
mettre en correspondance, d’envoyer des alarmes, de maintenir une base
e e ´ e
de donn´ es simplifi´ e pour analyser l’historique des ev´ nements et enfin de
12

13. 2.4 Les logiciels de supervision 2 La supervision / administration r´ seau
e
g´ n´ rer automatiquement des comptes rendus graphiques.
e e
– Big Brother : superviseur simple de services fonctionnant sous Windows
NT. Il est efficace mais ne permet de ne superviser qu’un nombre restreint
de services (http, pop, nntp, smtp et quelques autres). De plus on ne peut
lui ajouter de nouvelles fonctionnalit´ s et il est incapable de remonter les
e
alarmes autrement que graphiquement (pas d’envoie de mail ou de sms).
`
– CiscoWorks 2000 : outil de supervision propri´ taire a Cisco, parfaitement
e
adapt´ pour monitorer et configurer le mat´ riel cisco. Attention ce super-
e e
viseur mat´ riel utilise les propri´ t´ s sp´ cifiques du mat´ riel de la marque
e ee e e
cisco (CDP 12 , etc...). Il n’est donc pas du tout adapt´ pour un autre type
e
de mat´ riel. En outre, il permet de configurer facilement et graphiquement
e
le mat´ riel CISCO sans connaissance des commandes de leurs IOS (permet
e
mˆ me de configurer les VLAN et le Spanning Tree). Il s’installe sous Win-
e
dows NT.
– MRTG 13 : outil de visualisation bas´ sur SNMP et permettant la r´ alisation
e e
d’un historique graphique des variables repr´ sentatives des performances du
e
´e
r´ seau et de ses el´ ments. MRTG est inclus dans Nagios.
e
– Nagios : voir 3
Parmi les logiciels les plus employ´ s, nous retiendrons la plateforme HP Open-
e
View et Nagios (anciennement NetSaint).
Maintenant que le concept de supervision est connu, nous allons vous pr´ senter
e
un outil de supervision libre et tr` s utilis´ : Nagios.
e e
12
Cisco Discovery Protocol.
13
Multi Router Trafic Grapher.
13

14. 3 Supervision : l’exemple de Nagios
3 Supervision : l’exemple de Nagios
´ `
Un des besoins les plus exprimes en matiere de gestion de reseau´
´
est la surveillance des services. C’est donc dans une demarche de qualite´
` ` ´ ´
de service, et de maniere a pouvoir reagir dans les plus brefs delais, que
de nombreuses solutions de supervision de services ont vu le jour, dont
Nagios.
3.1 Pr´ sentation g´ n´ rale
e e e
3.1.1 Le concept
Nagios est un syst` me de supervision de services, la version stable actuelle
e
est la 1.214 . Il a et´ d´ velopp´ pour fonctionner sur une plateforme Linux ou
´e e e
´
eventuellement Unix avec un concept assez simple : les services de surveillance
lancent par intermittence des contrˆ les de services et de stations que l’on d´ finit,
o e
a `
grˆ ce a des greffons 15 externes.
3.1.2 Le fonctionnement
Nagios r´ cup` re les informations fournit par les services de surveillance et les
e e
analyse. Si le r´ sultat de cette analyse fait remonter un probl` me, les services de
e e
`
surveillance peuvent envoyer des avertissements a l’administrateur du r´ seau de
e
e e ´
diff´ rentes mani` res : courriers electroniques, messages instantan´ s, SMS, etc.
e
3.1.3 mode de licence
Nagios est distribu´ sous les termes de la GNU General Public Licence Version
e
2 comme publi´ e par la Free Software Foundation (FSF16 ). Cette licence donne la
e
permission l´ gale de copier, distribuer et/ou modifier Nagios sous certaines condi-
e
tions.
3.1.4 P´ rim` tre de l’outils
e e
Nagios poss` de de nombreuses fonctionnalit´ s, voici les principales :
e e
– Surveillance des services r´ seaux(SMTP, POP3, http, NNTP, PING, etc)
e
– Surveillance des ressources des stations (serveur, routeur ...) comme la charge
du processeur, des informations sur l’utilisation des disques durs, les proces-
sus en cours, les fichiers de log, . . .
– Surveillance des donn´ es environnementales comme par exemple la temp´ rature.
e e
14
T´ l´ chargeable sur http ://www.nagios.org/download
ee
15
le terme ”Greffon” est la traduction officielle du mot anglais ”plugin”
16
e´ ` e
Fondation cr´ ee par Richard M. Stallman au d´ but des ann´ es 80 visant a d´ velopper les logiciels
e e
libres. http ://www.gnu.org/
14

15. 3.1 Pr´ sentation g´ n´ rale
e e e 3 Supervision : l’exemple de Nagios
– Une conception simple de greffons permettant aux administrateurs de d´ velopper
e
facilement leurs propres fonctionnalit´ s de surveillance.
e
e e `
– Possibilit´ de d´ finir des groupes de contacts a joindre en cas d’apparition
e e e ´
de probl` me via diff´ rentes m´ thodes (le courrier electronique, les messages
instantan´ s).
e
– Sectorisation des groupes de contacts par rapport aux probl` mes rencontr´ s
e e
¸´
et d´ finition de procedures
e
e e e ˆ
– D´ finition de gestionnaires d’´ v´ nements qui peuvent etre ex´ cut´ s afin d’au-
e e
tomatiser la r´ solution de probl` mes rencontr´ s.
e e e
– Surveillance des architectures des syst` mes r´ partis ou redondants.
e e
`
– L’interface de commandes externes permet des modifications a la vol´ e du e
`
comportement de la surveillance et du retour d’informations a travers l’utili-
sation de gestionnaires d’´ v´ nements, d’une interface web et d’applications
e e
tierces.
– L’historique de l’´ tat du r´ seau est conserv´ mˆ me apr` s un red´ marrage
e e e e e e
– Possibilit´ de plannifier des p´ riodes d’inactivit´ s des contrˆ les pour corres-
e e e o
`
pondre a une p´ riode d’inactivit´ physique d’un serveur.
e e
`
– Retour d’informations disponible a travers n’importe quel navigateur, per-
mettant de consulter l’´ tat courant du r´ seau, l’historique des avertissements
e e
et les fichiers de log.
– Un sch´ ma simple de gestion des autorisations permet de g´ rer facilement
e e
`
les droits de consultation des informations par les utilisateurs a travers un
navigateur.
e ´
Nagios poss` de egalement une fonctionnalit´ importante : l’h´ ritage. Cela permet
e e
de hierarchiser l’ensemble des hˆ tes supervis´ s. Concrˆ tement, si un hˆ te faisant
o e e o
la jonction entre la machine Nagios et le reste d’une branche ne fonctionne plus,
´e
Nagios ne g´ n´ rera pas d’alertes concernant les el´ ments de cette branches.
e e
3.1.5 Architecture
´e
Voici les el´ ments de l’architecture de Nagios :
– Un ordonnanceur : Nagios est d’abord un moteur g´ rant l’ordonnacement
e
`
des v´ rifications, ainsi que les actions a prendre sur incidents (alertes, esca-
e
lades, prise d’action corrective) ;
– Une IHM17 : La partie visible a travers un simple serveur web, tel Apache,
`
est bas´ e sur des CGI18 ;
e
– Des sondes : Les sondes de Nagios sont des petits scripts ou programmes
qui sont la base des v´ rifications.
e
17
IHM : Interface Homme-Machine
18
CGI : Common Gateway Interface
15

16. 3.2 Les greffons 3 Supervision : l’exemple de Nagios
3.2 Les greffons
3.2.1 Principe de base
Nagios est un moteur d’ordonnancement de v´ rifications diverses assur´ es par
e e
des greffons. La relation entre le moteur principal et les greffons se fait d’une part
dans la configuration de Nagios, pour que Nagios sache quelles v´ rifications lancer
e
`
sur, ou a destination, de quelles machines ou services ; d’autre part par le code re-
tour ainsi que la sortie standart d’un greffon.Ces greffons fonctionnent soit en local
`
sur la machine Nagios, soit effectuent des tests a distance.
Voici comment on peut sch´ matiser le fonctionnement de base :
e
F IG . 2 – Illustration du principe de fonctionnement des greffons
Il est donc possible d’effectuer des tests de toutes sortes (fonctionnement de
services, espace disque, charge, . . .) sur la machine Nagios, ainsi que des tests
simples (par exemple ping) sur une machine distante.
3.2.2 Fonctionnalit´ s avanc´ es
e e
Afin de pouvoir effectuer des v´ rifications plus pouss´ es sur une machine dis-
e e
tante sans pour autant modifier la configuration de s´ curit´ mise en place, les
e e
cr´ ateurs de nagios ont d´ velopp´ diff´ rent agents de transport et d’ex´ cution de
e e e e e
test. Cette possibilit´ reprend une fonction d´ finie par la norme ISO 7498/4 : la
e e
Structure de gestion de r´ seaux (MNS).
e
Voici deux des principaux agents propos´ s par Nagios :
e
– NRPE (Nagios Remote Plugin Executor) : il constitue une m´ thode de sur-
e
veillance dite active. En effet, l’initiateur et l’ordonnanceur des tests est la
`
machine nagios : le plugin check nrpe permet a la machine Nagios d’envoyer
des instructions aux d´ mon NRPE situ´ sur la machine distante.
e e
– NSCA (Nagios Service Check Acceptor) : il s’agit l` d’une m´ thode passive :
a e
le client NSCA est install´ , configur´ et lanc´ sur chaque hˆ te distant de sorte
e e e o
` `
a envoyer des r´ sultats de tests a la machine Nagios.
e
16

17. 3.3 Configuration des composants 3 Supervision : l’exemple de Nagios
3.2.3 Ecriture de greffons
Le projet Nagios fournit en standart bon nombre de greffons de base, mais la
` ´
simplicit´ de leur mode de fonctionnement permet a l’administrateur d’en ecrire
e
pour ses propres besoins.
3.3 Configuration des composants
3.3.1 Apache
Il est n´ cessaire d’int´ grer dans le serveur web apache un certain nombre de di-
e e
rectives. Ces directives vont permettre de r´ gler diff´ rentes options (chemin d’acc` s,
e e e
autentification, etc.). Il est donc possible pour r´ aliser ses op´ rations d’intervenir
e e
directement sur le fichier de configuration du serveur Apache, soit en int´ grant un
e
`
fichier de configuration propre a Nagios.
3.3.2 Authentification
e ` ˆ
L’acc` s a Nagios doit etre restreint, car il peut montrer des informations impor-
ˆ
tantes voir confidentielles. De plus, des actions peuvent etre prises via l’interface
Web comme par exemple l’acquiescement d’une alarme au red´ marrage d’un ser-
e
e e ´e e e
veur. La d´ finition des r` gles d’authentification ayant et´ r´ alis´ durant la configu-
ration de apache, il suffit de renseigner le fichier /etc/nagios/htpasswd. Cela se fait
par le biais de l’utilitaire htpasswd fourni avec apache :
#htpasswd [-c] /etc/httpd/htpasswd nagios
New password: ******
Re-type new password: ******
Updating password for user nagios
e `
L’utilisateur nagios utilis´ correspond a un contact d´ fini dans /etc/nagios/contacts.cfg
e
`
et non a l’utilisateur POSIX.
3.3.3 Nagios
Les fichiers de configuration de Nagios se trouve dans le r´ pertoire /etc/nagios/.
e
`
Ces fichiers de configuration, a l’exception des fichiers nagios.cfg et cgi.cfg, uti-
lisent une structure unique de d´ finition des objets sur le principe suivant :
e
define {
param1 value
param2 value
...
paramn value
}
17

18. 3.4 Utilisation 3 Supervision : l’exemple de Nagios
Le fichier de configuration principal :
Le fichier de configuration principal (par d´ faut, /usr/local/nagios/etc/nagios.cfg)
e
contient un certain nombre de directives qui affectent la mani` re dont Nagios fonc-
e
tionne. Ce fichier est lu par le processus Nagios et par les CGIs. Un fichier de
`
configuration principal est g´ n´ r´ automatiquement a titre d’exemple quand vous
e ee
lancez le script ”configure” avant de compiler les programmes.
Fichier de configuration des ressources :
Les fichiers des ressources sont utilis´ s pour stocker les macros d´ finies par les
e e
utilisateurs. Ces fichiers peuvent aussi contenir d’autres informations (telles que la
configuration des connexions de la base de donn´ es), bien que celles-ci d´ pendent
e e
de la mani` re dont est compil´ Nagios. L’avantage de ces fichiers est de pouvoir y
e e
`
mettre des donn´ es sensibles de configuration qui ne seront pas accessibles a tra-
e
vers les CGIs.
Fichier de configuration des objets :
Le fichier de configuration des objets (historiquement appell´ ”host” dans les fi-
e
chiers de configuration) d´ finit les hˆ tes, services, groupes d’hˆ tes, contacts, groupes
e o o
´e `
de contacts, commandes, etc ... C’est l` que sont d´ fini les el´ ments a surveiller.
a e
Fichier de configuration des CGIs :
Le fichier de configuration des CGIs (par d´ faut, /usr/local/nagios/etc/cgi.cfg) contient
e
un certain nombre de directives qui affectent le mode de fonctionnement des CGIs.
´
Fichier de configuration des informations etendues :
´
Le fichier de configuration des informations etendues est utilis´ pour d´ finir des
e e
e o ˆ
informations suppl´ mentaires pour les hˆ tes et les services qui doivent etre utilis´ s
e
par les CGIs.
`
Il est possible de tester la coh´ rence des fichiers de configuration a l’aide de la
e
commande suivante :
#/usr/bin/nagios -v ../etc/nagios.cfg
3.4 Utilisation
3.4.1 L’interface d’administration
Nagios a bas´ l’enti` re int´ raction entre les administrateurs et le programme
e e e
via une interface web. Ceci pour r´ pondre aux besoins d’accessibilit´ des admi-
e e
nistrateurs (claires, regroup´ es, graphiques, accessibles de n’importe quel endroit,
e
´
etc.) mais aussi pour s’appuyer sur des technologies Unix eprouv´ es comme le
e
serveur Web apache qui va prendre en charge une partie de la gestion des acc` s a e `
l’interface.
18

19. 3.4 Utilisation 3 Supervision : l’exemple de Nagios
L’interaction utilisateur via son navigateur et les processus Nagios sur la sta-
a `
tion de supervision vont se faire grˆ ce a des CGIs (Common Gateway Interface) et
permettre entre autre la pr´ sentation des informations de mani` re graphique. Cette
e e
´ `
interface va permettre egalement a l’administrateur d’utiliser des commandes ap-
pel´ es commandes externes (dont la s´ curit´ est bas´ e sur la gestion des droit Unix)
e e e e
`
afin d’intervenir a distance, am´ liorant ainsi la r´ activit´ .
e e e
3.4.2 Des alarmes aux administrateurs
La traduction claire et graphique de l”´ tat des noeuds en quasi temps-r´ el
e e
est une mesure indispensable de la supervision de r´ seau. N´ anmoins elle n’est
e e
pas suffisante et l’une des fonctionnalit´ s les plus int´ ressantes de Nagios est son
e e
interfacage avec un serveur SMTP19 ou de SMS20 . Ainsi il est possible de pr´ venir
¸ e
instantan´ ment les administrateurs au lieu d’attendre que ceux-ci effectuent des
e
v´ rifications. Ils sont tenus au courant automatiquement de l’´ tat des services et
e e
cela engendre une r´ activit´ plus grande.
e e
e ´
Une deuxi` me etape permise par Nagios est la classification des remont´ es e
d’informations aux diff´ rents administrateurs class´ s par secteur de comp´ tences.
e e e
Ainsi un expert du service d´ faillant sera alert´ , ciblant les comp´ tences n´ cessaires
e e e e
e e e`
et r´ duisant proportionnellement les d´ lais de remise en fonction. Ajout´ a cette
fonction, Nagios permet l’automatisation de l’escalade des actions et alertes en-
e e `
clench´ es en r´ ponse a une situation donn´ e, permettant une plus grande liaison et
e
e e e `ˆ
une meilleure synchronisation des r´ ponses et proc´ dures amen´ es a etre mise en
place dans la supervision des services d’un r´ seau.
e
3.4.3 Les statistiques et l’anticipation
Nagios offre un service efficace de m´ morisation et de traduction graphique
e
´ e
des ev´ nements advenus sur l’ensemble des services et stations du r´ seau. Cette
e
fonction est indispensable pour mener une analyse approfondie des causes ayant
e e ´
men´ es aux diff´ rentes pannes survenues. Il semble evident que pour am´ liorer la
e
proactivit´ et non la r´ activit´ , une connaissance pointue des coˆ ts et besoins de
e e e u
ˆ
son r´ seau, proportionnelle aux ressources mise en place doit etre maintenue et an-
e
ticip´ e. Cela passe forc´ ment par la mise en place d’outils g´ n´ rant des statistiques
e e e e
e e `
repr´ sentatives et adapt´ es a l’architecture de son r´ seau et de ses services.
e
19
Simple Mail Transer Protocol
20
Short Message Service
19

20. 4 Conclusion
4 Conclusion
4.1 Bilan
Les r´ seaux sont devenus un pilier de l’´ conomie mondiale. Les besoins et les
e e
enjeux de ces technologies ne cessant d’augmenter, la supervision est alors appa-
rue pour apporter une garantie de fiabilit´ , de r´ activit´ et d’ad´ quation des moyens
e e e e
mis en place. N´ anmoins la grande disparit´ de ces technologies de r´ seau pose un
e e e
certain nombre de probl` mes : comment superviser toutes ces technologies, com-
e
ment r´ cup´ rer les informations, etc.
e e
´e `
Les organismes de normalisations ont et´ les premiers a apporter une r´ ponse
e
en d´ finissant un format commun des donn´ es, un mod` le d’administration pour les
e e e
adresser et des protocoles pour les communiquer. La mise en place d’une proc´ dure
e
de supervision de r´ seaux passe alors forc´ ment par l’application concr` te d’une de
e e e
ces normes, sans laquelle il est impossible d’obtenir une r´ elle plus valu sur l’ad-
e
´ e`
ministration de son r´ seau. Le seul v´ ritable standard actuel du monde IP elabor´ a
e e
partir de ces normes est le protocole SNMP. Il constitue la base de la majorit´ des
e
plateformes logicielles de supervision r´ seau dont Nagios, une des plus populaires.
e
e a `
Nagios r´ ussit, grˆ ce a son exploitation intelligente des capacit´ s des techno-
e
`
logies Unix, a proposer une plate-forme de supervision d’une grande vari´ t´ de ee
services, compl` te et facilement modulable.
e
Elle r´ pond aux besoins de supervision de nombreux services bas´ s sur des
e e
protocoles diff´ rents et a su pr´ senter des fonctionnalit´ s adapt´ es aux attentes
e e e e
e e `
concr` tes de la supervision comme l’accessibilit´ et ses interactions a distance,
l’automatisation des remont´ es d’alarmes jusqu’aux administrateurs, ou encore les
e
´ e
comptes-rendus et historiques graphiques des ev´ nements du r´ seau.
e
4.2 Quel avenir ?
e e `
Nagios 2.0 est virutellement prˆ t mais la documentation n’´ tant pas a jour, sa
sortie en est diff´ r´ . Cette version int´ grera notamment des am´ liorations dans la
ee e e
configuration. Parall` lement, un projet nomm´ OREON est en cours de d´ veloppement.
e e e
Ce projet a pour but de construire une solution compl` te bas´ e sur Nagios.
e e
Les organismes de normalisation de la supervision et les diff´ rents acteurs
e
e ´
du r´ seau sont etroitement li´ s, ce qui permet le d´ veloppement de normes qui
e e
r´ pondent aux plus justes aux besoins des r´ seaux d’aujourd’hui et permettent
e e
d’anticiper les besoins futurs. Les outils commerciaux de supervision b´ n´ ficient
e e
alors directement des avanc´ es des recherches men´ es au sein des consortiums par
e e
`
les constructeurs. La supervision avance ainsi a grand pas et sera certainement un
pillier des r´ seaux de demain.
e
20

21. ´ ´
REFERENCES
5 Ressources
5.1 Bibliographie
5.1.1 Ouvrages
R´ f´ rences
ee
[1] ”Les r´ seaux”, Guy Pujolle, edition Eyrolles, 3eme edition 2002
e ´ ´
[2] ”Th´ orie et pratique : Supervision avec Nagios”, GNU Linux Magasine No
e
65.
[3] ”Pratique de la gestion de r´ seau”, Nazim AGOULMINE, Omar CHER-
e
KAOUI, Edition Eyrolles 2003
[4] ”Nagios, un outil GPL de surveillance pour petits et grands r´ seaux
e
h´ t´ rog` nes”, Pierre-Antoine Angelini, JRES 2003
ee e
5.1.2 R´ f´ rences de sites internet
ee
Sites web ind´ pendants
e
http ://www.snmplink.org :
Un site contenant des informations sur SNMP et les MIB.
http ://wwwsnmp.cs.utwente.nl/ :
Un site tr` s complet sur les normes de supervision de r´ seaux.
e e
http ://www.et.put.poznan.pl/snmp/main/mainmenu.html :
Un site qui introduit tr` s simplement les diff´ rentes versions des normes SNMP.
e e
Sites Web commerciaux et institutionnels
http ://www.nagios.org : le site officiel de Nagios
http ://www.dmtf.org : le site officiel du DMTF.
http ://www.iso.org : le site officiel de l’ISO.
http ://www.ietf.org : le site officiel de l’IETF.
http ://www.snmp.org : le site officiel du centre de recherche international
sur SNMP.
21

22. 5.2 Glossaire ´ ´
REFERENCES
5.2 Glossaire
A:
ASN.1 (Abstract Syntaxe Notation number One)
Notation formelle qui permet de sp´ cifier tr` s facilement et sans sacrifier a la
e e `
g´ n´ ralit´ les informations manipul´ es par les protocoles de t´ l´ communications,
e e e e ee
ind´ pendamment des syst` mes informatiques, des logiciels et des modes de trans-
e e
fert des donn´ es.
e
C:
CIM (Common Information Model)
Norme d´ velopp´ e par le DMTF permettant de d´ crire des donn´ es, des applica-
e e e e
tions ou des entit´ s de telle mani` re que les administrateurs et les programmes de
e e
gestion puissent contrˆ ler les diff´ rentes applications et dispositifs des diff´ rentes
o e e
e e e e `
plates-formes de la mˆ me mani` re, assurant ainsi l’interop´ rabilit´ a travers le
r´ seau.
e
CGI (Common Gateway Interface)
Interface standard install´ e sur les serveurs HTTP permettant entre autres l’envoi
e
`
de variables d’entr´ e et d’environnement a tout programme serveur dont on de-
e
mande l’ex´ cution (utile par exemple pour la saisie de formulaires via le Web).
e
CMIP (Common Management Information Protocol)
Norme de supervision de r´ seaux d´ finie par l’ISO qui permet de fournir les ser-
e e
vices li´ s au standard CMIS.
e
CMIS (Common Management Information Services)
Norme de supervision de r´ seaux d´ finie par l’ISO qui pr´ sente les services uti-
e e e
lisables par les entit´ s de gestion. CMIS d´ finie un ensemble de primitives et la
e e
´
structures des messages echangeables par CMIP.
D:
DMTF (Distributed Management Task Force)
Consortium industriel tr` s actif dans la recherche et le d´ veloppement de normes
e e
de supervision ainsi qu’` leur mise en place.
a
I:
ICMP (Internet Control Message Protocol)
Extension du protocole Internet qui permet la g´ n´ ration de messages d’erreurs, de
e e
tests et d’informations relatifs aux conditions de transmission sur le r´ seau.
e
22

23. 5.2 Glossaire ´ ´
REFERENCES
IETF (Internet Engineering Task Force)
Groupe de travail qui d´ veloppe les nouveaux standards pour l’Internet.
e
IOS (Internetworking Operating System)
Permet aux routeurs et commutateurs de fonctionner avec (IP, IPX) en r´ seau local,
e
´
(X.25, RNIS, PPP, Frame Relay) en r´ seau etendu avec les protocoles de routage :
e
RIP, IGRP.
ISO (International Organisation for Standardization)
Organisation internationale de standardisation regroupant les organismes similaires
de 89 nations. L’ISO se charge des standards qui r´ gissent l’Internet actuellement.
e
IT (Information Technology)
Se dit de l’ensemble des technologies (mat´ rielles et logicielles) qui permettent la
e
`
collecte, le stockage et l’exploitation des informations a des fins d’usage sp´ cifique.
e
Ces technologies sont en train de r´ volutionner les structures sociales, culturelles et
e
´
economiques en g´ n´ rant de nouveaux comportements vis-` -vis de l’information
e e a
et de l’intelligence, de la connaissance et de leur repr´ sentation, des m´ tiers et de
e e
l’activit´ professionnelle.
e
M:
MIB (Management Information Base)
ˆ e a `
Base de donn´ es d’objets pouvant etre consult´ e grˆ ce a un syst` me de supervision
e e
de r´ seau.
e
MRTG (Multi Router Traffic Grapher)
Logiciel Unix gratuit bas´ sur SNMP permettant la traduction graphique de donn´ es
e e
pertinentes r´ cup´ r´ es sur des entit´ s du r´ seau.
e ee e e
N:
NMS (Network Management System)
Syst` me de gestion de r´ seau.
e e
O:
OSI (Open Systems Interconnection)
`
Architecture a 7 couches qui normalise les niveaux de service et les types d’inter-
´ `
actions entre les ordinateurs qui echangent des informations a travers un r´ seau.
e
Elle d´ crit le flux des donn´ es entre la connexion physique et le r´ seau d’une part
e e e
et le programme de l’utilisateur final d’autre part.
23

24. 5.2 Glossaire ´ ´
REFERENCES
R:
RFC (Request For Comment)
e ´
Une s´ rie de documents techniques emanant de la communaut´ de recherche et du
e
d´ veloppement de l’Internet.
e
S:
SMS (Short Message Service)
ˆ
Messages courts qui peuvent etre envoy´ s et recus sur des t´ l´ phones mobiles
e ¸ ee
GSM.
SMTP (Simple Mail Transfer Protocol)
´
Protocole de gestion des courriers electroniques sur Internet.
SNA (System Network Architecture)
Architecture de r´ seau en couche introduit par IBM et qui servit, plus tard, de base
e
au mod` le OSI.
e
SNMP (Simple Network Management Protocol)
Protocole de supervision de r´ seaux concu par l’IETF pour le monde IP. Il existe
e ¸
actuellement 3 versions.
24

25. 6 ANNEXES
6 ANNEXES
6.1 SNMP : D´ tail du Packet Data Unit
e
Il existe deux structures de PDU dans SNMP. La premi` re est commune aux
e
requˆ tes et aux r´ ponses. Elle est constitu´ e des champs suivants :
e e e
F IG . 3 – PDU SNMP (requˆ tes et r´ ponses).
e e
L’autre PDU est propre aux alarmes (trap). Il est construit de la mani` re sui-
e
vante :
F IG . 4 – PDU SNMP (alarmes).
6.1.1 PDU Type
Il identifie le message transport´ par le PDU. Ses valeurs possibles sont les
e
suivantes :
– 0 : GetRequest
– 1 : GetNextRequest
– 2 : SetRequest
– 3 : GetResponse
– 4 : Trap
6.1.2 Request ID
Il permet de faire correspondre une requˆ te avec une r´ ponse.
e e
6.1.3 Error Status
Il est utilis´ par les r´ ponses et les requˆ tes pour indiquer une erreur du type
e e e
suivant :
25

26. 6.1 SNMP : D´ tail du Packet Data Unit
e 6 ANNEXES
– 0 : NoError
– 1 : tooBig
– 2 : noSuchName
– 3 : badValue
– 4 : readOnly
– 5 : genError
6.1.4 Error Index
Il indique, dans le cas d’une erreur, quelle variable a caus´ l’erreur.
e
6.1.5 Variable Binding List
Ce champ liste les variables. Pour chaque variable, il est constitu´ de l’identi-
e
e`
ficateur unique de la variable dans la base MIB (ObjectName), associ´ a la valeur
de la variable (Value).
6.1.6 Entreprise
Il est l’identifiant de l’agent ayant g´ n´ r´ l’alarme.
e ee
6.1.7 Agent-addr
C’est l’adresse IP de l’agent ayant g´ n´ r´ l’alarme.
e ee
6.1.8 Generic-Trap
Ce champ prend une des septs valeurs possibles de l’alarme :
e e `
– 0 : ColdStart : red´ marrage du syst` me a froid.
e e `
– 1 : WarmStart : red´ marrage du syst` me a chaud.
– 2 : LinkDown : le lien n’est plus op´ rationnel.
e
`
– 3 : LinkUp : le lien est a nouveau op´ rationnel.
e
e `
– 4 : AuthentificationFailure : Tentative d’acc` s a l’agent avec un mauvais nom
de communaut´ . e
– 5 : EgpNeighborLoss : la passerelle adjacente ne r´ pond plus.
e
– 6 : EntrepriseSpecific : alarme sp´ cifique aux entreprises.
e
6.1.9 Specific-Trap
e e `
Ce champ est un code d´ terminant la nature de l’alarme. Il est sp´ cifique a
chaque agent propri´ taire.
e
6.1.10 Time-Stamp
´
Ce champ donne le temps ecoul´ , en millisecondes, entre l’envoi de l’alarme
e
et l’initialisation de l’agent.
26

27. 6.2 Quelques outils et leur interface 6 ANNEXES
6.2 Quelques outils et leur interface
6.2.1 Nagios
´
F IG . 5 – Nagios - Liste des etats des services supervis´ s.
e
F IG . 6 – Nagios - Information d´ taill´ e sur l’´ tat d’un service.
e e e
27

28. 6.2 Quelques outils et leur interface 6 ANNEXES
F IG . 7 – Nagios - Repr´ sentation graphique des machines supervis´ es.
e e
F IG . 8 – Nagios - Etat d’un service sur une machine pour une p´ riode donn´ e.
e e
28

29. 6.2 Quelques outils et leur interface 6 ANNEXES
6.2.2 HP Open View
F IG . 9 – HP Open View - Vue d’ensemble apr` s la premi` re d´ couverte.
e e e
F IG . 10 – HP Open View - Vue par sectorisation g´ ographique.
e
29

30. 6.2 Quelques outils et leur interface 6 ANNEXES
F IG . 11 – HP Open View - Vue par le web.
6.2.3 Big Brother
´
F IG . 12 – Big Brother - Tableau des etats des services par serveur.
30

31. 6.2 Quelques outils et leur interface 6 ANNEXES
F IG . 13 – Big Brother - Page dynamique de remont´ d’erreurs.
e
6.2.4 CiscoWorks
F IG . 14 – CiscoWorks - Page d’accueil.
31

32. 6.2 Quelques outils et leur interface 6 ANNEXES
6.2.5 MRTG
F IG . 15 – MRTG.
32

33. TABLE DES FIGURES TABLE DES FIGURES
Table des figures
1 Network Management System (MNS). . . . . . . . . . . . . . . . 8
2 Illustration du principe de fonctionnement des greffons . . . . . . 16
3 PDU SNMP (requˆ tes et r´ ponses). . . . . . . . . . . . . . . . . .
e e 25
4 PDU SNMP (alarmes). . . . . . . . . . . . . . . . . . . . . . . . 25
5 ´
Nagios - Liste des etats des services supervis´ s. . . . . . . . . . .
e 27
6 Nagios - Information d´ taill´ e sur l’´ tat d’un service. . . . . . . .
e e e 27
7 Nagios - Repr´ sentation graphique des machines supervis´ es. . . .
e e 28
8 Nagios - Etat d’un service sur une machine pour une p´ riode donn´ e.
e e 28
9 HP Open View - Vue d’ensemble apr` s la premi` re d´ couverte. . .
e e e 29
10 HP Open View - Vue par sectorisation g´ ographique. . . . . . . .
e 29
11 HP Open View - Vue par le web. . . . . . . . . . . . . . . . . . . 30
12 ´
Big Brother - Tableau des etats des services par serveur. . . . . . . 30
13 Big Brother - Page dynamique de remont´ d’erreurs. . . . . . . .
e 31
14 CiscoWorks - Page d’accueil. . . . . . . . . . . . . . . . . . . . . 31
15 MRTG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
33