Memoiretymtyma

DEDICACES
Je dédie ce mémoire à :
 Mes très chers parents en guise de remerciements pour leur dévouement à mon
éducation et surtout aux sacrifices consentis pour la bonne marche de mes études
 Mes frères et sœurs
 Ainsi qu’à tous les membres de ma famille
 Mes amis
 Mes promotionnaires
Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 1

REMERCIEMENTS
Nous remercions tout d’abord ALLAH le tout puissant de nous avoir accordé vie et santé
jusqu’à la réalisation de ce travail, ainsi que son prophète Mohamed (Paix et salut sur lui).
Nous tenons également à exprimer nos vifs remerciements à tous ceux qui par leur travail,
leur idée, leur collaboration ont participé de prés ou de loin à la réalisation de ce mémoire à
savoir :
 Notre professeur encadreur Monsieur Samuel Ouya, grâce à son sens poussé de la
pédagogie et à sa rigueur. Il nous a fait bénéficier de ses connaissances, tout en ayant
la volonté de nous encadrer.
 Tous les professeurs de la section mathématique informations.
 Toute la promotion IGTT2 Téléinformatique 2010-2012 de l’ESMT pour leur esprit

de groupe et leur parfaite entente.
 Mon maitre de stage Omar Sagnang, Mohamed Alimou aidara, mon chef de service
Namory Dia et toute l’équipe de la supervision IP.
Nous ne saurions terminer sans exprimer tous nos remerciements à nos très chers parents,
pour le soutien qu’ils n’ont jamais cessé de nous apporter tout au long de nos études. Qu’ils
trouvent l’expression de toute notre gratitude et notre profonde reconnaissance.

Table des matières
INTRODUCTION
CHAPITRE01 : Présentation générale et choix d’une plateforme de supervision
I. Présentation de la structure d’acceuil........................................................8

1. Historique et présentation de la SONATEL........................................................................8
2. Les différentes activités de la société F...............................................................................9
3. Organigramme de l’entreprise.............................................................................................9
II. Les enjeux et les acteurs de la supervision...............................................13

1. La problématique des réseaux privés d’entreprise...........................................................13
2. Les différents aspects de la supervision réseaux...............................................................13
a. L’analyse de flux..................................................................................................................14
b. La supervision SNMP : l’état des équipements.................................................................14
c. La supervision applicative : l’état des services..................................................................15
III. Choix du nagios et de cacti........................................................................15

1. Les offres éditeurs...............................................................................................................15
2. Les offres du monde libre...................................................................................................16
PREMIERE PARTIE : LE NAGIOS (OUTIL DE SUPERVISION DES

EQUIPEMENTS ET DES SERVICES)
CHAPITRE02: Architecture et Principe de fonctionnement du nagios
I. Historique et fonctionnement du protocole SNMP.................................18

1. Historique et présentation..................................................................................................18
2. Principe de fonctionnement du SNMP...............................................................................18
3. Nagios et SNMP...................................................................................................................20
4. Sécurité du protocole SNMP..............................................................................................20
a. L’authentification.................................................................................................................22
b. Le cryptage............................................................................................................................22
c. L’estampillage de temps.......................................................................................................23
II. Présentation et principe de fonctionnement de nagios..........................23

1. Historique............................................................................................................................23
2. Les fonctionnalités...........................................................................................................24
3. L’architecture de Nagios.................................................................................................24
4. Principe de fonctionnement de Nagios............................................................................25
a. Un fonctionnement par plugin..........................................................................................25
b. Les modes de fonctionnement complémentaires.............................................................26
c. Les états de nagios............................................................................................................27
5. Les notifications/envois d'alertes de nagios.....................................................................28
CHAPITRE03: Implémentation de Nagios
I. Installation...................................................................................................30
1. Pré-requis.............................................................................................................................30
2. Installation de nagios...........................................................................................................30
3. Installation des plugins Nagios...........................................................................................33
4. Installation du protocole SNMP.........................................................................................33
II. Configuration..............................................................................................33
1. Configuration d’apache......................................................................................................33
2. Configuration des fichiers principaux de nagios...............................................................36
3. Configuration du protocole SNMP...................................................................................40
III. Les interfaces de Nagios.............................................................................42

1. Les vue de monitoring.........................................................................................................42
2. Les vues de reporting..........................................................................................................44
IV. L’accès aux informations...........................................................................44
DEUXIEME PARTIE : LE CACTI (OUTIL DE SUPERVISION POUR

L'ANALYSE DE FLUX RESEAUX ET SYSTEMES)
I. RRDTOOL..................................................................................................48
1. Présentation.........................................................................................................................48
2. Manipulation.......................................................................................................................48
a. Création de fichiers RRD....................................................................................................48
b. Peuplement d’un fichier RRD............................................................................................49
c. Création du graphique........................................................................................................50

II. CACTI.........................................................................................................51
1) Présentation.........................................................................................................................51
2) Script de collecte de données..............................................................................................51
3) Création de la commande...................................................................................................52
4) Création de l’hôte................................................................................................................54
5) Source de données...............................................................................................................55
a. Modèle..................................................................................................................................56
b. Génération des sources à partir du modèle.......................................................................57
6) Graphiques..........................................................................................................................57
a. Modèle..................................................................................................................................57
b. Génération des graphiques à partir du modèle.................................................................59
7) Positionnement du graphique.............................................................................................60
CONCLUSION

Table des figures
Figure 1: Les actionnaires de l’entreprise..........................................................................................8

Figure 2:Formation du logo de la Sonatel..........................................................................................9
Figure 3:Organigramme du pôle d’exploitation DRSI/DEX...........................................................12
Figure 4:Accès à un service distant...................................................................................................14
Figure 5: Entité SNMPV3 : Machine SNMP + Applications..........................................................21
Figure 6: Architecture de Nagios......................................................................................................25
Figure 7 : Mode de fonctionnement de Nagios avec SNMP.............................................................27
Figure 8 : Notifications de Nagios.....................................................................................................29
Figure 9: Page d’accueil de Nagios....................................................................................................36
Figure 10 : Vue d'ensemble des informations par nagios................................................................43
Figure 11: Vue d'ensemble de l’état des hôtes du nagios.................................................................44
Figure 12: Phase d’authentification pour l’accès à Nagios..............................................................45
Figure 13: Ajouter une nouvelle commande.......................................................................................52
Figure 14: Paramètres d'entrées de la commande.............................................................................53
Figure 15: Déclaration des champs de sorties.....................................................................................54
Figure 16: Ajout d'un hôte...................................................................................................................54
Figure 17: Création de graphes standards...........................................................................................55
Figure 18: Ajout d'une source de données..........................................................................................56
Figure 19: Créer un modèle de graphique...........................................................................................58
Figure 20: Définir les éléments du graphique.....................................................................................59

INTRODUCTION
Actuellement aucune entreprise ne peut se passer d'outils informatiques, et très souvent un

réseau informatique de taille plus ou moins importante est mis en œuvre. Le nombre des
machines dans ces réseaux peut parfois devenir extrêmement élevé; La maintenance ainsi que
la gestion de ces parcs informatiques deviennent alors des enjeux cruciaux, d'autant plus
qu'une panne du réseau peut parfois avoir des conséquences catastrophiques.
C'est pourquoi les administrateurs réseau font appel à des logiciels de surveillance et de
supervision de réseaux. Ces logiciels vérifient l'état du réseau ainsi que des machines
connectées et permettent à l'administrateur d'avoir une vue d'ensemble en temps réel de
l'ensemble du parc informatique sous sa responsabilité. Il peut être aussi informé (par email,
par SMS) en cas de problème. Grâce à un tel système, les délais d'interventions sont fortement
réduits.
Plusieurs logiciels réalisent ces taches, comme par exemple Websense, Tivoli, Observer, Hp
Openview, Ciscoworks, Patrol et d'autres, mais certains sont payants.
Dans ce domaine, un logiciel fait office de référence: Nagios. En effet Nagios est très
performant et possède une prise en main assez intuitive. Il s'installe sur une machine
possédant un système d'exploitation Linux, mais peut superviser aussi bien des machines
Linux que Windows. Cet outil permet également une supervision des équipements réseaux
(routeur, switch), ce qui est primordial pour l'utilisation que l'on va en faire.
De plus, Nagios est un outil Open source: Chaque société peut l'adapter comme elle lui
semble. Puis, la société ne payera pas de licence: Elle ne payera que les frais de formation,
d'installation et de maintenance.
Enfin un autre avantage: Sa cohabitation avec l’outil de supervision CACTI rend la

supervision réseaux complète et indépendante. Une grosse communauté est réunie autour de
ces logiciels, ce qui facilite les recherches de documentations et de réponses à nos questions.
Notre projet consiste donc à superviser un réseau grâce à l'outil Nagios & Cacti. Chacun de
ces outils fera l’objet d’une partie complète.

CHAPITRE 1
Présentation de la structure d’acceuil
1. Historique et présentation de la SONATEL
La Société Nationale des Télécommunications (SONATEL) premier opérateur de

télécommunications au Sénégal a été créée le 23 Juillet 1985 par la fusion de l’Office des
Postes et des Télécommunications (OPT) et de Télé Sénégal.
Elle est devenue en 1997 une société privée en s’alliant à France Télécom qui possède
actuellement 42% de son capital. Cette figure montre les différents actionnaires de la
SONATEL.
Figure 1: Les actionnaires de l’entreprise
Elle comporte plusieurs filiales dont :
 SONATEL Mobiles créée En 1999, avec la marque Alizé gérant toutes les offres
mobiles du groupe.
 SONATEL Multimédia créée En 2001 chargée du développement de l’activité
internet sous la marque Sentoo.
 ORANGE Mali créée en 2002, la Guinée Bissau et la Guinée Conakry en 2007 ou
SONATEL commence à s’imposer comme un leader régional.
 SONATEL Business Entreprise créée En 2004, spécialisée dans les réseaux privés
d’entreprise.
En Novembre 2006, le groupe SONATEL adopte la marque commerciale Orange et un

nouveau logo formé par la ligature de deux mots dit « et commercial », symbole de sa fidélité
avec tous ses partenaires.

Figure 2:Formation du logo de la Sonatel
Le 31 Décembre 2007, SONATEL détient une part de marché d’environ 71% pour les
services mobiles avec plus de 5 millions de clients. Son réseau couvre environ 84% du
térritoire sénégalais. Son capital est estimé à cinquante (50) milliards de FCFA. F
FFFFF
2. Les différentes activités de la société F
La SONATEL assure l’exploitation et le développement de son secteur d’activité. Elle

dispose d’une connectivité internationale sécurisée grâce aux câbles sous-marins avec une
bande passante internet internationale de 11 Gbit/s actuellement.
Elle a un réseau GSM (2G, 3G) et RTC pour offrir les services de téléphonie fixe et mobile.
Elle a aussi un réseau de données IP/MPLS pour offrir l’internet, la TV/ADSL, la Mobile TV
et permettre aussi d’interconnecter les sites distants des entreprises par VPN.
3. Organigramme de l’entreprise
La direction de la SONATEL est composée d’une direction générale, d’une direction générale
adjointe, des directeurs des filiales (Orange Mali, Orange Conary, Orange Bissau, etc) et de
15 directions opérationnelles composées chacune de plusieurs départements, services et
centres techniques.
On fera une présentation détaillée du service DRSI/DEX/ERT/SQT au sein de lequel on a

effectué notre stage.
La Direction des Opérations Réseaux et Système d’Information (DRSI)

La Direction des Opérations Réseaux et Système d’Information (DRSI) anciennement appelée
DO (Direction des Opérations) est constituée de deux pôles :
 Le pôle Exploitation des réseaux (DEX).
 Le pôle Intervention (DINT).
Le pôle Exploitation des réseaux (DEX)
Ce pôle est chargé des missions suivantes :

 Assurer l’exploitation et la supervision.
 Assurer le déploiement, l’administration et le suivi de la maintenance des
