N° d’ordre : 09 / L3 / TCO Année Universitaire : 2010 / 2011

UNIVERSITE D’ANTANANARIVO
----------------------
ECOLE SUPERIEURE POLYTECHNIQUE
-----------------------
DEPARTEMENT TELECOMMUNICATION

MEMOIRE DE FIN D’ETUDES

en vue de l’obtention

du DIPLOME de Licence ès Sciences Techniques

Spécialité : Télécommunication

par : RAKOTOARISOA Mamy Vonjimampianina

MISE EN PLACE D’UN SERVEUR DE SUPERVISION

UTILISANT CACTI SOUS REDHAT/LINUX

Soutenu le 03 Août 2012 devant la Commission d’Examen composée de :

Président : Monsieur ANDRIAMIASY Zidora

Examinateurs :
Monsieur RAKOTOMALALA Mamy Alain
Madame ANDRIANTSILAVO Haja Samiarivonjy
Monsieur RANDRIAMIHAJARISON Jimmy

Directeur: Monsieur RATSIMBAZAFY Andriamanga

 REMERCIEMENTS

Je voudrais rendre grâce à Dieu pour sa bonté, de m’avoir donné santé, force durant mes
études et durant la réalisation et rédaction de cet ouvrage.
Je tiens à exprimer mes sincères remerciements à l’issue de ce mémoire de fin d’études à
l’égard de :

Monsieur ANDRIANARY Philippe, Professeur, Directeur de l’Ecole Supérieure Polytechnique

d’Antananarivo de m’avoir accueilli au sein de son établissement.

Monsieur RAZAKARIVONY Jules, Maître de Conférences, Chef du Département

Télécommunication.

Monsieur ANDRIAMIASY Zidora, Maître de Conférences qui me fait l’honneur de présider le

jury de cette soutenance.

Monsieur RATSIMBAZAFY Andriamanga, Maître de conférences, Directeur de mémoire, pour

ses précieux conseils et surtout de m’avoir su m’orienté.

Tous les enseignants qui sont membres du jury de cette soutenance malgré leurs obligations:

Monsieur RAKOTOMALALA Mamy Alain, Maître de Conférences ;

Madame ANDRIANTSILAVO Haja Samiarivonjy, Doctorant ;
Monsieur RANDRIAMIHAJARISON Jimmy, Doctorant.

Tout le corps enseignant et personnel de l’Ecole Supérieure Polytechnique, surtout ceux au sein du
Département Télécommunications.

Monsieur RAFALIMANANA Edmond, Directeur des Systèmes d’Information (DSI), au sein du

Ministère des Finances, qui a bien voulu accepter ma participation au sein de sa direction.

Monsieur RAJAOMANDROSO Herimalala, Chef de Service Réseaux Base de Données et

Application au sein de la DSI, qui a bien voulu m’encadrer lors de mon stage.

Tout le personnel de la DSI pour leur accueil sympathique et leur coopération professionnelle.

Toute ma grande famille et mes amis, mes collègues et tous ceux qui ont de près ou de loin
contribué à la réalisation de ce travail.

i
 TABLE DES MATIERES
REMERCIEMENTS ...................................................................................................................................... i
TABLE DES MATIERES ............................................................................................................................ ii
ABREVIATIONS ......................................................................................................................................... vi
INTRODUCTION GENERALE.................................................................................................................. 1
CHAPITRE 1 LA SUPERVISION INFORMATIQUE ............................................................................. 3
1.1 Introduction ...................................................................................................................................... 3
1.2 Définition ........................................................................................................................................... 3
1.3 Intérêt et Rôle ................................................................................................................................... 3
1.4 Mode de fonctionnement ................................................................................................................. 4
1.4.1 Supervision réseau ......................................................................................................................................... 4
1.4.2 Supervision système ....................................................................................................................................... 4
1.4.3 Supervision applicative .................................................................................................................................. 4

1.5 Architecture d’administration ........................................................................................................ 5

1.6 Architecture des systèmes de gestion .............................................................................................. 6
1.6.1 Approche centralisée ..................................................................................................................................... 6
1.6.1.1 La plateforme de gestion ............................................................................................................................ 7
1.6.1.2 Les applications de gestion ........................................................................................................................ 7
1.6.2 Architecture hiérarchique ............................................................................................................................. 8
1.6.3 Approche distribuée ....................................................................................................................................... 9

1.7 Structure des systèmes de gestion des réseaux .............................................................................. 9

1.7.1 Le modèle informationnel ........................................................................................................................... 10
1.7.2 Modèle de communication .......................................................................................................................... 10
1.7.3 Modèle organisationnel ............................................................................................................................... 10

1.8 Les approches décentralisées de la gestion des réseaux .............................................................. 11

1.9 Principe général .............................................................................................................................. 15
1.10 Conclusion ....................................................................................................................................... 16
CHAPITRE 2 LES PROTOCOLES DE GESTION DE RESEAU ........................................................ 17
2.1. Le modèle OSI ................................................................................................................................ 17
2.1.1 Les sept couches du modèle OSI ................................................................................................................. 17
2.1.1.1 Couche physique ...................................................................................................................................... 18
2.1.1.2 Couche liaison de données ....................................................................................................................... 18
2.1.1.3 Couche réseau .......................................................................................................................................... 18
2.1.1.4 Couche transport ...................................................................................................................................... 18

ii
 2.1.1.5 Couche session ......................................................................................................................................... 18
2.1.1.6 Couche présentation ................................................................................................................................. 18
2.1.1.7 Couche application ................................................................................................................................... 18
2.1.2 La norme ISO 7498/4 .................................................................................................................................. 19
2.1.2.1 Gestion des performances ........................................................................................................................ 19
2.1.2.2 Gestion des configurations ....................................................................................................................... 20
2.1.2.3 Gestion de la comptabilité ........................................................................................................................ 20
2.1.2.4 Gestion des anomalies .............................................................................................................................. 21
2.1.2.5 Gestion de la sécurité ............................................................................................................................... 21
2.1.2.6 Structure de gestion des réseaux .............................................................................................................. 21

2.2 Le protocole CMIP ......................................................................................................................... 23

2.3 Le modèle TCP/IP .......................................................................................................................... 24
2.4 Le protocole SNMP ........................................................................................................................ 24
2.4.1 Définition ..................................................................................................................................................... 24
2.4.2 Principe de fonctionnement ........................................................................................................................ 24
2.4.2.1 Les équipements gérés ............................................................................................................................. 24
2.4.2.2 L’agent ..................................................................................................................................................... 25
2.4.2.3 Le superviseur .......................................................................................................................................... 25
2.4.3 Le protocole.................................................................................................................................................. 25
2.4.4 Interrogation d’un agent ............................................................................................................................. 26
2.4.5 Evolution des versions de SNMP ................................................................................................................ 27
2.4.5.1 SNMPv1 ................................................................................................................................................... 27
2.4.5.2 SNMPv2p ................................................................................................................................................. 28
2.4.5.3 SNMPv2c ................................................................................................................................................. 28
2.4.5.4 SNMPv2u ................................................................................................................................................. 28
2.4.5.5 SNMPv2* ................................................................................................................................................. 28
2.4.5.6 SNMPv3 ................................................................................................................................................... 28
2.4.6 La MIB ......................................................................................................................................................... 29
2.4.7 La sécurité avec SNMP ............................................................................................................................... 30

2.5 Comparaison du modèle TCP/IP par rapport au modèle ISO................................................... 31

2.6 Conclusion ....................................................................................................................................... 33
CHAPITRE 3 LES OUTILS DE SUPERVISION .................................................................................. 34
3.1 Introduction .................................................................................................................................... 34
3.2 Les offres éditeurs ou logiciel propriétaire: ................................................................................. 34
3.2.1 HP OpenView .............................................................................................................................................. 34
3.2.1.1 Présentation .............................................................................................................................................. 34

iii
 3.2.1.2 Utilisation ................................................................................................................................................. 35
3.2.2 IBM TIVOLI Monitoring ............................................................................................................................ 37

3.3 Les offres du monde libre .............................................................................................................. 38

3.3.1 Nagios .......................................................................................................................................................... 38
3.3.1.1 Présentation .............................................................................................................................................. 38
3.3.1.2 Principe et fonctionnement....................................................................................................................... 39
3.3.1.3 Utilisation ................................................................................................................................................. 40
3.3.2 Centreon ....................................................................................................................................................... 41
3.3.2.1 Présentation .............................................................................................................................................. 41
3.3.2.2 Principe et fonctionnement....................................................................................................................... 41
3.3.2.3 Conclusion sur Centreon .......................................................................................................................... 42
3.3.3 CACTI .......................................................................................................................................................... 43
3.3.3.1 Présentation .............................................................................................................................................. 43
3.3.3.2 Principe et fonctionnement....................................................................................................................... 43
3.3.3.3 Extensions ................................................................................................................................................ 45
3.3.3.4 Conclusion sur Cacti ................................................................................................................................ 46
3.3.4 EyesOfNetwork ............................................................................................................................................ 47

3.4 Conclusion ....................................................................................................................................... 48

CHAPITRE 4 INSTALLATION ET MISE EN ŒUVRE ...................................................................... 49
4.1 Le choix de CACTI ........................................................................................................................ 49
4.2 Prérequis ......................................................................................................................................... 49
4.2.1 RRDTool ...................................................................................................................................................... 49
4.2.2 Apache.......................................................................................................................................................... 50
4.2.3 MySQL ......................................................................................................................................................... 50
4.2.4 PHP .............................................................................................................................................................. 50
4.2.5 SNMP ........................................................................................................................................................... 50

4.3 Installation des prérequis .............................................................................................................. 50

4.3.1 Installation de RRDTool.............................................................................................................................. 50
4.3.2 Installation de PHP ..................................................................................................................................... 51
4.3.3 Installation de MySQL ................................................................................................................................ 51
4.3.4 Installation de SNMP .................................................................................................................................. 51

4.4 Configurations ................................................................................................................................ 51

4.4.1 Configuration de serveur MySQL ............................................................................................................... 51
4.4.1.1 Attribution de mot de passe ...................................................................................................................... 51
4.4.1.2 Création de la base de données cacti ........................................................................................................ 51
4.4.1.3 Création de l’utilisateur ............................................................................................................................ 51

iv
 4.4.1.4 Attribution de privilège ............................................................................................................................ 51
4.4.2 Configuration SNMP................................................................................................................................... 52

4.5 Installation de cacti ........................................................................................................................ 52

4.5.1 Installation des tables de cacti.sql ............................................................................................................... 52
4.5.2 Configuration de cacti ................................................................................................................................. 53
4.5.3 Configuration httpd ..................................................................................................................................... 53
4.5.4 Installation de CACTI cronjob .................................................................................................................... 54
4.5.5 Interface graphique de CACTI.................................................................................................................... 54

4.6 Utilisation de CACTI ..................................................................................................................... 58

4.6.1 Présentation des menus de CACTI ............................................................................................................. 58
4.6.2 Création des graphes ................................................................................................................................... 58
4.6.3 Extrait de graphe ......................................................................................................................................... 61

4.7 Avantages et inconvénients ............................................................................................................ 62

4.7.1 Avantages ..................................................................................................................................................... 62
4.7.2 Inconvénients ............................................................................................................................................... 63

4.8 Conclusion ....................................................................................................................................... 64

CONCLUSION GENERALE .................................................................................................................... 65
ANNEXE 1 : FORMAT DES MESSAGES SNMP .................................................................................. 66
ANNEXE 2 : EXTRAIT DES RFCs .......................................................................................................... 70
ANNEXE 3 : QUELQUES RFC ................................................................................................................ 72
BIBLIOGRAPHIE ...................................................................................................................................... 73
FICHE DE RENSEIGNEMENTS ............................................................................................................. 75
RESUME ...................................................................................................................................................... 76
ABSTRACT ................................................................................................................................................. 76

v
 ABREVIATIONS

ANS.1 Abstract Syntax Notation One

AT Address Translation
CMIP Common Management Information Protocol
CMIS Common Management Information Service
CMOT Common Management information protocol Over TCP/IP
CPU Central Processing Unit
DCE Distributed Computing Environment
DES Data Encryption Standard
DME Distributed Management Environment
DOD Departement Of Service
DSI Direction des Systèmes d'Information
EON EyesOfNetwork
GED Generic Event Dispatcher
GPL General Public Licence
HNM Hierarchical Network Management
HP/OV Hewlett Packard Open View
HTTP Hypertext Transfer Protocol
IBM International Business Machines Corporation
IETF Internet Engineering Task Force
IP Internet Protocol
ISO International Standard Organisation
ITIL Information Technology Infrastructure Library
ITU International Telecommunication Unit
JSON Java Script Object Notation
LAN Local Area Network
LILO Last InLast Out
Mbd Management by delegation
MIB Management Information Base
MRB Management Request Broker
MRTG Multi Router Traffic Grapher

