Etude Des Outils de La Supervision Reseau

ETUDE DES OUTILS DE LA
SUPERVISION RÉSEAU
Génie Informatique & Réseaux

Systèmes et Réseaux
Mounia LASSOULI
Mustapha OUAGHRIS
Mohamed MARRAKCHI
Année universitaire:2006-2007
PROJET DE FIN D’ÉTUDES
ANNÉE 2007
Rachid ELLIASMINE
Remerciements
Année universitaire:2006-2007
Tout d’abord, nous tenons à remercier tous les membres de l’équipe SI du site
OCEAN pour leur aide, leur bonne humeur et pour le temps qu’ils nous ont
consacré et surtout pour tout le matériel qu’ils ont mis à notre disposition afin
de réaliser cette étude.
Parmi cette équipe, nous tenons à remercier Mr Rachid ELLIASMINE

Responsable pole projet Phone Assistance et Mr Driss LAHRICHI responsable
informatique du site ainsi que toute l’équipe SI de site OCEAN.
Un grand merci également à notre professeur de réseau au sein de EMSI qui

est notre encadrant Mr Mohamed MARRAKCHI pour son aide, ses conseils et
pour nous avoir aidés à mieux nous orienter dans le projet.
Enfin, nous remercions nos familles et toute personne qui nous a aidé à réaliser
ce projet.
PHONE ONLINE 2 EMSI

ANNÉE 2007
Sommaire
REMERCIEMENT ………………………………………………………………………………. 2
INTRODUCTION ………………………………………………………………………………. 6
PARTIE I : avant Propos et présentation de la société .................................. 7
1.1 Aperçu sur le métier des centres d’appels au Maroc ............................... 7

1.2 Présentation générale Phone Assistance (Site OCEAN) ........................... 8
1.2.1 Activité selon le site PA .............................................................. 9
1.2.2 Présentation Générale du site OCEAN ........................................... 9
1.2.3 Les missions des équipes systèmes d'informations de OCEAN ......... 11
PARTIE II : Mécanismes de la supervision d’un parc informatique ............... 13
2.1 Qu’est-ce qu’est la supervision ? ....................................................... 13

2.2 Le principe de la supervision ............................................................. 13
2.3 Le protocole SNMP .......................................................................... 14
2.3.1 Présentation ........................................................................ 14
2.3.2 Fonctionnement ................................................................... 14
2.3.2.1 Agent ...................................................................... 14
2.3.2.2 la MIB ..................................................................... 15
2.3.2.3 Les commandes SNMP ............................................... 17
2.3.2.4 Echange des messages .............................................. 17
2.3.3 différentes versions de SNMP ................................................. 18
2.3.3.1 SNMP v1 .................................................................. 18
2.3.3.2 SNMP v2 .................................................................. 19
2.3.3.3 SNMP v3 .................................................................. 19
2.4 Pourquoi l’entreprise a-t-elle besoin de la supervision ? ........................ 22
2.5 Les équipement concernés par la supervision ...................................... 23
Partie III : cahier des charges .............................................................. 24
PHONE ONLINE 3 EMSI

ANNÉE 2007
3.1 Etat actuel du parc informatique de site OCEAN .................................. 24

3.2 Les inconvénients ........................................................................... 25
3.3 Les besoins .................................................................................... 25
Partie IV : les outils de la supervision .................................................... 29
4.1 Nagios ........................................................................................... 29

4.1.1 Présentation ........................................................................ 29
4.1.2 Fonctionnalité ...................................................................... 29
4.1.3 Installation et configuration ................................................... 29
4.1.3.1 Prérequis ................................................................. 29
4.1.3.1.1 Les dépendances ............................................ 29
4.1.3.1.2 Compte Utilisateur «Nagios» ............................ 30
4.1.3.1.3 Apache ......................................................... 30
4.1.3.2 Installation Nagios ..................................................... 30
4.1.3.3 Installation des plugins .............................................. 31
4.1.3.4 Mise en place de l'interface ......................................... 32
4.1.3.5 Les fichiers de configurations ...................................... 32
4.1.3.5.1 nagios.cfg ..................................................... 33
4.1.3.5.2 checkcommands.cfg ................................... ... 33
4.1.3.5.3 contactgroups.cfg ........................................... 34
4.1.3.5.4 contacts.cfg ................................................... 34
4.1.3.5.5 hostgroups.cfg................................................ 35
4.1.3.5.6 hosts.cfg ....................................................... 35
4.1.3.5.7 services.cfg ................................................... 36
4.1.3.5.8 timeperiods.cfg .............................................. 37
4.1.3.5.9 cgi.cfg .......................................................... 37
4.1.3.6 Les services ............................................................. 38
4.1.3.6.1 Vérification de l'intégrité des fichiers de
configurations .............................................................. 38
4.1.3.6.2 Démarrer Nagios ............................................ 38
4.1.3.6.3 Démarrer Apache ........................................... 38
4.1.4 Oreon ......................................................................................... 39
PHONE ONLINE 4 EMSI

ANNÉE 2007
4.1.4.1 Avantages d’Oreon ............................................................ 39

4.1.4.2 Inconvénients d’Oreon ....................................................... 39
4.1.5 Test ........................................................................................... 40
4.1.5.1 Avantages de Nagios ......................................................... 41
4.1.5.2 Inconvénients de Nagios .................................................... 41
4.2 La plate-forme HP Open View (Network Node Manager) ....................... 41

4.2.1 Présentation ........................................................................ 41
4.2.2 Fonctionnement ................................................................... 43
4.2.2.1 Découverte et Cartographie automatique du réseau ....... 45
4.2.2.2 La collecte d’informations critiques .............................. 45
4.2.2.3 Les bases de données et l’analyse ............................... 46
4.2.3 Installation .......................................................................... 47
4.2.4 Configuration .......................................................................
47
4.2.4.1 Map ......................................................................... 47
4.2.4.2 Polling ..................................................................... 48
4.2.4.3 Alarme .................................................................... 48
4.2.5 Test ................................................................................... 48
4.2.5.1 Avantages ................................................................ 49
4.2.5.2 Inconvénients ........................................................... 49
4.3 Tivoli ............................................................................................. 50

4.3.1 Présentation ........................................................................ 50
4.3.2 Fonctionnalité ...................................................................... 51
4.3.3 Installation .......................................................................... 52
4.3.4 Configuration .......................................................................
52
4.3.5 Test ................................................................................... 53
4.3.5.1 Inconvénients ........................................................... 53
SOLUTION CHOISIE ………………………………………………………………………… 54
CONCLUSION ......................................................................................... 55
GLOSSAIRE ........................................................................................... 56
PHONE ONLINE 5 EMSI

ANNÉE 2007
URLOGRAPHIE ....................................................................................... 57
INTRODUCTION
Les réseaux informatiques, présents à l’heure actuelle dans de

nombreuses entreprises et dans les administrations, sont indispensables au bon
fonctionnement général de ces dernières. Tout problème ou panne sur le
système d’une entreprise peut avoir de lourdes conséquences aussi bien
financières qu’organisationnelles. La supervision des réseaux s’avère donc
nécessaire et indispensable. Elle permet entre autre d’avoir une vue globale du
fonctionnement et des problèmes pouvant survenir dans un réseau mais aussi
d’avoir des indicateurs et informations sur la performance de son architecture.
De nombreux logiciels de la supervision, qu’ils soient libres ou propriétaires,
existent sur le marché, la plupart s’appuyant sur le protocole SNMP.
Dans la première partie nous allons donner un aperçu sur le métier des
centres d’appels au Maroc puisque notre projet a été réalisé dans un parc
informatique d’un centre d’appels. Ensuite nous présenterons l’entreprise dans
laquelle nous avons effectué cette étude. Nous entamerons la seconde partie
par une petite définition de la supervision ainsi que de son principe avant de
faire une présentation générale du protocole SNMP. Dans la même partie nous
répondrons sur une question évidente que toutes entreprises posent sur les
raisons du choix la solution de la supervision.
Ensuite nous décrirons le cahier des charges qui nous permettra de choisir la
solution optimale pour notre cas ; ce choix sera traité dans la cinquième partie,
cette partie étant précédée par une étude comparative de quelques outils de la
supervision.
PHONE ONLINE 6 EMSI

ANNÉE 2007
Partie I : Avant-propos et présentation de la société
1.1 Aperçu sur le métier des centres d’appels au Maroc
Centre d’appels (en anglais Call center): une plate-forme, hébergée par
l'entreprise ou externalisée, chargée d'assister les utilisateurs (relation client).
Les centres d'appels permettent d'assister des clients dans le cadre d'un
service après-vente (SAV), d'un support technique, d'une télévente ou bien
d'accompagner les personnels d'une entreprise dans le cadre de l'utilisation
d'un outil ou dans leurs tâches quotidiennes. Dans le cas d'un centre d'appel
dédié au support technique, le terme anglais est Help Desk ou Hot Line.
Le phénomène des centres d’appels est arrivé au Maroc voici quelques

années ; ce domaine a connu une évolution foudroyante en peu de temps, et
aujourd’hui ce secteur d'activité peut être considéré comme l'un des plus
porteurs en matière de création d'emplois et comme ayant un fort potentiel en
matière d'investissement.
La tendance au développement des centres d'appels au Maroc se poursuit

depuis plus de cinq ans. En moyenne une vingtaine de nouveaux sites ouvrent
par an ; fin 2006, il y avait plus de 137 centres d'appels opérationnels, contre
50 en 2004. Les besoins de recrutement sont de l'ordre de 250 postes par
semaine, le nombre de personnes travaillant dans ce secteur est estimé à plus
de 17500 personnes et la majorité de ceux qui travaillent dans ce secteur
possèdent un Bac+2 et une très bonne maîtrise des langues étrangères.
En dehors de l’axe Casa Rabat, de nouvelles villes marocaines deviennent

une destination prisée pour les centres d'appels : Marrakech, Fès, et bientôt
Oujda à l'est.
PHONE ONLINE 7 EMSI

ANNÉE 2007
Le chiffre d'affaires a été presque multiplié par quatre passant de 830

millions de dirhams à 2,94 milliards de dirhams en deux ans.
Le nombre total de positions est estimé à plusieurs milliers. Non

seulement le secteur est dopé par les besoins croissants de l'offshore, mais
également par des projets locaux de centres d'appels bancaires, administratifs,
et dans de grands groupes.
Les éditeurs et les équipementiers des centres d'appels rivalisent avec

des offres de plus en plus avantageuses, permettant aux centres d'appels
d'améliorer la qualité et la rentabilité des différents sites de production. De
nouvelles offres en télécommunication vont bientôt placer le Maroc parmi les
pays les plus compétitifs en coûts de télécommunications à l'échelle
internationale.
1.2 Présentation générale de Phone Assistance
Phone Assistance (PA) a été fondée par le groupe marocain Saham de