serveurs.
 gérer les systèmes, bases de données et réseaux informatiques.
 Concevoir et mettre en œuvre les dossiers, procédures et modes opératoires
d’exploitation des applications.
Il a sous sa responsabilité les structures suivantes :

 Le département Exploitation Informatique (EXI).
 Le département Exploitation des Réseaux d’accès Radio et Transport
(ERT).
 Le département Exploitation Des Services (EDS).
 Le département Exploitation du Cœur de Réseau et des Plateformes de
Service (ECP).
Le département ERT
Les principales attributions de ce département sont les suivantes :
 Assurer le bon fonctionnement des services réseaux et SI (Systémes

d’Information).
 Traiter les signalisations et incidents réseau.
 Assurer l’efficacité du trafic, la disponibilité des services, réseaux et SI.
 Superviser et exploiter les réseaux, plateformes et les équipements.
Le département ERT est composé de plusieurs services parmi lesquels nous retrouvons :
 SRI (Supervision Réseaux IP & ADSL).

 SQT (Support et Qualité Technique Réseau Transport).
 SRT (Supervision Réseaux Transmission).
 SRR (Supervision Réseaux Radio).
 SQR (Support et Qualité Technique Réseau Radio).
 Ingénieurs Support IP.
 Ingénieurs Support Transmission.
 Ingénieurs Support Radio.
Notre stage s’est effectué au service SQT. Le schéma suivant nous montre l’organigramme
du pôle d’exploitation DRSI/DEX.

i
s
A
i
r
a
t
é
u
c
n
D
p
m
e
é
a
t
D
p
m
e
n
E
r
l
x
i
o
ti
a
'
i
o
R
s
é
c
d
E
n
l
p
x
t
ti
n
a
t e
t
n
l
ô
P
x
u
a
e
s
é
r
u
e
n
o
d
t
x
e
a
m
r
o
f
n
R
S
i
v
u
s
é
d
t
I
ti x
a
c
s
e
u
q
S
&
F
P
e
E
tX
D
C
E
/
P
X
s
D
n
a
r
T
S
D
T
R
X
E
/
I
-
Figure 3:Organigramme du pôle d’exploitation DRSI/DEX

Les enjeux et les acteurs de la supervision
Nous allons présenter dans ce chapitre la notion de supervision de réseau. En quoi cela
consiste il exactement et concrètement ? Nous tenterons de répondre à cette question en
présentant les deux grands axes de la supervision et leurs objectifs respectifs.
1. La problématique des réseaux privés d’entreprise
La notion de supervision s’applique essentiellement dans un contexte de réseau privé. L’idée

maîtresse de la supervision est de contrôler la bonne santé du réseau et des services
informatiques afin de mesurer la Qualité de Service (QoS). Cette notion de QoS n’est pas
récente, mais elle est devenue le point d’intérêt central des stratégies de développement
d’entreprise. La situation économique actuelle peu favorable exige des entreprises qu’elles
contrôlent leurs dépenses. La tendance n’est pas à l’investissement dans de nouvelles
technologies, mais à l’optimisation et au rendement de l’existant à moindre coût. De plus,
l’évolution des méthodes de travail au sein même de l’entreprise veut qu’une part de plus en
plus importante de l’activité de celle-ci sollicite les outils informatiques. Dans le cas des
sociétés de services en informatique, c’est toute l’activité des ingénieurs et dirigeants qui
repose intégralement sur la bonne disponibilité des services informatiques et réseaux. C’est
dans cette volonté de contrôle que s’intègre la supervision de réseaux.
L’enjeu pour ces entreprises est donc primordial, puisque leurs chiffres dépendent directement
des outils informatiques tels que le mail, le partage de fichier, l’intranet… Les utilisateurs
doivent pouvoir accéder à ces services à tout instant. Malheureusement, un simple incident
survenu sur une ligne ou un équipement peut rompre toute la chaîne. L’objectif des
administrateurs d’un système d’information est donc de pouvoir connaître en permanence
l’état du réseau, et d’être averti en temps réel des différents incidents pour réduire au
maximum le délai d’intervention et de coupure du service.
La haute hiérarchie des entreprises est elle aussi concernée par les outils de supervisions. Un
responsable de service informatique doit pouvoir informer sa Direction de la QoS de son
système informatique en s’appuyant sur des chiffres concrets. Par exemple il doit pouvoir
affirmer que le service de messagerie a été l’année précédente à 2 % inaccessible, 13%
perturbé…
2. Les différents aspects de la supervision réseaux
Un utilisateur qui accède à service informatique, comme par exemple une simple consultation
d’une page web de l’intranet, met en œuvre de nombreux mécanismes et doit réunir toutes les
bonnes conditions. Tout d’abord les lignes de communications ne doivent pas être engorgées.
Les éléments actifs établissant le chemin ainsi que la machine fournissant le service doivent
être opérationnels et le service concerné doit être disponible. Le schéma ci-dessous retrace les
différents points clés, garants de l’accessibilité d’un service.

Figure 4:Accès à un service distant
Nous voyons donc se distinguer deux axes majeurs de la supervision de réseau au sens général
:
 L’analyse de flux
 la supervision des équipements et des services.
Notre étude porte en première partie sur la supervision des équipements et des services en
utilisant le logiciel nagios. En deuxième partie on va étudier l’analyse des flux en utilisant le
logiciel cacti.
a. L’analyse de flux
L’analyse de flux consiste à connaître l’activité en temps réel sur les liaisons réseaux. Les
buts sont à la fois d’identifier les liaisons saturées et d’identifier l’origine de cette sur
utilisation des ressources. De plus, au travers de statistiques, les dirigeants peuvent décider de
l’augmentation des débits des liaisons qui sont saturées.
Tout cela joue un rôle déterminant dans la stratégie de développement de l’entreprise.
De nombreux outils permettent de faire cela. Ils utilisent tous le même principe de sondes qui
« sniffent » le trafic sur une liaison précise.
Ces informations sont ensuite analysées selon les besoins des administrateurs. En général les
informations recherchées sont des classements par nombre de paquets transmis par utilisateurs
ou par application, par protocoles…
Ceci permet d’identifier les causes principales de la saturation constatée.
Nous pouvons citer par exemple les logiciels rrdtool ou Ntop qui sniffent au niveau des
interfaces de machines ou routeurs, fastnet (payant) qui nécessite la mise en place d’une
sonde, ou encore cacti qui donne les statistiques à temps réels sur les équipements à l’aide de
graphes.
b. La supervision SNMP : l’état des équipements
Comme nous allons le voir dans la suite, SNMP est le protocole de référence en matière de
supervision. Il permet à un serveur central de communiquer avec tous les équipements et

serveurs pour connaître l’état de très nombreux paramètres tels que la température dans le
châssis de la machine, l’état des interfaces, des ports, le taux d’utilisation CPU…
Ce protocole permet également au serveur central (appelé station d’administration SNMP), de
récupérer toutes les alertes SNMP (les traps) émises par les éléments actifs ou serveurs
supervisés. Une interface permet généralement d’administrer l’ensemble des machines et de
visualiser leurs états en temps réel.
c. La supervision applicative : l’état des services
La supervision applicative, longtemps ignorée, et aujourd’hui au cœur des préoccupations

d’entreprises. Le principe de cette supervision est différent de celui vu avec SNMP. La
supervision applicative consiste à surveiller en testant régulièrement les services qui tournent
sur les machines serveurs des réseaux. La nouveauté est de se placer du point de vue de
l’utilisateur final du service. En effet, même si tous les liens réseau sont en bon état de
fonctionnement, le programme responsable d’un service peut en revanche être interrompu ou
perturbé. SNMP ne permet pas de savoir par exemple, si le FTP est ouvert, si le serveur web
renvoie bien la page… C’est ce que propose de faire les outils de supervision applicative. La
station d’administration va régulièrement tester et mesurer la qualité des services en les
sollicitant comme le ferait un utilisateur. Nous pouvons connaître ainsi le temps que met le
serveur web à nous retourner la page, savoir si le serveur DNS traite bien les requêtes qui lui
parviennent, le temps de réponse aux pings des différents routeurs…
Là encore une interface permet d’administrer le tout, de visualiser l’état des services ou
encore de remonter des alertes aux administrateurs…
I. Choix du nagios et de cacti

1. Les offres éditeurs
Les gros éditeurs logiciels ont rapidement compris que la supervision était une ressource clé
pour les entreprises qui, de plus en plus, utilisent leur système d'information et ont donc
besoin d'une disponibilité toujours plus grande de leur infrastructure informatique.
Par conséquent, la supervision est un domaine dans lequel les sociétés n'hésitent pas à investir
depuis quelques années. Ayant rapidement compris cela, les gros éditeurs logiciels sont donc
très vite entrés dans la course aux logiciels de supervision.
Aujourd'hui, la majorité des gros éditeurs logiciels propose des outils complets de
supervision. On retrouve, parmi les plus connus :
 HP : la gamme Openview (NNM, OVO, ...)
 BMC : Patrol
 IBM : Tivoli
 Computer Associates : Unicenter TNG
 BigBrother
Ces outils, véritables frameworks de la supervision, possèdent tous leur avantage face à la
concurrence. Cependant, tous ont également le même défaut : le prix !
En effet, il faut savoir que, pour une entreprise de taille moyenne, il lui faudra compter
plusieurs millions pour superviser son système.

2. Les offres du monde libre
Depuis une dizaine d'années déjà, plusieurs projets de supervision ont vu le jour au sein de la
communauté du logiciel libre. Il suffit pour cela d'aller faire un petit tour sur sourceforge pour
se rendre compte de la multitude de projets émergeants autour de la supervision système et
Réseau. On notera ainsi, parmi les plus populaires : Zabbix, Cacti et Nagios qui feront
l'objet de notre étude.
 Cacti
C’est un outil de création de graphiques reposant sur une interface web basée sur PHP et
MySQL et qui utilise le moteur RRDTool pour collecter les statistiques.
La force de Cacti provient du fait qu'il peut être aisément installé et utilisé. Il est possible de
partager ses modèles (Template) avec d'autres utilisateurs et ainsi de vous faire gagner du
temps.
 Nagios
Nagios (anciennement appelé Netsaint) est une application permettant la surveillance système
et réseau. Elle surveille les hôtes et services spécifiés, alertant lorsque les systèmes ont des
dysfonctionnements et quand ils repassent en fonctionnement normal. C'est un logiciel libre
sous licence GPL.

PARTIE 1
L’OUTIL DE SUPERVISION DES

EQUIPEMENTS ET DES SERVICES :
NAGIOS

CHAPITRE 2
Architecture et principe de fonctionnement de nagios
I. Historique et fonctionnement du protocole SNMP
1. Historique et présentation
Créé en 1988 par l’IETF (Internet Engineering Task Force), SNMP (Simple Network
Management Protocol) était à l'origine destiné à l'administration distante des ponts et des
routeurs. Aujourd’hui, SNMP est utilisé pour l'administration d'un large éventail de matériel
informatique. C'est un protocole réseau qui permet comme son nom l'indique, de gérer les
équipements réseaux ainsi que les machines informatiques. Ce protocole est donc utilisé par
les administrateurs réseaux pour détecter à distance les problèmes qui surviennent sur leur
réseau. Le protocole SNMP définit des échanges entre un client et un serveur afin de :
 Connaître l’état d’un appareil.
 Gérer les évènements exceptionnels
 Mesurer le trafic et les erreurs à distance.
 Configurer les appareils à distance
Il est l’un des protocoles (simples) de gestion de réseaux les plus utilisés, devenu de fait un
standard quasi incontournable dans le domaine. Il s’appuie sur le protocole TCP/IP ce qui
peut expliquer le fait qu’il se soit propagé si rapidement.
Il existe trois versions de SNMP : SNMPv1, SNMPv2 et SNMPv3 et plusieurs standards qui
définissent ce protocole : la RFC 1155SMI (Structure of Management Information), RFC
1156MIB (Management Information Base), RFC 1157SNMP Protocol, etc.
2. Principe de fonctionnement du SNMP
Plus qu’un simple protocole de liaison, la mise en place d’une structure utilisant SNMP fait
intervenir plusieurs concepts:
 La station d’administration