vi
NDO Nagios Data Out
NMA Network management Application
NME Network Management Entity
NMS Network Management System
NNM Network Node Manager
NPC Nagios Plugin for Cacti
NRPE Nagios Remote Plugin Executor
NSCA Nagios Service Check Acceptor
OSF Open Software Foundation
PgSQL Postgre Structured Query Language
PHP Hypertext Preprocessor
RFC Request For Comments
RRA Round Robin Archive
RRD Round Robin Database
SGBD Système de Gestion de Base de données
SMI Structure of Management Information
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
SQL Structured Query Language
SSH Secure Shell
SSL Secure Socket Layer
TCP/IP Transfert Control Protocol /Internet Protocol
UDP User Datagram Protocol
WAN Wide Area Network

vii
 INTRODUCTION GENERALE

Dans le domaine des entreprises modernes, l’adoption d’un système d’information facilite
énormément les processus d’administration du personnel, des matériels et de la productivité. Un
tel outil aide à bien satisfaire les exigences croissantes non seulement des administrateurs, mais
aussi des utilisateurs, c’est pourquoi les développeurs conçoivent ce système de telle façon que
tous les besoins soient satisfaits à travers une bonne gestion de toutes les branches de l’entreprise.

En effet, toutes les entreprises, de nos jours, sont équipées d’un réseau local ou LAN (Local Area
Network) au minimum, et pour les plus importantes d’entre elles de réseaux longue distance ou
WAN (Wide Area Network), leurs parcs informatiques englobent des centaines, voire des milliers
de terminaux engendrés par des serveurs de bases de données et des serveurs de traitements.

L’apparition de ces nouveaux environnements informatisés rend la surveillance des éléments clefs
du réseau et du système une opération indispensable, afin de minimiser la perte d’exploitation et
garantir que les utilisateurs ne s’aperçoivent pas des anomalies de fonctionnement. Ces anomalies
provoquent des conséquences variables en degré pour le fonctionnement au niveau de système
d’entreprise. En effet, l’arrêt d’un service de messagerie n’est pas aussi couteux que la perte de la
base de données de son entreprise due à un disque défectueux.

Vu que le système informatique est au cœur des activités d’entreprise, sa maitrise devient
primordiale, puisque, il doit fonctionner pleinement et en permanence pour garantir la fiabilité et
l’efficacité exigées, d’une part. D’autre part, les problèmes liés au système informatique tels que
les défaillances, les pannes, les coupures et les différents problèmes techniques doivent être
réduits, du fait qu’une indisponibilité du système ou du réseau peut causer des pertes
considérables.

Afin de minimiser le nombre de ces pertes, une surveillance et un contrôle s’avèrent obligatoire.
La notion de la « supervision informatique » fût apparue et devenue une tâche vitale pour tout
système informatique. D’où le titre de ce mémoire : « MISE PLACE D’UN SERVEUR DE
SUPERVISION UTILISANT CACTI SOUS REDHAT / LINUX ». La supervision
système/réseau doit assurer trois fonctionnalités :

1
 garantir la disponibilité de leurs système et réseau ;
tenter de prévenir en cas de problème ;
garantir une durée d’intervention et de résolution minimale.

Pour commencer, nous allons voir ce qu’est la supervision informatique. Après cela, nous verrons
les protocoles utilisés pour la gestion de réseau. Et ensuite, nous allons illustrer quelques outils de
supervision informatique. Et avant de conclure, nous essayerons de réaliser un serveur de
supervision utilisant CACTI.

2
 CHAPITRE 1
LA SUPERVISION INFORMATIQUE

1.1 Introduction

La gestion d'un parc informatique est un travail permanent. Un bon administrateur système doit
savoir à tout moment l'état des différents équipements et des différents services.

Cependant, l'administrateur ne peut pas se permettre de passer son temps devant un tableau avec
des voyants verts en attendant qu'un voyant passe au rouge pour agir, il est occupé à d'autres
tâches, donc il ne peut pas surveiller les statuts des machines en permanence. L'examen quotidien
des logs systèmes est un bon début, mais, si un problème survient, on s'en rend compte seulement
le lendemain, ce qui peut être trop tard.

Pour simplifier leur travail, les administrateurs utilisent généralement ce qu’on appelle un
« moniteur de supervision informatique » [1], un tel moniteur permet d'avoir une vue globale du
fonctionnement de réseau ainsi que du niveau de performances des systèmes, et d’alerter par
différents moyens l’apparition d’une anomalie.

Dans ce chapitre, nous allons présenter les notions de base concernant la supervision informatique.

1.2 Définition

La supervision informatique désigne un ensemble de concepts recouvrant la surveillance du bon

fonctionnement des systèmes informatiques dans un parc [2].

Entre outre, elle consiste à indiquer l’état d’un serveur, d’un équipement réseau ou d’un service
software pour anticiper les plantages ou diagnostiquer rapidement une panne.

1.3 Intérêt et Rôle

Le concept de supervision réseau est né au début des années 1980, lors de la croissance importante
de mises en place de réseaux informatiques dans les entreprises. La taille grandissante de ceux-ci
ainsi que leur hétérogénéité posaient un réel problème de gestion et d’administration, multipliant
les besoins en main d’œuvre d’experts administrateurs. C’est donc à cette époque qu’ont été
menées les premières réflexions sur un nouveau concept, celui de la supervision.

3
La supervision doit permettre de gérer les anomalies (détection et résolution des problèmes), les
configurations (inventaire, configuration matérielle et logicielle), les performances (évaluer les
comportements et optimiser le fonctionnement), la sécurité (filtrage des accès, redondance des
équipements, sauvegarde) et la comptabilité (déterminer l’utilisation et le coût de ressources
réseau). La supervision doit correspondre à un système réactif et proactif.

1.4 Mode de fonctionnement

Plusieurs actions sont ainsi réalisées : acquisition de données, analyse, puis visualisation et
réaction. Un tel processus est réalisé à plusieurs niveaux d'un parc de machines :

au niveau interconnexions (Réseau),

au niveau de la machine elle-même (Système),
au niveau des services offerts par cette machine (Applications).

1.4.1 Supervision réseau

Par le terme réseau on entend ici l'aspect communication entre les machines. Le rôle est de
s'assurer du bon fonctionnement des communications et de la performance des liens (débit,
latence, taux d'erreurs). C'est dans ce cadre que l'on va vérifier par exemple si une adresse IP est
toujours joignable, ou si tel port est ouvert sur telle machine, ou faire des statistiques sur la latence
du lien réseau.

1.4.2 Supervision système

La surveillance se cantonne dans ce cas à la machine elle-même et en particulier l’utilisation de

ses ressources : le processeur, la mémoire vive et le stockage ou disque dur. Si l'on souhaite par
exemple contrôler la mémoire utilisée ou la charge processeur sur le serveur on analyse les
fichiers de logs système.

1.4.3 Supervision applicative

Cette technique est plus subtile, c'est elle qui va nous permettre de vérifier le fonctionnement
d'une application lancée sur une machine. Cela peut être par exemple une tentative de connexion
sur le port de l'application pour voir si elle retourne ou demande bien les bonnes informations,
mais aussi de l'analyse de logs applicatifs.

4
En effet, rien ne garantit qu'un port X ouvert veuille dire que l'application qui tourne derrière n'est
pas plantée.

Figure 1.01 : Mode de fonctionnement d’une supervision

1.5 Architecture d’administration

Le figure 1.02 donne une architecture classique d'administration appelé le modèle Gérant/ Agent
(Manager/Agent). Le système est composé d'une entité d’administration et des entités de gestion
NME (Network Management Entity) qui sont géré par cette entité et un protocole pour la gestion
comme CMIP (Common Management Information Protocol) ou SNMP (Simple Network
Management Information Protocol).

Figure 1.02 : Elément du système de gestion de réseau

5
Chaque entité dans le réseau a un Agent pour l’opération de gestion, une base de données stockées
dans un MIB et assume les travaux ci-dessous :

Collecter des informations statistiques concernant la communication, les opérations de

réseau.
Stocker les informations localement dans une base de données.
Répondre les commandes de l’entité de contrôle de réseau, inclus : Transmet des
informations statistiques à l’entité d’administration de réseau, modifie les paramètres,
donne des informations d’état…

L’entité d’administration a une entité de gestion NME et aussi un logiciel pour gérer le réseau
appelé NMA (Network Management Application). Ce dernier contient une interface permettant à
l’administrateur de faire des opérations de gestion.

1.6 Architecture des systèmes de gestion

Il existe trois approches de base pour les architectures des systèmes de gestion des réseaux [3]:

Approche centralisée,
Approche hiérarchique,
Approche distribuée

1.6.1 Approche centralisée

Cette approche consiste à faire remonter toutes les informations de gestion de chaque ressource du
réseau vers un point central qui les analyse et décide de l'opération à entreprendre. Chaque
ressource est représentée par un programme appelé agent. Ce dernier communique les
informations sur l'état de la ressource à la station de gestion ou manager (voir Figure 1.03).

6
 Figure 1.03 : Architecture centralisée

Dans l'approche centralisée, il existe une autre variante qui consiste à subdiviser le gestionnaire en
deux parties :

une plate-forme de gestion,

des applications de gestion.

1.6.1.1 La plateforme de gestion

La plate-forme assure le regroupement et le traitement élémentaire des informations de gestion du

réseau. Elle rend transparente l'utilisation des protocoles de communication pour les applications
de gestion.

1.6.1.2 Les applications de gestion

Les applications de gestion utilisent les services offerts par la plate-forme pour réaliser les
fonctions avancées de la gestion du réseau.

7
 Figure 1.04 : Approche centralisée basé sur une plateforme de gestion

1.6.2 Architecture hiérarchique

La figure 1.05 décrit cette approche qui utilise le concept gestionnaire des gestionnaires. Dans ce
concept, chaque gestionnaire est responsable de la gestion de son domaine, lequel est constituée
d'un ensemble d'agents. Les gestionnaires de domaine ne communiquent pas directement entre eux
; ils communiquent uniquement avec le gestionnaire central.

Figure 1.05 : Approche hiérarchique

8
1.6.3 Approche distribuée

Cette approche est constituée de plusieurs gestionnaires de domaine indépendants qui

communiquent entre eux pour s'échanger de l'information sur l'état du réseau. Chacun des
gestionnaires est responsable de son propre domaine (cf. Figure 1.06). Cette approche permet
d'augmenter la stabilité et la performance des systèmes de gestion des réseaux.

Figure 1.06 : Approche distribuée

1.7 Structure des systèmes de gestion des réseaux

Un système de gestion est composé d'un ensemble de logiciels et de matériels qui assurent le bon
fonctionnement du réseau. La gestion est réalisée par l'échange d'informations entre le
gestionnaire et les différentes ressources matérielles et logicielles du réseau. Il existe deux
principaux standards de systèmes de gestion des réseaux :

SNMP (Simple Network Management Protocol) de l'IETF (Internet Engineering Task

Force),
CMIP (Common Management Information Protocol) de l'ISO (International Organization
for Standardization).

Ces deux standards sont décrits dans le second chapitre.

Pour mieux décrire l'architecture de ces systèmes de gestion, nous allons le décomposer en trois
modèles distincts [4] :

9
 le modèle informationnel,
le modèle de communication,
le modèle organisationnel.

Ces modèles englobent les parties essentielles d'un système de gestion des réseaux.

1.7.1 Le modèle informationnel

Ce modèle fournit une vue du réseau par les données et structure l'information de gestion. Ces
informations définissent les besoins de gestion des ressources matérielles et logicielles existantes
sur le réseau. Elles sont stockées dans une base de données appelée MIB (Management
Information Base cf. 2.4.6).

Au niveau de la normalisation, l'ISO définit ces informations de gestion comme des objets stockés
dans une MIB. Ces objets sont définis selon le sens du concept orienté objet. Par contre, l'IETF
représente ces informations de gestion à travers des variables stockées dans une base de données
virtuelle. Le modèle informationnel constitue la base sur laquelle reposent les deux prochains
modèles.

1.7.2 Modèle de communication

Ce modèle décrit comment l'information de contrôle est acheminée entre les entités de gestion. Il
fournit les moyens de recueillir des informations élémentaires ou statistiques auprès des agents
représentant les ressources. Pour cela, l'ISO a défini le protocole CMIP et l'IETF a défini le
protocole SNMP.

1.7.3 Modèle organisationnel

Ce modèle définit les entités de gestion qui échangent des informations de contrôle en utilisant le
modèle de communication. Il repose essentiellement sur le concept de la relation
gestionnaire/agent. Le gestionnaire et l'agent sont des processus qui échangent des informations de
gestion à travers un protocole de communication. Chaque agent gère sa propre MIB sur laquelle le
gestionnaire peut agir. Ce concept de gestionnaire/agent est repris par tous les organismes de
normalisation.