Moulay Hafid EL ALAMY en 2000. Depuis, Phone Assistance a démontré son
savoir-faire dans le secteur des centres de contact en délocalisation, dans un
contexte national approprié à l’implantation de cette activité.
Vision stratégique de développement, qualité des prestations et

professionnalisme de ses collaborateurs sont autant d’atouts qui lui ont permis
de séduire et de fidéliser des opérateurs européens prestigieux.
Dans un marché en forte croissance, Phone Assistance, avec l’introduction

de son capital de Bertelsmann comme actionnaire de référence depuis 2004,
est aujourd’hui reconnu comme le leader marocain des centres de contact en
délocalisation.
Phone Assistance est composée d’un siège, le Holding et de six sites : site
Soleil, site Palmier, site Oasis, site Océan, site Médina et le sixième site
PHONE ONLINE 8 EMSI

ANNÉE 2007
implanté à Marrakech est le site Dune. En 2006, Phone Assistance compte près
de 3000 collaborateurs.
1.2.1 Activité selon le site PA
Tous les sites de Phone Assistance ont des activités différentes pour
différents secteurs. La grande partie des activités qui existent sur tous les sites
concerne des entreprises françaises.
Le dispatching des activités selon les sites se fait comme suit :
- Site Soleil
• Service annuaire
• Service téléphonique
• Activité Back Office
- Site Palmier
• Service client
• Gestion des réclamations
- Site Oasis
• Télémarketing
- Site Océan
• Assistance Technique
- Site Médina
• Gestion des réclamations
- Site Dune
1.2.2 Présentation Générale du site OCEAN
PHONE ONLINE 9 EMSI

ANNÉE 2007
Le site Océan est le quatrième site du groupe Phone Assistance dans

l’ordre chronologique puisqu’il a été créé en 2006 ; il regroupe deux activités
principales, l’assistance technique d’un FAI Français et l’annuaire d’une
entreprise privée française. Le nombre de collaborateurs est estimé à plus de
750 personnes.
L’architecture de l’organisation du site OCEAN
D irecteur du site
R esponsable des Affaires

C ontrôleur de gestion Équipe AG
Générales(AG)
C oordinateur R H C oordinateur Production C oordinateur SI
R esponsable Opérationnel
Équipe RH Adm inistrateur R éseau
d’Activité(R OA)
Superviseur/ R esponsable
Équipe F ormation T echnicien Inform aticien
D e Groupe(R D G)
T élé conseillers
/ C hargé
Équipe R ecrutem ent d’Assistance T echnique Planificateur
(C AT)
PHONE ONLINE 10 EMSI

ANNÉE 2007
1.2.3 Les missions des équipes systèmes d'informations de OCEAN
Le département du système d’information (DSI) du site OCEAN possède

des équipements informatiques de haute gamme, soit au niveau des routeurs,
des Gateway télécoms, des serveurs et des postes de travail.
La mission de l’équipe SI du site est divisée en deux stratégies
d’interventions ; la première consiste à veiller au bon fonctionnement de la
production et dans cette partie on trouve deux possibilités selon la nature de
l’activité ou du client. Le premier type de client est celui qui permet à l’équipe
SI locale un accès total aux différentes parties du système (télécoms, routeur,
base de données,…) et dans ce cas ce sont les membres de la SI qui assurent
toutes les tâches. Le deuxième type de client est celui qui autorise un accès
restreint à son système pour l’équipe SI locale et dans ce cas la tâche principale
de l’équipe locale est de remonter les incidents aux équipes SI du client.
La deuxième partie des interventions est celle qui concerne les différentes
interventions au niveau du système interne pour assurer le bon fonctionnement
des applications et des accès pour tous les utilisateurs locaux.

ANNÉE 2007
L’architecture réseau du site OCEAN
Réseau de prod1 Réseau de prod n
-----
Réseau Production1 LLI+ Internet
LLI+
Serveurs
LS Internet
-----
Postes de travail
Serveurs
DMZ
Réseau Production n
Serveurs
Serveurs
Réseau Admin
Postes de travail
Postes de travail

ANNÉE 2007
Partie II : les mécanismes de la supervision d’un réseau

informatique
2.1 Qu’est-ce qu’est la supervision ?
Dans le jargon informatique, la supervision est la surveillance du bon

fonctionnement d’un système ou d’une activité, en rapportant et alertant les
fonctionnements normaux et anormaux des systèmes informatiques.
La supervision en terme réseau porte sur la surveillance du
fonctionnement, des débits, de la sécurité mais également du contrôle de flux.
2.2 Le principe de la supervision
Une grande majorité des logiciels de supervision sont basés sur le

protocole SNMP qui existe depuis de nombreuses années ; nous faisons la
description de ce protocole par la suite dans la même partie.
La plupart de ces outils permettent de nombreuses fonctions dont les

principales sont :
• surveiller le système d’information

• visualiser l’architecture du système
• analyser les problèmes
• déclencher les alertes en cas de problèmes
• effectuer des actions en fonction des alertes
D’après les fonctions décrites ci-dessus et réalisées par l’outil de la

supervision, la tâche de l’administrateur se trouve simplifiée. Il n’a plus qu’à
faire des vérifications ou la réalisation des actions en fonction des alertes
déclenchées, sans oublier que l’outil donne une vision globale du système
d’information afin de localiser les problèmes le plus rapidement possible.

ANNÉE 2007
2.3 Le protocole SNMP
2.3.1 Présentation
Créé en 1988 par l’IETF(Internet Engineering Task Force), SNMP signifie

Simple Network Management Protocol (protocole simple de gestion de réseau).
C’est un protocole qui permet de gérer les équipements réseaux ainsi que les
machines informatiques, ce protocole étant utilisé par les administrateurs
réseaux pour détecter à distance les problèmes qui surviennent sur leur réseau.
Chaque machine, que ce soit sous Windows ou Linux possède de
nombreuses informations capitales pour l’administrateur réseau. On retrouve
des informations comme la quantité de RAM utilisée, l’utilisation du CPU,
l’espace disque et encore bien d’autres indicateurs. SNMP va permettre de
remonter ces informations à l’administrateur de façon centralisée pour pouvoir
réagir au plus vite aux pannes éventuelles.
2.3.2 Fonctionnement
2.3.2.1 Agent
Sur une machine à superviser, pour que SNMP envoie les informations
que l'on souhaite, il faut qu'un agent soit installé sur celle-ci. Cet agent écoute
sur le port 161 et attend que le serveur lui envoie des requêtes pour lui
répondre.
L'agent pourra aussi envoyer des alertes lui-même si l'administrateur

réseau les a configurées. Par exemple, pour surveiller l'occupation CPU d’une
machine, l'administrateur définira une valeur critique à partir de laquelle une
alerte doit lui être émise.
Pour finir l'agent pourra aussi agir sur l'environnement local, c'est
pourquoi ce protocole est critique car il peut servir à d'autres personnes mal
intentionnées pour prendre le contrôle à distance de certains équipements sur
le réseau.

ANNÉE 2007
Généralement, l'administrateur possède un outil permettant de centraliser

ce que lui retournent tous les agents et c'est donc cet outil qui va interroger les
équipements du réseau, afin de pouvoir gérer un réseau entier.
2.3.2.2 La MIB
Présentation
Pour que SNMP fonctionne, il est nécessaire qu'un protocole d'échange