C’est la machine qui centralise toutes les données, c’est le cœur du système. C’est notamment
cette station qui va dialoguer avec les différents matériels à administrer.
 Les agents SNMP
Ce sont des démons installés sur tous les éléments du réseau à superviser (machines serveurs
ou éléments actifs). Ils envoient les traps SNMP et répondent aux requêtes de la station
d’administration.
Comme on le constate le protocole est simple. Cependant, étant un protocole Internet, il doit
être utilisable sur des plates formes hétérogènes (matériel et système d’exploitation !). Il a
donc fallu lui associer des standards pour la gestion, le stockage des informations transportées

et utilisées par le protocole. Un élément indissociable de SNMP est donc la MIB pour
Management Information Base, une base d’informations de gestion.
 Les MIBs (Management Information Base)

Ce sont des sortes de bases de données avec une topologie en arbre qui décrivent et
sauvegardent des variables SNMP. Elles sont présentes sur toutes les machines, y compris la
station d’administration. SNMP doit permettre de retrouver les informations et d’agir sur les
paramètres des équipements de façon indépendante du matériel et du logiciel. C’est à l’agent
lui-même de traduire les informations entre SNMP et la plate forme de supervision.
 Les variables SNMP
Ce sont les feuilles de la MIB. Ces variables sont identifiées numériquement ou
nominalement par des OID (Object Identifier).
Comme nous le disions plus haut, le protocole est utilisé pour connaître à un instant donné
l’état d’un matériel. Ainsi ce sont ces variables qui nous permettront de connaître par exemple
le nombre de paquets entrants et sortants sur une interface donnée ou encore la température
CPU d’un serveur....
SNMP est un protocole de type client serveur, donc basé sur l'utilisation de démons (les
agents SNMP).Le principe est très simple sur chacune des machines, on installe un petit
programme : l’agent SNMP.
Cet agent enregistre en permanence des informations relatives à la machine et les stocke dans
une base de données. Ainsi, de son ordinateur, l’administrateur peut interroger chacune de ses
machines et obtenir les informations qu’il souhaite.
C'est un protocole de la couche application (niveau 7 du modèle OSI) qui se base sur UDP
pour l'acheminement des informations entre les différents agents (les agents écoutent les
requêtes sur les ports UDP 161 et les alarmes sur le port 162).
Chaque agent situé sur un nœud du réseau qui est dit administrable (MN : Managed Node)
renseigne périodiquement les variables de MIB (délai paramétrable dans le fichier de
configuration par défaut fixé à 30 secondes avec l’agent de netsnmp2). Ces nœuds peuvent
être soit des hôtes (stations de travail ou serveurs), soit des éléments d’interconnexion
(Switch, hubs, routeurs).
Lorsqu’un évènement inattendu se produit sur un des périphériques gérés, par exemple un
échec de transmission ou une modification d’état, le périphérique envoie un « trap » SNMP au
NMS (Network Management System). Ce trap contient une indication de l’évènement ayant
provoqué la génération du message. Le gestionnaire SNMP doit alors prendre des mesures qui
s’imposent. Il peut se contenter d’enregistrer le message dans un fichier de suivi, ou prendre
des mesures plus immédiates, par exemple demander des informations complémentaires au
périphérique lui ayant envoyé le message.
Ces informations supplémentaires sont obtenues grâce à des requêtes de lecture des variables
MIB. Si le NMS est programmé pour le contrôle du périphérique, il peut lui demander de
modifier la valeur de ses variables MIB.
L'accès aux variables d'un matériel réseau se fait grâce à un mot de passe particulier que l'on
appelle la communauté.
 Les communautés
La chaine de caractères communauté de SNMP authentifie l’accès aux objets et aux fonctions
de la MIB. Pour que le NMS puisse accéder à un équipement, il faut que la chaîne de
caractères définie sur la MIB ait au moins un des attributs suivants :

 READ Only (RO) : donne à toutes les stations de management autorisées, le droit de
lire le contenu de la MIB excepté la chaîne de caractères « community ». Il ne donne
pas le droit d’écriture pour autant.
 READ-Write (RW) : donne à toutes les stations de management autorisées le droit de
lire et d’écrire sur tous les éléments de la MIB mais n’autorise pas l’accès à la chaîne
de caractères.
 Read-Write-All : donne le droit de lecture et d’écriture à toutes les stations de travail
sur tous les éléments de la MIB y compris les chaînes de caractères.
D’une manière générale nous distinguons deux modes de fonctionnement complémentaires
mais aux principes bien distincts :
 Le mode « poll SNMP » : La station d’administration demande à un agent SNMP de
lui retourner la valeur de telle ou telle variable. Cela se passe donc en deux étapes, la
requête du serveur pour interroger le client, et la réponse du client. Le serveur (ou
station d’administration SNMP) peut ainsi connaître à des intervalles réguliers les
informations qu’il souhaite.
 Le mode « Trap SNMP » : un trap SNMP est un message informatif qui est envoyé
par l’agent SNMP en cas d’incident à destination du serveur qui est toujours en écoute
de ces messages.
3. Nagios et SNMP
Le logiciel de supervision Nagios ne dispose pas nativement d’une supervision avancée
d’équipements par SNMP. Comme nous l’avons expliqué dans les rubriques ci-dessus, SNMP
peut être un outil intégré à Nagios. Cependant des plugins spécifiques NRPE, NSCA fourni
par Nagios permettent de ne pas utiliser SNMP. Néanmoins, l’utilisation de ces plugins
impose l’installation d’un agent spécifique (les agents SNMP étant par défaut sur tous les
commutateurs) sur chaque machine supervisée ! Des plugins utilisant SNMP sont également
fournis dans l’installation par défaut de Nagios. Nous pouvons citer check_snmp ou
check_ifoperstatus par exemple. Le second va nous permettre par exemple de remonter
l’état, le statut (up ou down) d’un port précis d’un commutateur donné.
Nagios n'est pas un gestionnaire SNMP, cependant, on peut utiliser ce protocole, soit via le
plugin "check_snmp" qui utilise la commande snmpget soit via un script Perl, pour contrôler
certains services ainsi que gérer des remontées d'alertes (traps snmp).
Le principe de fonctionnement se déroule de la manière suivante :

Un hôte sur le réseau (ou plutôt une application de cet hôte) envoie une interruption SNMP au
serveur qui héberge Nagios. Celui-ci la reçoit via le service snmptrapd (qui est en écoute sur
le port UDP 162). Snmptrapd la passe ensuite à SNMPTT, dont le rôle est de rendre
intelligible l'interruption. Pour cela, il se base sur la MIB de l'application émettrice, qui sera
bien sûr récupérée et transformée au préalable pour en nourrir SNMPTT.
SNMPTT envoie enfin l'interruption interprétée à Nagios, via le fichier de commandes
externes de celui-ci. Il utilise pour cela la commande Nagios submit_check_result.
4. Sécurité du protocole SNMP
La sécurité de ce protocole se ressent essentiellement au niveau de la version 3 : SNMPv3.

Cette nouvelle version du protocole SNMP vise essentiellement à inclure la sécurité des
transactions. La sécurité comprend l'identification des parties qui communiquent et

l'assurance que la conversation soit privée, même si elle passe par un réseau public.
Ci-dessous, une description de l’architecture de SNMPv3 :
Figure 5: Entité SNMPV3 : Machine SNMP + Applications
Cette sécurité est basée sur 2 concepts :
 USM (User-based Security Model)
 VACM (View- based Access Contol Model)
 User Security Module(USM)
Trois mécanismes sont utilisés. Chacun de ces mécanismes a pour but d'empêcher un type
d'attaque.
 L'authentification : Empêche quelqu'un de changer le paquet SNMPv3 en cours de

route et de valider le mot de passe de la personne qui transmet la requête.
 Le cryptage : Empêche quiconque de lire les informations de gestions contenues dans

un paquet SNMPv3.

 L'estampillage du temps : Empêche la réutilisation d'un paquet SNMPv3 valide a déjà
transmis par quelqu'un.
a. L’authentification
L'authentification a pour rôle d'assurer que le paquet reste inchangé pendant la transmission,
et que le mot de passe est valide pour l'usager qui fait la requête. Pour construire ce
mécanisme, on doit avoir connaissance des fonctions de hachage à une seule direction. Des
exemples de ces fonctions sont : MD5 et SHA-1. Ces fonctions prennent en entrée une chaîne
de caractères de longueur indéfinie, et génèrent en sortie une chaîne d'octets de longueur finie
(16 octets pour MD5, 20 octets pour SHA-1).Pour authentifier l'information qui va être
transmise, on doit aussi avoir un mot de passe qui est « partagé ». Le mot de passe ne doit
donc être connu que par les deux entités qui s'envoient les messages, et préférablement par
personne d'autre.
Les étapes d'authentification sont les suivantes :
 Le transmetteur groupe des informations à transmettre avec le mot de passe.
 On passe ensuite ce groupe dans la fonction de hachage à une direction.
 Les données et le code de hachage sont ensuite transmis sur le réseau.
 Le receveur prend le bloc des données, et y ajoute le mot de passe.
 On passe ce groupe dans la fonction de hachage à une direction.
 Si le code de hachage est identique à celui transmis, le transmetteur est authentifié.
Avec cette technique, le mot de passe est validé sans qu'il ait été transmis sur le réseau.
Quelqu'un qui saisit les paquets SNMPv3 passants sur le réseau ne peut pas facilement trouver
le mot de passe.
Pour ce qui est de SNMPv3, l'authentification se fait à l'aide de HMAC-MD5-96 ou de

HMAC-SHA- 96, qui est un peu plus compliqué que ce qui a été décrit ici. Le résultat de la
fonction de hachage est placé dans le bloc paramètres de sécurité du paquet SNMPv3.
L'authentification se fait sur tout le paquet.
L'étape d'authentification ne vise pas à cacher l'existence du paquet ou à le crypter. Si l'on

utilise uniquement l'authentification, les personnes qui saisissent les paquets passants sur le
réseau peuvent encore en voir le contenu. Toutefois, elles ne peuvent pas changer le contenu
sans connaître le mot de passe.
b. Le cryptage
Le cryptage a pour but d'empêcher que quelqu'un n'obtienne les informations de gestion en
écoutant sur le réseau les requêtes et les réponses de quelqu'un d'autre.

Avec SNMPv3, le cryptage de base se fait sur un mot de passe « partagé » entre le manager et
l'agent. Ce mot de passe ne doit être connu par personne d'autre. Pour des raisons de sécurité,
SNMPv3 utilise deux mots de passe : un pour l'authentification et un pour le cryptage. Ceci
permet au système d'authentification et au système de cryptage d'être indépendants. Un de ces
systèmes ne peut pas compromettre l'autre. SNMPv3 se base sur DES (Data Encryption
Standard) pour effectuer le cryptage. On utilise une clé de 64 bits (8 des 64 bits sont des
parités, la clé réelle est donc longue de 56 bits) et DES encrypte 64 bits à la fois.
Comme les informations que l'on doit encrypter sont plus longues que 8 octets, on utilise du
chaînage de blocs DES de 64 bits. Une combinaison du mot de passe, d'une chaîne aléatoire et
d'autres informations forme le « Vecteur d'initialisation ». Chacun des blocs de 64 bits est
passé par DES et est chaîné avec le bloc précédent avec un XOR. Le premier bloc est chaîné
par un XOR au vecteur d'initialisation. Le vecteur d'initialisation est transmis avec chaque
paquet dans les « Paramètres de sécurité », un champ qui fait partie du paquet SNMPv3.
Contrairement à l'authentification qui est appliquée à tout le paquet, le cryptage est seulement
appliquée sur le PDU. La RFC 3826 "The Advanced Encryption Standard (AES) Cipher
Algorithm in the SNMP User-based Security Model" relate l'intégration d'AES dans SNMP.
Celui renforce le chiffrement en remplacement du DES. Cependant, pour le moment, cette
RFC est en cours de validation et donc pas encore officialisée.
c. L’estampillage de temps
Si une requête est transmise, les mécanismes d'authentification et de cryptage n'empêchent