10
1.8 Les approches décentralisées de la gestion des réseaux

Les approches décentralisées consistent à répartir les tâches de gestion entre les différentes entités
qui interviennent dans la gestion d'un réseau. Ces entités coopèrent entre elles pour accomplir ces
tâches. Chaque entité est autonome et peut assurer un traitement particulier.

Le passage vers l'approche décentralisée permet d'assurer l'autonomie, l'évolution et l’ouverture

des systèmes de gestion des réseaux. Pour cela, plusieurs architectures ont été proposées. Parmi
les plus importantes, nous présentons les architectures :

Distributed Management Environment,

Hierarchical Network Management,
Management by delegation

1.8.1 Distributed Management Environment

L'architecture DME (Distributed Management Environment) est proposée par l'OSF (Open
Software Foundation) [5]. Elle définit une norme pour le développement d'applications de gestion
qui concernent aussi bien la gestion des logiciels, des systèmes et des services, que la gestion des
unités de traitement réparties.

L'architecture DME offre un certain nombre de composants de base intègres et réutilisables. Ces
composants constituent un environnement de développement d'applications de gestion. DME est
composée de deux parties essentielles : le MRB (Management Request Broker) et les objets
serveurs (figure 1.07). Le MRB est la pièce centrale de l'architecture DME. Il implante une API de
base qui accède aux services fournis par DME.

Le MRB fournit une interface de programmation normalisée pour utiliser les protocoles SNMP et
CMIP à travers une API. Il fournit également des mécanismes d'appel des méthodes associées à un
objet DME. Ce dernier est utilisé pour la modélisation des ressources à gérer et pour la
modélisation des applications de gestion.

11
 Figure 1.07 : Architectures DME

L'objet serveur de DME offre des opérations qui permettent l'accès aux données enregistrées dans
cet objet, de même que la création et la suppression des instances de cet objet. A chaque fois que
le MRB reçoit un message, il le transmet à l'objet serveur qui est associé à l'objet spécifié. La
localisation des objets DME sur le réseau se fait par l'intermédiaire du service Répertoire de DCE
(Distributed Computing Environment) [6].

1.8.2 Hierarchical Network Management

L'architecture HNM (Hierarchical Network Management) est proposée par l'Université de Vienne
[7]. Elle utilise le concept de SubManager semblable au protocole de gestionnaire de gestionnaires
décrit dans le SNMPv2 [8].

Un SubManager est associé à un groupe d'agents. Il rassemble l'information élémentaire de ces

agents, exécute quelques traitements et produit des valeurs plus significatives qui peuvent être
employées par un gestionnaire supérieur (figure 1.08). Cette méthode réduit de manière
significative la quantité de trafic de gestion, car c'est uniquement l'information traitée qui est
envoyée au gestionnaire principal.

12
 Figure 1.08 : Architecture HNM

A chaque fois qu'on veut intégrer des fonctionnalités supplémentaires au système, des procédures
Network Management Procédure (NMP) peuvent être chargées d'une manière dynamique sur le
SubManager. Ces procédures sont enregistrées dans deux tables (subMgrEntry et subMgrOps) de
SubManager. Chaque procédure est lancée périodiquement et un processus est créé. Le processus
exécute la procédure et enregistre le résultat dans la table subMgrValue qui est lue par le
gestionnaire.

1.8.3 Management by delegation

L'architecture Mbd (Management by delegation) est proposée par l'Université de Californie [9].
Elle définit un modèle plus flexible qui utilise le concept du serveur élastique dont la
fonctionnalité peut être étendue au moment de l'exécution. Cela se fait en déléguant de nouvelles
procédures fonctionnelles au serveur.

Dans l'approche Mbd, au lieu d'apporter les données de la ressource gérée vers l'application de
gestion, les applications sont déléguées aux ressources gérée et exécutées dans le même
environnement que les données. Le gestionnaire (delegator entity) emploie un protocole de

13
délégation pour télécharger et contrôler un programme déléguée voire dans (la figure 1.09). Ce
dernier peut être délégué à une ressource gérée au démarrage, de telle sorte que la ressource
assume les responsabilités d'autonomie. L'architecture Mbd n'exige pas un modèle sémantique
uniforme des données de la ressource gérée, ce qui résout le problème d’hétérogénéité entre les
différentes ressources du réseau et élimine les limites du développement d'applications de gestion.

Figure 1.09 : Architecture Mbd

L'architecture Mbd peut inter opérer avec les protocoles existants SNMP et CMIP. Elle étend les
capacités de ces protocoles en ajoutant des fonctionnalités supplémentaires aux ressources gérées ;
par exemple, une ressource qui supporte le protocole SNMP peut évoluer pour supporter des accès
de CMIP.

L'utilisation du Mbd permet à des ressources du réseau d'acquérir des capacités de gestion
d'autonomie locale. Cela leur permet d'assurer une gestion entièrement autonome en cas de perte
de communication avec le gestionnaire.

1.8.4 Résumé des architectures DME, HNM et Mbd

Les architectures DME, HNM et Mbd proposent de nouvelles approches des systèmes de gestion
des réseaux. Elles assurent une indépendance vis-à-vis des protocoles de gestion des réseaux,

14
assurent l'expansibilité des fonctionnalités du système de gestion et délèguent des tâches de
gestion aux ressources gérées. La complexité de ces architectures ne leur a pas permis d'être
adoptées par l'industrie informatique, ce qui a limité leur développement.

1.9 Principe général

Sur le point de l’administration, un réseau informatique se compose d’un ensemble d’objets qu’un
système d’administration surveille et contrôle. Chaque objet est géré localement par un processus
appelé agent qui transmet régulièrement ou sur sollicitation les informations de gestion relatives à
son état et aux événements qui le concernent au système d’administration.

Le système d’administration comprend un processus managé qui peut accéder aux informations de
gestion de la MIB locale via un protocole d’administration comme SNMP ou CMIP de qui le met
en relation avec les divers agents.

Le principe se repose donc sur les échanges :

D’une part, entre une base d’informations appelée MIB et l’ensemble des éléments
administrés (objets) ;
D’autre part, entre les éléments administrés et le système d’administration.

Figure 1.10 : Structure fonctionnelle d’une administration réseau

15
1.10 Conclusion

Le domaine de la supervision est un domaine important de l’administration systèmes et réseaux.

Les systèmes informatiques étant de plus en plus complexes, leur surveillance et la localisation
des problèmes deviennent de plus en plus ardus pour l’administrateur réseaux et systèmes. La
pression est d’autant plus forte que les entreprises ou organismes s’appuient sur le système
d’information pour leur activité, demandant ainsi une très grande réactivité de la part de
l’administrateur. Il lui faut donc automatiser la surveillance de son système.

16
 CHAPITRE 2
LES PROTOCOLES DE GESTION DE RESEAU

2.1. Le modèle OSI

Le modèle OSI (Open Systems Interconnection) a été développé en 1978 par l’ISO (International
Organisation of Standard) afin que soit défini un standard utilisé dans le développement de
système ouvert. Les réseaux s’appuyant sur les spécifications de l’OSI « parlent le même
langage », c’est-à-dire qu’ils utilisent des méthodes de communication semblable pour échanger
des données [10].

Le modèle comporte sept couches succinctement présentées dans 2.1.1. Ces couches sont parfois
réparties en deux groupes :

Les quatre couches inférieures sont plutôt orientées communication et sont souvent
fournies par un système d'exploitation
Les trois couches supérieures sont plutôt orientées application et plutôt réalisées par des
bibliothèques ou un programme spécifique. Dans le monde IP, ces 3 couches sont rarement
distinguées. Dans ce cas, toutes les fonctions de ces couches sont considérées comme
partie intégrante du protocole applicatif.

2.1.1 Les sept couches du modèle OSI

Application,
Présentation,
Session,
Transport,
Réseau,
Liaison de données,
Physique.

Chacune de ces sept couches est spécialisée dans une tâche bien précise [11]. Les données de
l’ordinateur émetteur traversent chacune de ces sept couches (de haut en bas) avant d’être
transmises au support de communication, puis, arrivées à la destination, les trames traversent
chacune de ces sept couches (de bas en haut) avant d’être communiquées à l’ordinateur récepteur.

17
Voici les sept différentes couches avec leurs caractéristiques en partant du niveau le plus bas :

2.1.1.1 Couche physique

La couche physique est chargée de la transmission effective des signaux entre les interlocuteurs.
Son service est limité à l'émission et la réception d'un bit ou d'un train de bit continu (notamment
pour les supports synchrones).

2.1.1.2 Couche liaison de données

La couche liaison de données gère les communications entre 2 machines adjacentes, directement
reliées entre elles par un support physique.

2.1.1.3 Couche réseau

La couche réseau gère les communications de proche en proche, généralement entre machines :
routage et adressage des paquets.

2.1.1.4 Couche transport