soit défini. Il y a aussi une standardisation des informations que ce protocole
peut transporter ; c'est un protocole Internet, qui doit être utilisable sur des
plates-formes hétérogènes (matériel comme système d'exploitation). C'est pour
cette raison que l'on parlera de la MIB (Management Information Base). En
effet la MIB est une base de données des informations de gestion maintenue
par l'agent et c’est à cette base que l’on va demander les informations.
Structure de la MIB
La structure de la MIB est hiérarchique : les informations sont regroupées

en arbre, chaque information a un OID (Object identifier), une suite de chiffres
séparés par des points, qui l'identifie de façon unique et le nom indiqué dans le
document qui décrit la MIB.
Par exemple, 1.3.6.1.2.1.2.2.1.2 est l'OID « ifDescr » qui est la chaîne

de caractères décrivant une interface réseau (comme eth0 sur Linux ou
Ethernet0 sur un routeur Cisco).
Les MIB sont décrites en utilisant ASN.1
Par exemple, ifDescr est décrite par :
ifDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only
STATUS mandatory
DESCRIPTION

ANNÉE 2007
"A textual string containing information about the interface. This string should
include the name of the manufacturer, the product name and the version of the
hardware interface."
::= { ifEntry 2 }
Une des MIB les plus connues est la MIB-II, cette dernière est décrite
dans la RFC 1213, et elle est mise en œuvre dans quasiment tous les
équipements TCP/IP. Elle compte dix groupes : «système», «interfaces», «at»,
«IP», «ICMP», «TCP», «UDP», «EGP», «transmission» et «SNMP».

ANNÉE 2007
2.3.2.3 les commandes SNMP
Il existe 4 types de requêtes SNMP :
• get-request : le Manager SNMP demande une information à un

agent SNMP
• get-next-request : le Manager SNMP demande l'information
suivante à l'agent SNMP
• set-request : le Manager SNMP met à jour une information sur un
agent SNMP
• trap : l'agent SNMP envoie une alerte au Manager
Les alertes sont transmises lorsqu’un événement non attendu se produit sur
l’agent, ce dernier informe le manager via une «trap». Plusieurs types d’alertes
sont alors possibles : ColdStart, WarmStart, LinkDown, LinkUp,
AuthentificationFailure.
Pour chaque envoi de message, une réponse est retournée à l’exception de

la commande «trap». Les réponses sont du type suivant:
• get-response : l’information a bien été transmise.

• NoSuchObject : aucune variable n’a été trouvée.
• NoAccess : les droits d’accès ne sont pas bons.
• NoWritable : la variable ne peut être écrite.
2.3.2.4 Echange des messages
Voici un schéma récapitulant les échanges pouvant être effectués entre un

agent et le manager :

ANNÉE 2007
Le protocole SNMP est principalement utilisé avec UDP/IP. (il peut aussi
utiliser TCP). L’utilisation d’UDP permet un échange de message plus rapide que
l’utilisation de TCP. L’inconvénient est qu’il est possible de perdre des trames
lors de l’échange de messages (mode non connecté). Les ports UDP sont donc
le 162 pour le manager et le 161 pour les agents.
2.3.3 différentes versions de SNMP
2.3.3.1 SNMP v1
C'est la première version de SNMP qui a été très utilisée et qui l'est
encore mais qui a un défaut majeur : la sécurité est très faible. Cette dernière
se basant sur la communauté « Public » par défaut, il suffit de définir la même
communauté pour interroger les agents (RFC 1155 à 1157).
Format des messages SNMP :
- Le champ version contient la version de SNMP utilisée

ANNÉE 2007
- Communauté : le type de communauté

- Type PDU : il s’agit du type de requête
- ID request : permet d’associer les réponses aux requêtes
- Statut erreur : type d’erreur (0 si aucune)
La principale faiblesse de cette version est qu’elle n’était absolument pas

sécurisée. En effet, il n’y a pas de cryptage des données et aucune
authentification. C’est pour cela qu’une version sécurisée de SNMPv1 appelée
SNMPSec a existé mais elle n’a quasiment jamais été utilisée.
2.3.3.2 SNMP v2
La seconde version est une évolution de la version SNMPv1. SNMPv2 qui

a été publiée sous l’ensemble de propositions de standards Internet. Il s’agit
d’un avant-projet de standard, il rajoute de la sécurité avec SNMPsec mais
aussi de nouvelles opérations. Cette version est toujours restée expérimentale
et a laissé place à la version 3. De nombreuses évolutions ont existé sans
jamais être adoptées : SNMPv2p, SNMPv2c, SNMPv2u…
2.3.3.3 SNMP v3
La version 3 de SNMP a permis essentiellement d’introduire la sécurité

des transactions. Elle comprend l’identification des deux parties qui
communiquent mais s’assure aussi que les messages échangés ne puissent pas
être lus par n’importe qui.
La sécurité est basée sur différents concepts différents :
USM (User-based Security Model)
USM permet d’assurer plusieurs fonctions :
Authentification
L’authentification permet de s’assurer que le paquet n’est pas modifié

pendant la transmission et que le mot de passe est valide. Elle se fait grâce à

ANNÉE 2007
HMAC-MD5-96 ou HMAC-SHA- 96 qui sont deux fonctions d’hachage. Grâce à

ceci tous les paquets vont être authentifiés, mais cette authentification ne nous
garantit pas encore la confidentialité des données.
Le cryptage
Le cryptage permet de s’assurer que personne ne puisse décrypter un
message SNMP échangé sur le réseau. La version 3 de SNMP utilise pour cela le
cryptage symétrique DES avec des clés de 64 bits.
L’estampillage du temps
Lors de l’envoi d’une requête SNMP, le cryptage et l’authentification ne

permettent pas d’éviter qu’une personne récupère cette requête et la
retransmette plus tard sur le réseau (Replay Attack). C’est pour cela que l’on a
un timestamp de 150s sur les messages qui nous assure qu’il sera
automatiquement refusé une fois ce délai passé.
VACM (View Access Control Model)
Le VACM permet de contrôler les différents accès à la MIB. Il est possible

de restreindre l’accès en lecture et en écriture pour un utilisateur ou un groupe
d’utilisateurs.
Le format d’une trame SNMP v3 est très différent de celui de la version 1 :

ANNÉE 2007
Les informations contenues dans cette trame sont relativement différentes:
• msgVersion : pour snmpv3, on place 3 dans ce champ. On place 0

pour SNMPv1
• msgID : l’identifiant du message
• msgMaxSize : la taille maximale d’une réponse à une requête
• msgFlags : il s’agit de différents types de drapeaux (sur 3 bits):
- précise si une réponse est attendue
- précise si on a utilisé du cryptage
- précise si on a utilisé l’authentification

ANNÉE 2007
• msgSecurityModel : type de sécurité utilisé pour encrypter le reste

du paquet
• msgSecurityParameters : paramètres de sécurité. Ce bloc n’est pas
défini dans SNMPv3 et a été standardisé par le module de sécurité
DES
• scopedPDU : message SNMP
2.4 Pourquoi l’entreprise a-t-elle besoin de la supervision ?
Pour répondre à l'augmentation de la production, pour satisfaire aux

besoins exigeants des clients ainsi qu’aux normes mondiales de qualité de
service, la supervision du réseau informatique de l'entreprise est devenue
importante avec les nombreux équipements informatiques qu’il contient.
Devant cette situation, la supervision du réseau devient indispensable. Les
entreprises ont donc réfléchi à la possibilité de mettre en place des applications
ou des outils capables de surveiller leurs réseaux informatiques, quel que soit
leur état technique.
La supervision manuelle (traditionnelle) d'un réseau informatique n'est
pas efficace quand une entreprise a un nombre assez important d’équipements
informatiques ou réseaux à superviser et le pourcentage des interventions
techniques par rapport à une période de temps définie est moindre en
comparaison avec l'utilisation des outils qui aident à la résolution des
problèmes.
Devant cette situation, et du fait de l'importance de la gestion du temps
dans une entreprise, cette dernière a envisagé de mettre en place des
applications ou des outils permettant la bonne supervision du réseau
informatique afin de gagner du temps dans les différentes interventions
techniques faites par les gens de DSI et de fournir un niveau supérieur de
qualité de service (QoS); le gain de temps permet le gain d'argent, ce point
étant la clé de tout investissement économique.
La réduction des coûts de la maintenance des équipements informatiques
et l'harmonisation des ressources informatiques grâce à l’utilisation des outils

ANNÉE 2007
de la supervision sont d'autres raisons qui s'ajoutent pour forcer les entreprises
à la recherche de solutions efficaces.
2.5 Les équipement concernés par la supervision
Quand une entreprise a déjà ou qu’elle souhaite la mise en place d'une

application d’un outil pour la supervision de son réseau informatique, cette
entreprise désire que les solutions de cet outil touchent le maximum
d’équipements informatiques et réseaux, fixes ou mobiles, passifs ou actifs et
quel que soit leur degré technologique, parmi ces équipement on peut citer :
• Routeurs
• Switchs
• Serveurs
• Ordinateurs, …
Sans oublier la supervision des liaisons spécialisées (LS), des LS Internet
et des connexions ADSL, ainsi que la supervision des services réseaux comme
(HTTP, POP3, SMTP, FTP,…).

ANNÉE 2007
Partie III : cahier des charges
3.1 Etat actuel du parc informatique du site OCEAN
Le parc ou le réseau informatique du site OCEAN est assez grand, vu le

nombre de liaisons spécialisées, de routeurs, de Switchs, de serveurs, de
postes de travail qu’il contient, mais sa supervision reste manuelle.
Comme déjà vu auparavant, le site contient deux activités différentes ;
chaque activité a son réseau avec un nombre d’équipements importants, et la
supervision des deux réseaux plus le réseau admin (personnels Back Office) est
faite manuellement par les administrateurs réseaux de site, chaque
administrateur réseau étant dédié à une activité. La supervision est basée sur
des éléments basiques qui sont intégrés dans le système et dont on peut citer
des exemples :
- Les routeurs sont surveillés via le Telnet d’inviter de commande de
Windows
- Les interfaces réseau des routeurs et des Switchs sont surveillées via des
outils graphiques des constructeurs si il y en a ou via le Telnet.
- Aucune visibilité sur le taux d’utilisation des LS.
- Aucune visibilité sur les paquets perdus ou reçus sur les liaisons dans un
moment donné.
- L’état du trafic général des données sur le réseau est chose inconnue.
- Aucun historique sur l’utilisation des liaisons ni sur le trafic réseau, pour
en dégager les périodes dont il y a un pic dans le réseau
- Manque des reportings des données de tout le réseau
- Manque de visibilité sur l’utilisation des CPU et de la RAM des serveurs
- Manque d’historique sur le taux des pannes d’un équipement réseau
- Le temps passé pour cibler un problème réseau est important vu le
manque de la visibilité sur les équipements informatiques.
- Manque de l’architecture générale du réseau informatique
- Le temps des interventions peut être grand suite au manque des outils
qui permettent de déterminer l’origine du problème.

ANNÉE 2007
3.2 Les inconvénients
D’après la situation du réseau de ce site qui a été décrite dans la partie ci-
dessus, toute personne de métier peut en déduire que le réseau de cette
entreprise est mal surveillé, et la méthode utilisée actuellement a beaucoup
d’inconvénients parmi lesquels :
- La qualité de service (QoS) envers les utilisateurs est inférieure
- Perte de temps important dans la phase de détermination de la nature du
problème réseau
- Manque des alertes à chaud sur tout équipement réseau
- Si une interface réseau tombe en panne l’administrateur n’est au courant
que si l’utilisateur l’appelle pour lui signaler le problème
- Les outils de base qui sont utilisés restent très limités en temps de
performance et de disponibilité des données
- Aucune vision générale sur le réseau en temps réel
- Manque des statistiques sur l’utilisation des ressources réseaux
- Manque des statistiques sur les pannes des équipements réseaux
- Le travail de l’administrateur réseau est désorganisé
- La non disponibilité des données concrètes de réseau informatique afin de
les communiquer à la direction du site si elle en a besoin
3.3 Les besoins
Avant d’entamer la partie des tests des outils de la supervision à laquelle

nous avons consacré toute une partie, nous allons lister d’abord les attentes de
l’équipe SI et ce qu’ils souhaitent avoir dans la nouvelle organisation de leur
réseau à l’aide d’un outil de la supervision.
Ces besoins qui seront détaillés ci-après seront une base que nous
suivrons pendant toute la durée des tests des outils de la supervision et ils
seront aussi une base qui va nous permettre de choisir l’outil qui répond au
mieux aux attentes de l’équipe SI du site OCEAN.
Avant de commencer la description des besoins selon la nature des
équipements réseaux, l’outil de la supervision doit donner la possibilité de

ANNÉE 2007
configurer et de paramétrer une architecture globale du réseau afin que cette

architecture soit dynamique en terme de changement d’état d’un équipement
(actif ou passif) ; par exemple, si une interface réseau d’un routeur est down,
l’outil doit la marquer en rouge ou par une couleur différente.
Les besoins sont listés ci-dessous selon la nature de l’équipement réseau
pour lequel nous souhaitons avoir une surveillance.
• liaison spécialisée (LS)
Pour toute LS, qu’elle soit nationale ou internationale ou Internet, les

informations que nous souhaitons avoir sont regroupées ci-dessous.
- être averti via tous les moyens possibles et à chaud lorsqu’une liaison
spécialisée est down et lorsqu’elle devient up après tout
dysfonctionnement
- les taux d’occupation ou d’utilisation d’une LS dans un moment donné
- taux des paquets reçus dans une période choisie
- taux des paquets perdus dans une période donnée
- la possibilité de définir des seuils des LS
- possibilité de paramétrage des alertes
- avertir à chaud lors de l’existence des perturbations au niveau de la
liaison
- être averti en temps réel si une LS dépasse le seuil défini, si le taux des
paquets perdus est important.
- possibilité d’analyser tout le trafic circulant sur les LS.
- toutes les informations demandées qu’elles soient bien structurées, bien
organisées et accessible à partir d’une interface web
- avoir une visibilité sur tout l’historique de l’utilisation de la LS et de
l’exporter vers un fichier Excel par exemple
• Routeur/PIX (pare-feu matériel)/Switch
L’outil doit avoir la possibilité de surveiller tous les équipements réseaux

(routeur, PIX et Switch), quels que soient leurs tailles, leurs marques, leurs
gammes et leurs degrés technologiques.

ANNÉE 2007
- être averti à chaud si une interface réseau sériale ou Ethernet est down
- toute interface down doit être marquée par une couleur différente sur
l’équipement dans l’architecture globale de réseau
- être averti à chaud si une interface réseau sériale ou Ethernet est
redevenue up
- être averti sur l’état des ports (down, up) et de le marquer avec une
couleur différente sur l’architecture générale du réseau
- avoir la possibilité de définir des seuils
- avoir la possibilité de visualiser la configuration de routeur
- être averti en temps réel s’il y a une congestion au niveau du routeur
- avoir une visibilité sur le taux d’utilisation des CPU et de la RAM de
routeur, Switch et PIX
• Serveur
L’outil doit avoir la possibilité de surveiller toute sorte de serveurs quelles que
soient leurs marques, leurs gammes, leurs tailles ainsi que leurs performances
sans oublier l’indépendance du système d’exploitation.
L’application est sensée répondre aux besoins cités ci-dessus :
- fournir des informations et une visibilité sur l’utilisation de CPU, la RAM et
la taille (utilisée et libre) des disques dur ou des partitions d’un serveur
- avoir la possibilité de définir des seuils sur n‘importe quelle information
désirée
- envoyer des alertes pour tout changement au niveau des parties
suivantes
• interface réseau (down ou up)
• taux d’utilisation de CPU, RAM et si la taille libre de disque dur ou
d’une partition est insuffisante.
• sur un service bloqué ou qui n‘est pas bien monté
- possibilité de marquer la partie qui est a eu un changement au niveau du
serveur avec une couleur différente
- possibilité de reporter toutes les informations vers un fichier Excel ou
HTML par exemple.

ANNÉE 2007
• tous les échanges effectués entre les stations clientes et le serveur

ne doivent pas occuper le réseau et ne doivent pas créer des
problèmes de saturation du réseau. Tous les échange de requête et
réponse doit également être sécurisés au niveau du réseau et
l’interface de supervision doit être verrouillée par un mot de passe
et rendue accessible aux seules personnes concernées.
• Services réseaux
L’application de la supervision est sensée superviser tous les services

réseaux parmi lesquels on peut citer SMTP, POP3, HTTP, FTP, SNMP ou ICMP.
Pour la partie du reporting, l’outil doit fournir des mécanismes qui

permettent de reporter toutes sortes d’informations qui sont en relation avec la
supervision des équipements souhaités vers une base de données afin
d’exporter toutes ces informations vers des fichier Excel ou HTML par exemple.
A la fin de ce petit descriptif des besoins, nous pouvons les résumer en trois
principales catégories qui sont indispensables pour la supervision de notre
réseau informatique :
• avoir un schéma global de tout le réseau
• définir des seuils et avoir des alertes à chaud (temps réel)
• reporting de toutes les informations

ANNÉE 2007
PARTIE IV : les outils de la supervision
4.1 Nagios
4.1.1 Présentation
Nagios est un logiciel qui permet de superviser un système d'information

complet.
C'est un logiciel libre, il est sous licence GPL. Les fonctionnalités de Nagios sont
nombreuses.
La première particularité de Nagios est la modularité. En effet des plugins
peuvent être ajoutés pour effectuer des taches spécifiques. De nombreux
plugins sont déjà écrits par la communauté Nagios mais nous pouvons en écrire
nous-même pour des taches spécifiques.
Nagios va être couplé avec Oreon qui va permettre de faciliter l’administration
mais aussi remonter les graphes et effectuer du reporting. Nagios intègre bien
sûr une notification par mail ou sms selon le jour et l’heure. Voici les
avantages/inconvénients de Nagios :
4.1.2 Fonctionnalités
• Surveillance des services réseaux (SMTP, POP3, HTTP, NNTP, PING, etc.).
• Surveillance des ressources des hôtes (charge processeur, utilisation des
disques, etc.).
• Système simple de plugins permettant aux utilisateurs de développer
facilement leurs propres vérifications de services.
• Notifications des contacts quand un hôte ou un service a un problème et
qu’il est résolu (via email, pager, ou par méthode définie par l’utilisateur).
• Possibilité de définir des gestionnaires d’événements qui s’exécutent pour
des événements sur des hôtes ou des services, pour une résolution des
problèmes
• Interface web, pour voir l’état actuel du réseau, notification et historique
des problèmes, fichiers log, etc.
• Plugins existant pour utiliser MRTG ou RRDTool
4.1.3 Installation et configuration
4.1.3.1 Prérequis
4.1.3.1.1 Les dépendances
Avant d’installer Nagios et ses plugins, quelques dépendances doivent être

installées.
Un compilateur de C et C++ ainsi qu’un interpréteur PERL sont nécessaires
pour installer et utiliser Nagios et ses plugins:
Commande Fedora Core 5 :

ANNÉE 2007
yum install gcc gcc-c++ perl
(Installation de gcc, gcc-c++ et de Perl)
Note : On peut remplacer la commande « yum » par la commande « apt-get »

sur d'autres distributions Linux.
4.1.3.1.2 Compte Utilisateur «Nagios»
Pour éviter des problèmes de sécurité, il est préférable de lancer «Nagios» avec
un compte utilisateur normal.
Nous allons donc créer un nouveau compte utilisateur et créer les répertoires
avec les droits nécessaires.
Commandes FC5 :
addgroup nagios
adduser –g nagios nagios
mkdir /usr/local/nagios
chown nagios.nagios /usr/local/nagios
(On crée un nouveau groupe, utilisateur et répertoire et on donne les droits à

cet utilisateur sur ce répertoire).
4.1.3.1.3 Apache
Etant donné qu’on utilisera une interface web pour consulter les résultats des
commandes de Nagios, l’installation d’un serveur web est requis (dans mon
cas, j’ai utilisé « Apache »).
Commande FC5 :
yum install httpd
(Installation d’Apache)
4.1.3.2 Installation Nagios
Télécharger les fichiers binaires de Nagios sur le site officiel à l’adresse

suivante: http://www.nagios.org/download/

ANNÉE 2007
Décompresser l’archive téléchargée précédemment :
tar xzf nagios-2.5.tar.gz
Aller dans le répertoire décompressé puis exécuter la commande suivante :
./configure --prefix=/usr/local/nagios --with-cgiurl=/cgi --with-htmurl=/html

--with-nagios-user=nagios --with-nagios-group=nagios
Puis exécuter les commandes suivantes successivement :
make all
make install
make install-init
make install-config
La commande « make install-config » installera des fichiers de configuration par

défaut dans le répertoire « /usr/local/nagios/etc ».
L’inconvénient est que les fichiers de configuration en exemple ont la
nomenclature suivante « filename.cfg-sample ». Vous devrez renommer tous
les fichiers de configuration avec la commande suivante :
mv filename.cfg-sample filename.cfg
4.1.3.3 Installation des plugins
Les plugins sont des scripts de Nagios qui permettent d’exécuter diverses
commandes sur les hôtes à surveiller.
Exemple de plugin : « check_process » est un plugin qui vous permet de voir
combien de processus sont actuellement exécutés sur un hôte.
Télécharger l’archive de plugins sur le site official à l’adresse suivante:

http://www.nagios.org/download/
Décompresser l’archive téléchargée précédemment :
tar xzf nagios-plugins.tar.gz
Aller dans le répertoire décompressé puis exécuter les commandes suivantes :

ANNÉE 2007
./configure --prefix=/usr/local/nagios/libexec
make && make install
Tous les plugins sont installés dans le répertoire /usr/local/nagios/libexec et se

présente sous forme de script.
D’autres plugins sont disponibles et peuvent nécessiter la présence d’un
interpréteur PERL.
Vous pouvez télécharger davantage de plugins sur : http://www.nagiosexchange.org/
4.1.3.4 Mise en place de l'interface Web
Afin d’accéder à l’interface web de Nagios des modifications doivent être faites
dans le fichier de configuration d’Apache (httpd.conf).
Ouvrir le fichier httpd.conf à l’aide d’un éditeur de texte puis insérer les lignes
suivantes :
ScriptAlias /nagios/cgi-bin /usr/local/nagios/sbin

AllowOverride AuthConfig
Options ExecCGI
Order allow,deny
Allow from all
Alias /nagios /usr/local/nagios/share

Options None
AllowOverride AuthConfig
Order allow,deny
Allow from all
Note : Il est important que le ScriptAlias soit positionné avant l’Alias sinon une
erreur lors du lancement du service Apache apparaîtra.
4.1.3.5 Les fichiers de configurations
Lors de la création des fichiers de configuration avec la commande « make

install-config », les fichiers suivants ne sont pas créés:
hosts.cfg
hostgroups.cfg
contacts.cfg
contactgroups.cfg
services.cfg
timeperiods.cfg
Par contre, le contenu des fichiers ci-dessus est stocké dans un seul fichier
nommé « minimal.cfg ».

ANNÉE 2007
Pour pouvoir configurer plus facilement Nagios, il est conseillé de suivre cette
nomenclature.
Il est nécessaire de créer un à un les fichiers de configuration ci-dessus et de
copier le contenu du fichier « minimal.cfg » dans les fichiers respectifs.
4.1.3.5.1 nagios.cfg
Ce fichier est l’un des premiers fichiers de configuration a être édité. Il contient
le chemin des fichiers de configurations qui doivent être lus par Nagios ainsi
que des options additionnelles.
Tout d’abord, mettre en commentaire la ligne ci-dessous en ajoutant un « # »

en début de ligne :
#cfg_file=/usr/local/nagios/etc/minimal.cfg
Puis enlever les « # » des lignes suivantes afin qu’elles ne soient plus en
commentaire :
cfg_file=/usr/local/nagios/etc/hosts.cfg
cfg_file=/usr/local/nagios/etc/hostgroups.cfg
cfg_file=/usr/local/nagios/etc/contacts.cfg
cfg_file=/usr/local/nagios/etc/contactgroups.cfg
cfg_file=/usr/local/nagios/etc/services.cfg
cfg_file=/usr/local/nagios/etc/timeperiods.cfg
Une option facultative mais qui peut être intéressante à connaître. Vous pouvez
changer le format de la date qui est affiché lors de vos enregistrements :
Modifier la ligne « date_format=us » par la ligne ci-dessous :
date_format=euro
4.1.3.5.2 checkcommands.cfg
Ce fichier contient les commandes des plugins par défaut de Nagios. Si vous
souhaitez automatiser les nouveaux plugins installés, il vous faudra ajouter les
commandes dans ce fichier.
Les commandes se présentent sous la forme suivante :
# 'check_process' command definition

ANNÉE 2007
define command{
command_name check_process
command_line $USER1$/check_process -H $HOSTADDRESS$ - w $ARG3$ -c $ARG4$
4.1.3.5.3 contactgroups.cfg
Ce fichier permet de définir un groupe de contact. Les définitions répertoriées

dans ce fichier permettent de différencier les groupes à avertir en cas d’alertes.
Le contenu de ce fichier sera utilisé dans le fichier « contacts.cfg ».
Saisir la définition ci-dessous dans votre fichier de configuration :
define contactgroup{
contactgroup_name nagios
alias Nagios Administrator
members nagios
4.1.3.5.4 contacts.cfg
Le fichier contacts contient l’ensemble des personnes à avertir en cas d’alertes

(avertissement ou alerte critique). On peut y définir l’intervalle de notification,
des droits, des commandes ainsi que l’adresse email du destinataire.
Saisir la définition ci-dessous dans votre fichier de configuration :
define contact{
contact_name nagios
alias Nagios Admin
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email nagios@localhost.localdomain

ANNÉE 2007
4.1.3.5.5 hostgroups.cfg
Ce fichier contient les groupes d’hôtes à surveiller. Il est possible de créer

plusieurs groupes d’hôtes comme un groupe pour les utilisateurs, un groupe
pour les serveurs, un groupe pour les matériels réseaux, etc.…
Dans notre cas, j’ai défini un groupe pour des stations de travail:
define hostgroup{
hostgroup_name workstation
alias Poste de Travail
members localhost
4.1.3.5.6 hosts.cfg
Ce fichier se distingue par 2 parties : l’une regroupant des options diverses à

appliquer aux hôtes sous forme d’un modèle et l’autre de descriptions d’hôtes
utilisant ces modèles.
Il est possible de créer plusieurs modèles selon la nature de l’hôte à surveiller
(station de travail, serveurs, commutateurs…)
Modèle d’un hôte à surveiller :
define host{
name Modele_hote ; The name of this host template

notifications_enabled 1 ; Host notifications are enabled
event_handler_enabled 1 ; Host event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program restarts
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST
A TEMPLATE!
Description hôte :
# Since this is a simple configuration file, we only monitor one host - the # local host (this machine).
define host{

ANNÉE 2007
use Modele_hote ; Name of host template to use

host_name localhost
alias local machine
address 127.0.0.1
check_command check-host-alive
max_check_attempts 10
check_period 24x7
notification_interval 120
notification_period 24x7
notification_options d,r
contact_groups nagios
Vérifier que l’option « use » d’un hôte correspond bien à un modèle prédéfini
(comme pour Modele_hote).
4.1.3.5.7 services.cfg
Dans le même principe que le fichier « hosts.cfg », on a une partie pour créer
des modèles contenant des options de service et une autre partie pour fournir
une description du service utilisé
define service{
name Modele_service ; The 'name' of this service template

active_checks_enabled 1 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted
parallelize_check 1 ; Active service checks should be parallelized (disabling this can lead to major
performance problems)
On définit l’hôte que l’on va surveiller et à la ligne « check_command » on

définira la commande à utiliser avec ses arguments.
Dans le cas présent, on définit « localhost » comme étant l’hôte à analyser et

on utilisera la commande « check_ping » préalablement définit dans le fichier
« checkcommands.cfg » comme étant la commande pour pinguer l’hôte :
# Définir le service "ping" pour pinguer la machine en local
define service{
use Modele_service
host_name localhost
service_description PING
is_volatile 0
check_period 24x7

ANNÉE 2007
max_check_attempts 4
normal_check_interval 5
retry_check_interval 1
contact_groups nagios
notification_options w,u,c,r
notification_interval 960
notification_period 24x7
check_command check_ping!127.0.0.1
4.1.3.5.8 timeperiods.cfg
Ce fichier permet de définir les intervalles de surveillance que se soit pour

exécuter une commande, des logs, des notifications par emails.
Il est possible de définir plusieurs intervalles de surveillance selon les besoins.
Le template ci-dessous permet une surveillance toutes les 24 heures et 7 jours

sur 7 :
define timeperiod{
timeperiod_name 24x7
alias 24 Hours A Day, 7 Days A Week
sunday 00:00-24:00
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-24:00
4.1.3.5.9 cgi.cfg
Ce fichier définit les options d’affichage et les paramètres de sécurité pour

l’interface web de nagios.
Il faut donc activer l’authentification afin de limiter l’accès à l’interface web.
Editer le fichier « cgi.cfg » et redéfinir les paramètres suivants :
use_authentication=1
authorized_for_system_information=nagiosadmin
authorized_for_configuration_information=nagiosadmin
authorized_for_system_commands=nagiosadmin
authorized_for_all_services=nagiosadmin
authorized_for_all_hosts=nagiosadmin
authorized_for_all_service_commands=nagiosadmin
authorized_for_all_host_commands=nagiosadmin

ANNÉE 2007
4.1.3.6 Les services
4.1.3.6.1 Vérification de l'intégrité des fichiers de configurations
Avant de démarrer Nagios, on doit procéder à la vérification des fichiers de

configurations. Si une erreur est présente dans un des fichiers, le processus
sera stoppé immédiatement après son lancement.
Pour vérifier les fichiers de configurations, taper la commande :
/usr/local/nagios/bin/nagios –v /usr/local/nagios/etc/nagios.cfg
Si aucune erreur n’est signalée, vous pouvez désormais démarrer Nagios.
4.1.3.6.2 Démarrer Nagios
Vous pouvez lancer Nagios de plusieurs façon mais la plus simple reste le
démarrage de service. Etant donné que nous avons exécuté précédemment la
commande « make install-init » pour créer notre script de démarrage.
Exécuter la commande suivante pour démarrer Nagios :
service nagios start
Dans le cas où vous n’auriez pas installé le script, exécuter la commande

suivante :
/usr/local/nagios/bin nagios –d /usr/local/nagios/etc/nagios.cfg
(L’option « -d » démarre Nagios en mode daemon).
Vérifier que le service est bien lancé avec la commande :
ps –aux | grep nagios
4.1.3.6.3 Démarrer Apache
Une fois que Nagios est démarré, lancer le service Apache afin de consulter les
résultats des commandes via l’interface web.

ANNÉE 2007
Exécuter la commande suivante :
service httpd start
4.1.4 Oreon
Oreon consiste à inclure dans une solution complète l’ensemble des services de
Nagios existants, ainsi que des modules d’installation et de configuration du
serveur Nagios. Oreon est en perpétuelle évolution grâce au monde open
source très actif autour de ce projet, ce qui permet une aide en cas de
problème à travers les différents forums et des évolutions logicielles permettant
une efficacité accrue et la correction de bug logicielle rapide.
4.1.4.1 Avantages d’Oreon
• Une installation complète et automatique des packages nécessaires à

l’utilisation de NAGIOS.
• Facilite la configuration de Nagios.
• Une découverte automatique du réseau et une configuration des
ressources découvertes (serveurs, équipements réseaux...) au niveau du
serveur de supervision. L’utilisateur n’aurait plus qu’à sélectionner la
ressource à superviser et lui indiquer quel type d’alerte qu’il souhaite
remonter.
• Graphe le résultat des alertes, système de reporting.
4.1.4.2 Inconvénients d’Oreon
• Requiert plus de ressources matérielles

• Architecture logique de l’application :
Sur le schéma suivant on peut voir qu’il y a deux façons pour superviser notre
réseau.
En effet Nagios permet de faire une supervision passive et active grâce aux
plugins NRPE et NSCA.

ANNÉE 2007
La configuration de Orean Avec Nagios
4.1.5 Test
La solution de supervision Nagios/Oreon remplit tout à fait ses tâches en nous

proposant un outil relativement simple à configurer (au contraire de Nagios seul
où il faut éditer les fichiers de configuration avec un éditeur...) et qui convient
tout à fait à une supervision, même de grande échelle.
Concrètement, quand on rencontre des problèmes, Nagios peut envoyer des

notifications aux contacts administratifs selon différentes voies (le courrier
électronique, le message immédiat, SMS, etc.). Puis via un navigateur web on
peut consulter à chaque instant les renseignements de statut actuels, les
historiques et les rapports

ANNÉE 2007
Avant d’explorer quelques résultats obtenus lors de notre test, nous allons vous
citer quelques points forts et faibles de nagios :
4.1.5.1 Avantages de Nagios
 Surveillance des services de réseau (SMTP, POP3, HTTP, FTP,

etc.).
 Surveillance des ressources d'hôte (la charge d'unité centrale, le
disque et l'usage de mémoire, les processus, journaux
d’événements, etc.).
 Notifications des services ou hôtes qui rencontrent des problèmes
(via le courrier électronique, ou d'autre méthode définie
d'utilisateur), mais aussi le suivi des incidences.
 Possibilité de concevoir des plugins personnalisés.
 Capacité de définir une hiérarchie réseau, permettant la
localisation du problème.
 Capacité de définir des procédures de résolution proactive face à
des événements.
 Consultation des statuts via une interface Web.
4.1.5.2 Inconvénients de Nagios
 Configuration compliquée qui oblige une très bonne connaissance de

Nagios.
 Graphes pas assez clairs.
 Administration compliquée.
4.2 La plate-forme HP Open View NNM (Network Node

Manager)
4.2.1 Présentation
HP Open View (HPOV) est une plate-forme proposant un ensemble d’outils

d’administrations développé par la compagnie HP, cette application client
serveur conçue pour aider les administrateurs systèmes à détecter, prévenir ou
résoudre les problèmes qui peuvent survenir sur des équipements réseau, sur
des systèmes ou des applications. Elle utilise pour ce faire des agents que l’on
installe sur les machines à superviser et qui communiquent avec le gestionnaire
par l’intermédiaire de procédures d’appels à distance. Elle récupère et
interprète aussi les messages SNMP émis par diverses entités. Elle permet
l’exécution automatique d’actions sur événements ou bien à intervalle régulier.
Elle ajoute à la vue classique de la liste d’alarmes une vue graphique du service
supervisé, qui permet après configuration d’avoir une vision précise d’une

ANNÉE 2007
application distribuée et de son comportement, accélérant ainsi le processus de

traitement des problèmes.
Les offres de HP Open View ont comme rôle la gestion de bout en bout des
services IT, HPOV compte sept solutions mentionnées ci-dessous :
• Gestion de l’infrastructure : cette partie contient un des modules les plus
populaires en matière de supervision de réseaux IP: NNM pour Network
Node Manager qui offre de nombreuses fonctionnalités basées sur SNMP,
cet outil que nous détaillerons dans les parties qui suivent
• Gestion des applications : HPOV Application Management (en anglais)
pour que les applications critiques soient toujours disponibles et de
fonctionnement correct ; dans cette solution nous trouvons HPOV
Operations, HPOV Performance, HPOV OVIS et les Smart-Plug-Ins
• IT Service Management (CMDB) : pour la gestion complète du cycle de
vie des services IT
• Business Service Management : cette solution propose un monitoring des
processus de l’entreprise d’un point de vue métier
• Gouvernance des systèmes d’information : afin de répondre aux
exigences de respect des nouvelles réglementations en matière de
gestion de l’infrastructure informatique
• HPOV Configuration Management : offre une approche unique de la
gestion des changements et des configurations avec le principe de gestion
de l’état désiré
• Gestion des identités : grâce aux modules HPOV Select Identity, Select
Access et Selection Federation, il est possible de gérer de façon
centralisée des accès à tous les services et ressources du domaine
informatique

ANNÉE 2007
NNM est un outil central de la plate-forme HPOV, Ce logiciel a été développé

afin de mieux traiter les problèmes qui peuvent survenir dans un réseau
informatique comme, par exemple, les réseaux locaux Ethernet, les
commutateurs Ethernet et les routeurs IP.
• C’est un outil à la fois de supervision mais aussi de management des
équipements qui peuvent faire partie de ce réseau.
• L’outil présente la cartographie de l'infrastructure IP, et offre des
fonctionnalités de gestion des configurations, des alarmes et des
performances,
• Il permet par exemple de savoir en temps réel l’état (up/down) d’un
routeur.
• En temps qu’Agent SNMP il permet de prévoir les problèmes et de faire
du management à distance.
• C'est une application fédératrice des outils d'administration utilisés qui
fonctionne en mode distribué.
• C’est un outil complet en matière d’administration réseau.
4.2.2 Fonctionnement
Pour gérer l'ensemble des éléments actifs de notre réseau, on utilise une
station de gestion : NMS (Network Management Station) qui contient le
protocole de gestion de réseaux et les applications de gestion. Elle permet de
récolter et d'analyser les données relatives aux équipements physiques
connectés au réseau (ponts, routeurs, hubs) et de les gérer.
La station de gestion interroge les agents pour observer leur
fonctionnement et leur envoie des commandes pour leur faire exécuter
certaines tâches. Les agents renvoient les informations requises aux
stations de gestion.
La NMS est composée d’une console centrale, de différents programmes, et
bases de données qui interagissent entre eux.
L’architecture pour NNM est la suivante :

ANNÉE 2007
Quelques explications sont ici nécessaires.

Au lancement de NNM, ovstart lance les différents processus de NNM. Ceux-
ci sont managés par ovspmd. Ce dernier gère et synchronise les différents
processus de NNM. Sur Windows 2000, ovspmd est lancé en tant que
service. Les principaux processus sont :
• Pmd ( HP Openview Post Master Service) : gère les applications et les
processus qui utilisent le protocole SNMP
• Ovalarmsrv : c’est un processus qui tourne en arrière-plan et qui gère
les informations sur toutes les alarmes reçues suite à un événement.
• Ovw : processus de l’interface graphique de NNM. Il fournit un plan
graphique de l’environnement administré. Le tout est organisé de
façon hiérarchique : chaque plan contient des sous plans jusqu’à ce
que l’on arrive au niveau des interfaces des différents nœuds.
• Ovwdb : c’est un processus qui tourne en arrière-plan et qui
maintient la base de donnée des objets qu’utilise ovw. Il met à jour
cette base de donnée pour que ovw puisse afficher correctement la
topologie du réseau.
• Ipmap : c’est une application intégrée à ovw qui lit les données
concernant la topologie grâce à ovtopmd et « écoute » les
événements sur la topologie IP et utilise ces derniers pour exhiber la
topologie IP du réseau. Celle-ci est montrée sous forme hiérarchique
avec initialement 4 niveaux : le niveau Internet, le niveau réseau, le
niveau segment, le niveau nœud.
• Netmon : c’est le processus qui découvre les nœuds et les
supervise. C’est un processus essentiel et central de NNM qui
interagit avec de nombreux autres processus.
Netmon fait différentes requêtes : envoi de messages ICMP (ping) pour

ANNÉE 2007
sonder les nœuds, envoi de messages SNMP pour connaître l’état des
nœuds. Au début, netmon part de la station manager et regarde la
passerelle par défaut, il fait un ping sur la celle-ci. A la réception de la
réponse de ce ping, il fait un snmpwalk (parcours de toutes les variables
MIB) sur la passerelle ; ensuite, il regarde dans la table de routage de
cette dernière ainsi que dans sa table ARP et ping toutes les entrées.
Puis, pour celles qui répondent, il fait des snmpwalk. Et ainsi de suite
sur chaque élément trouvé. Quand il aura établi une topologie stable du
réseau, il enverra des ping à intervalle de temps régulier.
Quand netmon détecte un changement, il met à jour la base de donnée
(topology database) à travers ovtopmd et envoie l’événement approprié
à pmd. Ce dernier enregistre cet événement dans event database et le
transfère à ipmap, ovactiond et xnmevent . A la réception de ce
message, ipmap met à jour le plan et la map database ; xnmevents,
pour sa part, met à jour le navigateur d’alarmes.
4.2.2.1 Découverte et Cartographie automatique du réseau
NNM possède un ensemble de processus qui tourne en tâche de fond et qui

propose une des fonctionnalités les plus intéressantes de ce logiciel : la
découverte automatique des entités IP, ces dernières sont alors cartographiées
pour représenter une vue logique de canaux de communications existant entre
la plate-forme de supervision et les entités découvertes.
La représentation alors obtenue n’est pas forcément une traduction fidèle du
réseau au niveau physique. Néanmoins elle est représentative des capacités de
la station de gestion à fournir des informations précises et pertinentes sur les
entités du réseau ainsi que de la topologie d’interconnexion.
Pour obtenir un tel dynamisme cartographie automatique, NNM fait tourner un
service (netmon).
4.2.2.2 La collecte d’informations critiques
Au-delà de l’automatisation de la découverte, NNM embrasse complètement

l’environnement SNMP en implémentant le modèle d’administration de cette
norme. La plate-forme se positionne en manageur et va donc permettre aux
administrateurs de solliciter les différents nœuds gérés du réseau pour obtenir
des informations adaptées à leurs besoins. Une automatisation ajustée des
sollicitations à la criticité des entités du réseau offre une traduction quasi-
temps réel du statut de ces derniers. NNM prend à sa charge de traduire les
réponses de ces requêtes graphiquement : les changements d’état des nœuds
du réseau alors obtenus sont explicités par une modification de la couleur des
symboles associés. SNMP offrant à NNM une connaissance fine des
interdépendances entre les diverses entités va pouvoir étendre les implications
d’une éventuelle panne et ainsi permettre un diagnostic plus rapide et juste des
administrateurs.
NNM en tant que manageur reçoit de la part des entités du réseau toutes les
alertes émises par les différentes ressources matérielles du réseau. NM permet
alors l’adaptation manuelle de réponses automatiques personnalisées à chaque
alarme reçue, induisant ainsi une proactivité des réponses aux événements

ANNÉE 2007
survenus et fournissant au réseau les moyens de se réparer par lui-même, ou de

mener des tâches d’évaluations des symptômes des pannes.
Pour permettre aux administrateurs de récupérer de plus amples informations
sur des stations et postes de travail, les versions récentes de NNM incluent le
standard DMI du DMTF qui, à l’instar d’un environnement NNM, permet une
gestion de sollicitation et remontée d’alarmes avec des protocoles plus
spécifiques et adaptés à ce besoin précis.
4.2.2.3 Les bases de données et l’analyse
Les bases de données opérationnelles de NNM, carte, topologie, tendance, et

événement peuvent être considérées comme une base de données logique
simple. Ces bases stockent les données opérationnelles employées par NNM,
rendant les informations critiques rapidement disponibles :
 La base objet : elle contient les informations sémantiques sur les
symboles des cartes. L’information est générique c’est-à-dire qu’elle n’est
pas adaptée aux besoins spécifiques de l’utilisateur. Les informations sur
les objets liés aux symboles sont uniques et représentent les propriétés
de ce dernier, comme par exemple le sysObjectID.
 La base des cartes : elle contient les informations de présentation de
chaque carte : les objets s’y trouvant, leur emplacement et leur symbole.
 La base de la topologie : elle gère les informations critiques au sujet des
nœuds IP. Cela inclue : l’état de ceux-ci, ainsi que le temps de dernière
modification la prochaine fois qu’un contrôle devra être effectué. Cette
base permet de fournir ces informations aux nombreux services en
charge de contrôler un disfonctionnement éventuel.
 La base des événements : elle contient tous les événements et alarmes
reçus par la plate-forme de supervision et présente la première source
d’information pour le service de corrélation des remontées d’alarmes ainsi
que pour le navigateur d’alarmes qui présente graphiquement l’ensemble
des alertes triées par catégorie.
 La base des tendances : elle est liée aux services snmpCollect et stocke
pour lui les informations de ses différentes actions. Celles-ci sont par
exemple exploitées graphiquement lors de la génération des comptes-
rendus graphiques.
« L’entrepôt de données » (Data Warehouse) est une base de données

relationnelle qui stocke les données exportées des bases opérationnelles et
permet ainsi aux administrateurs de définir leurs propres comptes-rendus.
Pour résumer les fonctionnalités de NNM se déclinent ainsi :
 Cartographier automatiquement l’ensemble du réseau et établir une

norme visuelle de changement de couleur des nœuds du réseau pour indiquer
les changements de statuts de ces derniers.
 Collecter les informations critiques du réseau et maintenir une notation
dynamique des alarmes indispensables aux administrateurs.

ANNÉE 2007
 Mettre en correspondance les informations collectées pour aider les

administrateurs à déterminer la source des problèmes éventuels.
 Maintenir une base de données permettant l’extraction d’informations
pour simplifier une analyse de l’historique des événements.
 Permettre la génération automatique de comptes-rendus graphiques.
4.2.3 Installation
NNM a été installé sur une station HP qui fait tourner le système d’exploitation
Windows XP SP2. Cette machine qui est NMS pour notre projet est dotée d’une
mémoire vive d’une taille de 512Mo et d’un espace disque important pour
installer tous les modules nécessaires pour le bon fonctionnement de NNM. La
version de NNM installée est 7.01. Préalablement il est obligatoire d’installer
une base de données Oracle, la version installée sur cette machine est 8.01, il
faut ajouter également au système d’exploitation les composantes du serveur
Apach, les composantes IIS et les composantes de protocole SNMP.
Puisqu’on a fait tourner NNM sur une machine Windows, l’installation de ce
dernier est facile et simple en même temps, à part quelques paramètres à
renseigner lors du déroulement de l’installation.
Quant à l’agent, il doit être installé dans tous les éléments que l’on souhaite
superviser, par une installation manuelle.
4.2.4 Configuration
Avec le logiciel NNM, l’administrateur réseau n’a pas besoin de réviser tous les
guides et tous les catalogues afin de le configurer, puisque ce dernier, et avec
ces moyens dont il dispose, facilite la configuration.
La partie la plus lourde dans une configuration d’un outil de la supervision est
considérée comme un jeu d’enfant, car NNM permet à la découverte
automatique des éléments réseaux d’un parc informatique via le service
netmon, décrit ci-dessus. Les parties restantes dans la configuration de NNM
consistent sont les maps, polling et alarmes.
4.2.4.1 Map
Les équipements du réseau sont affichés sur des cartes. Les périphériques et
les sous réseaux peuvent être organisés en sous cartes, pour une meilleure
organisation. Elles contiennent des équipements de différents types et ne
provenant pas forcément d’un même constructeur.
- la présentation de différents éléments de la map en couleur différente

- la visualisation d’une façon simultanée de plusieurs sites d’une seule ou
de différentes zones géographiques
Dans cette version de NNM, l’application nous signale par l’intermédiaire d’une
dizaine de couleurs l’état courant d’un nœud du réseau en changeant son icône.
Voici les plus importantes :

ANNÉE 2007
- L’état Critical, représenté par une icône rouge, nous signale que l’élément
est « down ».
- L’état Normal, représenté en vert, l'objet est managé et il n’y a aucun
problème.
- L’état Unmanaged, représenté en blanc, l’appareil n’est pas managé.
- L’état Unknown, représenté en bleu, aucun rapport sur le statut du
matériel, soit il n’a pas encore répondu soit il n’est pas dans la liste de
polling.
4.2.4.2 Polling
C’est la fonction qui permet de savoir si un périphérique est en fonctionnement,

éteint ou injoignable. Une requête est envoyée à l’objet managé lui demandant
simplement de répondre. Si le périphérique répond, il fonctionne, dans le cas
contraire l’application déclenchera une alarme.
Seuls les éléments présents dans la liste de polling - Polling List - seront
managés. D’ailleurs c’est par l’intermédiaire de cette liste que nous pouvons
configurer la fréquence de polling selon les besoins de l’entreprise, car cela peut
impliquer une charge supplémentaire importante sur le réseau si beaucoup
d’objets sont managés.
4.2.4.3 Alarme
NNM signale le changement d’état d’un périphérique managé par l’intermédiaire

d’alarmes. Elles se configurent dans le Log Alarmes et peuvent être
paramétrées pour activer un programme, une alerte sonore, etc.
La gestion de différents type d’alarmes selon leurs criticité, est faite par
l’administrateur réseau, c’est lui qui détermine le degré de la criticité des
informations du matériel supervisé ; pour ce type d’informations remontées en
alarme on trouve (critique, important mais non critique, warning et normal) ;
chaque type d’alarme est présenté par une couleur différente qu’on peut
personnaliser, il y a aussi la possibilité de cumuler les alarmes de tous les sites
configurés dans une seule liste. Par exemple elles peuvent tout simplement
signaler le changement d’état d’un port sur un switch ou un routeur.
4.2.5 Test
Avec la mise en place de la version d’évaluation de NNM, l’étape la plus

importante de notre étude a commencé puisque nous sommes appelés à faire
évaluer cette version de NNM sur le réseau de OCEAN.
Dès la première ouverture de la console de NNM, ce dernier a pu schématiser
une grande partie du réseau, grâce à sa fonction de découverte automatique,
l’architecture réseau est présentée malgré le manque de quelques
équipements.

ANNÉE 2007
Avant d’explorer quelques résultats obtenus lors de notre test, nous allons citer
quelques points forts et faibles de NNM :
4.2.5.1 Avantages
 NNM grâce à SNMP présente un moyen de supervision des ressources du

réseau efficace qui offre un pilotage intuitif et des informations fortement
valorisées.
 La plate-forme s’est imposée comme l’une des références de la
supervision de réseaux et représente une solution professionnelle de
qualité.
 Une prise en compte des services du réseau par ce manageur offrirait une
réponse globale aux besoins de la supervision d’un réseau IP,
fonctionnalité dont la mise en place reste essentielle.
4.2.5.2 Inconvénients
 NNM ne propose pas automatiquement de mesures de réponses aux

événements (même si elle le permet) et ne tire pas profit de ces
informations pour proposer une analyse et une remontée des points
stratégiques ou critiques du réseau (goulots d’étranglements, problèmes
techniques fréquents, etc.).
 L’automatisation des réponses ne peut être effectuée que manuellement
par un administrateur qui aura développé des scripts de réponses
spécifiques à une alarme ou un ensemble d’alarmes. La spécification a
alors un coût très important puisque HPOV doit être en mesure de
traduire les événements envoyés par une ressource particulière, ce qui
impose que la plate-forme bénéficie des MIB adéquats. La librairie de
base de NNM est pauvre. Cela impose que les administrateurs de la plate-

ANNÉE 2007
forme connaissent très précisément les alarmes constructrices générées

lorsqu’un événement survient, et les ressources pour les traduire.
 NNM ne propose pas non plus d’interfaçage de base avec un serveur mail.
C’est un point qui limite les temps de réaction d’un processus d’escalade
dans la résolution des pannes. Les administrateurs ne seront tenus au
courant des événements que s’ils consultent l’interface graphique ou les
logs et comptes-rendus de la station de gestion. L’information est à leur
initiative alors que la pro-activité sous-entend une automatisation
complète des remontées d’événements.
 Une plate forme très lourde
 Pour avoir plus de services et fonctionnalité il faut acheter les modules
dédiés
 Le prix est très élevé
Après avoir complété le schéma réseau détecté par NNM en ajoutant les
éléments manquants, nous avons commencé notre test point par point :
La supervision des liaisons spécialisées (LS) n’est pas permise par la version
de NNM que nous avons utilisée. De ce fait le test sur le flux des LS a été écarté
de notre étude sur NNM.
Equipements réseau : NNM donne une importance à la supervision de ces
(routeur, Switch, PIX), la surveillance se concentre surtout sur l’état des ports
ou des interfaces de ces équipements. L’élément réseau est présenté avec tous
les ports qu’il contient sur le schéma général, et avec le changement de la
couleur d’un port par exemple (en rouge) on peut être conscient du
changement de statut qui a eu lieu. NNM permet d’avoir beaucoup
d’informations sur ces éléments comme leurs OS, des informations sur le CPU
et la mémoire vive, le nombre de paquets envoyés, reçus et perdus.
Les informations présentées par NNM sont variées et l’administrateur réseau a
la possibilité de les consulter via le navigateur web (HTML)
La supervision des services réseaux est permise sous NNM
Pour la partie des alarmes, NNM a des mécanismes qui lui permet de faire des
remontées en temps réel selon les seuils définis. NNM utilise des moyens pour
avertir l’administrateur, par le changement de la couleur, l’affichage d’une
alerte, par l’envoi d’un mail et même d’un SMS, bien que nous n’ayons pas la
possibilité de tester ce dernier.
Le service reporting de NNM n’est pas à la hauteur, puisque les informations
présentées sont peu explicites.
4.3 Tivoli Netview

4.3.1 Présentation
En 1997, IBM proposait la plate-forme Netview 6000 v2. L’architecture de cette
plate-forme est orientée vers les réseaux IP. Tivoli racheté par IBM en 1996,
est la marque IBM pour l’ensemble des solutions d’administration du système
d’information de l’entreprise. Tivoli apporte des solutions d’administration
ouvertes englobant les réseaux, les systèmes, les applications et les échanges

ANNÉE 2007
interentreprises. Ces solutions allient interopérabilité et évolutivité. Conçues

pour faciliter la gestion des systèmes d’information et optimiser les
performances de l’entreprise, elles balayent tous les aspects de la gestion, de la
technologie, de l’infrastructure aux nouveaux périphériques, en passant par les
applications, l’e-business et les services administrés, indépendamment des
réseaux et des utilisateurs. Les fonctions couvrent les divers aspects de la
sécurité, les applications métier et les bases de données, dont on peut citer
quelques exemples des logiciels de la plate-forme Tivoli
• Administration : des logiciels qui offrent des solutions complètes qui

garantissent la fiabilité de l’infrastructure et la qualité des services. Ces
services permettent d’identifier et de résoudre les problèmes de manière
proactive pour optimiser les performances, exemples :
 IBM Tivoli NetView

 IBM Tivoli Monitoring solutions
 IBM Tivoli Business Systems Manager
 IBM Tivoli Cofiguration Manager
 IBM Tivoli Remote Control
• Sécurité : Ces solutions permettent de déployer rapidement les projets e-
business tout en réduisant les risques, assurent une mise en œuvre cohérente
de la sécurité et des politiques de protection des informations personnelles
 IBM Tivoli Identity Manager

 IBM Tivoli Risk Manager
 IBM Tivoli Privacy Manager for e-businsess
• Stockage : Ces solutions vérifient la disponibilité des applications métier,

optimisent la protection des données et l’utilisation des ressources
 IBM Tivoli Storage Resource Manager

 IBM Tivoli Storage Manager
4.3.1 Fonctionnalités
IBM Tivoli NetView est une solution évolutive et globale du réseau distribué qui
permet de donner de la souplesse à la gestion des réseaux. Il permet la
disponibilité des systèmes critiques d'entreprise et la résolution rapide des
problèmes. Il fait la découverte des réseaux TCP / IP, l'affichage des topologies,
la corrélation et la gestion des événements via SNMP, NetView surveille le
réseau et recueille des données sur la performance. Parmi les fonctionnalités
les plus importantes dans cette plate-forme sont :
 Supervision de tout le réseau, même la zone DMZ ainsi que tout le réseau
derrière un pare-feu

ANNÉE 2007
 Supervision de toute sorte de routeurs même s’ils contiennent du MPLS,

Netview fournit des outils de diagnostic pour avoir une visibilité sur le
statut des ports des équipements réseaux
 Tivoli NetView SmartSets permet de grouper les ressources réseaux par
type, emplacement, fournisseur, les services offerts ou d'autres
caractéristiques. De ce fait l’administrateur peut gérer un ensemble des
ressources comme s’il s’agit d’un seul appareil
 Intégration Cisco : Tivoli Netview s’intègre avec Cisco CiscoWorks2000 et
prévoit la configuration de l'unité pour aider à gérer efficacement les
dispositifs Cisco. Les consoles Web de Tivoli NetView et CiscoWorks2000
travaillent toutes les deux pour aider à simplifier la gestion, la
configuration et la disponibilité du matériel Cisco
 Réponse automatique à un événement : Tivoli NetView utilise des règles
de corrélation d'événements qui peuvent construire des directives à
mettre en œuvre afin d’aider à diagnostiquer la racine des problèmes
sans signaler toutes les manifestations symptomatiques.
 Possibilité de gérer le réseau à partir d’un navigateur Web ou à partir
d’une console, sans oublier la possibilité d’envoyer des ping ou des tracert
vers les équipements réseaux.
 Élaboration des rapports sur les tendances et l'analyse du réseau
4.3.3 Installation
La version d’évaluation Tivoli NetView a été installée sur une machine qui a PV
3.0Ghz comme processeur et 1Go de la RAM, l’outil a été installé sur le système
d’exploitation Windows XP SP2. Lors de l’installation, l’administrateur réseau
doit s’attacher à renseigner quelques paramètres parmi lesquels :
 Il faut sélectionner l’option « server »
 Il faut rentrer le mot de passe qui va permettre la gestion de l’outil à
partir de la console ou le navigateur Web
 Il est préférable de laisser les noms de communauté SNMP en blanc
 Le choix d’un des domaines suivants : sous-réseau local uniquement,
réseau fédérateur uniquement ou tous les réseaux
 La saisie du nom de hôte sur lequel réside le serveur d'événements et le
choix de son système d’exploitation
 Dans la zone « Listening port of the event server », il faut taper 5529
puisque nous avons un serveur d'événements Windows
4.3.4 Configuration
Sur la partie de la configuration de Tivoli NetView, l’administrateur réseau a la

possibilité de spécifier quelques paramètres selon la particularité de réseau à
superviser. Tivoli NetView dispose d’un paramètre qui permet de définir des
ressources réelles comme critique et non critique en utilisant l'agrégation
priorité.

ANNÉE 2007
On peut définir aussi la priorité sur une agrégation de la ressource des

ressources Propriétés portable pour une ressource sélectionnée. Quand une
véritable ressource change de statut, de l'état d'un total de la ressource, qui est
une partie est fixée comme suit:
- Le statut de la mère globale de la ressource est déterminé par l'état réel
de la ressource et de ses frères et sœurs
- Le statut des grands-parents globaux de la ressource est déterminé par
les statuts des ressources réelles au titre de la maison mère.
Les éléments de la console de l’administration de NNM peuvent être

paramétrés ; parmi ces éléments on peut citer :
- l’interconnexion de tous les équipements réseaux actifs, leurs couleurs,
ainsi que leurs symboles
- alarmes : cette partie est aussi gérable par l’administrateur réseau,
puisqu’il a la possibilité de renseigner les informations critiques de chaque
équipement réseau et de choisir la manière dont il veut être informé du
changement de statut de cet équipement.
4.3.5 Test
En faisant une comparaison entre les fonctionnalités de Tivoli Netview et notre

cahier de charges, nous pouvons rapidement déduire quels sont les points
manquants sur cet outil de IBM.
Pour la supervision des équipements réseaux, et sans la présence de

CiscoWorks2000, Tivoli Netview ne sera pas capable de faire une supervision
totale de ces équipement, sachant que la surveillance des ports ou les
interfaces d’un routeur est très importante car si ce dernier est tombé en panne
tout le réseau sera impacté.
L’analyse de flux réseau est possible sous Tivoli Netveiw, les statistiques
affichées par ce dernier sont variées ; de plus nous trouvons un descriptif des
statistiques sur l’utilisation des services réseaux selon le taux de leurs
utilisations dans le réseau informatique.
4.3.5.1 Inconvénients
- une plate forme chère

- pour avoir des services supplémentaires sur Tivoli Netview il faut acheter
des modules à part
- un outil très lourd qui demande beaucoup de ressources afin d’assurer la
bonne surveillance du réseau

ANNÉE 2007
SOLUTION CHOISIE
Pourquoi Nagios ?
Outre le fait que Nagios est un outil de supervision gratuit, nous nous sommes
également basés sur les fonctionnalités qu’il propose ; sa réponse au cahier des
charges défini dans la troisième partie de cette étude est satisfaisante, sans
oublier que c’est un outil open source qu’une grande communauté de
développeurs enrichit de nombreux plugins liés à des services bien précis pour
la supervision d’un réseau informatique.
En plus des points cités ci-dessus sur le choix de Nagios, avec sa mise en place
sur le réseau de site OCEAN, va permettre au groupe phone de bien déterminer
ses besoins en terme de supervision réseau, cette dernière est considérée
comme élément essentiel de projet de la centralisation des systèmes
d’informations qui a été procédé par le groupe.

ANNÉE 2007
CONCLUSION
Comme nous l’avons explicité dans notre étude, la supervision réseau est un
des moyens indispensables pour favoriser la croissance de rendement d’une
entreprise. Sur le marché, on trouve de nombreux outils libres ou propriétaires.
Le propos de cette étude était de comparer l’outil gratuit Nagios avec les deux
outils de la supervision les plus utilisés dans le monde, NNM de HP et Tivoli
Netview d’IBM. Après les recherches et les tests effectués sur les outils cités ci-
dessus en se basant sur le cahier des charges, la solution que nous avons
retenue est l’outil Nagios.
Ce rapport de stage nous a permis d’acquérir maintes connaissances dans le

monde de la supervision des réseaux informatiques, et notamment sur le
principe et le fonctionnement du fameux protocole SNMP, ainsi que sur le
principe et les fonctionnalités de quelques outils de la supervision comme
Nagios, NNM et NetView.

ANNÉE 2007
GLOSSAIRE
CPU: Central Processing Unit

DMZ : Zone Démilitarisée
DSI : Département du Système d’Informations
EGP: Exterior Gateway Protocol
FAI : Fournisseur d’Accès Internet
FTP: File Transfert Protocol
GPL: General Public License
HP: Hewlett Packard
HPOV: HP Open View
HTML: HyperText Markup Language
HTTP: HyperText Transfer Protocol
ICMP: Internet Control Message Protocol
IETF: Internet Engineering Task Force
IP: Internet Protocol
IT: Information Technology
LS: Liaison Spécialisée
MIB: Management Information Base
MRTG: Multi Router Traffic Grapher
NMS: Network Management Station
NNM: Network Node Manager
OID: Object identifier
PA: Phone Assistance
PDU: Protocol Data Unity
POP3: Post Office Protocol 3
QoS: Quality of Service
RAM: Read Acces Memory
RRDTool : Round Robin Database Tool
SAV: service après-vente
SI: Système d’Informations
SMTP: Simple Mail Transfert Protocol
SNMP: Simple Network Management Protocol
TCP: Transmission Control Protocol
TCP/IP: Transmission Control Protocol / Internet Protocol
UDP: User Datagram Protocol
V: Version
VACM: View Access Control Model
USM: User-based Security Model
URLOGRAPHIE

ANNÉE 2007
www.nagios.org  site de l’outil Nagios
www.nagiosexchange.org  site des plugings Nagios
www.oreon-project.org  site de Oreon
www.openview.hp.com  site de NNM de HP
www.ibm.com/software/tivoli/products/netview/  site de Tivoli Netview
www.supinfo-projects.com site des projets des élèves ingénieurs de supinfo
www.commantcamarche.com  site de communauté informatique
www.google.com  le fameux moteur de recherche

Etude Des Outils de La Supervision Reseau

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Etude Des Outils de La Supervision Reseau

Загружено:

Авторское право:

Доступные форматы

ETUDE DES OUTILS DE LA

Génie Informatique & Réseaux

Parmi cette équipe, nous tenons à remercier Mr Rachid ELLIASMINE

Un grand merci également à notre professeur de réseau au sein de EMSI qui

PHONE ONLINE 2 EMSI

PARTIE I : avant Propos et présentation de la société .................................. 7

1.1 Aperçu sur le métier des centres d’appels au Maroc ............................... 7

PARTIE II : Mécanismes de la supervision d’un parc informatique ............... 13

2.1 Qu’est-ce qu’est la supervision ? ....................................................... 13

Partie III : cahier des charges .............................................................. 24

PHONE ONLINE 3 EMSI

3.1 Etat actuel du parc informatique de site OCEAN .................................. 24

Partie IV : les outils de la supervision .................................................... 29

4.1 Nagios ........................................................................................... 29

PHONE ONLINE 4 EMSI

4.1.4.1 Avantages d’Oreon ............................................................ 39

4.2 La plate-forme HP Open View (Network Node Manager) ....................... 41

4.3 Tivoli ............................................................................................. 50

PHONE ONLINE 5 EMSI

Les réseaux informatiques, présents à l’heure actuelle dans de

PHONE ONLINE 6 EMSI

Partie I : Avant-propos et présentation de la société

1.1 Aperçu sur le métier des centres d’appels au Maroc

Le phénomène des centres d’appels est arrivé au Maroc voici quelques

La tendance au développement des centres d'appels au Maroc se poursuit

En dehors de l’axe Casa Rabat, de nouvelles villes marocaines deviennent

PHONE ONLINE 7 EMSI

Le chiffre d'affaires a été presque multiplié par quatre passant de 830

Le nombre total de positions est estimé à plusieurs milliers. Non

Les éditeurs et les équipementiers des centres d'appels rivalisent avec

1.2 Présentation générale de Phone Assistance

Phone Assistance (PA) a été fondée par le groupe marocain Saham de

Vision stratégique de développement, qualité des prestations et

Dans un marché en forte croissance, Phone Assistance, avec l’introduction

PHONE ONLINE 8 EMSI

1.2.1 Activité selon le site PA

1.2.2 Présentation Générale du site OCEAN

PHONE ONLINE 9 EMSI

Le site Océan est le quatrième site du groupe Phone Assistance dans

L’architecture de l’organisation du site OCEAN

R esponsable des Affaires

C oordinateur R H C oordinateur Production C oordinateur SI

PHONE ONLINE 10 EMSI

1.2.3 Les missions des équipes systèmes d'informations de OCEAN

Le département du système d’information (DSI) du site OCEAN possède

PHONE ONLINE 11 EMSI

L’architecture réseau du site OCEAN

Réseau de prod1 Réseau de prod n

PHONE ONLINE 12 EMSI

Partie II : les mécanismes de la supervision d’un réseau

2.1 Qu’est-ce qu’est la supervision ?

Dans le jargon informatique, la supervision est la surveillance du bon

2.2 Le principe de la supervision

Une grande majorité des logiciels de supervision sont basés sur le

La plupart de ces outils permettent de nombreuses fonctions dont les

• surveiller le système d’information

D’après les fonctions décrites ci-dessus et réalisées par l’outil de la

PHONE ONLINE 13 EMSI

2.3 Le protocole SNMP

Créé en 1988 par l’IETF(Internet Engineering Task Force), SNMP signifie

L'agent pourra aussi envoyer des alertes lui-même si l'administrateur

PHONE ONLINE 14 EMSI

Généralement, l'administrateur possède un outil permettant de centraliser