pas quelqu'un de saisir un paquet SNMPv3 valide du réseau et de tenter de le réutiliser plus
tard, sans modification.
Par exemple, si l'administrateur effectue l'opération de remise à jours d'un équipement,

quelqu'un peut saisir ce paquet et tenter de le retransmettre à l'équipement à chaque fois que
cette personne désire faire une mise à jour illicite de l'équipement. Même si la personne n'a
pas l'autorisation nécessaire, elle envoie un paquet, authentifié et encrypté correctement pour
l'administration de l'équipement.
On appelle ce type d'attaques le « Replay Attack ». Pour éviter ceci, le temps est estampillé
sur chaque paquet. Quand on reçoit un paquet SNMPv3, on compare le temps actuel avec le
temps dans le paquet. Si la différence est plus que supérieur à 150 secondes, le paquet est
ignoré.
SNMPv3 n'utilise pas l'heure normale. On utilise plutôt une horloge différente dans chaque
agent. Ceux-ci gardent en mémoire le nombre de secondes écoulées depuis que l'agent a été
mis en circuit. Ils gardent également un compteur pour connaître le nombre de fois où
l'équipement a été mis en fonctionnement. On appelle ces compteurs BOOTS (Nombre de fois
ou l'équipement a été allumé) et TIME (Nombre de secondes depuis la dernière fois que
l'équipement a été mis en fonctionnement).
La combinaison du BOOTS et du TIME donne une valeur qui augmente toujours, et qui peut
être utilisée pour l'estampillage. Comme chaque agent a sa propre valeur du BOOTS/TIME, la
plate-forme de gestion doit garder une horloge qui doit être synchronisée pour chaque agent
qu'elle contacte. Au moment du contact initial, la plateforme obtient la valeur du
BOOTS/TIME de l'agent et synchronise une horloge distincte.

II. Présentation et principe de fonctionnement de nagios
1. Historique
Nagios est un outil de Supervision Libre. Il est disponible sous Licence GNU GPL
version2 .Développé sous le nom de NetSaint en 1999 par Ethan Galstad, le projet est ensuite
renommé en Nagios ("Nagios Ain't Gonna Insist On Sainthood") pour des raisons de droits de
marques en 2001.
En effet, une société avait déjà déposé ce nom et Ethan a préféré modifier le nom de son
projet plutôt que de consommer du temps et de l‘argent.
Les principaux développeurs sont Ethan Galstad pour le cœur de Nagios, Karl DeBisschop,
Subhendu Ghosh, Ton Voon et Stanley Hopcroft ont réalisé les principaux plugins de Nagios.
Cependant, de nombreuses personnes ont participé au projet et continuent de le faire.
Notamment sur la partie plugins, de nombreux développeurs mettent à disposition de la
communauté leurs propres plugins. La partie "Liens" (en cours de construction pour le
moment) indique une série de sites web mettant à disposition des plugins.
2008
2. Les fonctionnalités
En réalité Nagios peut superviser de nombreux éléments. Il est simple de l'étendre car il est
conçu dans cette optique. Il permet de superviser plusieurs équipements compatible avec le
protocole SNMP comme :
 les Windows NT/2000/2003/XP
 tous les Linux (Debian, Ubuntu, Redhat...)
 les AS400
 Serveurs
 les Switchs
 les routeurs
 les firewalls
 les robots de sauvegarde,
.
Nagios supervise à la fois le hardware que le software. Au niveau du hardware, il suffit
d'installer l'agent SNMP spécifique au constructeur du serveur (Dell, Compaq, IBM, ...). Au
niveau hardware sont généralement disponibles les éléments suivants:
o état de chacun des CPU
o état des barrettes de RAM
o état de chacun des disques physiques
o état de la carte RAID
o état des ventilateurs et des alimentations (branché/débranché, fonctionnement
correct/incorrect)
o température des équipements
Au niveau software, il existe de nombreux plugins permettant de superviser:
o le taux d'occupation du CPU, de la RAM, du SWAP, des filesystems (partitions)
o le nombre de processus
o la présence de point de montage NFS ou de partage
o l'ouverture d'un port TCP
o la réponse à une requête particulière (SQL, HTTP, POP, IMAP, ...)

3. L’architecture de Nagios
L'architecture de base de Nagios est simple:
2008
 un ordonnanceur: Nagios est d'abord un moteur gérant l'ordonnancement des