La couche transport gère les communications de bout en bout entre processus (programmes en
cours d'exécution).

2.1.1.5 Couche session

La couche session gère la synchronisation des échanges et les « transactions », permet l'ouverture
et la fermeture de session.

2.1.1.6 Couche présentation

La couche présentation est chargée du codage des données applicatives, précisément de la

conversion entre données manipulées au niveau applicatif et chaînes d'octets effectivement
transmises.

2.1.1.7 Couche application

La couche application est le point d'accès aux services réseaux, elle n'a pas de service propre
spécifique et entrant dans la portée de la norme.

18
 Figure 2.01 : Les 7 couches du modèle ISO

2.1.2 La norme ISO 7498/4

L’ISO s’intéresse de près à la supervision. Et, dès 1988, l’organisme publie la norme ISO7498/4
définissant les principales fonctions que doivent implémenter les systèmes de supervision et
d’administration. Ces fonctions sont les suivantes [12]:

Gestion des performances ;

Gestion des configurations ;
Gestion de la compatibilité ;
Gestion des anomalies ;
Gestion de la sécurité.

2.1.2.1 Gestion des performances

La gestion des performances analyse de manière continue les performances du réseau afin de le
maintenir dans un état de performance acceptable. Cette gestion s’opère en trois étapes :

19
 Tout d’abord, des variables contenant des informations significatives quant aux
performances du réseau sont récupérées. Parmi celles-ci on peut citer le temps de réponse
d’une station utilisateur ou encore le taux d’occupation d’un segment réseau.
Une fois ces variables obtenues, elles sont analysées. Si elles dépassent un seuil de
performance fixé préalablement, une alarme est tout de suite envoyée à l’administrateur
du réseau, pour régler le problème au plus vite.
Ces variables de gestion de performances sont réactualisées à court intervalle de temps
dans le but d’être le plus réactif possible au moindre embryon de baisse de performance.

La gestion des performances permet donc une évaluation du comportement des ressources et un
contrôle de l’efficacité des activités de communication.

2.1.2.2 Gestion des configurations

La gestion des configurations effectue un suivi des différentes configurations des éléments
présents sur le réseau. Elle stocke dans une base de données les versions des systèmes
d’exploitation et des logiciels installés sur chaque machine du parc réseau. Par exemple pour un
ordinateur du réseau, la base contiendra la version de son système d’exploitation, du protocole
TCP/IP, etc.

La gestion des configurations permet donc une identification et un contrôle des systèmes ouverts.
Elle collecte et fournit des informations sur les différents systèmes du réseau.

2.1.2.3 Gestion de la comptabilité

La gestion de la comptabilité a pour but de mesurer l’utilisation des ressources afin de réguler les
accès et d’instaurer une certaine équité entre les utilisateurs du réseau. Ainsi des quotas
d’utilisation peuvent être fixés temporairement ou non sur chacune des ressources réseaux. De
plus, la gestion de la comptabilité autorise la mise en place de systèmes de facturation en fonction
de l’utilisation pour chaque utilisateur.

La gestion de la comptabilité permet donc un établissement des coûts d’utilisation ainsi qu’une
facturation de l’utilisation des ressources.

20
2.1.2.4 Gestion des anomalies

La gestion des anomalies détecte les problèmes réseaux que ce soient logiciels ou matériels. Elle
essaie d’isoler le plus précisément le problème en effectuant divers tests. Quand cela est possible,
elle règle elle-même automatiquement l’anomalie. Sinon, elle alerte les personnes concernées par
le type du problème afin de solliciter leur intervention. La gestion des anomalies garde dans une
base de données l’ensemble des problèmes survenus ainsi que leur solution, de manière à être
encore plus efficace face à un incident récurrent. Cette fonction de la norme ISO7498/4 demeure
de loin la fonction la plus implémentée à ce jour.

La gestion des anomalies détecte donc et corrige les fonctionnements anormaux des éléments du
réseau.

2.1.2.5 Gestion de la sécurité

La gestion de la sécurité contrôle l’accès aux ressources en fonction des politiques de droits
d’utilisation établies. Elle veille à ce que les utilisateurs non autorisés ne puissent accéder à
certaines ressources protégées.

La gestion de la sécurité met donc en application les politiques de sécurité.

2.1.2.6 Structure de gestion des réseaux

Après avoir défini les fonctionnalités de la supervision réseau, l’ISO s’est attaché à décrire la
structure de la gestion des réseaux (Network Management System).

L’ISO propose d’installer un agent de gestion sur chaque machine supervisée, comme le montre la
figure 2.02:

21
 Figure 2.02 : Système de gestion de réseau

Cet agent récupère périodiquement et stocke localement des informations sur la machine sur
laquelle il tourne. Quand il détecte un problème, il le signale au service de gestion centralisé. Le
service de supervision, en fonction de la nature de l’anomalie, prend un ensemble de décisions
dont une bonne partie est transmise à l’agent de gestion présent sur la machine en difficulté.
L’agent exécute alors l’ensemble des actions réparatrices demandées par le superviseur afin de
remettre la machine en état.

Toutefois, le service central de supervision ne reste pas inactif en attendant que ses agents lui
rapportent des problèmes. Il peut en effet questionner régulièrement ses agents, par le biais de
requêtes, pour connaître l’état complet d’une machine, et par addition, l’état de l’ensemble du
réseau.

Les objets stockés dans les bases de données des agents sont normalisés au format ASN.1
(Abstract Syntax Notation One). Ces bases de données ont aussi été normalisées par l’ISO. Elles
sont appelées bases de données MIB.

Pour transmettre les différents messages échangés entre l’agent de supervision et le superviseur,
un protocole réseau de couche OSI a été défini par l’ISO : le protocole CMIP.

22
En effet, les travaux de l’ISO sur la supervision restent trop complets et complexes à mettre en
œuvre. Ils ont toutefois eu le mérite de poser un cadre clair à la supervision réseau.

2.2 Le protocole CMIP

Le protocole CMIP ou Common Management Information Protocol est un protocole

d’administration de réseau [13], qui supporte l’échange d’informations entre l’application
d’administration et les agents d’administration.

SNMP a été développé comme solution de transition plus simple de CMIP/CMIS en attendant que
le support logiciel CMIP/CMIS soit suffisant. SNMP est amené à disparaître dès la généralisation
de CMIP/CMIS, qui représente l’entité à administrer. Ces objets peuvent être modifiés ou
contrôlés et ils peuvent être utilisés pour effectuer des tâches sur l’agent administré.

Le protocole CMIP est un protocole largement utilisé dans le domaine de télécommunication.

Cependant, ce protocole consomme beaucoup de ressources sur le système administré, ce qui fait
que ce protocole n’est pas très largement diffusé. De plus, le protocole CMIP est défini pour
fonctionner sur la pile du protocole OSI. Cependant, le standard utilisé de nos jours dans la
majorité des environnements de réseau locaux est le protocole TCP/IP. Pour preuve du succès de
SNMP, la plupart des équipements actifs l’implémente seul le protocole SNMP.

Figure 2.03 : Architecture du système de gestion OSI

23
CMIS définit plusieurs services dont :

Des services de demande d’un gérant à un agent pour la création (M-CREATE) ou la

destruction (M-DELETE) d’informations concernant des objets de gestion, signalisation
faite par un agent à un gérant par rapport aux changements d’état d’un objet (M-EVENT-
REPORT), mettre à jour une information (M-SET), obtenir une valeur (M-GET).
Des services concernant les mises en relation entre SMAE pour l’échange d’informations
notamment l’initialisation (M-INITIALIZE), la fermeture (M-TERMINATE).
Des services d’annulation (M-ABORT)…

2.3 Le modèle TCP/IP

Un protocole de communication est un ensemble de règles permettant à plusieurs ordinateurs de

dialoguer entre eux. TCP/IP (Transmission Control Protocol/Internet Protocol) est un des langages
utilisés dans les réseaux. Le terme TCP/IP n’est pas limité à l’expression Transmission Control
Protocol/Internet Protocol [10]. TCP recouvre toute une famille de protocoles comme UDP (User
Datagram Protocol), FTP (File Transfert Protocol), Telnet (Terminal Emulator Protocol), http
(,Hypertext Transfert Protocol), etc.

2.4 Le protocole SNMP

2.4.1 Définition

Le SNMP c’est l’acronyme de Simple Network Management Protocol qui se traduit par Protocole
Simple de Gestion de Réseau. Il s'agit d'un simple protocole qui permet aux administrateurs
réseaux/système de gérer, superviser et diagnostiquer les matériels informatique en réseau à
distance [14].

2.4.2 Principe de fonctionnement

Avec le protocole SNMP, le système de gestion de réseau est basé sur trois éléments principaux :
les nœuds gérés, l’agent et un superviseur.

2.4.2.1 Les équipements gérés

Les équipements managés sont des éléments du réseau (ponts, switches, hubs, routeurs ou
serveurs), contenant des « objets de gestion » pouvant être des informations sur le matériel, des
éléments de configuration ou des informations statistiques.

24
2.4.2.2 L’agent

Les agents sont des entités qui se trouvent au niveau de chaque interface qui connecte
l’équipement managé au réseau et qui permette de récupérer des informations sur différents
équipements tels que les switchs, les hubs, les routeurs et les serveurs contenant des objets
gérables via SNMP.

2.4.2.3 Le superviseur

Le superviseur est la console qui permet à l'administrateur réseau d'exécuter des requêtes de
management.

Figure 2.04 : Architecture SNMP

SNMP permet le dialogue entre le superviseur et les agents afin de recueillir les objets souhaités
dans la MIB.

Un grand nombre de logiciels libres et propriétaires utilisent SNMP pour interroger régulièrement
les équipements et produire des graphes rendant compte de l’évolution des réseaux ou des
systèmes informatiques (NetCrunch 5, MRTG, Cacti, Nagios, Zabbix, The Dude, ...).

2.4.3 Le protocole

Une requête SNMP est un datagramme UDP habituellement à destination du port 161 de la
machine surveillée. La réponse, quant à elle, est envoyée vers le port 162 du superviseur [10].

Les commandes utilisées dans les requêtes et réponses sont indiquées dans le Tableau 2.01. Il est
possible de lire et de modifier les données sur la machine distante.

25
 Commande Action

get-request Le Superviseur SNMP demande une information à un agent SNMP

get-next-request Le Superviseur SNMP demande l’information suivante à l’agent SNMP

set-request Le Superviseur SNMP met à jour une information sur un agent SNMP
get-reponse L’agent SNMP répond à un get-request ou à un set-request

trap L’agent SNMP envoie une alarme au Superviseur

Tableau 2.01 : Liste des commandes acceptées dans la version 1 de SNMP.

2.4.4 Interrogation d’un agent

Le superviseur a généralement accès à une série de commandes en ligne permettant d’interroger

les agents, dont le nom commence par snmp :

récupérer les informations provenant d’un agent par l’utilisation de requêtes simples
(snmpget, snmpgetnext) ou multiples (snmpwalk, snmptable, snmpdelta) ;
manipuler la configuration du matériel (snmpset) ;
récupérer un groupe d’informations donné (snmpdf, snmpnetstat, snmpstatus) ;
convertir les identifiants de la MIB de la forme numérique vers la forme textuelle et
inversement, afficher le contenu de la MIB et sa structure (snmptranslate).

Par exemple, si on veut connaître depuis combien de temps le serveur fonctionne (ou uptime), on
fait la requête suivante :

[root@localhost usr]# snmpget -v 1 -c public localhost

\.1.3.6.1.2.1.1.3.0

Et la réponse obtenue est :

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (113531256) 13

days, 3:21:52.56

Une autre forme de cette requête est :

[root@localhost usr]# snmpget -v 1 -c public localhost

\.iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0

26
Et la réponse obtenue est :

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (113539659) 13

days, 3:23:16.59

La première forme utilise une expression numérique .1.3.6.1.2.1.1.3.0 et la deuxième

une expression textuelle. On voit que les deux formes numérique et textuelle sont équivalentes.
Ceci est vérifiable par l’expression de la Figure 2.06.

Le fonctionnement, relativement simple, est résumé sur la figure 2.05 : l’agent n’envoie ou ne
modifie les informations qu’à la demande du superviseur. En cas de problème, il est possible pour
l’agent d’envoyer une alerte ou « trap » au superviseur mais il n’attend pas d’acquittement.

Figure 2.05 : Fonctionnement de SNMP

2.4.5 Evolution des versions de SNMP

SNMP existe au moins en trois versions : 1, 2 et 3 ; la version 1 étant la plus ancienne. Voici les
différentes versions de SNMP [15] :

2.4.5.1 SNMPv1

Ceci est la première version du protocole, définie dans le RFC (Request For Comments) 1157. On
dit que la sécurité de cette version est triviale, car la seule vérification qui est faite est basée sur la
chaîne de caractères " community ".

27
SNMPsec (historique): Cette version ajoute de la sécurité au protocole SNMPv1. La sécurité est
basée sur des groupes. Très peu ou aucun manufacturier n'a utilisé cette version qui est maintenant
largement oubliée. La première version est décrite dans le RFC 1155.

2.4.5.2 SNMPv2p

Beaucoup de travaux ont été exécutés pour faire une mise à jour de SNMPv1. Ces travaux ne
portaient pas seulement sur la sécurité. Le résultat est une mise à jour des opérations du protocole,
des nouvelles opérations, des nouveaux types de données. La sécurité est basée sur les groupes de
SNMPsec.

2.4.5.3 SNMPv2c

Cette version du protocole est appelé " community stringbased SNMPv2 ". Ceci est une
amélioration des opérations de protocole et des types d'opérations de SNMPv2p et utilise la
sécurité par chaîne de caractères "community " de SNMPv1 selon le RFC - 1441

2.4.5.4 SNMPv2u

Cette version du protocole utilise les opérations, les types de données de SNMPv2c et la sécurité
basée sur les usagers.

2.4.5.5 SNMPv2*

Cette version combine les meilleures parties de SNMPv2p et SNMPv2u. Les documents qui
décrivent cette version n'ont jamais été publiés dans les RFC. Des copies de ces documents
peuvent être trouvées sur le site web et SNMP Research.

2.4.5.6 SNMPv3

Cette version est décrite dans le RFC 3411; elle comprend une combinaison de la sécurité basée
sur les usagers et les types et les opérations de SNMPv2p, avec en plus la capacité pour les "
proxies ". La sécurité est basée sur ce qui se trouve dans SNMPv2u et SNMPv2*.

28
2.4.6 La MIB

La MIB ou Management Information Base se traduit par base d'information pour la gestion du
réseau.

C’est un ensemble d'informations structurées sur une entité réseau, par exemple un routeur, un
commutateur ou un serveur [16].

Pour que SNMP fonctionne, il faut une standardisation des informations que ce protocole peut
transporter : ces informations sont stockées dans une MIB.

La MIB se présente comme une base de données normalisée, qui permet de lire et d’écrire sur les
équipements distants, de façon également normalisée. Ce sera à l’agent lui-même de faire la
traduction entre les informations transmises par SNMP et la plate-forme.

Elle est organisée hiérarchiquement, comme montré sur la figure 2.06. Chaque nœud ou feuille de
l’arbre est situé par un index, cette numérotation étant normalisée. Pour rendre cet arbre plus
lisible, les nœuds possèdent un nom, cette nomenclature étant elle-même normalisée.

Elle contient une partie commune à tous les agents SNMP en général, une partie commune à tous
les agents SNMP d’un même type de matériel et une partie spécifique à chaque constructeur.

On peut lire la MIB en faisant référence aux index ou aux noms : interroger .1.3.6.1.2.1.1.3.0 ou
.iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0 désigne la même feuille, sysUp-
TimeInstance.

29
 Figure 2.06 : Arborescence de la MIB

2.4.7 La sécurité avec SNMP

Un agent SNMP est plus ou moins finement paramétrable, suivant le système. Il est possible, par
exemple de créer des groupes de sécurité qui auront accès en lecture seule, d’autres en
lecture/écriture, d’autres encore en lecture seule, mais sur certaines branches seulement.

Chaque groupe devra disposer d’une sorte de mot de passe, appelé "community". En général, la
communauté "public" est celle qui a le droit de lecture sur les informations non sensibles.

L’inconvénient majeur est qu’avec SNMP v1, qui est actuellement la seule version vraiment
stabilisée et reconnue par tous, ce mot de passe circule en clair sur le réseau, ce qui rend dans ce
cas SNMP plus que dangereux. Les versions suivantes de SNMP corrigent ce problème majeur
[17].

30
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.

Figure 2.07: Mécanisme de Cryptage/Décryptage sur DES

2.5 Comparaison du modèle TCP/IP par rapport au modèle ISO

Tout d'abord, les points communs. Les modèles OSI et TCP/IP sont tous les deux fondés sur le
concept de pile de protocoles indépendants. Ensuite, les fonctionnalités des couches sont
globalement les mêmes [18].

Au niveau des différences, on peut remarquer que : le modèle OSI faisait clairement la différence
entre trois concepts principaux, alors que ce n'est plus tout à fait le cas pour le modèle TCP/IP.
Ces trois concepts sont les concepts de services, interfaces et protocoles. En effet, TCP/IP fait peu
la distinction entre ces concepts, et ce malgré les efforts des concepteurs pour se rapprocher de
l'OSI. Cela est dû au fait que pour le modèle TCP/IP, ce sont les protocoles qui sont d'abord

31
apparus. Le modèle ne fait finalement que donner une justification théorique aux protocoles, sans
les rendre véritablement indépendants les uns des autres.

Enfin, la dernière grande différence est liée au mode de connexion. Certes, les modes orienté
connexion et sans connexion sont disponibles dans les deux modèles mais pas à la même couche :
pour le modèle OSI, ils ne sont disponibles qu'au niveau de la couche réseau (au niveau de la
couche transport, seul le mode orienté connexion n'est disponible), alors qu'ils ne sont disponibles
qu'au niveau de la couche transport pour le modèle TCP/IP (la couche internet n'offre que le mode
sans connexion). Le modèle TCP/IP a donc cet avantage par rapport au modèle OSI : les
applications (qui utilisent directement la couche transport) ont véritablement le choix entre les
deux modes de connexion.