vérifications, ainsi que les actions à prendre sur incidents (alertes, escalades, prise
d'action corrective).
 une IHM: la partie graphique visible à travers un simple serveur web, tel Apache est
basée (pour les versions jusqu'à la 2.0) sur des CGI.
 des sondes: les sondes de Nagios (les greffons ou plugins) sont de petits scripts ou
programmes qui sont la base des vérifications.
2008
Figure 6: Architecture de Nagios
4. Principe de fonctionnement de Nagios
a. Un fonctionnement par plugin
Nagios n'est donc qu'un moteur d'ordonnancement de vérifications diverses et variées. Enfin,
un peu plus, mais nous n'allons utiliser que cette vision pour l'instant.
Ces vérifications sont assurées par des greffons (plugins en anglais), dont le développement
est séparé du moteur principal (pour les greffons de base).
Le terme plugin désigne une extension prévue des fonctionnalités, en comparaison des ajouts
non prévus initialement apportés à l'aide de patches.
La relation entre le moteur et les greffons est assurée d'une part dans la configuration de
Nagios pour que Nagios sache quelles vérifications lancer sur ou à destination de quelles
machines ou services, d'autre part par le code retour ainsi que la sortie standard d'un greffon.
En effet, un greffon n'est qu'un script, un programme qui sache fournir un code retour (0: tout
va bien, 1: avertissement, 2: alerte), et éventuellement un petit message décrivant le
déroulement de l'exécution (aide au diagnostic en cas de problème).
Les codes retours sont aussi nommés: 0: OK, 1: WARNING, 2: CRITICAL et 3:
UNKNOWN. Ce sont donc ces états qui seront ensuite remontés au moteur qui prendra les
décisions et lancera les actions programmées. Ces greffons fonctionnent soit en local sur la
machine supervisée (par exemple les vérifications sur les disques), soit effectuent des tests à

distances tels que les tests sur des protocoles réseaux tels SMTP ou exécution à distance via
SSH ou autre.
2008
Ces plugins se trouvent dans le répertoire /usr/local/nagios/libexec/
 Un exemple de plugin
L'écriture d'un greffon ou plugin doit respecter deux règles: légèreté et simplicité. En effet, ce
greffon doit passer inaperçu dans son exécution, au sens où il ne doit pas se faire sentir sur la
charge globale de la machine, et doit rester simple dans l'esprit d'un greffon Nagios. À ce titre,
il doit accomplir une tâche et une seule, mais le faire bien. Le choix du langage est libre : Perl,
C, bash,…etc.
Dans l’exemple suivant nous allons créer un script permettant de détecter le système
d’exploitation de la machine testée en utilisant le protocole SNMP.
nmap -O $1>/usr/local/nagios/libexec/tmp
OS=`cat /usr/local/nagios/libexec/tmp|grep "linux"|wc -l`
if test "$OS" -ge 1; then
$ECHO "OS=LINUX\n"
exitstatus=$STATE_OK
2else
OS=`cat /usr/local/nagios/libexec/tmp|grep "Windows"|wc -l`
if test "$OS" -ge 1; then
$ECHO "OS=WINDOWS\n"
else
$ECHO "OS INCONNU\n"
fi
fi
rm /usr/local/nagios/libexec/tmp
define command {
command_name snmp_OS
command_line $USER1$/check_snmp -H $HOSTADDRESS$ -o
system.sysDescr.0 -l OS
}
define service {
host_name mon_pc_serveur
service_description OS_par_SNMP
check_command snmp_OS
use generic-service
}
b. Les modes de fonctionnement complémentaires
Nous pouvons distinguer deux modes de fonctionnement complémentaires de Nagios : le

mode actif, ou de polling et le mode passif ou de traps.

 En mode polling, Nagios exécute un plugin pour réaliser un test à des intervalles de
temps réguliers. Il analyse ensuite la réponse et adopte un comportement en fonction
de celle-ci. Ce mode de fonctionnement entraîne une génération du trafic sur le réseau.
 En mode passif, Nagios reste à l’écoute de tout ce qu’on peut lui dire. Pour
communiquer avec lui, il suffit d’installer le programme client send_nsca sur les
serveurs à superviser et de faire tourner le démon nsca sur le serveur Nagios.
Dans notre configuration, c’est le démon snmptrapd de Net-SNMP qui utilise ce programme
client via le script ‘traitement-trap’.
Quelque soit le mode de fonctionnement, Nagios remonte des alertes aux administrateurs
définis dans ses fichiers de configuration, que soit par mail, sms, pagger… Nagios met aussi
en permanence à jour sont interface web qui reflète donc en temps réel l’état du réseau et des
services.
Figure 7 : Mode de fonctionnement de Nagios avec SNMP
c. Les états de nagios
La situation d’un service ou d’un hôte est définie par :

 son status (OK, WARNING, UP, DOWN,…etc.)
 son état : « SOFT » ou « HARD »
La notion d’état est indispensable à la logique de supervision de Nagios,

Il permet de :
 déterminer quand les notifications sont émises.
 déclencher l’exécution des gestionnaires d’événements.
 éviter les fausses alertes.
 l’état « SOFT »
L’état SOFT correspond à une vérification :
 qui retourne un résultat différent de « OK »,
 mais n’a pas atteint le nombre maximum d’essais spécifié par max_check_attempts.


Nagios n’envoie pas de notifications car le problème n’est pas encore avéré sérieux.
La valeur de la macro $STATETYPE$ utilisée par le gestionnaire d’événements est
positionnée à «SOFT ». Le gestionnaire d’événements est appelé.
 l’état « HARD »
L’état HARD d’un service correspond à une vérification :
 Qui retourne toujours un résultat différent de « OK », alors que le service a été testé le
nombre maximum de fois spécifiées par max_check_attempts dans la définition de
l’hôte.
 qui retourne un résultat différent de « OK » tandis que l’hôte associé est « DOWN »
ou « UNREACHABLE ».
Les changements d’états interviennent lors du :

o passage d’un état « OK » stable à un état HARD différent de « OK ».
o passage d’un état HARD différent de « OK » à un état « OK » stable.
o changement de niveau d’un état HARD différent de « OK ». ex : « WARNING » vers
« UNKNOWN ».
Lors d’un passage à l’état HARD, Nagios :
 logue le service ou l’hôte qui pose problème.
 positionne la valeur de la macro $STATETYPE$ à « HARD » et appelle le
gestionnaire d’événements.
 envoie les notifications d’alerte aux contacts identifiés.
2008
Lors d’un retour depuis l’état HARD, Nagios :
 logue le retour à l’état normal du service ou de l’hôte.
 appelle le gestionnaire d’événements.
 informe les contacts que la situation est de nouveau normale.
.
5. Les notifications/envois d'alertes de nagios
Nagios dispose de plusieurs moyens pour déclarer un problème :
 Le premier est l'interface web : elle est consultable avec un simple navigateur web,
sans fonctions avancées et contraignantes (pas de plugin JavaScript, applet Java,
Flash, ... nécessaires). Cette interface web est orientée technique : les techniciens
l'apprécient beaucoup car elle est claire, efficace et fonctionnelle. Les décideurs ne la
trouvent pas très agréable au niveau visuel. Cependant, il n'est pas possible de rester
constamment devant une interface web sauf si l'on dispose d'une équipe dédiée à cela
(souvent appelée pupitre, service desk ou plus rarement exploitation). Il existe
d'autres moyens d'avertir les administrateurs.
 Il ya aussi l’alerte sonore qui permet de déclencher l’alarme dès qu’il ya

disfonctionnement sur un équipement. Cependant, elle est moins utilisée car elle peut
déranger et n’est donc pas fiable dans une entreprise.

 Le second moyen le plus courant est le mail. Dès qu'un problème survient, un mail
peut être envoyé à une équipe d'administration. Toutes les informations nécessaires
sont disponibles dans le mail. Enfin, que se passe-t-il si le serveur de mails ne
fonctionne plus et qu'il n'est pas possible de mettre une équipe devant l'interface web
constamment?
200 8
Figure 8 : Notifications de Nagios

Implémentation de Nagios
I. Installation
1. Pré-requis
La mise en place de Nagios requiert une plateforme UNIX. Nous avons choisi Debian qui est
plus apte pour une administration avancée. Nagios a, en plus des plugins, besoin de satisfaire
un certain nombre de dépendances. Les pré-requis à l'installation sont les suivants :
• Un serveur web (ex: Apache) fonctionnel
• Une base de données.
• Les librairies graphiques suivantes : libgd 1.6.3 ou plus, Libjpeg, libpng
• les compilateurs tels que gcc, g++.
• Disposer des droits d'administration sur la machine;
• Disposer d'une connexion à Internet configurée et activée ;
• Avoir activé l'accès au dépôt «APT Universel » ;
2. Installation de nagios
En ligne de commande, il faudra tout d’abord :
 Passer en root
$ su root

 Installer les compilateurs :
#apt- get install make gcc g++
 Ajouter l'utilisateur nagios
adduser nagios
 Identifier l'utilisateur Apache
grep "^User" /etc/apache2/apache2.conf
 Ajouter l'utilisateur "nagios" dans Apache
usermod -G nagios nagios
usermod -G www-data,nagios www-data
 Créer le répertoire d'installation
mkdir /usr/local/nagios
 Changer le propriétaire du répertoire d'installation par l'utilisateur nagios
chown -R nagios: nagios /usr/local/nagios
 Installer les libraires indispensables
apt-get install libjpeg62-dev libgd-tools
 Installer GD-utils
tar -zxvf gd-2.0.33.tar.tar
cd gd-2.0.33
. /configure
make && make install
 Installation de nagios
Dans notre étude, nous allons installer le package nagios 2.9 qui est une version très stable.
Nous allons tout d’abord désarchiver le package téléchargé ensuite passer à la compilation
puis à l’installation.
cd /tmp
tar -zxvf nagios-2.10.tar.gz
cd nagios-2.10/
Les fichiers de Nagios seront placés, par défaut dans des répertoires qu’il faudra ensuite
chercher dans le système de fichiers. Pour faciliter l’accès tout en respectant ce système de

fichiers, lançons un script de configuration qui nous permettra de déterminer certaines
caractéristiques de Nagios.
. /configure --prefix=/usr/local/nagios --with-
cgiurl=/nagios/cgi-bin --with-htmurl=/nagios/ --with-nagios-
user=nagios --with-nagios-group=nagios --with-command-
group=nagios
make all
make install
 Installation du service (démon)
make install-init
 Installation des scripts et des droits pour l'exécution de commandes externes
make install-commandmode
 Installation des fichiers de configuration (fichiers par défaut)
make install-config
Aller dans le répertoire Nagios
cd /usr/local/nagios
 Création des fichiers de config principaux, il faut éviter de laisser les

fichiers de configuration avec l’extension sample
cd /usr/local/nagios/etc
mv cgi.cfg-sample cgi.cfg
mv localhost.cfg-sample localhost.cfg
mv resource.cfg-sample resource.cfg
mv commands.cfg-sample commands.cfg
mv nagios.cfg-sample nagios.cfg
 Automatiser le démarrage du service nagios
update-rc.d nagios defaults

3. Installation des plugins Nagios
Les plugins de Nagios sont les commandes utilisées pour vérifier les services des hôtes
surveillés. Tout d’abord, télécharger nagios-plugins-1.4.10.tar.gz avant de passer à
l’installation.
cp Nagios-plugins.tar.gz /tmp
cd /tmp
tar –xvzf Nagios-plugins.tar.gz
cd Nagios-plugins
. /configure
make
make install
4. Installation du protocole SNMP
L’installation du protocole SNMP, pour qu’il puisse envoyer des traps à nagios, nécessite
certains pré-requis :
 Le paquetage Net-SNMP, qui fournit le service de capture des traps
SNMP "Snmptrapd"
apt-get install net-snmp
 Le paquetage Perl Net-SNMP associé.
apt-get install nmap librrds-perl libgd-gd2-perl libnet-snmp-perl
 Le paquet SNMP
apt-get install snmp snmpd
 L'outil de transformation SNMP trap translator ou SNMPTT, qui rend les traps
lisibles par un humain, et les envoie à Nagios.
apt-get install snmptt
Sur la machine distante, il est important d'avoir activé le service SNMP. Sur la station de
surveillance, seul snmptrapd, qui réceptionne les traps (snmpd gère les requêtes en
provenance d'une machine distante donc inutile sur celle-ci), doit être actifs (si on reçoit des
traps bien sûr !). On peut tester le bon fonctionnement de ces processus en ligne de commande
par un snmpget, un snmpwalk ou un snmptrap .
II. Configuration
1. Configuration d’apache
Il faut modifier le fichier de configuration d’apache en y ajoutant le script qui lui permet de
prendre nagios en compte.

vim /etc/apache2/site-enabled/nagios
Ajouter à la fin du fichier :
Script Alias /nagios/cgi-bin /usr/local/nagios/sbin
<Directory "/usr/local/nagios/sbin">
Options ExecCGI
AllowOverride None
Order allow, deny
Allow from all
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
Require valid-user
</Directory>
Alias /nagios /usr/local/nagios/share
<Directory "/usr/local/nagios/share">
Options None
AllowOverride None
Order allow, deny
Allow from all
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
Require valid-user
</Directory>
 Redémarrage du service apache
/etc/init.d/apache2 restart

 Création du mot de passe pour l'accès au site
htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
 Forcer les CGI à utiliser l'authentification
gedit /usr/local/nagios/etc/cgi.cfg
Vérifier la ligne : use_authentication=1.
Il faut qu'elle soit à 1 et donner les droits d'administration à l'utilisateur nagiosadmin en

déconnectant les lignes souhaitées. Il est possible ici de remplacer les paramètres all par une
adresse IP fixe ou une plage d’adresse IP (exemple : 192. ou 172.24.). Cela permet de limiter
l’accès à Nagios à ces adresses. Il faudra ensuite protéger les répertoires en créant
les fichiers d’authentification:
vim /usr/local/nagios/sbin/.htaccess
vim /usr/local/nagios/share/.htaccess
 Puis insérer dans ces deux fichiers :
AuthName "Accès à nagios" AuthType Basic AuthUserFile
/usr/local/nagios/etc/htpasswd.users requière valid-user
 Et enfin créer le fichier qui recense les mots de passes
htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
New password:
Re-type new password:
Adding password for user nagiosAdmin.
Lancer le service Nagios manuellement
/etc/init.d/nagios start
Notons qu’il est essentiel de vérifier la configuration de nagios après chaque

modification des fichiers de configuration
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
Accéder au site : http://localhost/nagios/

Figure 9: Page d’accueil de Nagios
2. Configuration des fichiers principaux de nagios
La configuration de Nagios demande beaucoup de temps et n'est pas chose aisée. En effet,
l'ensemble de la configuration du logiciel se fait dans des fichiers textes d'extension .cfg.
L'ensemble des fichiers de configuration sont définis selon le format suivant :
define type
attribut1 valeurs
attribut2 valeurs
... valeurs
Ce mécanisme de définition implique qu'aucun espace ne pourra être inséré dans les
paramètres et leurs valeurs. La cohérence des fichiers de configuration peut être testée en
exécutant Nagios avec l'option -v et en lui fournissant le fichier de configuration
principal.
# /etc/init.d/nagios -v [chemin d'accès au fichier nagios.cfg]

Comme nous le savons, Nagios supervise les équipements à travers le réseau. Ils peuvent
être des serveurs, des équipements réseaux, ou tout autre type de machine reliée au réseau.
Ces hosts peuvent être regroupés dans un ou plusieurs groups, permettant ainsi
d'agir sur un ensemble de machines plutôt que sur chacune, une par une. Viennent
ensuite les services. Ils correspondent aux services testés par les plugins. Définis dans un
fichier de configuration, les services font appel aux plugins via des commandes elles-
mêmes définies dans un fichier checkcommands.cfg.
L'ordonnancement de la vérification des services se fait elle selon des périodes de temps
définis par les clauses timeperiod dans le fichier timeperiods.cfg. Le rôle de Nagios est
donc de prévenir lorsqu'un problème survient. Les contacts à prévenir sont définis dans le
fichier contacts.cfg et peuvent eux aussi être groupés dans le fichier contactgroups.cfg.
L'escalade des alertes entre les groupes, en cas de non réponse, peut être définie dans le
fichier escalations.cfg. Il reste alors le fichier misccommands.cfg dans lequel sont
déclarées les commandes non-destinées au lancement de plugin. On y trouvera par exemple
les commandes nécessaires à l'envoi de mail, de SMS, etc. Enfin, d'autres fichiers peuvent
également être utilisés tels que dependencies.cfg pour définir des dépendances entre
services, cgi.cfg pour la configuration des CGI, hostextinfo.cfg pour les infos
supplémentaires sur les hôtes (icône, coordonnées graphiques sur la statusmap, ...)
et serviceextinfo.cfg idem que hostextinfo.cfg mais pour les services.
 nagios.cfg
Il s'agit du fichier principal de configuration de Nagios. Il contient notamment la

liste des autres fichiers de configuration utilisés, ainsi que l'ensemble des directives globales
de fonctionnement de Nagios, comme le nom et le groupe de l'utilisateur nagios.
 ressource.cfg
Il s'agit d'un fichier de déclaration utilisé par les autres fichiers de configuration
de Nagios. Il permet de définir des variables globales pour une utilisation simplifiée dans les
autres fichiers de configuration (ex : $USER1$=/usr/local/nagios/libexec).
La surveillance de services et d'hôtes s'articule autour de plusieurs fichiers de

configuration et ces fichiers sont tous liés les uns aux autres. C'est pour cela que nous allons
plutôt envisager un petit exemple plutôt que de nous lancer dans une explication détaillée de
toutes les options. Pour utiliser un test de service il faut plusieurs choses :
 un greffon ou plugin utilisable en ligne de commande (le nom commence

par check_), il est très intéressant de le tester via la ligne de commande pour voir ses
arguments
 un objet Nagios définissant la commande utilisant le plugin précédent
 un objet Nagios définissant le service utilisant la commande précédente.
Script Shell → chekcommands.cfg → services.cfg

 hosts.cfg
Fichier de configuration des équipements supervisés. Une définition d'hôte

s'applique à un serveur "physique", une station de travail, un périphérique, un
équipement, qui se trouve sur votre réseau. Chaque hôte saisi nécessite une structure
particulière, incluant notamment son nom, son adresse IP, le type de test à effectuer pour
caractériser l'état de l'hôte (généralement ping)...
Tout d'abord, nous allons définir notre fichier d'hôtes. Ce fichier se trouve dans
/etc/nagios/hosts.cfg. .
Dans notre cas les fichiers cgi.cfg, hosts.cfg, hostgroups.cfg, services.cfg, servicegroups.cfg,
contacts.cfg, contactgroups.cfg, timeperiods.cfg, escalations.cfg constituent un seul fichier
nommée appelé bigger.cfg
De ce fait, une fois le Nagios configuré et qu'il tourne, la mise à jour (ajout hôte ou service)
nécessitera juste une modification sur du fichier bigger.cfg. Ci-dessous un exemple de fichier
bigger.cfg. Cet exemple permet des tester la charge du CPU (SNMP_CPU) de l’hôte nommé
GW_VOIP1.
KANNEL-SNTL:~# cd /etc/nagios3
KANNEL-SNTL:/etc/nagios3# vim bigger.cfg
define timeperiod{
timeperiod_name 24x7
alias 24 Hours A Day, 7 Days A Week
sunday 00:00-24:00
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-24:00
}
define contact{
contact_name nagios
alias Nagios Admin
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email nagios@sonatel.sn
}

# 'routeur-admins' contact group definition
define contactgroup{
contactgroup_name routeur-admins
alias Routeurs Administrators
members nagios
}
define host{
name generic-host ; The name of this host template
notifications_enabled 1 ; Host notifications are enabled
event_handler_enabled 1 ; Host event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 0 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program
restarts
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A
REAL HOST, JUST A TEMPLATE!
contact_groups nagios
}
define host{
use generic-host ; Name of host template to use
host_name GW_VOIP1
alias GW_VOIP1
address 10.1.1.1
check_command check-host-alive
max_check_attempts 10
notification_interval 240
notification_period 24x7
notification_options u
}
#'GW_VOIP 'hostgroup definition

define hostgroup{
hostgroup_name GW_VOIP
alias GW_VOIP
members GW_VOIP1
}
define service{
name generic-service ; The 'name' of this service template
active_checks_enabled 1 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted
parallelize_check 1 ; Active service checks should be parallelized (disabling
this can lead to major performance problems)
obsess_over_service 1 ; We should obsess over this service (if necessary)

check_freshness 0 ; Default is to NOT check service 'freshness'
notifications_enabled 1 ; Service notifications are enabled
event_handler_enabled 1 ; Service event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program
restarts
}
# Service definition
define service{
use generic-service
hostgroup_name GW_VOIP
service_description SNMP_CPU
is_volatile 0
check_period 24x7
normal_check_interval 10
retry_check_interval 1
process_perf_data 1 ; Process performance data
notification_options n
check_command check_snmp_cpu!1.3.6.1.4.1.9.2.1.56.0!
publickey!'0:30'!'0:70'
contact_groups routeur-admins
# Service definition
define servicegroup{
servicegroup_name GW_VOIP_CPU
alias GW_VOIP_CPU
members GW_VOIP1,SNMP_CPU
3. Configuration du protocole SNMP
Tout se passe toujours sur l'hôte hébergeant Nagios.
 Configuration de Snmptrapd
Le fichier de configuration /etc/snmp/snmptrapd.conf doit contenir :
traphandle default /usr/sbin/snmptt
disableAuthorization yes
donotlogtraps yes

Ca signifie que :
 on traite de la même façon toutes les interruptions : avec SNMPTT
 on accepte toutes les interruptions
 on ne journalise pas les interruptions reçues (c'est SNMPTT qui s'en chargera). On
aura quand même une trace de snmptrapd dans syslog, grâce à l'option -Lsd du lanceur
2008
Le lanceur du service snmptrapd doit être modifié pour ne pas traduire les OID, mais les
laisser sous forme numérique. C'est SNMPTT qui fera la traduction. I l faut modifier
/etc/rc.d/init.d snmptrapd :
OPTIONS="-On -Lsd -p /var/run/snmptrapd.pid"
Relancer snmptrapd après modification :
service snmptrapd restart
 Configuration de SNMPTT
Nous allons faire fonctionner SNMPTT en mode "stand-alone" ; il sera appelé chaque fois
que nécessaire par le gestionnaire d'interruptions snmptrapd.
L'initialisation est plus longue dans ce cas, mais le paramétrage plus simple.
 Compilation des MIB

Il faut maintenant récupérer le ou les fichiers MIB des équipements à superviser, pour les
convertir au format SNMPTT. Le but est d'extraire ce qui dans le fichier MIB est un
commentaire, pour que SNMPTT le mette en correspondance avec l'OID qui sera reçu. Pour
chaque fichier MIB, on lance la commande :
2008
snmpttconvertmib --in=<fichier MIB> --
out=/etc/snmp/snmptt.conf.<equipement> \
--exec='/usr/local/nagios/libexec/eventhandlers/submit_check_result $r
TRAP 1'
Ajouter enfin au fichier de configuration /etc/snmp/snmptt.ini les fichiers générés :

[...]
[TrapFiles]
snmptt_conf_files = <<END
/etc/snmp/snmptt.conf.<equipement1>
/etc/snmp/snmptt.conf.<equipement2>
END
Il faudra maintenant configurer les services Nagios, pour qu’il prenne en compte SNMP.
Pour cela, il faut définir un service générique pour les traps SNMP, dérivé du service
générique général :
define service{
name generic-service
register 0
check_period 24x7

notification_options w,u,c,r
notifications_enabled 1
}
define service{
name snmptrap-service
use generic-service
register 0
service_description TRAP
is_volatile 1
check_command check-host-alive
passive_checks_enabled 1
check_period none
contact_groups admins
}
Et le dériver pour chaque machine supervisée, par exemple :

define service{
host_name mail-server
use snmptrap-service
contact_groups admins
}
III. Les interfaces de Nagios
L'interface de Nagios est accessible via un simple navigateur web. Elle permet à
l'administrateur d'avoir accès à l'ensemble des informations de supervision. Basée sur des
CGI, cette interface peut donc être sécurisée par les mécanismes associés au serveur
web et aux CGI afin de restreindre les accès aux informations en fonction des profils
utilisateurs.
Elle est composée de deux grands types de vues :
• Monitoring
• Reporting
Il est également possible d'accéder à la configuration du logiciel via cette interface, mais
uniquement en lecture.
1. Les vue de monitoring
Les vues de monitoring permettent de connaître l'état des équipements et des services
supervisés, et éventuellement d'effectuer des actions sur ces derniers. Les vues principales
disponibles sont les suivantes :

 Tactical Overview : vue générale résumant l'ensemble des informations. C'est la vue
synthétique, où l'on trouve l'essentiel des informations importantes sur le bon
fonctionnement du système d'informations supervisé. Cette fenêtre rassemble
l'ensemble des alertes, les états et les fonctions de retrouver les informations capitales.
Cette page possède des liens divers pour rentrer un peu plus dans les détails. La
fenêtre à droite au centre doit avoir ses graphes de couleur verte, lorsque tout va bien.
Il peut arriver que le statut soit en "PENDING": ceci ce produit quand Nagios manque
de données. Il est dans l'incapacité d'en déduire un état quel qu'il soit. Dans ce cas,
généralement il suffit d'attendre un peu; si l'état ne change pas, il faut analyser avec
précision pourquoi Nagios de reçoit pas de données.
Figure 10 : Vue d'ensemble des informations par nagios
 Host détail : permet de visualiser l’état des machines supervisées (soit par le biais
d'une vérification par plugins, soit par un ping si aucun service n'est
défini).Cette fenêtre présente l'état global des machines du réseau, avec leurs statuts
(ACTIF, EN PANNE ...). Ici toutes les machines sont actives, ce que traduit la couleur
verte. Une machine inactive aurait été signalée par la couleur rouge qui représente un
état critique.
 Service Détail : vue des services supervisés. La liste exhaustive, par équipement,
des services supervisés. Cette vue peut être lourde si il y a un parc important avec un
grand nombre de services supervisés.
 Service Group Summary : donne une vue de l’ensemble des hôtes avce leurs états

Figure 11: Vue d'ensemble de l’état des hôtes du nagios
2. Les vues de reporting
Les vues de Reporting permettent de créer, à la volée, des rapports sur l'activité du système
d'information, en fonction des données collectées par Nagios…
Les vues principales disponibles sont les suivantes :
 Availability : permet de créer des rapports de disponibilité des équipements

 Alert History : permet d'avoir un historique des alertes
IV. L’accès aux informations

L’accès aux informations fournies par Nagios se fait classiquement par l’interface web qui est
fourni avec l’installation par défaut.
Grâce à la documentation qui y est jointe, les utilisateurs pourrons découvrir comment
n’afficher que les informations par groupe de machines (seulement les données concernant
les imprimantes ou les serveurs linux) ou par services, etc. La cartographie et autres
informations sont donc accessibles via un navigateur. L’accès à ces données est protégé par
un mot de passe.

Figure 12: Phase d’authentification pour l’accès à Nagios

PARTIE 2
L’OUTIL DE SUPERVISION POUR

L’ANALYSE DE FLUX RESEAUX
ET SYSTEMES :
CACTI

INTRODUCTION
Cacti est un logiciel de supervision (dit de « capacity planning ») basé sur RRDtool
permettant de surveiller l'activité de son architecture informatique à partir de graphiques
quotidiens, hebdomadaires, mensuels et annuels. Cette solution n'est donc pas destinée à
alerter en temps réel sur les dysfonctionnements d'un système mais bien de proposer une
vision dans le temps de l'évolution d'indicateurs matériels et logiciels (trafic réseau,
occupation des disques, temps deréponse, etc.).
Toutes les fonctionnalités ne sont pas présentées ici, il faudra par exemple se reporter aux
autres sources d'informations pour découvrir les requêtes SNMP indexées, la gestion des
utilisateurs, l'import et l'export XML des modèles, etc.
Tout d'abord le logiciel RRDtool (version 1.0), pouvant être utilisé de manière autonome, sera
présenté. La suite du document constituera un tutoriel décrivant les étapes depuis la création
d'un script de collecte d'informations jusqu'à l'obtention d'un graphique sur l'interface
utilisateur, en passant par la création des modèles de sources de données et de graphiques.

I. RRDTOOL
1. Présentation
Le programme RRDtool a été développé par Tobias Etiker dès 1995. Il est librement
téléchargeable sur le site suivant : http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/.
RRD est l'acronyme de Round Robin Database, qui peut se traduire par « base de données
cyclique ». Ce mécanisme permet de stocker des données dans des fichiers de taille
invariante, définie à la création, par un mécanisme de pile LILO (Last In Last Out). Un fichier
RRD peut contenir plusieurs RRA (Round Robin Archive) qui correspondent aux différents
cycles de conservation des données (jour, semaine, mois, année, etc.).
Une fois les données collectées, RRDtool fournit des outils permettant de générer des
graphiques hautement personnalisables, retraitant les données à la volée.
2. Manipulation
a. Création de fichiers RRD
La commande suivante initialise un fichier RRD :
# rrdtool create linagora.rrd \

--start 1120082400 \
DS: vitesse: COUNTER:600:U:U \
RRA:AVERAGE:0.5:1:24 \
RRA:AVERAGE:0.5:6:10
Le fichier se nomme linagora.rrd. La date d'initialisation (option --start) est donnée dans le
format UNIX, c'est à dire le nombre de secondes écoulées depuis le 1er janvier 1970.
Le fichier RRD créé contient une source de données (DS pour Data Source). Elle représente la
donnée que l'on souhaite stocker et la manière dont les valeurs seront conservées. Les valeurs
d'une source de données sont nommées points de données primaires (PDP pour Primary Data
Point). Une source de données peut être de l'un des types suivants :
 COUNTER : est stockée la différence entre le PDP actuel et le PDP précédent, le tout
divisé par la période d'échantillonnage. Ce type ne fonctionne que pour des PDP en
augmentation constante (comme un compteur).
 DERIVE : idem que COUNTER, mais accepte les PDP négatifs.
 ABSOLUTE : idem que COUNTER sauf que le PDP précédent est toujours 0. C'est
également la même chose que GAUGE, sauf que le PDP est divisé par la durée
d'échantillonnage.
 GAUGE : le PDP brut est stocké, sans calcul avec le PDP précédent ou la durée
d'échantillonnage.
Par exemple, si on enregistre toutes les 300 secondes (5 minutes) les PDP suivants : 300, 600,
900, 1200, on obtiendra comme valeurs stockées :
COUNTER = 1 1 1 1
DERIVE = 1 1 1 1
ABSOLUTE = 1 2 3 4
GAUGE = 300 600 900 1200

Pour déclarer une source de données, il faut donner son nom, son type, son battement de cœur
(heartbeat) et les PDP minimaux et maximaux (si un PDP sort de ces limites il est considéré
comme inconnu). Le battement de cœur est le temps maximum en secondes d'attente d'un
PDP après lequel il est considéré comme inconnu. Dans l'exemple précédent, les valeurs
suivantes ont été choisies :
nom : vitesse
type : COUNTER
battement de coeur : 600
minimum : U (pour unknown, inconnu)
maximum : U (pour unknown, inconnu)
Suite à la source de données, les RRA sont déclarées. Elles déterminent le nombre
d'échantillons (PDP) nécessaires pour calculer un point de consolidation primaire (CDP pour
Primary Consolidation Point) et le nombre d'échantillons à conserver. Une RRA a besoin
d'une fonction de consolidation (CF) qui indique comment calculer le CDP à partir des PDP :
AVERAGE : le CDP est la moyenne des tous les PDP.
MINIMUM : le CDP est le PDP le plus petit.
MAXIMUM : le CDP est le PDP le plus grand.
LAST : le CDP est le dernier PDP.
Les paramètres fournis ensuite à la RRA sont le facteur xfiles (xff pour xfiles factor) qui
détermine la proportion de PDP inconnus nécessaire pour rendre le CDP inconnu, le nombre
d'échantillons (steps) et enfin le nombre de CDP à conserver (rows).
Remarque : les RRA sont appliquées à chaque source de données, il n'est pas possible de
sélectionner les RRA par source, il faut créer des fichiers RRD différents pour obtenir cette
fonctionnalité.
b. Peuplement d’un fichier RRD
UNIX. Par exemple, pour stocker les valeurs kilométriques indiquées dans l'exemple :
# rrdtool update linagora.rrd 1120082400:12345 1120082700:12357
On note que les deux dates sont distantes de 300 secondes, qui est la durée d'échantillonnage
par défaut. Après la date et le séparateur « : », la valeur brute est indiquée. Selon le type de
source de données, elle sera ou non retraitée. Si plusieurs DS sont déclarées, la valeur
correspondante est préfixée du nom de la source à enrichir.
Dans l'exemple, la source est de type COUNTER, il faut donc au minimum deux valeurs
avant d'obtenir un PDP. Dans ce cas, pour la valeur 12345, le premier vaudra nan (Not a
Number). Ensuite, pour la valeur 12357, le PDP vaudra (12357-12345)/300 soit 0,04. Ces
valeurs seront stockées dans l'archive bihoraire mais il faudra attendre d'avoir au moins 6 PDP
pour stocker une valeur dans l'archive pentahoraire (et cette valeur sera calculée à partir de la
fonction de consolidation choisie).
Les valeurs conservées dans le fichier RRD auront une dimension en kilomètres par seconde,
la transformation en kilomètres par heure pourra être réalisée plus tard, au moment de la
création du graphique.
Il est évident que la peuplement d'un fichier RRD doit être exécuté automatiquement par un
script prenant en charge la collecte des données et la mise à jour de la base. Pour Cacti, ce
script sera nommé poller.