Figure 2.08 : Comparaison du modèle TCP/IP par rapport au modèle OSI

32
2.6 Conclusion

Dans le modèle OSI, Il existe un protocole connu pour la gestion de réseaux CMIP/CMOT. C’est
un protocole orienté connexion, c’est à dire que chaque message est acquitté. CMIP est basé sur
un principe de notification et d’événement. L’avantage principal du CMIP est la sécurité, il peut
fonctionner sur des réseaux hétérogènes mais leur inconvénient est la complexité. À cause du
problème, il n’est pas utilisé largement dans la réalité.

En effet, dans le monde TCP/IP, Le protocole SNMP est un protocole simple, il garde largement
l'avantage et donc est une bonne solution pour la gestion des réseaux informatiques. Cependant, le
faiblesse dans ce protocole est la sécurité. Dans des ses dernières versions, les faiblesses sont plus
améliorées. Mais avec leurs avantages connus, SNMP est la meilleure solution pour gérer un
réseau informatique. C'est la raison pour laquelle la plupart des réseaux informatiques,
aujourd'hui, l'utilisent.

33
 CHAPITRE 3
LES OUTILS DE SUPERVISION

3.1 Introduction

Le marché de la supervision informatique déborde des logiciels de monitoring ; il en existe une

diversité, d’autres sont payants et d’autres font partie du monde libre ou on peut même trouver des
Open Source, Nous allons dans ce qui suit citer quelques-uns et nous détaillerons les plus connus
et répandus dans le milieu des entreprises.

Le marché de la supervision peut être découpé en deux grandes sous-parties :

Les offres éditeurs : qui permettent de fournir des moniteurs de supervision payants.
Les offres du monde libre : qui permettent d’avoir des moniteurs gratuits (Open-source).

3.2 Les offres éditeurs ou logiciel propriétaire:

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.

Dans ce qui va suivre, nous présenterons deux leaders des logiciels propriétaires de supervision
qui sont: HP OpenView et IBM Tivoli.

3.2.1 HP OpenView

3.2.1.1 Présentation

OpenView est le nom générique sous lequel sont regroupés un ensemble d’applications destinées à
la supervision d’un réseau informatique [19]. Elles sont organisées autour d’un produit central :
HP/OV(Hewlett-Packard OpenView) NNM (Network Node Manager) qui fournit une série
d’outils pour vérifier la configuration d’un réseau, prendre en compte des évènements, isoler les
alarmes et analyser les performances des réseaux TCP/IP. HP/OV s’appuie sur le protocole SNMP
et permet de :

34
 découvrir automatiquement les nœuds (stations) et les éléments du réseau ;
fournir une description détaillée de l’état de chaque agent SNMP du réseau à l’aide des
MIBs.

Une interface graphique permet un affichage de l’état courant des équipements en fonctions de
différentes couleurs (système de MAP). Un système d’alarme permet de synchroniser le tout avec
des déclenchements d’alarmes si un hôte change d’état ou devient injoignable, et des actions
peuvent alors être effectuées.

Ses principaux atouts sont les suivants :

Une vue globale du système d’information ;

Une vision des différents incidents ;
Un contrôle homogène des différents matériels ;

3.2.1.2 Utilisation

HP/OV Network Node Manager est utilisé pour surveiller principalement les équipements réseau
(commutateurs, …), les serveurs et les machines UNIX.

Lorsque l’on est sur l’interface du logiciel, on obtient la cartographie suivante :

Figure 3.01: Cartographie par HP OV

35
Le logiciel cartographie automatiquement le réseau et l’on retrouve notamment les sous-réseaux,
le routeur (au centre), …

Les couleurs utilisés pour la cartographie sont les suivantes :

vert : équipement connecté et administrable SNMP ;

rouge : équipement inaccessible ;
bleu : équipement qui n’est pas connu d’OpenView : soit il n’a pas encore répondu, soit il
n’est pas dans la liste de polling ;
blanc : équipement non managé.

Les stations sont représentées par des carrés cf. figure 3.02, les connecteurs par des losanges et les
sous-réseaux par des ronds (cf. figure 3.01).

Si on clique sur un sous-réseau, exemple le sous réseau 141.115.4, on obtient la Figure 3.02.

Figure 3.02 : Sous réseau 141.115.4

36
Seules les machines UNIX et les serveurs sont surveillés, les autres machines sont dîtes «
unmanaged ». Il est inutile de veiller à leur supervision selon l’administrateur, en raison par
exemple de l’arrêt et du redémarrage des machines à tous moments de la journée, et qui estime
que les utilisateurs qui ont des problèmes doivent le signaler eux-mêmes.

Après analyse des fonctions de ce logiciel, on peut résumer que cette application peut fournir
beaucoup d’informations mais nombreuses sont celles qui ne sont pas exploitées. En effet,
l’administrateur surveille principalement les équipements réseau (statuts, alarmes, …), les
serveurs (arrêt, redémarrage), c’est-à-dire les ressources communes, les stations SUN, les postes
de travail sauvegardés et les adresses IP dupliquées. HP/OV ne permet pas d’avoir une vision
simplifiée et personnalisé du réseau supervisé. Un tri des objets serait nécessaire, mais très long et
fastidieux. Par ailleurs, beaucoup d’alarmes sont remontées et seules quelques-unes ont un réel
intérêt. Pour finir, il n’y a pas moyen d’obtenir des graphes « à la demande » dans HP/OV, ce qui
crée une lacune dans la vision globale du réseau supervisé.

3.2.2 IBM TIVOLI Monitoring

Les solutions IBM Tivoli Monitoring sont conçues pour une meilleure gestion des applications en
ligne essentielles à l’entreprise en [19] :

surveillant de manière proactive les ressources système vitales ;

en détectant efficacement les goulets d’étranglement et les problèmes potentiels ;
en répondant automatiquement aux événements.

En s’appuyant sur les meilleures pratiques pour identifier et résoudre les problèmes
d’infrastructure, il a été conçu pour aider les opérateurs à surveiller et gérer les matériels et
logiciels essentiels, comprenant les systèmes d’exploitation, les bases de données et les
applications sur des environnements répartis

Ce moniteur de supervision se classe parmi les leaders du domaine, puisqu’il offre de nombreux
avantages. En effet, il :

Surveille les composants vitaux de votre infrastructure à la demande, en vous aidant à

isoler et prévenir rapidement les problèmes de performance ;

37
 Visualise les mesures de performances historiques et en temps réel sous forme de tableaux
et graphiques, avec en plus des conseils spécialisés et des actions automatiques au sein
d’IBM Tivoli Enterprise Portal ;
Consolide la surveillance et la gestion de systèmes répartis et de systèmes hôte à l’aide
d’une seule console de travail personnalisable ;
Fournit des outils de surveillance puissants et personnalisables à davantage d’opérateurs
nécessitant beaucoup moins de compétences et formation en programmation pour déployer
le produit ;
Aide à réduire les coûts opérationnels informatiques globaux en simplifiant l’installation et
la configuration, et en déployant des règles allégées avec des fonctionnalités de
surveillance automatique ;
Effectue automatiquement le suivi de l’état des principaux composants de votre
environnement informatique complexe et reçoit des alertes uniquement en cas d’incident ;
Aide à optimiser l’offre de services informatiques en intégrant des produits de gestion et
des processus informatiques pour stimuler les performances et respecter les accords de
niveau de service ;
Aide à optimiser le temps de réalisation en simplifiant l’installation et la surveillance, avec
également des fonctionnalités de gestion s’appuyant sur des technologies pointer-cliquer

3.3 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 une simple recherche sur le Net pour
se rendre compte de la multitude de projets émergeants autour de la supervision système et réseau.

3.3.1 Nagios

3.3.1.1 Présentation

Nagios (anciennement appelé Netsaint), est un logiciel libre sous licence GPL (GNU General
Public Licence) permettant la supervision système et réseau [19]. Il permet de surveiller des hôtes
et services spécifiques en indiquant leurs états en permanence.

Ce programme est dit « modulaire » et se décompose en trois parties :

Le moteur de l’application qui ordonnance les tâches de supervision ;

38
 L’interface web, qui permet d’avoir une vue d’ensemble du système d’informations et des
possibles anomalies ;
Les plugins, une centaine de petits programmes que l’on peut ajouter en fonction des
besoins en matière de supervision.

Nagios permet de superviser la plupart des services réseaux, les ressources des machines sur les
systèmes d’exploitation les plus répandus [20]. Cet outil offre la possibilité d’utiliser le protocole
SNMP pour notamment la remontée d’alarmes. Nagios est utilisable à distance via un tunnel
sécurisé (SSH Secure Shell, SSL Secure Sockets Layer). La remontée d’alarmes est entièrement
paramétrable et une alerte non acquittée est envoyée à un groupe différent (gestion des escalades).
De plus, ce logiciel permet la création d’utilisateurs pour donner des accès limités à certains
éléments.

3.3.1.2 Principe et fonctionnement

Nagios peut être vu comme un moteur d’ordonnancement de toutes les vérifications qui régissent
la supervision du réseau. Ces vérifications sont assurées par ce que l’on appelle des « greffons »
(plugins en anglais). Ceux-ci peuvent être de simples scripts qui fournissent un code retour. Les
codes sont 0 (OK), 1 (Warning), 2 (Critical) et 3 (Unknown). Ces états 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 (tests sur des protocoles réseaux tels SMTP (Simple Mail Transfer
Protocol) ou exécution à distance via SSH ou autre). Les vérifications peuvent être passives
(rarement ou dans certains cas où la sécurité impose d'interdire une connexion dans un sens, ou
encore dans le cas de supervision hiérarchique), mais le plus souvent actives.

La vérification d'un service à distance (par l'exécution d'un greffon situé sur une autre machine,
par exemple, ou par SNMP), se fait, elle aussi, par le biais de l'exécution d'un greffon local au
serveur Nagios.

NRPE (Nagios Remote Plugin Executor) permet l'exécution de plugins à distance, à choisir parmi
un certain nombre de services disponibles.

NSCA (Nagios Service Check Acceptor) permet de son côté la remontée d'informations de façon
passive (vu du point de vue de Nagios). L'ordonnancement des vérifications est assuré de façon

39
locale à chaque machine, et surtout permet d'inverser le sens des connexions entre serveur
supervisé et serveur superviseur, ce qui peut avoir un intérêt dans un réseau sécurisé, avec des
firewalls en diode (ne laissant passer les flux que dans un sens). La différence entre NRPE et
NSCA est l'initiateur de la vérification :

NRPE reçoit la demande de vérification de la part de Nagios, exécute la vérification, puis renvoie
le résultat. Avec NSCA, la vérification est planifiée en local, exécutée, puis le résultat est envoyé à
Nagios.

Figure 3.03 : Fonctionnement de NRPE

Figure 3.04 : Fonctionnement de NSCA

3.3.1.3 Utilisation

Globalement, Nagios permet par son interface graphique de visualiser les états des machines
serveurs et de vérifier le bon fonctionnement des services qu’ils offrent aux utilisateurs du réseau.
On peut également créer quelques graphes statistiques sur les états des machines ou services mais
la marge de création reste assez limitée. Il parait donc très intéressant d’y implémenter d’autres
outils comme Centreon, … ou du moins de réutiliser cet outil de supervision.