c. Création du graphique
RRDtool fournit des outils pour générer les graphiques s'appuyant sur les sources de données
des fichiers RRD. La mise à jour du graphique est indépendante de la mise à jour des données,
ce qui signifie que pour obtenir un graphique « temps réel » il faut d'abord effectuer la mise à
jour du fichier RRD puis ensuite générer une nouveau graphique à partir de ces données. La
commande suivante génère un graphique basique :
# rrdtool graph linagraphique.png \

--start 1120082400 --end 1120086000 \
DEF:celerite=linagora.rrd:vitesse:AVERAGE \
LINE2:celerite#FF0000
Le nom du graphique choisi est linagraphique.png, il sera créé dans le répertoire courant.
Les dates de début et de fin sont données sous format UNIX par les options --start et --end.
Vient ensuite la définition (DEF) de la source de données à utiliser. Il faut choisir pour cela un
identifiant (ici celerite), le nom du fichier RRD (ici linagora.rrd), le nom de la source de
données (ici vitesse) et enfin la fonction de consolidation (ici AVERAGE).
Pour finir, les éléments du graphique sont configurés, ils utilisent ou non une des sources de
données définies plus haut (DEF). Voici quelques types possibles (liste non exhaustive) pour
ces éléments :
GPRINT : élément de légende.
COMMENT : commentaire en bas du graphique.
LINEx : ligne d'épaisseur x.
AREA : aire.
VRULE : ligne horizontale.
Pour certains de ces types, il faut déclarer la DEF associée ainsi que la couleur, au format
#RRGGBB. Dans l'exemple, c'est une ligne d'épaisseur 2 et de couleur rouge qui représente la
vitesse (définie par celerite).
Il est possible de modifier à la volée les valeurs qui seront utilisées pour créer le graphique,
sans altérer les données du fichier RRD : ce sont les définitions calculées (CDEF pour
Calculations DEFinitions), utilisant le langage RPN (Reverse Polish Notation). Il a comme
particularité de définir des opérations en spécifiant d'abord les opérandes et ensuite l'opérateur
(par exemple 2+3 s'écrira 2,3,+ en RPN).
Pour obtenir des kilomètres par heure plutôt que des kilomètres par seconde, il faut multiplier
les données du fichier RRD par 3600, la commande de création de graphique sera alors :
# rrdtool graph linagraphique.png \
--start 1120082400 --end 1120086000 \
DEF:celerite=linagora.rrd:vitesse:AVERAGE \
CDEF:celeriteh=celerite,3600,\*
LINE2:celeriteh#FF0000
Remarque : le caractère * doit être échappé pour que l'expression soit syntaxiquement
correcte.
L'outil de création de graphique réserve d'autres fonctionnalités dont certaines seront exposées
dans le tutoriel Cacti présenté ci-après.

II. CACTI
1) Présentation
Cacti est un logiciel écrit en PHP, s'appuyant sur un base de données MySQL pour stocker
tous ses éléments de configuration et sur RRDtool pour créer les fichiers RRD, les peupler et
obtenir les graphiques correspondants. Il a pour objectif de faciliter les manipulations parfois
fastidieuses de RRDtool, néanmoins une bonne connaissance des fonctionnalités de cet outil
est nécessaire pour apprécier l'utilisation de Cacti (cf. 2. RRDtool). Il est librement
téléchargeable sur le site http://www.cacti.net.
La suite de ce document va décrire comment programmer un script de collecte de données,
comment l'intégrer aux commandes Cacti puis créer les modèles de source de données et de
graphiques associés. Ensuite seront décrites les étapes permettant de déclarer un serveur puis
lui générer les sources de données et les graphiques issus des modèles créés précédemment.
Pour terminer, il sera expliqué comment gérer l'arbre des graphiques présenté sur l'interface
utilisateur.
Le script d'exemple permettra de mesurer d'une part le temps nécessaire pour réaliser une
authentification sur un annuaire, et d'autre part le temps nécessaire pour réaliser une lecture
sur cet annuaire. On obtiendra au final un graphique possédant deux courbes reflétant
l'évolution de ces deux temps de réponse.
2) Script de collecte de données
Le script peut être programmé dans n'importe quel langage, du moment qu'il reste exécutable
sur le système d'exploitation hébergeant Cacti. Si PHP est choisi, il est possible d'optimiser
l'exécution du script en respectant la norme fixée par les développeurs pour créer un script
serveur (voir documentation officielle sur le site http://www.cacti.net).
Le script peut prendre ou non des paramètres en entrée, il doit par contre respecter le format
de sortie suivant :
attribut1:valeur1 attribut2:valeur2 attribut3:valeur3 ...
Si le script ne renvoie qu'une valeur, le nom de l'attribut peut être omis. Il est important de
mettre des espaces entre chaque couple attribut/valeur mais de ne pas en mettre avant et après
le caractère séparateur « : ».
Le script d'exemple se nomme temps_ldap.pl et prend en entrée l'adresse et le port de
l'annuaire LDAP. Voici son usage :
./temps_ldap.pl -h hostname -p port
Il renvoie deux valeurs, un pour l'attribut bind, l'autre l'attribut search, par exemple :
bind:0.001 search:0.004

3) Création de la commande
Le script doit être copié dans le répertoire des scripts de Cacti :
# cp temps_ldap.pl /var/www/html/cacti/scripts
Il doit être exécutable pour l'utilisateur cacti :
# chmod u+x /var/www/html/cacti/scripts/temps_ldap.pl

# chown cacti /var/www/html/cacti/scripts/temps_ldap.pl
Se connecter à l'interface web de Cacti en administrateur (par défaut http://serveur/cacti/,

identifiant : admin). Cliquer ensuite sur Data Input Methods dans le sous-menu
Collection Methods puis sur Add en haut à droite pour ajouter une nouvelle commande :
Le formulaire propose les champs suivants :
Figure 13: Ajouter une nouvelle commande
Name : nom de la commande, pour usage dans Cacti.

Input Type : nature de la commande (script externe, requête SNMP, script serveur PHP,
etc.).
Input String : chemin complet du script. Les paramètres doivent être placés entre <>,
ils seront détectés par Cacti.
Pour le script d'exemple, les valeurs à renseigner sont les suivantes :
Name : Temps de réponse LDAP
Input Type : Script/Command
Input String : /var/www/html/cacti/scripts/temps_ldap.pl -h <hostname> -p <port>
Cliquer sur create pour enregistrer la nouvelle commande. Le message Save Successful doit
apparaître en haut de la page.
Il faut à présent préciser les paramètres d'entrée de la commande, qui ont été définis plus haut
dans le champ Input String. Dans le tableau Input Fields, cliquer sur Add :

Figure 14: Paramètres d'entrées de la commande
Le formulaire propose les champs suivants :

Field [Input] : identifiant du paramètre d'entrée (généré à partir des valeurs entre <> du
champ Input String).
Friendly Name : nom explicite du paramètre, pour usage dans Cacti.
Regular Expression Match : expression régulière validant la saisie du champ.
Allow Empty Input : permettre une valeur vide pour ce champ.
Special Type Code : nature spéciale du champ, permettant à Cacti de remplir
Dynamiquement sa valeur. Les natures suivantes sont disponibles :
 hostname : adresse du serveur.
 snmp_community : communauté SNMP.
 snmp_username : utilisateur SNMP.
 snmp_password : mot de passe SNMP.
 snmp_port : port SNMP.
 snmp_timeout : temps maximal de connexion SNMP.
 snmp_version : version SNMP.
Pour chaque paramètre, cliquer sur create pour valider et sur Add pour ajouter le suivant. Le
message Save Successful doit apparaître en haut de la page.
Pour terminer il faut déclarer les champs de sortie, en cliquant sur Add en haut du tableau
Ouput Fields :

Figure 15: Déclaration des champs de sorties
4) Création de l’hôte
Avant toute chose, il faut déclarer les hôtes supervisés dans Cacti. Il est fortement conseillé
que ces hôtes soient accessibles par SNMP, mais ce n'est pas une obligation.
Cliquer sur Devices dans le sous-menu Management, puis sur Add en haut à droite :
Figure 16: Ajout d'un hôte
Pour l'exemple, il faut remplir les champs Description et Hostname, choisir ucd/net SNMP
Host pour le champ Host Template et modifier si besoin le nom de la Communauté SNMP. Si
on ne souhaite pas de SNMP, conserver None comme modèle.

Cliquer sur create pour créer l'hôte. Un message de réussite doit s'afficher en haut de la page.
Si le modèle ucd/net SNMP Host a été choisi, il est possible de créer rapidement les
graphiques de base :
 Trafic des cartes réseaux
 Occupation des partitions du disque
 Utilisation du processeur
 Charge du processeur
 Utilisation de la mémoire