40
3.3.2 Centreon

3.3.2.1 Présentation

Centreon (anciennement appelé Oreon) est un logiciel de supervision réseau, fondé sur le moteur
de récupération d’informations Nagios [21]. Il fournit une interface simplifiée pour rendre la
consultation de l’état du système accessible à un plus grand nombre d’utilisateurs, notamment à
l’aide de graphiques.

Centreon intègre la gestion de tous les fichiers de configuration de Nagios, un module de

chargement de configuration de Nagios avec des tests de validité des configurations (debugger de
Nagios). On retrouve également des fiches d’identité serveurs/équipements réseaux regroupant les
informations de base sur ces types de ressources.

En outre, Centreon offre des représentations graphiques élaborées et personnalisables. De plus, il

comprend un système de modules qui permet l’inclusion d’autres applications et un système de
calcul de la qualité de service en temps réel. Des alertes sont émises en cas de diminution de la
qualité de service et la notification est hiérarchisée. Enfin, la gestion des accès est bien ordonnée.

3.3.2.2 Principe et fonctionnement

Une fois Nagios installé sur le serveur Linux, il faut créer une base de données pour Centreon.
Cette base de données servira à stocker les informations sur les machines supervisées par
Centreon. Le plugin NDOutils servira à écrire les données dans la base.

Nagios n’écrit pas les informations sur sa configuration dans la base de données NDO (Nagios
Data Out). C’est pour cela qu’il faut installer le plugin NDOutils.

Ce dernier est composé de deux briques : NDOMOD et NDO2DB.

Le premier prend les événements à partir du daemon Nagios (1) et les envois via un socket TCP
ou UNIX (2) vers le second (3) qui va les convertir (4) dans un format compatible avec la base de
données choisie (MySQL ou PgSQL ou PostgreSQL) (5).

41
 Figure 3.05 : Fonctionnement de NDO avec Nagios

Centreon réutilisera alors les informations de la base. L’assistant d’installation et l’interface

graphique permettent de faire le lien avec les bases de données et Nagios.

Figure 3.06 : Rôles de Centreon par rapport à Nagios

3.3.2.3 Conclusion sur Centreon

Centreon apporte des fonctions de monitoring en temps réel, de traitement des données, de
notifications et de contrôle d’accès. De plus, et c’est son rôle principal, il permet de configurer
aisément Nagios. La fonction de tracés de graphes lui permet d’être un outil de supervision mono-
site très complet.

42
3.3.3 CACTI

3.3.3.1 Présentation

Cacti est un logiciel libre de supervision réseau basé sur la puissance de stockage de données
RRDTool [22]. Il s’agit d’un outil de gestion de base de donnée RRD (Round Robin Database)
sous licence GPL qui est le standard de l’industrie open source permettant la sauvegarde haute
performance et le tracé de graphique et de données chronologiques. En outre, le principal avantage
d’une base RRD est sa taille fixe.

Cacti est considéré comme le successeur de MRTG (Multi Router Traffic Grapher) et également
comme une interface d’utilisation de RRDTool. Il permet principalement de représenter
graphiquement divers statuts de périphériques réseau en utilisant SNMP ou encore grâce à des
scripts. Les données sont récoltées auprès des différents agents SNMP grâce à un script PHP. Pour
de meilleures performances, un exécutable nommé cactid peut également effectuer les
interrogations [19].

L'intérêt de ce logiciel réside essentiellement dans son principe de « modèles » (Templates) qui
permet de créer d’une manière générique les graphiques afin de les réutiliser. D’une manière
générale, « tout » est modèle sous Cacti. Cela est avantageux lorsque de nombreuses données
identiques doivent être observées, mais cela peut se révéler fastidieux à configurer lorsque les
données sont hétérogènes. Contrairement à MRTG qui régénère l'ensemble des graphiques toutes
les 5 minutes, Cacti génère les images dynamiquement à l'affichage à partir des fichiers de
données RRDTool.

Il est également possible d'effectuer des opérations simples (et des combinaisons d'opérations)
avec les différentes données grâce à une interface graphique qui permet l'utilisation simplifiée.

3.3.3.2 Principe et fonctionnement

Cacti fonctionne selon le principe suivant : acquisition, stockage et présentation des données (voir
Figure 3.07).

43
 Figure 3.07 : Principe de fonctionnement de cacti

L’acquisition de données se fait de manière indexée ou non indexée.

« Data Input Method » permet d’acquérir une ou plusieurs valeurs numériques (par exemple, une
réponse d’un ping en ms ou un nombre d’utilisateurs connectés sur un poste) grâce à des scripts
ou des requêtes SNMP. Et cette méthode définit les sources des données.

« Data Query » liste des données (par exemple, liste d’interfaces ou de partitions) selon un index
ce qui facilite la création de graphes lorsqu’on a souvent des données similaires.

Ces dernières sont ensuite stockées dans des modèles de données (« Data Template ») qui
définissent la façon dont sont stockées les données (« Data Source ») dans les fichiers de la base
de données RRD.

Une ou plusieurs sources de données peuvent alors être stockées dans un fichier.

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…). En fait ces RRA
correspondent à des moyennes de valeurs contenues dans le fichier RRD et permettent de
visualiser les données sur différentes échelles de temps.

A noter que c’est un autre outil, le poller, qui permet de stocker les données acquises dans les
fichiers de la base RRD.

La présentation des données est réalisée sous forme de modèles graphes (« Graph template ») qui
définissent la manière dont sont présentées les données dans les graphes. Une ou plusieurs sources
de données peuvent alors être présentées dans un même graphe.

44
 Figure 3.08 : Fonctionnement détaillé de Cacti

Le but premier de Cacti est de fournir des graphes. Pour cela, les différents éléments de Cacti sont
mis en relation afin de parvenir à la création de graphes. Tout est articulé autour du Poller (voir
Figure 3.08), un script en PHP qui est soumis à un planificateur de tâches ou Cron.

Les données sont récoltées par le biais de deux méthodes différentes (Data Input Method et Data
Query) s’appuyant sur le protocole SNMP ou de simples scripts.

Puis le poller va écrire ces données dans un fichier RRD grâce à RRDTool lorsque l’utilisateur
commandera (dans l’interface graphique) la création d’une source de donnée en associant un
modèle de donnée à un hôte.

Il ne reste ensuite qu’à créer le graphe en utilisant le fichier RRD (contenant les données à
représenter sur les graphes, les RRAs) avec un modèle de graphe.

3.3.3.3 Extensions

Les utilisateurs de Cacti ont développé des plugins, c’est-à-dire toutes sortes de petits programmes
qui viennent se greffer à Cacti [23]. Ceux-ci permettent d’offrir plus de fonctionnalités.

45
 « Architecture » : améliore encore plus la structure de Cacti (créer des addons, …) ;
« Weathermap » : outil particulièrement utile qui génère des cartes graphiques pour
mesurer les bandes passantes (en pourcentage ou en absolu) des liens réseaux.
« NTOP » : statistiques à propos de l’utilisation du réseau.
« Syslog-Ng » : permet de lire les messages syslog-ng dans l’interface de Cacti.
« BackUp » : ajoute une fonction de sauvegarde de l’installation de Cacti ;
« Discovery » : découvrir automatiquement les périphériques réseau non contrôlés par
Cacti et indique si SNMP est activé dessus ;
« Flowview » : visionneur des rapports fondés sur les données de flux crées par Netflow ;
« Haloe » : interface MySQL intégrée à Cacti pour enregistrer les événements à partir de
scripts, … ;
« MacTrack » : pour suivre les adresses IP et MAC et les ports ;
« Monitor » : ajoute un onglet pour visualiser les états (Up ou Down) de tous les hôtes. Si
un hôte tombe en panne une alerte sonore est émise ;
« RRDClean » : utilisé pour supprimer les RRAs non utilisées ;
« Reports » : envoie des graphes à des utilisateurs à des moments donnés ;
« Thold » : module « Threshold » (seuils, alertes, …) converti en plugin ;
« Tools » : ajoute des outils réseaux pour Cacti ;
« Update » : affiche les plugins installés et vérifie les mises à jour.

Il existe également NPC (Nagios Plugin for Cacti), permettant complètement d’intégrer Nagios à
Cacti et offrant les fonctionnalités suivantes [24]:

Une nouvelle interface à Nagios complètement intégré à Cacti ;

Une interface utilisateur riche développée avec Ext 2.0 ;
Un point d'entrée unique pour surveiller les états et tendances des composants;
Toutes les données sont mises à jour de façon asynchrone grâce à JSON (Java Script
Object Notation) ;
Importation/synchronisation des hôtes de Nagios dans Cacti (N2C).
Possibilités de personnaliser l'interface par utilisateur.

3.3.3.4 Conclusion sur Cacti

Cacti est un outil très orienté graphes. C’est sa fonction principale. Bien que compliqué à
manipuler, une fois acquis il constitue un puissant outil de métrologie.

46
En effet il est possible de personnaliser entièrement ses graphes. En revanche, on peut penser que
sans ses plugins Cacti est un peu léger en matière de supervision et les notions de « templates »
(modèles) et de base RRD peuvent paraître rebutantes.

Par exemple, la Weathermap permet de surveiller la charge du réseau de manière efficace, et le

Monitor permet de savoir facilement et visuellement l’état des machines en leur associant des
seuils d’alertes avec le plugin Thold.

3.3.4 EyesOfNetwork

EyesOfNetwork est une solution Open Source réunissant d’une manière pragmatique les processus
ITIL (Information Technology Infrastructure Library) et l’interface technologique permettant leur
application [25]. Le « bundle » EyesOfNetwork est composé d’un système d’exploitation
minimaliste incluant un ensemble d’applications répondant aux différents besoins de supervision :

GED (Generic Event Dispatcher) : gestion multi sites et sécurisée des évènements ;
Nagios : gestion des incidents et des problèmes ;
NagiosBP : gestion de la criticité des applications ;
NagVis : cartographie personnalisée de la disponibilité ;
Cacti : gestion des performances ;
Weathermap : plugin de cacti pour cartographier de la bande passante ;
Backup Manager : outil de sauvegarde de la solution ;
EONWeb : interface web unifiée de la solution ;
Ezgraph : librairie d’affichage des graphiques ;
SNMPTT : traduction des traps SNMP.

EyesOfNetwork est accessible via une interface Web unique dont l’objectif est de réunir les
différents acteurs d’un système d’informations (Administrateurs, Techniciens, Opérateurs, …).
Chacun de ces acteurs dispose d’une vue correspondant à son métier. Toutes les informations sont
consolidées en Base de Données MYSQL ou BERKELEY.

EyesOfNetwork est un produit sous licence GPL2 sponsorisé et proposé par APX dans le cadre de
prestations de services (Intégration, Télé-service, Support téléphonique et Tierce Maintenance
Applicative).

47
EyesOfNetwork parait être un outil très complet pour superviser un réseau multi-sites. Cependant,
il comprendrait trop de fonctions inutiles pour les besoins du service informatique.

3.4 Conclusion

Tous ces logiciels que nous avons décrits ci-dessus sont considérés comme un aboutissement et
une réussite dans leur branche, cependant, on voit qu’ils ont tous leurs propres inconvénients qui
doivent être résolus.

Un bon moniteur de supervision doit englober tous les avantages de ces derniers et aussi remédier
à leurs lacunes et inconvénients afin de converger vers la perfection et atteindre un niveau de
supervision et de fiabilité optimum.

Pour cela, la mise en place d’un tel moniteur exige le bon choix de plate-forme de développement
qui conduit à la réalisation d’une architecture distribuée fiable et robuste.

48
 CHAPITRE 4
INSTALLATION ET MISE EN ŒUVRE

4.1 Le choix de CACTI

Cacti est un outil de supervision reposant sur une interface web basée sur PHP et MySQL et qui
utilise le moteur RRDTool pour collecter les statistiques. Voici les principales caractéristiques :

Cacti ne nécessite pas un agent sur les hôtes à surveiller.

Cacti collecte les informations et les centralise sans client externe.
Il est possible d’écrire ses propres extensions sous forme de scripts; nous pouvons, par
exemple, interroger une application métier développée en interne pour remonter des
informations.
Cacti est développé en PHP, il possible de le modifier pour l’adapter à notre
environnement (le code source du programme est disponible et modifiable).
Il est possible de gérer finement les utilisateurs en définissant les graphiques qu’ils peuvent
voir et les actions qu’ils peuvent effectuer.
Toute la configuration de Cacti se fait via une console de gestion (page web).
La communauté autour de Cacti est nombreuse et compétente; beaucoup d’extensions sont
déjà disponibles.
4.2 Prérequis

Avant toute chose, le logiciel de supervision Cacti requiert certaines applications telles que :

RRDTool ;
Apache ;
MySQL ;
PHP ;
SNMP.

4.2.1 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.).

49
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.

4.2.2 Apache

Apache est un logiciel serveur HTTP [26]. Il s'agit d'une application fonctionnant à la base sur les
systèmes d'exploitation de type Unix, mais il a désormais été porté sur de nombreux systèmes,
dont Microsoft Windows.

4.2.3 MySQL

MySQL est un système de gestion de base de données (SGBD) [26]. Selon le type d'application, sa
licence est libre ou propriétaire. Il fait partie des logiciels de gestion de base de données les plus
utilisés au monde, autant par le grand public (applications web principalement) que par des
professionnels, en concurrence avec Oracle, Informix et Microsoft SQL Server.

4.2.4 PHP

Le PHP (Hypertext Preprocessor) est un langage de scripts libre principalement utilisé pour
produire des pages Web dynamiques via un serveur HTTP [26], mais pouvant également
fonctionner comme n'importe quel langage interprété de façon locale, en exécutant les
programmes en ligne de commande. PHP est un langage impératif disposant depuis la version 5 de
fonctionnalités de modèle objet complètes. En raison de la richesse de sa bibliothèque, on désigne
parfois PHP comme une plate-forme plus qu'un simple langage.

4.2.5 SNMP

SNMP est le protocole utilisé par CACTI pour récolter les informations provenant des machines à
superviser.

4.3 Installation des prérequis

4.3.1 Installation de RRDTool

# rpm –Uivh rrdtool-1.4.1-1.el5.wrl.i386.rpm

# rpm –Uivh rrdtool-ruby-1.4.1-1.el5.wrl.i386.rpm

# rpm –Uivh rrdtool-python-1.4.1-1.el5.wrl.i386.rpm

50
# rpm –Uivh rrdtool-devel-1.4.1-1.el5.wrl.i386.rpm

# rpm –Uivh rrdtool-perl-1.4.1-1.el5.wrl.i386.rpm

4.3.2 Installation de PHP

#rpm –Uivh php-5.1.6-27.el5_5.3.i386.rpm

#rpm –Uivh php-mysql-5.1.6-27.el5_5.3.i386.rpm

4.3.3 Installation de MySQL

#rpm –Uivh mysql-5.0.77-4.el5_6.6.i386.rpm

#rpm –Uivh perl-DBD-mysql-4.014-1.el5.rfx.i386.rpm

#rpm –Uivh mysql-server-5.0.77-4.el5_6.6.i386.rpm

4.3.4 Installation de SNMP

#rpm –Uivh net-snmp-5.3.2.2-14.el5.i386.rpm

4.4 Configurations

4.4.1 Configuration de serveur MySQL

4.4.1.1 Attribution de mot de passe

On doit attribuer un mot de passe pour le super utilisateur root de la base MySQL.

# mysqladmin -u root password mot_de_passe_à_créer

4.4.1.2 Création de la base de données cacti

# mysql -u root -p -e 'create database cacti'

4.4.1.3 Création de l’utilisateur

# useradd cacti

4.4.1.4 Attribution de privilège

La commande GRANT permet d'attribuer un privilège à différents utilisateurs sur différents objets
et la commande flush privilèges pour dire au serveur de relire les tables de droit.

# mysql --user=root mysql

mysql>GRANT ALL ON cacti.* TO cactiuser@localhost IDENTIFIED BY

‘mot_de_passe';
mysql>flush privileges;

51
4.4.2 Configuration SNMP

On édite le fichier de configuration de snmp par :

# vi /etc/snmp/snmpd.conf

Pour que SNMP fonctionne correctement, il faut configurer le fichier snmpd.conf comme
suit [27] :

com2sec local localhost DSI

group MyRWGroup v1 local

group MyRWGroup v2c local

group MyRWGroup usm local

view all included .1 80

access MyRWGroup "" any noauth exact all all

none

syslocation Unknown (edit /etc/snmp/snmpd.conf)

syscontact Root (configure /etc/snmp/snmp.local.conf)

pass .1.3.6.1.4.1.4413.4.1 /usr/bin/ucd5820stat

Puis enregistrer et quitter et on redémarre le service par :

#/etc/init.d/snmpd restart

Et pour que le service snmp lance au démarrage, on exécute la commande suivante :

# chkconfig snmpd on

4.5 Installation de cacti

On peut lancer l’installation de CACTI si toutes les dépendances requises sont installées.

#rpm –Uivh cacti-0.7.8i-1.el5.noarch.rpm

4.5.1 Installation des tables de cacti.sql

#rpm –ql cacti | grep cacti.sql

Et la réponse obtenue est :

/var/www/cacti/cacti.sql

52
Il faut ensuite injecter le fichier cacti.sql qui se trouve sur le répertoire
/var/www/cacti/cacti.sql vers la base de donné

# mysql -u cacti -p cacti < /var/www/cacti/cacti.sql

4.5.2 Configuration de cacti

On édite le fichier db.php par :

#vi /etc/cacti/db.php

Les commentaires sont précédées de ‘#’ qu’il ne faut pas confondre avec le ‘#’ en mode root de
linux qui précède chaque commande. On modifie le fichier db.php comme suit pour avoir la
correspondance avec la base de données [27],

#type de la base de données utilisée

$database_type = "mysql";

#nom de la base de données

$database_default = "cacti";

#base de données hôte

$database_hostname = "localhost";

#nom d’utilisateur de la base de données

$database_username = "cacti";

#mot de passe de la base de données

$database_password = "123456";

#numéro de port pour accéder à la base de données (port par

défaut de mysql)

$database_port = "3306";

4.5.3 Configuration httpd

On édite le fichier de configuration de Cacti

# vi /etc/httpd/conf.d/cacti.conf

On modifie le fichier cacti.conf comme suit pour que Cacti soit naviguable par d’autre nœud [27].

53
# Cacti: An rrd based graphing tool
Alias /cacti /usr/share/cacti
<Directory /usr/share/cacti/>
Order Deny,Allow
Deny from all
Allow from all #on modifie par all au lieu de 127.0.0.1
</Directory>

Après avoir sauvegardé le fichier cacti.conf, on redémarre le service httpd par :

# service httpd restart

4.5.4 Installation de CACTI cronjob

Dans le fichier /etc/cron.d/cacti Il faut dé commenté la ligne en enlevant le ‘#’ se trouve

au début de la ligne [27]:

*/5 * * * * cacti /usr/bin/php /var/www/cacti/poller.php > /dev/null

Pour activer l’échantillonnage des données tous les 5 minutes (présence de */5****).

4.5.5 Interface graphique de CACTI

Maintenant Cacti est prêt à terminer son installation. On ouvre un navigateur Web et on saisit
l’adresse url : http://localhost/cacti ou http://adresse_IP/cacti pour poursuivre l’installation

Figure 4.01 : Installation1

54
Figure 4.02 : Installation 2

55
 Figure 4.03 : Installation 3

Une fois cliquée sur Finish CACTI est prêt à être employer.

Voici la première interface de CACTI (voir Figure 4.04). Il suffit de logger avec le couple
nom_d’utilisateur/mot_de_passe pour entrer dans l’interface principale.

56
Figure 4.04 : Premier Interface login de l’utilisateur

Figure 4.05 : Interface principale de CACTI

57
4.6 Utilisation de CACTI

4.6.1 Présentation des menus de CACTI

New graph : Permet de créer les nouveaux graphiques.

Section management : Cette section permet de reconfigurer, modifier, classer les graphiques
créés.

Collection methods et Templates : Ces deux sections permettent de configurer la façon dont vont
se comporter et être affiché les données et les graphique.

Import/Export : Cette section permet d’importer ou d’exporter de nouveau templates ou scripts.

Configuration : C’est dans cette section que l’on paramètre Cacti, les paths, la version snmp, la
gestion des utilisateurs, etc…

Utilities : C’est dans cette section qu’il faudra se rendre en cas de problèmes, c’est ici que sont
affichés les caches de Cacti. Une commande qui se déroule mal sera indiquée ici, de même pour
ce qui se passe bien.

4.6.2 Création des graphes

Pour créer un graphe, il faut aller dans le menu console > Create > New Graphe > Create New
Host. Une nouvelle page comme formulaire s’affiche (cf. figure 4.06). C’est dans cette page que
nous allons configurer et définir l’adresse IP de la machine ou équipement à gérer. C’est
également dans cette page que nous allons mettre en place les interfaces que nous voulons faire de
graphe.

58
 Figure 4.06 : Création d’un graphe

Description : Il faut indiquer ici un nom explicite (nom de la machine à superviser).

Hostname : Il faut mettre ici l’adresse IP de la machine à superviser ou bien son nom fqdn (nom
pleinement qualifié).

Host template : Ici, nous définissons le type de système qui fonctionne sur la machine à
superviser. (win2000/xp, linux, netware serveur, Cisco router…).

Snmp Community : Lors du paramétrage de l’agent sur le poste client (il faut activer l’agent
snmp sur tous les postes à superviser), on définit un nom de communauté, ici snmp community est
DSI.

Snmp version : par défaut, c’est la version 1. En fonction du paramétrage de l’agent distant nous
pouvons choisir entre version 1, 2 ou 3.

59
Après avoir remplir ce formulaire on clique sur le bouton create au-dessous à droite. On a
ensuite cette interface (voir figure 4.07) qui montre que la machine hôte est prête à superviser

Figure 4.07 : Enregistrement de la création d’un graphe

Au cas où, le nœud qu’on veut superviser est éteint ou il y a une erreur lors de l’enregistrement, il
y a une indication d’erreur comme figure 4.08 et il faut vérifier manuellement le nœud que l’on
souhaite à superviser.

Figure 4.08 : Enregistrement de la création d’un graphe avec erreur

S’il n’y a pas d’erreur on peut créer les graphes que l’on veut avoir en cliquant sur Create Graphs
for this Host, et il suffit de cocher le nom du périphérique que l’on veut avoir son information.

60
 Figure 4.09 : Activation des graphes voulus

4.6.3 Extrait de graphe

Après avoir coché les graphes que l’on veut avoir, voici quelque extrait de graphe

Figure 4.10 : Réponse d’un ping de la machine WIN-XP en milliseconde

61
 Figure 4.11 : Utilisation de la partition /usr de la machine SRV-MONITOR

Figure 4.12 : Utilisation de la mémoire physique de la machine SRV-MONITOR

4.7 Avantages et inconvénients

Comme toutes les applications, Cacti présente aussi des avantages et des inconvénients.

4.7.1 Avantages
On peut mesurer la Disponibilité, la Charge, les erreurs, et bien d’autres choses, tout ceci
avec une archive
Cacti accèdes aux interfaces de vos routeurs et commutateurs, et collecter les
informations sur le trafic ainsi que les erreurs.
Cacti peut mesurer le taux de remplissage d’un disque, la charge du processeur, et bien
d’autres choses. Il peut réagir à certaines conditions, et envoyer des alertes à des seuils
et intervalles donnés.

62
 Graphique
Toutes les fonctions avancées de l’outil rrdgraph sont disponibles pour ajuster et
automatiser l’affichage de certains paramètres.
Il permet de structurer les informations dans un arbre hiérarchique
Sources de donnée
Il permet d’accéder aux fonctions avancées de rrdcreate et rrdupdate, y compris la
définition de multiples sources d’information pour chaque base base RRD
Collecte de données
Offre SNMP y compris l’utilisation php-snmp ou bien de net-snmp
Les sources de donnée peuvent être mises à jour via SNMP ou bien en utilisant un
script qui se chargera de la collecte des données.
Un composant facultatif cactid, implémente des routines SNMP en C avec le
multithreading. Critique pour de très grandes installations.
Modèles
On peut créer des modèles pour réutiliser les définitions des graphiques, et les sources
de donnée et les équipements (prédéfinitions).
Architecture Plugin de Cacti (CPA)
Étend la fonctionnalité de Cacti functionality. Beaucoup de greffons (plugins) sont
disponibles.
Gestion des utilisateurs
On peut gérer les utilisateurs localement, ou bien via LDAP, et on peut assigner
différents niveaux d’autorisation aux utilisateurs et aux groupes, avec un contrôle fin.
4.7.2 Inconvénients
La configuration des interfaces est fastidieuse
Il est important de maintenir la configuration Cacti à jour avec le réseau. Pour cela il
faut dédier une personne à cette tâche ou créer des scripts et partages de données.
Les erreurs de configuration peuvent être fastidieuses à rectifier.
La configuration de l’architecture de plugins n’a rien de banal
Les versions de l’architecture de plugins sont prévues pour des versions spécifiques de
Cacti.
La mise à niveau de Cacti une fois l’architecture PA installée peut être également
périlleuse.