Ces éléments sont indiqués dans les tableaux Associated Data Queries et Associated Graph
Templates. Pour créer les graphiques standards, cliquer sur Create Graphs for this Host en
haut à droite de la page :
Figure 17: Création de graphes standards
Dans le tableau Graph Templates, sélectionner la totalité des graphiques avec la case en haut à
droite. Dans les tableaux Data Query, sélectionner les interfaces réseaux et les partitions à
superviser. Cliquer ensuite sur create.
Il est demandé de préciser les noms de la source et du graphique pour l'utilisation du
processeur. Laisser les valeurs par défaut et cliquer sur create. En haut de la page doit
s'afficher la liste des graphiques générés.
Si le serveur ne possède pas SNMP, ces graphiques ne peuvent pas être crées, mais les étapes
suivantes permettent dans les deux cas de générer le graphique pour le temps de réponse
LDAP.
5) Source de données
La première étape consiste à créer un modèle de sources de données utilisant la commande

définie au 3 (Création de la commande).

La seconde étape, à renouveler pour chaque nouveau serveur, permet de créer une source de
données rapidement à partir du modèle.
a. Modèle
Pour créer un modèle de source de données, cliquer sur Data Templates dans le sous-menu
Templates. Cliquer sur Add en haut à droite :
Figure 18: Ajout d'une source de données
La plupart des champs possède l'option Use Per Data Source Value (Ignore this Value). Elle
permet de rendre le champ spécifique, c'est-à-dire que la valeur inscrite dans le modèle ne
sera pas propagée aux sources issues du modèle. Plus exactement, la valeur servira de valeur
par défaut dans la source mais le champ sera modifiable pour chaque source issue du modèle.
Cliquer sur create pour créer le modèle. Le message Save Successful apparaît en haut de la
page. Il est possible de créer de nouveaux éléments de la source en cliquant sur new en haut à
gauche du cadre Data Source Item.

Après sauvegarde, le cadre Custom Data apparaît, lié à la valeur inscrite dans le champ
Data Input Method. Il permet d'indiquer les valeurs des paramètres d'entrée. Un nouveau
champ apparaît également dans le cadre Data Source Item, nommé Output Field, qui permet
d'associer un champ de sortie (parmi ceux déclarés dans la méthode sélectionnée) à un
élément de la source de donnée. Il n'est pas obligatoire de déclarer un élément par champ de
sortie, mais il en faut au minimum un.
Cliquer sur save pour enregistrer le modèle.
b. Génération des sources à partir du modèle
Cliquer sur Data Sources dans le sous-menu Management. Sélectionner l'hôte concerné dans
le cadre Data Sources et cliquer sur Add en haut à droite.
Dans le cadre Data Template Selection, choisir le modèle qui vient d'être créé (champ
Selected Data Template), vérifier que l'hôte est bien sélectionné (champ Host), et cliquer
sur create.
Le cadre Supplemental Data Template Data apparaît, avec les champs spécifiques mentionnés
dans le modèle (options Use Per Data Source Value), plus le champ
Data Source Path qui détermine le nom du fichier RRD (il est conseillé de conserver la valeur
attribuée par Cacti).
Remplir les champs spécifiques et cliquer sur save. Le message Save Successful apparaît en
haut de la page. Pour l'exemple, les champs spécifiques sont le nom de la source de données
et le port de l'annuaire LDAP, il est possible de les modifier pour chaque source de données
générée.
La création de la source de données dans Cacti équivaut à la création du fichier RRD avec
RRDtool. Cependant comme la source est active, Cacti va la mettre à jour automatiquement
en utilisant la commande fournie, alors qu'il faudrait le faire manuellement avec RRDtool (cf.
Peuplement d'un fichier RRD).
6) Graphiques
Dans le même esprit que pour les sources de données, un modèle va d'abord être créé pour
permettre de générer facilement des graphiques pour chaque hôte.
a. Modèle
Pour créer un modèle de graphiques, cliquer sur Graph Templates dans le sous-menu
Templates. Cliquer sur Add en haut à droite. Un formulaire vierge avec plusieurs cadres
apparaît.
Lorsque que l'élément du graphique est lié à un nouvel élément de source de données (option
Data Source dans le formulaire précédent), une entrée est créée dans le tableau Graph Item
Inputs (elle correspond à une ligne DEF dans la commande de création de graphique
RRDtool). Une entrée peut servir à plusieurs élément (par exemple pour tracer la courbe et
afficher la valeur en légende). Il est possible d'éditer ces entrées en cliquant sur leur nom, on
obtient alors les options suivantes :

Figure 19: Créer un modèle de graphique
Il faut à présent définir les éléments du graphique que sont les courbes, les aires, les légendes,
etc. Les choix diffèrent avec ceux proposés par défaut dans RRDtool (Création du graphique).
Cliquer sur Add en haut à droite du cadre Graph Template Items. Le formulaire suivant
apparaît :

Figure 20: Définir les éléments du graphique
Les concepts de fonctions de consolidation et de CDEF sont ceux exposés dans (Création du
graphique). Cliquer sur create pour créer l'élément. Le message Save Successful apparaît en
haut de la page.
- Name : identifiant de l'entrée.

- Description : description de l'entrée (optionnel).
- Field Type : nature de l'entrée. C'est Data Source qui convient dans la majorité
des cas.
- Associated Graph Items : éléments du graphique associés. Il est préférable de
les configurer dans le tableau Graph Template Items.
Pour l'exemple, deux entrées (bind et search) seront créées automatiquement, il n'est pas
nécessaire de les modifier.
Cliquer sur save pour enregistrer le modèle.
b. Génération des graphiques à partir du modèle
Cliquer sur Graph Management dans le sous-menu Management. Sélectionner l'hôte concerné
dans le cadre Graph Management et cliquer sur Add en haut à droite.
Dans le cadre Graph Template Selection, choisir le modèle concerné (champ Selected Graph
Template), vérifier que l'hôte est bien sélectionné (champ Host), et cliquer sur create. Le
cadre Supplemental Graph Template Data apparaît, avec les champs spécifiques mentionnés
dans le modèle (options Use Per Data Source Value), plus les champs Data Source qui
déterminent les éléments des sources de données à associer aux entrées des éléments du
graphique (Graph Item Inputs).
Remplir les champs spécifiques (uniquement le nom pour l'exemple) et cliquer sur save. Le
message Save Successful apparaît en haut de la page.

7) Positionnement du graphique
Les graphiques sont créés mais n'apparaissent par dans l'arbre de présentation de Cacti
(Graph Tree). Pour cela il faut cliquer sur Graph Trees dans le sous-menu Management.
Pour créer un nouvel arbre, cliquer sur Add en haut à droite du cadre Graph Trees. Deux
paramètres seulement sont nécessaires :
- Name : Nom de l'arbre
- Sorting Type : Tri des éléments de l'arbre :
 Manual Ordering : tri manuel.
 Alphabetic Ordering : tri par ordre alphabétique.
 Numeric Ordering : tri par valeurs numériques.
Pour éditer un des arbres existants, cliquer sur le nom de celui-ci. Pour l'exemple, créer un
arbre « Temps de réponse LDAP » avec un tri manuel.
À l'intérieur d'un arbre, pour créer un élément, cliquer sur Add en haut à droite du cadre
Tree Items. Trois types d'éléments (Tree Item Type) peuvent être créés :
Header : branche d'un arbre. L'option Title contient le nom de la branche et l'option
Sorting Type la méthode de tri des éléments.
Graph : graphique simple. L'option Graph permet de sélectionner le graphique à afficher et
l'option Round Robin Archive permet de choisir la RRA associée.
Host : branche spéciale regroupant tous les graphiques d'un hôte. L'option Host permet de
sélectionner l'hôte et l'option Graph Grouping Style l'ordre de présentation des graphiques.
Pour l'exemple, créer des graphiques simples (avec RRA Daily) pour chaque hôte configuré.
Il est possible de modifier la hiérarchie des éléments en changeant la valeur de l'option Parent
Item.
Cliquer sur create ou save pour enregistrer les modifications. Elles sont visibles
immédiatement dans l'interface utilisateur. Les graphiques créés doivent se trouver dans la
branche « Temps de réponse LDAP ».

Conclusion
La supervision est devenue indispensable dans tout système d’information. Elle est à la base
du bon fonctionnement d’une architecture réseau et permet de réagir rapidement en cas de
problèmes ou pannes.
Elle se base à l’heure actuelle principalement sur le protocole SNMP qui depuis de
nombreuses années a quand même du mal à évoluer. En effet, de nombreux logiciels sont
encore basés sur la version 1 du protocole qui commence un peu à vieillir et qui n’est pas du
tout sécurisé. En effet la version 2, apportant notamment la sécurité n’a été qu’une phase de
transition vers la v3 qui est encore très peu utilisée.
Les logiciels de monitoring sont très nombreux qu’ils soient du monde du libre ou
propriétaires et supportent les principales plateformes des systèmes d’information. La plupart
sont encore basés sur le protocole SNMP. On peut alors se demander si les nouveaux
standards qui sont encore au statut de développement seront utilisés dans un avenir proche et
amené à le remplacer?

Bibliographie/Wébographie

Memoiretymtyma

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Memoiretymtyma

Încărcat de

Drepturi de autor:

Formate disponibile

DEDICACES

Je dédie ce mémoire à :

 Mes frères et sœurs

 Ainsi qu’à tous les membres de ma famille

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 1

 Tous les professeurs de la section mathématique informations.

 Toute la promotion IGTT2 Téléinformatique 2010-2012 de l’ESMT pour leur esprit

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 2

I. Présentation de la structure d’acceuil........................................................8

II. Les enjeux et les acteurs de la supervision...............................................13

III. Choix du nagios et de cacti........................................................................15

PREMIERE PARTIE : LE NAGIOS (OUTIL DE SUPERVISION DES

CHAPITRE02: Architecture et Principe de fonctionnement du nagios

I. Historique et fonctionnement du protocole SNMP.................................18

II. Présentation et principe de fonctionnement de nagios..........................23

CHAPITRE03: Implémentation de Nagios

III. Les interfaces de Nagios.............................................................................42

IV. L’accès aux informations...........................................................................44

DEUXIEME PARTIE : LE CACTI (OUTIL DE SUPERVISION POUR

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 4

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 5

Figure 1: Les actionnaires de l’entreprise..........................................................................................8

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 6

Actuellement aucune entreprise ne peut se passer d'outils informatiques, et très souvent un

Enfin un autre avantage: Sa cohabitation avec l’outil de supervision CACTI rend la

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 7

1. Historique et présentation de la SONATEL

La Société Nationale des Télécommunications (SONATEL) premier opérateur de

Figure 1: Les actionnaires de l’entreprise

Elle comporte plusieurs filiales dont :

En Novembre 2006, le groupe SONATEL adopte la marque commerciale Orange et un

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 8

2. Les différentes activités de la société F

La SONATEL assure l’exploitation et le développement de son secteur d’activité. Elle

On fera une présentation détaillée du service DRSI/DEX/ERT/SQT au sein de lequel on a

La Direction des Opérations Réseaux et Système d’Information (DRSI)

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 9

Le pôle Exploitation des réseaux (DEX)

Ce pôle est chargé des missions suivantes :

Il a sous sa responsabilité les structures suivantes :

 Assurer le bon fonctionnement des services réseaux et SI (Systémes

 SRI (Supervision Réseaux IP & ADSL).

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 10

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 11

Figure 3:Organigramme du pôle d’exploitation DRSI/DEX

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 12

1. La problématique des réseaux privés d’entreprise

La notion de supervision s’applique essentiellement dans un contexte de réseau privé. L’idée

2. Les différents aspects de la supervision réseaux

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 13

b. La supervision SNMP : l’état des équipements

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 14

c. La supervision applicative : l’état des services

La supervision applicative, longtemps ignorée, et aujourd’hui au cœur des préoccupations

I. Choix du nagios et de cacti

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 15

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 16

L’OUTIL DE SUPERVISION DES

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 17

I. Historique et fonctionnement du protocole SNMP

2. Principe de fonctionnement du SNMP

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 18

 Les MIBs (Management Information Base)

Mise en Place d’un utilitaire de supervision pour le réseau IP de la SONATEL Page 19