63
4.8 Conclusion

Cacti répond aux besoins de supervision de nombreux services basés sur des protocoles différents
et a su présenter des fonctionnalités adaptées aux attentes concrètes de la supervision comme
l’accessibilité et ses interactions à distance, l’automatisation des remontées d’alarmes jusqu’aux
administrateurs, ou encore les comptes rendus et historiques graphiques des évènements du réseau.

64
 CONCLUSION GENERALE

Quel que soit la taille et le secteur d'activité d’une entreprise, l'informatique est au cœur du
système d'information. Les problèmes liés à l'informatique doivent donc être réduits au minimum,
car une indisponibilité du système d'information peut entraîner une baisse globale de la
productivité et des pertes financières importantes.

Les réseaux sont devenus un pilier de l’économie mondiale. Les besoins et les enjeux de ces
technologies ne cessant d’augmenter, la supervision est alors apparue pour apporter une garantie
de fiabilité, de réactivité et d’adéquation des moyens mis en place. Néanmoins la grande disparité
de ces technologies de réseau pose un certain nombre de problèmes : comment superviser toutes
ces technologies, comment récupérer les informations, etc.

Les organismes de normalisations ont été les premiers à apporter une réponse en définissant un
format commun des données, un modèle d’administration pour les adresser et des protocoles pour
les communiquer. La mise en place d’une procédure de supervision de réseaux passe alors
forcément par l’application concrète d’une de ces normes, sans laquelle il est impossible d’obtenir
une réelle plus-value sur l’administration de son réseau. Le seul véritable standard actuel du
monde IP élaboré à partir de ces normes est le protocole SNMP. Il constitue la base de la majorité
des plateformes logicielles de supervision réseau dont Cacti, une des plus populaires.

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.

Un logiciel de supervision de réseau comme Cacti est indispensable pour un administrateur

lorsque le réseau devient complexe. Il permet d'avoir une vue globale de l’utilisation de tous les
nœuds utilisés dans un parc informatique.

Grace à Cacti, on peut aussi estimer les caractéristiques des serveurs et des équipements qu’on
doit utiliser pour minimiser les dépenses financières en termes de coût.

65
 ANNEXE 1 : FORMAT DES MESSAGES SNMP

SNMP est un simple request/response protocole dans lequel le gestionnaire SNMP communique avec les
agents SNMP et dispositifs gérés en utilisant SNMP PDU (Packet Data Unit) [28].

SNMPv1

Figure A1.01 : Format de message de SNMPv1

SNMP Version : Il s'agit un entier qui identifie la version du protocole SNMP. Pour
SNMPv1, sa valeur est 0.

Community String : Une chaîne d'octets qui peut contenir une chaîne utilisée pour ajouter de la
sécurité des dispositifs SNMP.

SNMP PDU : il est utilisé pour la communication entre les entités SNMP.

Pour SNMPv1, il y a deux types de formats de PDU, l'un pour le Trap et l’autre pour le reste des
types de PDU.

Le format de PDU applicable pour Get, GetNext, Set et réponse:

Figure A1.02 : Format de PDU pou get, get-next, set, get-request, get-reponse de SNMPv1

PDU Type : Spécifie le type de PDU

Request ID : Associes les requêtes SNMP avec les réponses.

Error status : Indique l'un d'un certain nombre d'erreurs et les types d'erreur. Il est défini
uniquement en réponse PDU, pour le reste il est défini comme 0.

66
Error Index : Associes une erreur avec une instance d'objet particulier. Il est défini
uniquement en réponse PDU, pour le reste il est défini comme 0.

Le format de PDU applicable pour le Trap

Figure A1.03 : Format PDU pour le trap

PDU Type : Spécifie le type de PDU comme piège

Enterprise : Identifie la gestion d'entreprise sous responsable de l'enregistrement dont le

trap a été défini.

Agent Address : Adresse IP de l’agent

Generic Trap : Utilisé pour identifier le trap générique. Il y a six types de pièges
génériques.

Specific Trap : Utilisé pour identifier le trap spécifique

Time Stamp : Valeur de l’objet MIB sysUpTime

SNMPv2

Le format de message de SNMPv2 est le même que le SNMPv1, mais les différences sont : le
format des PDUs et pour SNMPv2 la valeur de SNMP Version est 1.

Pour SNMPv2, il y a deux types de formats de PDU, l'un pour GetBulk et l’autre pour le reste des
types de PDU.

Le format de PDU applicable pour Get, GetNext, Set, Response, Trap et inform est le
même que le format de PDU applicable pour Get, GetNext, Set et réponse dans SNMPv1:
Le format de PDU applicable pour GetBulk

67
 Figure A1.04 : Le format de PDU applicable pour GetBulk

PDU Type : Spécifie le type de PDU

Request ID : Associes les requêtes SNMP avec les réponses.

Non Repeaters : Spécifie le nombre d'instances d'objets dans le champ de liaisons variable
qui n’est pas récupérées qu'une seule fois à partir du début de la demande.

Max repetitions Définit le nombre maximal de fois que d'autres variables au-delà de celles
spécifiées par le champ non répéteur doivent être récupérées.

SNMPv3

Le format de message de SNMPv3 est très différent des deux premières versions en raison de
beaucoup de paramètres de sécurité introduites dans cette version.

Figure A1.05 : Format de message de SNMPv3

Version : Il s'agit un entier qui identifie la version du protocole SNMP. Pour

SNMPv3, sa valeur est 3

ID Ce champ contient l'identificateur de message SNMP qui est un identifiant

unique associé au message. Le champ msgID est différent du champ reqID
disponible dans la PDU.

68
Max Size : Ce champ représente la taille maximale du message que l'entité demandant
de SNMP peut accepter.

Flags : Ce champ contient le niveau de sécurité des messages.

Security model : Ce champ indique le modèle de sécurité utilisé pour générer le message. Si
on utilise USM, sa valeur est 3

Engine ID : Ce champ a la valeur de snmpEngineID de l’entité SNMP

Engine Boots : Ce champ a la valeur de snmpEngineBoots de l’entité SNMP

Engine Time : Ce champ a la valeur de snmpEngineTime de l’entité SNMP

User Name : Ce champ contient la principale origine de la demande

Security Parameters : Ce champ contient les paramètres de sécurité qui sont le modèle de sécurité
dépendent

Context Engine ID : Dans un domaine administratif, le contextEngineID identifie de manière

unique une entité SNMP qui peut réaliser une instance d'un contexte avec un
contextName particulier.

Context Name : Un contextName est utilisé pour nommer un contexte. Chaque contextName
doit être unique au sein d'une entité SNMP

PDU : Le PDU est utilisé pour la communication entre les entités SNMP.

69
 ANNEXE 2 : EXTRAIT DES RFCs

RFC 1157 [29]

PDUs ::= CHOICE {

get-request GetRequest-PDU,
get-next-request GetNextRequest-PDU,
get-response GetResponse-PDU,
set-request SetRequest-PDU,
trap Trap-PDU
}

Message ::= SEQUENCE {

version -- version-1 for this RFC
INTEGER { version-1(0) },
community OCTET STRING, --
community name
data -- e.g., PDUs if trivial
ANY -- authentication is being used
}

PDU ::= SEQUENCE {

request-id INTEGER,
error-status -- sometimes ignored
INTEGER { noError(0), tooBig(1),
noSuchName(2), badValue(3),
readOnly(4), genErr(5) },
error-index INTEGER, -- sometimes
ignored
variable-bindings -- values are
sometimes ignored VarBindList

70
RFC 1155 [30]

OBJECT-TYPE MACRO ::=

BEGIN
TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
"ACCESS" Access
"STATUS" Status
VALUE NOTATION ::= value(VALUE ObjectName)
Access ::= "read-only"
| "read-write"
| "write-only"
| "not-accessible"
Status ::= "mandatory"
| "optional"
| "obsolete"
END

71
 ANNEXE 3 : QUELQUES RFC

RFC Description
RFC 1155 Définit la structure des informations d’administration (syntaxe
SMIv1)
RFC 1212 Décrit de façon plus concise la structure des informations
d’administration (syntaxe SMIv1) et les traps
RFC 1157 Définit le protocole SNMP
RFC 1213 Décrit la structure d’une MIB-II
RFC 1215 Décrit les traps
RFC 2578 Définit les types fondamentaux, model d’objet MIB SMIv2
RFC 2579 Conventions textuelles de SMIv2
RFC 1905 SNMPv2
RFC 2570 Introduction à SNMPv3
RFC 2571, 2572, 2573 Architecture SNMP (emphase sur la securité)
RFC 2574 Modèle de sécurité de SNMPv3
RFC 2575 Contrôle d’accès

Tableau A3.01 : Liste de quelques RFC

72
 BIBLIOGRAPHIE

[1] B. Assam « Conception et Réalisation d’un Système de Supervision Informatique à base

d’Agents Mobiles » INI Alger, Mémoire de fin d’etude, 2007-2008.

[2] http://fr.wikipedia.org/wiki/Supervision

[3] M. Kahani and P. Beadle. « Decentralized Approaches for Network Management. » ACM
Computer Communication Review Journal, 1997.

[4] N. Simoni et S. Znaty. « Gestion de réseau et de service ». InterEditions, 1997.

[5] OSF-DME-PD-0394-2. DME Overview. OSF online document, 1992.

[6] W. Rosenberry DCE. O'Reilly & Associates, Inc., 1994.

[7] M. Siegle and G. Trausmath. « A Concept and its Prototype in SNMPv2 », 1995.

[8] D. Harrington, P. Mayer and B. Wijnen. « An Architecture for Describing SNMP

Management Frameworks », 1998.

[9] Y. Yemini and G. Goldszmidt. « 2nd International Symposium on Integrated Network

Management », 1991.

[10] L. E. Randriarijaona, « Réseaux TCP/IP », cours 3ème Année Licence, Dép.

Télécommunication E.S.P.A, A.U. : 2010-1011.

[11] A. Ratsimbazafy, « Réseaux informatique », cours 2ème Année Licence, Dép

Télécommunication E.S.P.A, AU. : 2009-2010.

[12] T. Briche et M. Voland, « Les outils d’administration et de supervision réseau », 2004

[13] W. Stallings. SNMP, SNMPv2, and CMIP. Don Mills : Addison-Wesley, 1993.

[14] http://www.commentcamarche.net/contents/internet/snmp.php3

[15] http://www.frameip.com/snmp/

[16] http://fr.wikipedia.org/wiki/Management_Information_Base

[17] http://www-igm.univ-mlv.fr/~dr/XPOSE2004/rjourdan/concept.html

73
[18] http://www.frameip.com/tcpip/

[19] M. Mansalier, « Mise en place d’un outil de supervision réseau », 2008

[20] http://www.nagios.org/

[21] http://fr.wikipedia.org/wiki/Centreon

[22] http://www.cacti.net/

[23] http://docs.cacti.net/plugins

[24] http://wiki.monitoring-fr.org/nagios/integration/npc

[25] http://www.eyesofnetwork.com/?lang=fr

[26] N. M. Ravonimanantsoa, « Développement d’Application d’Entreprise » cours 3ème

Année Licence, Dép. Télécommunication E.S.P.A, A.U. : 2010-1011.

[27] http://doc.fedora-fr.org/wiki/Installation_et_configuration_de_Cacti

[28] http://verticalhorizons.in/snmp-message-format-snmp-pdu-format/

[29] http://www.ietf.org/rfc/rfc1157.txt

[30] http://www.ietf.org/rfc/rfc1155.txt

74
 FICHE DE RENSEIGNEMENTS

Nom : RAKOTOARISOA
Prénoms : Mamy Vonjimampianina
Adresse : Lot TH 266 Andravoahangy Tsena
Antananarivo 101
Téléphone : +261 033 07 880 83

E-mail : [email protected]

Titre du mémoire :

MISE EN PLACE D’UN SERVEUR DE SUPERVISION

UTILISANT CACTI SOUS REDHAT / LINUX

Nombre de pages : 76
Nombre de tableaux : 02
Nombres de figures : 43

Mots clés : Supervision, Cacti, Linux, SNMP, MIB

Directeur de mémoire : Monsieur RATSIMBAZAFY Andriamanga

Tél : +261 34 01 377 97

75
 RESUME

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.

ABSTRACT

The supervision is becoming indispensable in every information system. It forms the basis of an
active network architecture and in the event of problems or failures, it permits to intervene
quickly. Currently, it is mainly based on the SNMP protocol which still struggling to evolve for
many years. Indeed many programs are based on the first version of this protocol which begins to
become a little older and not secure at all. So, the second version, providing particularly more of
security, was appeared only as a transition phase to the third version which is still used in a very
little numbers.

76