République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Université de Carthage

Institut Supérieur des Technologies de

l’Information et de la Communication

Projet de fin d’etudes

Présenté en vue de l’obtention de la

Licence Fondamentale en Télécomunication

Mention : Télécommunications
Spécialité : Télécommunications

Mise en place d’une solution de surveillance

Réseau

Par
Zayani Rouaa

Charaabi Rawdha

Réalisé au sein de Médis

Soutenu publiquement le 24 mai 2019 devant le jury composé de :

Président : M. Aymen Chouk, Directeur technicommercial nord
afrique Feinmetall
Rapporteur : Mme Imen Samaali, Enseignante, ISTIC
Examinateur : Mme Ouertani Rym, Enseignante, ISTIC
Encadrant professionnel : M. Rami OBEY, Administrateur systèmes et réseaux,
Les laboratoires Médis
Encadrant académique : Mme Nessrine Ben Rejeb, Enseignante, ISTIC

Année Universitaire : 2019-2020

 République Tunisienne
Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique

Université de Carthage

Institut Supérieur des Technologies de

l’Information et de la Communication

Projet de fin d’etude

Présenté en vue de l’obtention de la

Licence Fondamentale en Télécomunication

Mention : télecommunication
Spécialité : télecommunication

Mise en place d’une solution de surveillance

Réseau

Par
Rouaa Zayani

Rawdha Charaabi

Réalisé au sein de Médis

Autorisation de dépôt du rapport de Projet de Fin d’Etudes :

Encadrant professionnel : Encadrant académique :

Le : Le :

Signature : Signature :
 Dédicaces

A mes chers parents,

A toute ma famille,

ZAYANI Rouâa

i
 Dédicaces

Je dédie ce travail à :

A mes chers parents,

pour tous leurs sacrifices, leur amour, leur tendresse, leur soutien et leurs prières tout au
long de mes études.

A mon cher frère, Yassin,

pour son appui et son encouragement.

A ma chère soeur Sawssen,

pour ses encouragements permanents et son soutien moral.

A toute ma famille,
pour leur soutiens tout au long de mon parcours universitaire.

CHARAABI Rawdha

ii
 Remerciements

Nous profitons de cette occasion pour adresser nos sincères remerciements a toutes les
personnes qui ont contribué de prés ou de loin à la réalisation de ce travail. Nous tenons à
remercier en premier lieu notre encadrant professionnel M. Rami Obay, administrateur
systèmes et réseaux à Médis. Son esprit professionnel, son accueil et son expertise qui ont
permis à ce travail d’aboutir.

Nous remercions également notre encadrante universitaire Mme. Nesserine Ben

Rejeb, maître assistante a l’Institut Supérieur des Technologies de l’Information et de la
Communication (ISTIC). Ses conseils nous ont aidés à surmonter beaucoup de difficultés,
nous la remercions chaleureusement pour sa pédagogie et sa patience sans oublier de
remercier toute l’équipe pédagogique de l’ISTIC pour l’aide théorique et pratique qu’ils
nous ont apporté.

iii
 Table des matières

Dédicace i

Remerciements iii

Introduction Générale 1

1 Cadre générale du projet et état de l’art 2

1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Missions générales . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Organigramme générale . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Direction du service informatique(GIT) . . . . . . . . . . . . . . . 4
1.2 Étude préalable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Étude théorique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Le concept de surveillance réseau . . . . . . . . . . . . . . . . . . . 6
1.3.2 Comparaison des différents logiciels de supervision réseau . . . . . . 6
1.3.3 NAGIOS CORE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Spécification des besoins et conception 14

2.1 Analyse et spécification des besoins . . . . . . . . . . . . . . . . . . . . . . 14
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.2 Spécification des besoins fonctionnels . . . . . . . . . . . . . . . . . 14
2.1.3 Diagrammes des cas d’utilisations . . . . . . . . . . . . . . . . . . . 15

iv
 2.1.4 Spécification des besoins non fonctionnels . . . . . . . . . . . . . . 17
2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Conception statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Conception dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Diagramme de séquence "Authentification" . . . . . . . . . . . . . . 21
2.4.2 Diagramme de séquence "Ajouter des équipements et des services" . 22
2.4.3 Diagramme de séquence "Ajouter des scripts" . . . . . . . . . . . . 23

3 Mise en œuvre de la solution 25

3.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Langages et bibliothèques utilisés . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1 Langages utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2 Bibliothèques utilisées . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Mise en place de Nagios et ses plugins . . . . . . . . . . . . . . . . . . . . 28
3.4 Supervision des machines/serveurs Windows . . . . . . . . . . . . . . . . . 28
3.5 Surveillance de la connexion internet . . . . . . . . . . . . . . . . . . . . . 30
3.6 Surveillance file d’attente des e-mails . . . . . . . . . . . . . . . . . . . . . 32
3.7 Surveillance de Symantec Backup Exec System Recovery 2010 . . . . . . . 35
3.8 Supervision des switchs/routeurs . . . . . . . . . . . . . . . . . . . . . . . 38
3.9 Notification par mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Conclusion Générale 42

Annexe 1, Installation de Nagios server sur Ubuntu 16.04 45

Annexe 2, Installation de NSClient++ sur le serveur Windows 48

Annexe 3, Configuration de SNMP sur le switch/routeur CISCO 50

v
 Table des figures

1.1 Organigramme de l’entrepise . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Architecture de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Architecture de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Plugins de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Diagramme de cas d’utilisation globale du système . . . . . . . . . . . . . . 15

2.2 Diagramme détaillé de cas d’utilisation "Ajouter des équipements et des
services" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Diagramme détaillé de cas d’utilisation "Ajouter des scripts" . . . . . . . . 17
2.4 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 Diagramme de séquence "Authentification" . . . . . . . . . . . . . . . . . . 21
2.6 Diagramme de séquence "Ajouter des équipements et des services" . . . . . 22
2.7 Diagramme de séquence du cas d’utilisation "Ajouter des scripts" . . . . . . 23

3.1 Caractéristiques de la machine . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Principe de fonctionnement de check-nt . . . . . . . . . . . . . . . . . . . . 29
3.3 Configuration des sevices de l’hôte ’rami’ . . . . . . . . . . . . . . . . . . . 30
3.4 Test Connexion internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Ajout du du script check_ok.bat . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 Script de test de la fil d’attente . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 Fil d’attente du serveur EDGE . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8 Ajout du script test_queue.ps1 . . . . . . . . . . . . . . . . . . . . . . . . 34
3.9 Ajout du service de l’hôte EDGE . . . . . . . . . . . . . . . . . . . . . . . 34
3.10 Sauvegarde du lecteur (C :) planifié . . . . . . . . . . . . . . . . . . . . . . 35

vi
Table des figures

3.11 Sauvegarde du lecteur (C :) réussi . . . . . . . . . . . . . . . . . . . . . . . 36

3.12 Script de vérification de l’état du travail du Backup Exec . . . . . . . . . . 37
3.13 Historique de travaux détaillé . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.14 Principe de fonctionnement de check-snmp . . . . . . . . . . . . . . . . . . 38
3.15 Ajout de l’hôte et du service . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.16 Statut des services détaillé pour tous les hôtes . . . . . . . . . . . . . . . . 39
3.17 Configuration de POSTFIX . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.18 Définition du contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.19 Exemple de notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1 Installation des pré-requis . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2 Configuration de l’utilisateur et du groupe . . . . . . . . . . . . . . . . . . 45
3 Installation de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4 Configuration d’Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5 Test du serveur Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6 Configuration du NSClient++ . . . . . . . . . . . . . . . . . . . . . . . . . 49
7 Configuration du SNMP sur le switch . . . . . . . . . . . . . . . . . . . . . 50
8 Configuration de SNMP sur le routeur . . . . . . . . . . . . . . . . . . . . 51

vii
 Liste des tableaux

1.1 Tableau comparatif des outils de supervision gratuits . . . . . . . . . . . . 10

1.2 Explication des codes de retours . . . . . . . . . . . . . . . . . . . . . . . 12

viii
 Introduction Générale

Ces dernières années, l’énorme développement des réseaux informatiques et des nou-
velles technologies ne cesse d’évoluer afin de faciliter la vie quotidienne et professionnelle.
Jusqu’à présent, le réseau d’entreprise est une composante de l’informatique de l’entre-
prise relativement immuable. En effet, il est indispensable de veiller constamment à son
bon fonctionnement.
Ce travail est réalisé à Médis dans le cadre d’un projet de d’études afin d’obtenir une
licence fondamentale en télécommunication. Au sein de Médis, la surveillance et la bonne
gestion du parc informatique présente un enjeu majeur. Elle permet de prévenir les dé-
faillances et de réduire les coûts de fonctionnement du système informatique. L’entreprise
a trouvé nécessaire de concevoir et développer un outil de surveillance pour son réseau.
Durant ces quatre mois de stage de fin d’études, nous proposons un outil complet,
documenté, performant et qui permet de superviser en temps réel toutes sortes de res-
sources informatiques. Notre solution permet également de remonter des alarmes en cas
de problèmes. En effet, notre projet consiste à superviser un réseau grâce à l’outil Open
source «Nagios». En fait, nous apportons quelques modifications afin d’adapter "Nagios"
au besoin de Médis.

Le présent rapport se compose de trois chapitre. Le premier chapitre, décrit le cadre

générale du projet. Ce chapitre a été consacrée essentiellement à l’étude de différentes
solutions de supervision, afin de choisir la solution la mieux adaptée aux exigences des
administrateurs au sein de Médis. Le deuxième chapitre, a été consacré à l’analyse des
besoins et à l’étude conceptuelle de cette solution. Le troisième chapitre, consiste à la
réalisation de notre projet pour l’implémentation de la solution de surveillance réseau au
sein de Médis.

1
 Cadre générale du projet et état de l’art
1
Introduction
Notre objectif dans ce chapitre est de mettre le travail dans son contexte général.
En premier lieu, nous commençons par faire une présentation de l’organisme d’accueil
Médis ou nous avons effectuées notre stage, ensuite nous présentons le cadre et les fonc-
tionnalités de ce travail. En second lieu nous définissons les concepts de base et les dif-
férents logiciels existantes de supervision des réseaux, tout en s’intéressant à l’outil de
supervision «Nagios».

1.1 Présentation de l’organisme d’accueil

Dans cette partie nous présentons la mission et l’organigramme général de l’entreprise.

1.1.1 Missions générales

La société Médis :« les laboratoires de médicaments stériles de Nabeul » est une
entreprise pharmaceutique tunisienne anonyme fondé en juillet 1995, ayant pour mission
de fabriquer et commercialiser divers médicaments génériques de haute qualité, à des
coûts hautement compétitifs et selon des normes de Bonne Pratique de Fabrication (BPF)
destiné au marché tunisien et au marché d’exportation pour le traitement d’une diversité
de maladie. [1]
Bien que Médis soit relativement nouvelle, la compagnie a su développer une notoriété
et une présence stratégique sur la scène locale. La société occupe actuellement la troisième
place de l’industries pharmaceutiques tunisiennes.

2
Chapitre 1. Cadre générale du projet et état de l’art

MédiS est certifié :

-Certification de qualité : ISO 9001 version 2004.
-Certification de l’environnement et sécurité de travail : ISO 14001 version 2007.
-Certification d’hygiène, santé et sécurité : ISO 18001 version 2008. [1]

1.1.2 Organigramme générale

Médis possède une hiérarchie claire et opérationnelle définissant les fonctions et les
responsabilités de chaque département qui sont au nombre de sept constitués de services
et de directions et reliés à la direction générale.

Figure 1.1 – Organigramme de l’entrepise

La figure 1.1 montre que le siège social de Médis regroupe le développement des af-
faires, l’approvisionnement, les ressources humaines, ainsi que tous les autres services
associés aux productions et à la commercialisation des produits tels que les services de
Recherche et Développement (R&D), l’assurance qualité, le contrôle de gestion, les affaires

3
Chapitre 1. Cadre générale du projet et état de l’art

réglementaires et le service d’export. Dans ce qui suit, nous décrirons le fonctionnement

du service informatique.

1.1.3 Direction du service informatique(GIT)

Au sein de Médis, les systèmes d’information et les réseaux informatiques sont gérés
par la direction du service informatique appelé Groupe de la Technologie Informatique
(GIT).
Ce groupe est composé d’un effectif pluridisciplinaire de collaborateurs composé d’un di-
recteur de département, d’administrateurs qui se chargent de l’administration et de la
maintenance du réseau et des systèmes Unix, Windows... . Ce département fait également
appel à des ingénieurs, des techniciens de réseaux informatiques et des développeurs in-
formatiques..
Ce groupe offre plusieurs fonctionnalités à l’entreprise, le plus important c’est entretenir
le réseau, assurer la production et les traitements informatiques et veiller à la sécurité et
à la continuité des activités névralgiques de l’entreprise. [1]

1.2 Étude préalable

Dans cette partie nous faisons l’étude de l’existant tout en détaillant la problématique
et en analysant la solution proposée.

1.2.1 Étude de l’existant

Médis dispose d’un réseaux informatique composé globalement de :

— 400 Hôtes (320 postes clients et 80 industriels).

— 21 serveurs physiques et 4 virtuelles.

— 3 routeurs firewall.

— 12 switch coeur/access/distribution.

La figure 1.2 présente une vue globale de l’architecture réseau de l’entreprise qui se com-
pose de plusieurs sous réseaux. Le premier sous réseau est destiné aux utilisateurs Médis
connectés à l’Internet par l’intermédiaire d’une connexion faisceaux hertziens. Le deuxième
sous réseaux est dédié au réseau Wifi et connecté à l’Internet par l’intermédiaire de ligne
spécialisée cuivre. Ce dernier est utilisé comme Backup pour la connexion internet du

4
Chapitre 1. Cadre générale du projet et état de l’art

réseau Médis. Le troisième et le quatrième sous réseaux sont destinés au réseau industriel
Medis1 et Medis2 (comptage, etc.)

Figure 1.2 – Architecture de l’entreprise

Après avoir présenter l’architecture de l’entreprise, nous soumettons la problématique

qui nous a menées à mettre en place notre projet.

1.2.2 Problématique
Ce présent travail s’est déroulé dans un environnement comportant un parc informa-
tique important composé de machines et de serveurs locaux et distants. L’administrateur
est responsable de ses équipements, ce qui rend sa tache difficile. En effet, l’administra-
teur doit vérifier la disponibilité des équipements, maintenir leurs états, détecter leurs
défaillances ... . Son plus grand souci est la maintenance et la gestion des serveurs et des
équipements.
C’est pour cela que l’entreprise souhaite mettre en place une solution capable de faciliter
et d’organiser l’administration de son réseau informatique. Cependant, les solutions de
surveillance de réseaux peuvent avoir un cout considérable. Il existe des solutions gra-
tuites, mais ces solutions doivent être adaptées au besoins et spécificités de l’entreprise.
Notre objectif est de choisir la meilleur solution de surveillance gratuite et de l’adapter
au besoins de Médis.

1.2.3 Solution proposée

La gestion et la maintenance des serveurs et des équipements réseau étant le plus
grand souci de l’administrateur, nous avons jugées nécessaire de mettre en place un outil

5
Chapitre 1. Cadre générale du projet et état de l’art

de surveillance du réseau performant, souple et gratuit.

Notre solution propose de contrôler le fonctionnement du réseaux, anticiper les problèmes
en faisant remonter des informations sur l’état des équipements, détecter les pannes afin
d’offrir à l’administrateur la possibilité d’arriver à résoudre les problèmes rapidement.
De manière générale, notre solution est capable d’évoluer facilement et efficacement au
rythme des besoins de l’équipe. L’objectif de notre solution est de :
•Surveiller la disponibilité de ses équipements et leurs services (processeurs, mémoires,
disque dur, les états des ports, le trafic..).
•Surveiller la connexion Internet.
•Surveiller la fil d’attente des emails du serveur de messagerie.
•Informer l’administrateur par un e-mail en cas de problèmes.
•Présenter des statistiques des pannes par ressources et pour une période donnée.

1.3 Étude théorique

Dans cette section nous définissons la notion de supervision réseaux. Par la suite, nous
décrirons les différents outils de monitoring existants et nous étudierons le logiciel choisi
pour implémenter notre solution.

1.3.1 Le concept de surveillance réseau

Le concept de surveillance réseau s’est développé dans les années 1980 avec la proli-
fération de la mise en place des réseaux informatiques dans les sociétés. La supervision
réseau est devenu indispensable et s’impose dans la plupart des entreprises possédant
un parc informatique conséquent puisque elle est capable de diagnostiquer et d’identifier
des problèmes ultérieurs et souvent de réparer leurs pannes. En fait, elle représente un
gain important en temps. En résumé, l’objectif de ces solutions est de surveiller le bon
fonctionnement des réseaux informatiques. [2]

Il existe plusieurs logiciels gratuits et Payants. Nous présentons dans ce qui suit une
comparaison de ces différents logiciels de supervision.

1.3.2 Comparaison des différents logiciels de supervision réseau

Les solutions de surveillance et de contrôle distant peuvent être classées en deux
groupes open source et propriétaire.

6
Chapitre 1. Cadre générale du projet et état de l’art

Les logiciels propriétaires :

À côté des outils de monitoring open source, les solutions commerciales sont des pro-
duits vendus par des grandes sociétés. Ces logiciels payants sont couteux, et la personna-
lisation de leurs interfaces sont plus compliqués. Mais, ces logiciels sont sollicitées par les
entreprises avec des besoins de supervision réseau plus avancés.
Nous présentons dans ce qui suit, les logiciels propriétaires de supervision les plus connu
et utilisés dans les PME à savoir HP openView et Cisco Works. Mais il existe d’autre lo-
giciels payants de supervision tel que Dell OpenManage, Microsoft Windows Operations
Manager et IBM Tivoli Monitoring.

•Cisco Works est conçu pour détecter et organiser les informations relatives à la
connectivité des équipements Cisco et d’autres nœuds du réseau
sur une carte topologique facile à comprendre et à parcourir qui
fournie des informations telles que les seuils de trafic, les protocoles,
les problèmes de connexion et l’état des équipements. C’est une
solution économique et facile à déployer qui aide les administrateurs
de réseau à maximiser leur efficacité administrative et à limiter
le temps consacré à la gestion des ressources du réseau. Mais la
non disponibilité de ses codes sources présentent un inconvénient
aux clients qui veulent mettre à jour leurs applications selon leurs
besoins. [3]
•HP OpenView est une solution de supervision modulaire très complète développée
par HP. C’est l’un des logiciels majeurs de la supervision. En ef-
fet, ce logiciel permet le management des équipements réseaux et
son interface graphique permet d’afficher l’état courant des équipe-
ments. HP OpenView est basé sur SNMP pour dialoguer avec les
différentes machines. Il permet également de gérer les applications,
la disponibilité des périphériques, les conditions et l’état du réseau,
les performances du système, la maintenance des programmes et des
services, ainsi que les ressources de stockage. Ce logiciel est com-
posé de deux systèmes. Un système de Map (interface graphique
appelée MAP) pour l’affichage de l’état courant des équipements et
un système d’alarme intégré. [4]

7
Chapitre 1. Cadre générale du projet et état de l’art

Les logiciels open source :

Un Logiciel "libre" met à la disposition son code source au grand public avec la liberté
d’étudier et de modifier le code au besoins. Ces logiciels mettent également à la disposi-
tion des utilisateurs une documentation en ligne. Nous constatons que chaque logiciel de
supervision est caractérisé par un certain nombre de fonctionnalités. Nous décrivons dans
ce qui suit les différentes fonctionnalités des logiciels de supervision gratuit les plus utilisés
à savoir Zabbix, Nagios et centreon. Il existe d’autre logiciels gratuits de supervision tel
que OpenNMS, Zenoss, Hypric et Mon... .

•Zabbix C’est une solution de monitoring complète distribuée sous licence GPL
v2 dédiée pour surveiller en temps réel le statut de divers services réseau,
serveurs et autres équipements réseau. Cet outil offre une richesse des
sondes, la réalisation des graphiques, des cartes et de nombreuses façons
de présenter un aperçu visuel de l’environnement informatique avec son
interface Web native. Les données sont protégées à tous les niveaux avec
un chiffrement renforcé entre tous les composants Zabbix et l’adminis-
trateur est averti en cas de problème. [5]

8
Chapitre 1. Cadre générale du projet et état de l’art

•Nagios (Anciennement Net saint), ce logiciel de supervision de réseaux est consi-

déré comme étant la référence des solutions de supervision Open Source,
c’est un outil très complet qui peut superviser pratiquement n’importe
quelle ressource reposant aujourd’hui sur Nagios XI, Nagios Log Server,
Analyseur de réseau Nagios, Nagios Fusion et Nagios Core. Le personnel
informatique utilise Nagios pour surveiller les composants critiques de
l’infrastructure informatique, notamment les métriques système, les pro-
tocoles réseau, les applications, les services, les serveurs et l’infrastructure
réseau. Nagios envoie des alertes par courrier électronique ou par SMS
et offre aux administrateurs des notifications d’événements importants.
Ses rapports fournissent un enregistrement de l’historique des pannes, des
événements, des notifications et permettent d’identifier les mises à niveau
d’infrastructure nécessaires avant que des défaillances ne se produisent.
Mais il est difficile à installer et à configurer, ne permet pas d’ajouter
des hosts via le Web et il a besoin d’un autre outil comme CENTREON
pour faciliter sa configuration. [6]
•Centreon (Anciennement Oréon), initialement basé sur Nagios®. Centreon a par-
couru un long chemin depuis ses origines. Aujourd’hui il est une plate-
forme de supervision conviviale et puissante reposant sur Centreon En-
gine, Centreon Broker et Centreon Web. Les professionnels de l’informa-
tique qui recherchent la flexibilité et la puissance de solutions comme
Nagios® tout en regrettant leur complexité adoptent avec enthousiasme
la simplicité et l’évolutivité de Centreon qui est devenu le numéro 1 de
la supervision open source en France pour superviser la disponibilité des
services et la performance des réseaux. [7]

Le tableau 1.1 résume les différents critères fonctionnels de ces outils open source.

9
Chapitre 1. Cadre générale du projet et état de l’art

Critéres fonctionnels Centreon Nagios Zabbix

Environnement d’installa- Unix Unix Unix
tion
Base de donnée PHP C++ PHP, C, C++
Protocole SNMP, SMTP, SNMP, SMTP, HTTP, FTP,
POP3, NNTP, pop3, NNTP, SMTP, SSH,
ICMP, HLDP ICMP, HLDP IMAP
Gestion d’une authentifi- Oui Oui Oui
cation
Création des graphes Oui Non Oui
simples à partir des
mesures
Création de graphes com- Non Non Oui
plexes avec mise en rela-
tion des métriques des ser-
vices supervisés
Utilisation d’agents sur les NRPE , NSclient NRPE , NSclient Agent Win-
machines cibles dows/Unix
Installation et configura- Oui Non Oui
tion simple
Intégration simple d’un Oui Non Oui
nouvel hôte dans un sys-
tème de configuration cen-
tralisée
Possibilité de mettre en Oui Non Oui
place simplement une su-
pervision centralisée entre
plusieurs sous réseaux

Table 1.1 – Tableau comparatif des outils de supervision gratuits

Dans cette partie nous avons étudié les différentes solutions de supervision, afin de
choisir celle qui répond le mieux au besoins et aux exigences de l’administrateur. Notre
choix c’est tourné vers l’outil Nagios parce qu’il s’agit d’un logiciel libre, simple d’utili-
sation que nous pourrons adapté au besoin de l’entreprise Médis. Dans ce qui suit, nous
décrirons le logiciel de surveillance choisi NAGIOS.

10
Chapitre 1. Cadre générale du projet et état de l’art

1.3.3 NAGIOS CORE

Nagios® Core a été initialement conçu pour fonctionner sous Linux,
mais il est capable de surveiller des machines linux que windows et
toutes sortes systèmes d’exploitations. Nagios est capable également
de superviser des équipements réseaux (routeurs, commutateurs ..)
grâce au protocole SNMP et de surveiller les nœuds ainsi que les services spécifiés. En
fait, Nagios offre plusieurs fonctionnalités à savoir :

•La surveillance des services réseau tel que : SMTP, POP3, HTTP, NNTP, PING, etc.
•La surveillance des ressources de l’hôte tel que : charge du processeur, utilisation du
disque, utilisation de la mémoire, etc.
•Une interface Web facultative permettant d’afficher l’état actuel du réseau, l’historique
des notifications et des problèmes, etc.
•La conception des simples greffons (plugins) permettant aux utilisateurs de développer
facilement leurs propres contrôles de service.
•Les notifications par mail ou par SMS lorsqu’un problème survient sur un service ou
une machine.
•Un support pour l’implémentation d’un système de surveillance redondant.[8]

Nagios possède un principe de fonctionnement qui est basé sur le paradigme serveur-
greffon.

Figure 1.3 – Architecture de Nagios

La figure 1.3 montre l’architecture de Nagios qui est décomposée en 3 parties :

•Un ordonnanceur, chargé de contrôler quand et dans quel ordre les contrôles des
services sont effectués.

11
Chapitre 1. Cadre générale du projet et état de l’art

•Une interface graphique qui affiche de manière claire et concise l’état des services
surveillés. Cette interface est basée sur des CGI (Common Gateway Interface) fournis
par défaut lors de l’installation de Nagios, ses rôles est l’interprétation des réponses des
plugins pour les présenter dans l’interface.
•Des greffons.

Nagios Core ne possède aucun mécanisme interne pour surveiller le statut des hôtes et
des services sur le réseau. Contrairement au autres outils de surveillance, Nagios repose
sur des programmes externes appelés plugins ou greffons. En fait, ces plugins peuvent être
des fichiers binaires compilés et écrits en C, C++, etc ou des scripts qui sont exécutables
en shell, Perl, PHP, etc . En effet, pour déterminer l’état de l’hôte ou du service, Nagios
évalue le code de retour des plugins. Le tableau 1.2 présente les quatre états qui peuvent
avoir les services : [8]

Code retour Etat Signification

1 Ok Tout va bien
2 Warning Le seuil d’alerte est dépassé
3 Critical Le service a un problème
4 Unknown Impossible de connaître l’état du
service

Table 1.2 – Explication des codes de retours

En revanche, il est possible de créer notre propre plugin et l’interfacer avec Nagios
tout en respectant les codes de retours précédemment expliqués. La figure 1.4 présente
les nombreux plugins standards pour Nagios.

Figure 1.4 – Plugins de Nagios

12
Chapitre 1. Cadre générale du projet et état de l’art

Nous citons les plugins les plus utilisés tel que :

•Check_ping : Vérifie la présence d’un hôte.
•Check_http : Vérifie le service HTTP d’un hôte.
•Check_nt : Vérifie les différents états tel que ( l’état du disque dur, l’état du processeur,
l’état du mémoire ... ) sur des machines possédant un système d’exploitation Windows.
•Check_nrpe : Permet de récupérer les différents informations sur les hôtes.
•Check_snmp : Récupère les divers informations sur un équipement grâce au protocole
SNMP (Simple Network Management Protocol).
•Check_disk : Vérifie l’espace occupé d’un disque dur.
•Check_mysql :Vérifie l’état d’une base de données MYSQL.
•Check_tcp : Vérifie l’ouverture d’un port TCP.
•Check_ssh : Vérifie la présence d’un service SSH (Secure Shell : un protocole de
communication sécurisé).
•Check_users : Compte le nombre d’utilisateurs sur la machine locale.

Nous avons besoin de quelques plugins pour la réalisation de notre travail. En fait, nous
avons utilisés parmi les divers plugins précédemment définis check_nt, check_nrpe ,
check_snmp , check_ping , check_disk et check_http.

Conclusion
A travers ce chapitre nous avons situé le projet dans son cadre général. Nous avons
présentés l’entreprise d’accueil et l’étude de l’existant. Suite à cette étude nous avons
soulevées les problèmes que rencontre l’entreprise lors de l’administration de son réseau.
Nous avons décrit les logiciels existants d’administration réseau afin d’implémenter la
solution que nous jugeons la plus adapté au besoin de la société Medis. Dans le chapitre
suivant, nous présenterons la conception UML détaillée de notre système.

13
 Spécification des besoins et conception
2
Introduction
Après avoir présenté le cadre générale du projet, lors de ce chapitre nous nous intéres-
sons à l’analyse des différents besoins fonctionnels et non fonctionnels. Nous commençe-
rons par l’identification des différents acteurs puis nous exposerons la conception statique
et dynamique de notre solution à travers les diagramme de classes et de séquences.

2.1 Analyse et spécification des besoins

Dans cette section, nous analysons les besoins des utilisateurs afin de spécifier les
diagrammes de cas d’utilisations globales et détaillés.

2.1.1 Identification des acteurs

Nous avons distinguées un seul utilisateur qui interagit directement avec le système
étudié, c’est l’administrateur qui est le "end user". En effet, sa fonction est centralisé sur
la surveillance et l’administration réseau. En fait, l’administrateur est le seul responsable
du bon fonctionnement du système.

2.1.2 Spécification des besoins fonctionnels

Nous identifions nos besoins fonctionnels selon l’acteur mentionné, l’administrateur,
afin de mieux comprendre son rôle qui est basé sur :

•L’authentification pour accéder au système.

•La gestion des utilisateurs.

14
Chapitre 2. Spécification des besoins et conception

•La gestion en temps réel des équipements en récupérant les informations de leurs états.
•La réparation des pannes détectées par Nagios.

2.1.3 Diagrammes des cas d’utilisations

Nous exprimons dans ce qui suit, les besoins de l’administrateur par les diagrammes
des cas d’utilisations. La figure 2.1 présente le diagramme de cas d’utilisation globale de
notre système.

Figure 2.1 – Diagramme de cas d’utilisation globale du système

Ce diagramme nous permet d’identifier les différents actions réalisés par l’adminis-
trateur via le système Nagios. En effet, l’administrateur réseau a le droit d’ajouter des
équipements tel que des routeurs, des commutateurs, des serveurs et des machines... Il
peut également ajouter des services tel que Ping, disk-C, CPU et Memory usage... Ainsi
l’administrateur peut consulter leurs status et ajouter des scripts afin d’assurer la sur-
veillance réseau. L’administrateur peut également consulter la liste des alertes et la liste
des rapports survenues tel que alert history et rapports de disponibilité des machines et des
services. Afin d’accéder à toutes ces fonctionnalité, l’administrateur doit être authentifié.
Afin de mieux comprendre notre système, nous présentons le raffinement des différents
cas d’utilisation.

15
Chapitre 2. Spécification des besoins et conception

Diagramme de cas d’utilisation"Ajouter des équipements et des services"

La figure 2.2 présente le diagramme de cas d’ajout des équipements et des services.

Figure 2.2 – Diagramme détaillé de cas d’utilisation "Ajouter des équipements et des
services"

Dés que l’administrateur se connecte au serveur Nagios, il a le droit d’ajouter ses

équipements. En fait, il doit configurer les paramètres nécessaire tel que le nom d’hôte, le
nom complet de l’hôte et l’adresse IP. Ensuite, l’administrateur peut également ajouter
les services et les associer à leurs équipements. Donc, il doit définir les commandes qui
représentent ce qu’il veut obtenir comme informations sur le serveur Nagios. Si l’ajout des
équipements et des services est correctement configuré, ces derniers doivent apparaitre
sur l’interface web de Nagios.

16
Chapitre 2. Spécification des besoins et conception

Diagramme de cas d’utilisation "Ajouter des scripts"

La figure 2.3 présente le diagramme de cas d’ajout des scripts.

Figure 2.3 – Diagramme détaillé de cas d’utilisation "Ajouter des scripts"

Après son authentification, l’administrateur a le droit d’ajouter des scripts. Il peut exé-
cuter des scripts en local sur la machine Windows et retourner les informations ensuite à
Nagios via le plugin NRPE. En effet, l’administrateur doit installer sur la machine Win-
dows le logiciel NSclient++, configurer le serveur NRPE et ajouter le script au dossier
"scripts" du "nsclient ++". Il doit également éditer et configurer le fichier "nsclient.ini" afin
de permettre l’utilisation des scripts personnalisés. Enfin, il doit tester le plugin NRPE
sur le serveur Nagios.

2.1.4 Spécification des besoins non fonctionnels

En plus des besoins fonctionnelles et afin d’offrir une solution complète et performante
à différents niveaux, notre solution doit garantir les besoins non fonctionnels suivants :

— Rapidité : Le logiciel de surveillance doit fonctionner correctement et prévenir

dés qu’un problème survient avant même que la plupart des utilisateurs en aient
conscience.

— Performance : Les fonctionnalités de l’application doivent répondre à toutes les

exigences des usagers d’une manière optimale.

17
Chapitre 2. Spécification des besoins et conception

— Sécurité : L’accès aux données doit être authentifié et contrôlé, la solution doit
garantir les services de sécurité.

— Ergonomie : L’application doit offrir une interface facile à utiliser le logiciel en toute
simplicité.

2.2 Conception
Dans cette section nous exposons la conception statique et dynamique de notre solution
en étudiant le diagramme de classes et les diagrammes de séquence qui présentent les
différents interactions entre les divers composants de notre application.

2.3 Conception statique

Dans cette partie nous détaillons le diagramme de classes. En fait, nous décrivons les
différents objets et méthodes de chacune de ces classes.

2.3.1 Diagramme de classes

La figure 2.4 présente le diagramme de classes qui est composé de neuf classes : la classe
administrateur, la classe moniteur réseau Nagios, la classe équipements, la classe systéme
d’exploitation, la classe machine Windows/Linux, la classe routeur, la classe serveur, la
classe commutateur et la classe services.

— Classe administrateur : Cette classe contient les objets suivantes : id, nom, pré-
nom et son e-mail. Un administrateur peut se connecter à un ou plusieurs moni-
teurs/serveurs «Nagios». Cette classe a comme méthodes : l’authentification, l’admi-
nistration réseau et systèmes et la configuration de Nagios afin de pouvoir consulter
l’état des équipements.

— Classe moniteur réseau Nagios : Cette classe contient les objets suivantes :
nom, version, adresse IP et adresse MAC du système de surveillance réseau. Tel
que un ou plusieurs moniteurs peuvent être utilisés par un administrateur. Il peut
gérer plusieurs équipements présents sur le réseau. Cette classe a comme méthodes :
la supervision des équipements, la collecte des informations, l’envoie des alertes à
l’administrateur et la création des rapports et des histogrammes.

18
Chapitre 2. Spécification des besoins et conception

— Classe équipements : Cette classe contient les objets : id, nom, adresse IP, adresse
MAC et l’état de l’équipement réseau. Chaque équipement est géré par un système
d’exploitation.

— Classe système d’exploitation : Cette classe contient le nom, la version et le

type de l’OS.

— Classe machine Windows/Linux : C’est un équipement qui contient dans sa

classe l’id et le nom de l’hôte.

— Classe routeur : C’est un équipement qui contient dans sa classe le nom, le nombre
des ports du routeur, la table du routage et la valeur des débits envoyés et reçus.

— Classe serveur : C’est un équipement qui contient dans sa classe le nom, le nombre
des ports du serveur et la valeur des débits envoyés et reçus.

— Classe commutateur : C’est un équipement qui contient dans sa classe le nom, le

nombre des ports du switch et la valeur des débits envoyés et reçus.

— Classe services : C’est un équipement qui contient dans sa classe le nom et l’état
des services. Un ou plusieurs services est possédée par un ou plusieurs machines,
serveurs, routeurs et commutateurs.

19
Chapitre 2. Spécification des besoins et conception

Figure 2.4 – Diagramme de classes

20
Chapitre 2. Spécification des besoins et conception

2.4 Conception dynamique

Dans cette section nous représentons les diagrammes de séquences et les scénarios
qui décrivent l’échange des messages selon un ordre chronologique entre l’acteur et le
système. Ces diagrammes de séquence sont généralement associés aux diagrammes de cas
d’utilisation dans la vue logique du système.

2.4.1 Diagramme de séquence "Authentification"

La figure 2.5 présente le diagramme de sequence "Authentification"

Figure 2.5 – Diagramme de séquence "Authentification"

Scénario nominal

Après que le système affiche l’interface d’authentification :

1. L’administrateur introduit son login et son mot de passe.

2. Le system vérifie le login et le mot de passe.

3. Si les données saisies sont correctes, le système affiche l’interface de Nagios.

21
Chapitre 2. Spécification des besoins et conception

4. Sinon, si les données saisies sont invalides "l’accès est refusé". Le système demande
de répéter la saisie de login et du mot de passe.

2.4.2 Diagramme de séquence "Ajouter des équipements et des

services"
La figure 2.6 présente le diagramme de séquence "Ajouter des équipements et des
services". Notons qu’un équipement peut être un routeur, un switch, un serveur, une
machine.. .

Figure 2.6 – Diagramme de séquence "Ajouter des équipements et des services"

Scénario nominal

1. L’administrateur s’authentifie.

2. Il demande au système d’ajouter des équipements et des services tel que (la dispo-
nibilité, la mémoire, l’état des ports, la connectivité internet ..).

3. Le système renvoie l’espace d’ajout.

4. L’administrateur saisie convenablement les données et édit les paramètres néces-

saires.

22
Chapitre 2. Spécification des besoins et conception

5. Le système vérifie les données avec la base de données :

6. Selon l’adresse IP, la Base de donnée renvoie au système le résultat de l’opération.

7. Le système affiche un message selon le résultat de l’opération.

2.4.3 Diagramme de séquence "Ajouter des scripts"

La figure 2.7 présente le diagramme de sequence de cas d’utilisation "Ajouter des
scripts".

Figure 2.7 – Diagramme de séquence du cas d’utilisation "Ajouter des scripts"

Scénario nominal

1. L’administrateur s’authentifie.

2. Il installe le logiciel NSclient++ et configure le serveur NRPE pour qu’il puisse

éxecuter son script sur sa machine Windows.

3. Il édit le script et le fichier "nsclient.ini" du NSclient++ sur sa machine Windows.

4. L’administrateur teste le plugin NRPE depuis Nagios.

5. Nagios demande de récupérer le script depuis la machine Windows.

6. Le système vérifie les données dans la base de données.

23
Chapitre 2. Spécification des besoins et conception

7. Si les étapes de l’ajout du script sont bien faite. Le système Nagios affiche le résultat
sur son interface web.

Conclusion
A travers ce chapitre, nous avons détaillés notre conception statique à savoir le dia-
gramme de classes. Nous avons également étudiés la conception dynamique en détaillant
les diagrammes de séquences. Le chapitre suivant présente l’architecture de notre solu-
tion et la partie réalisation du projet en présentant les environnements de travail et les
différents modules réalisés.

24
 Mise en œuvre de la solution
3
Introduction
A travers ce chapitre, nous présentons notre environnement de travail et nous men-
tionnons les différentes outils utilisés. Nous étudions l’architecture adopté pour notre
solution. La partie la plus importante de ce chapitre est la présentation des différents
modules implémentés et les scénarios d’exécutions.

3.1 Environnement de travail

Dans cette section, nous décrivons notre environnement de travail matériel et logiciel.

3.1.1 Environnement matériel

Durant la phase de réalisations du projet nous avons utilisés une machine virtuelle
avec les caractéristiques suivantes comme le montre la figure 3.1
•Systèmes d’exploitation : nous avons crée Ubuntu 16.04 LTS/Linux
sur laquelle nous avons installée Nagios.
•Processeurs :2
•Mémoire vive(GB) :2
•Disque dur :15 GB

Figure 3.1 – Caractéristiques de la machine

25
Chapitre 3. Mise en œuvre de la solution

3.1.2 Environnement logiciel

Nous présentons dans cette sous-section les logiciels utilisés lors du développement de
notre solution. Nous avons choisi le logiciel VMware Workstation 12, Star UML, Microsoft
Visio et Exchange Management Shell. Nous décrivons brièvement dans ce qui suit, ces
différents logiciels.

VMware Workstation 12

VMware Workstation est un hyperviseur fonctionnant sur les versions x64 sur les sys-
tèmes d’exploitations Windows et Linux. Cet outil, permet aux utilisateurs de configurer
des Machines Virtuelles (VM) sur une seule machine physique. Nous pouvons utiliser ces
machines simultanément avec la machine réelle. Chaque machine virtuelle peut exécuter
son propre système d’exploitation. [9]

Star UML

Star UML est un outil de modélisation logicielle open source qui prend en charge UML
(Unified Modeling Language). Il est basé sur UML version 1.4 et il fournit onze types de
diagrammes différents et accepte la notation UML 2.0. Il soutient activement l’approche
Mda (Model Driven Architecture) en supportant le concept de profil UML et en permet-
tant de générer du code pour plusieurs langues. [10]

Microsoft Visio

C’est un logiciel dédié pour créer des diagrammes professionnels pour Windows. Nous
avons utilisées Visio pour créer facilement l’organigramme et l’architecture de l’entreprise.

Exchange Management Shell (EMS)

C’est un environnement de ligne de commande repose sur la technologie Windows Power-

Shell. Pour l’automatisation des tâches comme l’administration d’Exchange. EMS fournit
une interface de ligne de commande puissante. Il est utilisé pour gérer tous les aspects
d’Exchange, pour créer des comptes de messagerie, configurer les propriétés de la base de
données de boîtes aux lettres et gérer des groupes de distribution. [11]

26
Chapitre 3. Mise en œuvre de la solution

3.2 Langages et bibliothèques utilisés

Dans cette section, nous présentons les différents langages et bibliothèques que nous
avons utilisés lors du développement de notre solution.

3.2.1 Langages utilisés

Nous présentons les différents langages de programmation utilisés dans la phase déve-
loppement à savoir powerShell et Batch.

POWERSHELL
C’est un langage de programmation orienté objet et un interpréteur de commandes (shell)
interactif pour Windows et Windows Server. PowerShell a été conçu pour automatiser les
tâches système et pour créer des outils d’administration de systèmes pour les processus
courants mis en œuvre. [12]

BATCH
Le langage de programmation Batch est utilisé pour simplifier certaines tâches répétitives
dans les systèmes d’exploitation Windows. Il est utilisé pour l’administration des systèmes
et des réseaux complexes. [13]

3.2.2 Bibliothèques utilisées

Nous décrivons dans ce qui suit les bibliothèques utilisées à savoir APACHE et GD.

APACHE
Apache est probablement le serveur HTTP le plus populaire. En faite celui qui met à
disposition la plupart des sites internet du WWW. Apache est produit par la "Apache
Software Fondation". On l’utilise généralement en conjonction avec d’autres logiciels qui
permettent d’interpréter du code et d’accéder à des bases de données. [14]

GD
C’est une bibliothèque libre servant à manipuler dynamiquement plusieurs types d’images
tels que les formats (GIF, PNG, JPEG, WBMP, XBM et XPM...). Son nom vient de "Gif
Draw" c’est à dire "dessiner un gif". GD supporte de nombreux langages tel que C, PHP,
PERL, PYTHON, PASCAL, GNU... . [15]

27
Chapitre 3. Mise en œuvre de la solution

3.3 Mise en place de Nagios et ses plugins

Pour une Mise en place de Nagios et ses plugins, nous avons besoins des outils basiques
de monitoring. Nous citons les différents outils de surveillance que nous avons utilisés.

— Notre solution de surveillance : "Nagios Core Version-4.4.3" qui est la plus récente.

— Les greffons de Nagios : "Nagios-plugins-2.2.1" .

— Le logiciel "NSClient++" pour la supervision des serveurs et des machines Windows

et pour l’ajout des scripts.

— Le logiciel "SNMP" pour la supervision des switchs et des routeurs.

Nagios peut fonctionner sur les systèmes d’exploitation Linux. Nous l’avons installé sous
Ubuntu 16.04.
Notons que les étapes d’installation et de configuration de Nagios et ses plugins sont dé-
taillées dans l’annexe 1.

En fait, nous avons suivi les étapes d’installation suivantes :

— L’installation de quelques bibliothèques utiles pour le bon fonctionnement de Nagios.

— La configuration de l’utilisateur et du groupe.

— L’installation de Nagios.

— La configuration d’Apache.

— Le test du serveur Nagios.

Après avoir compléter l’installation, nous pouvons commencer la supervision des équi-
pements. Pour la surveillance de ces machines distantes, il faut avoir sur ces machines un
agent qui pourra renseigner les plugins Nagios des informations dont ils ont besoin.

3.4 Supervision des machines/serveurs Windows

Pour les machines et les serveurs windows, nous avons décidées d’utiliser l’agent NS-
Client++. En effet, nous avons supervisées :
•Un serveur "windows server 2012 R2" qui permet la gestion des utilisateurs du
réseau, le stockage des données et l’identification des utilisateurs... .
•Un poste client "Windows 7".

28
Chapitre 3. Mise en œuvre de la solution

La figure 3.2 montre que l’agent "NSClient++" est basé sur une architecture client/serveur.
La partie cliente nommée check-nt, doit être disponible sur le serveur Nagios et la partie
serveur NSClient++, doit être installée sur la machine et le serveur Windows à surveiller.

Figure 3.2 – Principe de fonctionnement de check-nt

En fait, lorsque Nagios veut connaître une information par exemple sur le serveur, il
exécute le plugin check-nt, qui envoie une requête au serveur. Ensuite, au niveau du
serveur le programme NsClient++ reçoit la requête et va chercher les informations dans
ses ressources et renvoie le résultat au serveur Nagios.

Avant tout, nous définissons les informations qui seront récupérées par Nagios tel que :
•NSClient++ Version : C’est la version du plugin qui envoie les informations au ser-
veur Nagios. En faite, un e-mail sera envoyé à l’administrateur réseau si cette version n’est
pas la plus récente.
•Load CPU : Il s’agit du seuil de charge CPU supporté pour le serveur supervisé. Dans
notre cas, si la charge dépasse les 80 % un e-mail sera envoyé à l’administrateur réseau.
•Uptime : La durée écoulée depuis le dernier démarrage du serveur.
•C : Drive Space : La taille et l’occupation des disques dur (C :). En faite, lorsque 80%
de disque dur est occupé, un e-mail sera envoyé à l’administrateur réseau.
•Memory Usage : Si la taille de la RAM dépasse 80 %, un e-mail sera envoyé à l’ad-
ministrateur réseau.

Les étapes d’installation de l’agent sur la machine distante et sa configuration sur Nagios
seront détaillées dans l’annexe 2.

Configuration au niveau du serveur Nagios :

Nous devons configurer Nagios pour qu’il puisse superviser notre hôte et le serveur Win-
dows avec le plugin "check_nt". Nous remplaçons les champs host_name, alias, address,

29
Chapitre 3. Mise en œuvre de la solution

service_description et check_command par les valeurs appropriées pour l’hôte et les ser-
vices comme l’illustre la figure 3.3.

Figure 3.3 – Configuration des sevices de l’hôte ’rami’

3.5 Surveillance de la connexion internet

Tous les départements et les secteurs de Médis sont connectés entre eux, il est donc
primordiale de maintenir la connectivité du réseau. Le plus grand souci de notre admi-
nistrateur est la coupure de la connexion réseau qui va engendrer des problèmes et des
perturbations à plusieurs niveaux. C’est pour cela que nous avons eu recours a un script
qui test la connectivité d’un site web www.google.com. Il est donc possible de créer notre
propre plugin de sorte que celui-ci renvoie à Nagios :
•L’état du résultat (OK, CRITICAL, DOWN, UP).
•Un message en sortie pour donner le détail du résultat.

30
Chapitre 3. Mise en œuvre de la solution

La figure 3.4 présente notre script en batch (.bat)

Figure 3.4 – Test Connexion internet

Afin que notre script fonctionne, nous éditons le fichier "nsclient.ini" pour que l’utilisation
des scripts personnalisés soit permise puisque nous avons besoin de configurer des modules.
Ensuite, il est nécessaire de définir la commande externe dans NSClient pour l’ajout du
script nommée "check_ok" comme le présente la figure 3.5.

Figure 3.5 – Ajout du du script check_ok.bat

Ceci affiche un message « Ok everything is going to be fine » et renvoie le statut 0,

autrement dit "Tout va bien". Si ce n’est pas le cas, l’administrateur sera alerté qu’il y
a des difficultés au niveau de la connexion afin de diagnostiquer l’origine de la panne et
la réparer. Toutes les modifications nécessaires pour l’ajout du script sont décrites dans
l’annexe 2.
L’avantage lié à la surveillance de la connexion internet est que l’administrateur peut
savoir facilement l’origine des problèmes du serveur de messagerie. En effet, si l’état de la
fil d’attente est CRITIQUE et que l’état de la connexion est OK alors le problème survient
forcément lors de l’échange des e-mails. L’administrateur peut donc déduire l’état de la
fil d’attente par la connaissance de l’état de la connexion internet.

31
Chapitre 3. Mise en œuvre de la solution

3.6 Surveillance file d’attente des e-mails

Une file d’attente est un emplacement de stockage temporaire pour les messages qui
attendent l’étape suivante de traitement ou de remise vers une destination. Chaque file
d’attente représente un ensemble logique de messages que le serveur Exchange traite dans
un ordre spécifique. En fait, le serveur Exchange permet à un groupe de personnes de
partager des documents à distance pour favoriser le travail collaboratif [16]
Les mails envoyés depuis et vers le serveur transitent par la file d’attente des mails.
Certains messages peuvent rester bloqués dans la file d’attente et cela peut entraîner un
dysfonctionnement de serveur de messagerie. Dans l’entreprise, les clients se plaignent
que les mails envoyés ne parviennent pas à leurs destinataires ou arrivent avec un délai
significatif puisque le serveur des e-mail est surchargé et n’arrive pas à faire face au volume
de messages reçus. Dans la plupart du temps, cela peut arriver lorsque quelqu’un fait
transiter des spams sur le serveur mail ce qui monopolise la file d’attente. Notre objectif,
est de surveiller la file d’attente des e-mails du serveur de messagerie pour éviter ce genre
de problèmes et résoudre les encombrements. Nous avons eu recours au script en power
shell (.ps1) écrit dans la figure 3.6. Ce script examinera la file d’attente et déterminera
son statut.

32
Chapitre 3. Mise en œuvre de la solution

Figure 3.6 – Script de test de la fil d’attente

Si le nombre de messages présents dans la file d’attente dépassent "15", Nagios affiche
un message "$Nagios Description" et définit l’état de sortie "CRITICAL" . Sinon, si le
nombre de messages présents dans la file d’attente est supérieur ou égale "8", l’état est
définit à "WARNINIG" et il est affiché dans un message pour décrire son état : "EDGE/24
Queue has 8 messages to ns0.ovh.net". Sinon "OK" , tout va bien". La figure 3.7 montre
le résultat de l’affichage et de filtrage des files d’attente d’un serveur nommé EDGE/23.

Figure 3.7 – Fil d’attente du serveur EDGE

33
Chapitre 3. Mise en œuvre de la solution

Propriétés de la file d’attente : Une file d’attente a un grand nombre de propriétés

qui décrivent son but et son état :

•DeliveryType : Type de livraison, représente les résultats de la catégorisation du

message.

•Status : L’état actuel d’un message est stocké dans sa propriété Status. Notre valeur
d’état de messages est «active».

•MessageCount : La propriété MessageCount est importante et mérite également

d’être signalée, indique le nombre de messages présents dans la file d’attente.

•NextHopDomain : Utilise des valeurs spécifiques basées sur la valeur du champ

DeliveryType, n’est pas toujours un nom de domaine.

Ensuite, pour l’ajout du script nommée "test_queue.ps1" il suffit de définir la commande

externe dans NSClient comme le montre la figure 3.8.

Figure 3.8 – Ajout du script test_queue.ps1

La figure 3.9 montre la configuration au niveau du serveur Nagios afin d’ajouter l’hôte
"EDGE".

Figure 3.9 – Ajout du service de l’hôte EDGE

34
Chapitre 3. Mise en œuvre de la solution

3.7 Surveillance de Symantec Backup Exec System

Recovery 2010
Backup Exec System Recovery 2010 est la référence en matière de restauration du sys-
tème Windows®. En effet, il fournit une solution de restauration système rapide et simple
d’utilisation pour aider les administrateurs informatiques à répondre à leurs impératifs de
délai de récupération. Backup Exec effectue la sauvegarde et la récupération des fichiers,
des dossiers ou des lecteurs entiers, pour cela il faut l’indiquer les éléments à sauvegarder,
le moment de la sauvegarde et l’emplacement où stocker les données sauvegardées.[17]
En faite, nous avons planifiées un travail de sauvegarde du lecteur (C :). Afin que la
sauvegarde s’exécute automatiquement, selon une planification, nous avons entrées une
heure de début et nous avons sélectionnées les jours de la semaine où la sauvegarde doit
s’exécuter comme le montre la figure 3.10.

Figure 3.10 – Sauvegarde du lecteur (C :) planifié

35
Chapitre 3. Mise en œuvre de la solution

La figure 3.11 présente une sauvegarde du lecteur (C :) réussi effectuée par Backup Exec
System Recovery.

Figure 3.11 – Sauvegarde du lecteur (C :) réussi

Afin de mieux contrôler le travail fourni par Symantec Backup Exec 2010, nous avons eu
recours a un script en power shell (.ps1) écrit dans la figure 3.12. Ce script vérifiera le
dernier statut du travail Symantec Backup Exec 2010. Il prend deux arguments : le nom
du travail Symantec Backup Exec et le nombre de jours qui doivent s’écouler depuis le
dernier travail exécuté avant que son état ne soit considéré comme critique.
Get-BEJob <nom du travail> : Cette commande récupère tous les travaux de Ba-
ckup Exec d’un nom de travail.
Get-BEJobHistory <nom du travail> -FromLastJobRun : Cette commande per-
met d’afficher l’historique du travail de la dernière exécution d’un travail.
En fonction de l’état, Ce script renvoie les codes de sortie suivants : erreur c’est a dire
critique, non Succeeded c’est a dire avertissement et succeeded c’est a dire ok.

36
Chapitre 3. Mise en œuvre de la solution

La figure 3.12 présente notre script en power shell (.ps1)

Figure 3.12 – Script de vérification de l’état du travail du Backup Exec

La figure 3.13 présente un exemple d’un historique de travail détaillé pour une sauvegarde
nommée sauvegarde de nuit.

Figure 3.13 – Historique de travaux détaillé

37
Chapitre 3. Mise en œuvre de la solution

3.8 Supervision des switchs/routeurs

Nous utilisons un logiciel de supervision SNMP pour superviser le routeur et le switch.
Ce plugin permet de superviser tous les équipements sauf les PCs.

Figure 3.14 – Principe de fonctionnement de check-snmp

La figure 3.14 présente le principe de fonctionnement de SNMP. Nagios exécute le

plugin check-snmp (installé sur le serveur Nagios) quant il veut avoir une information sur
le routeur. Ce plugin envoie une requête au routeur, quand le routeur reçoit la requête, il
va chercher les informations dans sa MIB (Management Information Base). Il s’agit d’une
base de données de l’équipement. Cette base stocke toutes ses informations tel que les
statistiques, le débit et l’état des interfaces.. . Ensuite, le routeur renvoie le résultat au
serveur Nagios.
Nous configurons au niveau de Nagios, le routeur et le switch ainsi que le service PING
qui permet de vérifier leurs disponibilité comme le montre la figure 3.15

Figure 3.15 – Ajout de l’hôte et du service

38
Chapitre 3. Mise en œuvre de la solution

Nous configurons l’agent SNMP sur le routeur/switch. La configuration est détaillé en

Annexe 3.
La figure 3.16 présente l’état des services pour toutes les équipements supervisés.

Figure 3.16 – Statut des services détaillé pour tous les hôtes

3.9 Notification par mail

Nagios peut envoyer des courriels grâce au programme postfix à l’administrateur via son
adresse électronique lorsque des pannes ou des problèmes se produisent. Pour tester l’envoi
des e-mails, nous installons postfix. Ensuite nous configurons Nagios pour qu’il envoie ses
mails via postfix.

Installation de postfix : Nous présentons dans ce qui suit l’installation et la confi-

guration de postfix comme le montre la figure 3.9.

39
Chapitre 3. Mise en œuvre de la solution

(a) Nous sélectionnons le type général de configuration de messagerie.

(b) Nous entrons le nom complet de domaine de courrier qui va recevoir les notifications.

(c) Si la configuration de postfix au niveau du serveur Nagios est bien faite, il est affiché
un message.

Figure 3.17 – Configuration de POSTFIX

La figure 3.18 présente la configuration au niveau du serveur Nagios de l’administrateur

qui va recevoir les notifications.

Figure 3.18 – Définition du contact

40
Chapitre 3. Mise en œuvre de la solution

La figure 3.19 présente l’e-mail envoyé depuis Nagios à l’administrateur, lui informant
que le statut de la mémoire de l’hôte "rami" est CRITICAL puisque la taille de la RAM
a dépassé 80 %.

Figure 3.19 – Exemple de notification

Conclusion
A travers ce chapitre, nous nous sommes concentrés sur les réalisations et sur l’aspect
pratique de notre projet. Nous avons détaillés les étapes de la mise en place de notre
solution pour la surveillance des machines, des routeurs, des switchs et de la file d’attente.
Nous avons exposés toutes les configurations de ses équipements avec le serveur Nagios.

41
 Conclusion Générale

Un logiciel de surveillance de réseau comme Nagios est indispensable pour un admi-

nistrateur lorsque l’entreprise dispose de grand et large réseau.
Notre projet s’inscrit dans le cadre de la réalisation d’un projet de fin d’études au
sein de l’entreprise Médis pour l’obtention d’une licence fondamentale en télécommunica-
tion. Notre projet consiste à implémenter une solution de surveillance réseau gratuite basé
sur Nagios core qui existe aujourd’hui dans l’univers de l’entrepreneuriat. Notre solution,
permet au administrateur de Médis de faciliter la gestion du réseau informatique, main-
tenir et entretenir le bon fonctionnement du parc informatique. En fait, il était possible
de développer la solution avec centreon qui présente une évolution de Nagios pour son
interface et ses fonctionnalités. En effet, il est possible de superviser intelligemment la dis-
ponibilité des services et la performance des réseaux. Afin d’améliorer notre surveillance
réseau, nous pourrions utiliser d’autres plugins tel que check_dhcp, check_dns ainsi créer
d’autres plugins selon les besoins de l’administrateur de Médis.

42
 Bibliographie

[1] Présentation et historiques,

http://www.medis.com.tn/

[2] Le concept de supervision reseau,

https://rayaneotmani.wordpress.com/le-concept-de-supervision-reseau/

[3] https://www.cisco.com/web/FR/documents/pdfs/datasheet/ios/WINDOWS_6.1.pdf

[4] HP OpenView,
https://searchitoperations.techtarget.com/definition/HP-OpenView

[5] Zabbix,
https://www.zabbix.com/features

[6] Nagios Core,

https://www.nagios.com/products/nagios-core/

[7] Centreon,
https://www.centreon.com/solutions/centreon/

[8] https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/about.html

[9] VMware,
https://www.vmware.com/ca-fr/company/news/releases/2015/workstation-12-
pro-09032015.html

[10] StarUML documentation,

https://docs.staruml.io/

[11] Exchange Server PowerShell,

https://docs.microsoft.com/en-us/powershell/exchange/exchange-server
/exchange-management-shell?view=exchange-ps&viewFallbackFrom=exchange-ps)

43
Bibliographie

[12] PowerShell,
https://www.lemagit.fr/definition/PowerShell

[13] Batch,
https://www.techopedia.com/definition/26130/batch-script

[14] Serveur HTTP Apache 2,

https://doc.ubuntu-fr.org/apache2

[15] GD (bibliothéque),
https://fr.wikipedia.org/wiki/GD_(bibliothèque)

[16] Files d’attente,

https://docs.microsoft.com/fr-fr/exchange/mail-flow
/queues/queues?view=exchserver-2019

[17] Guide de l’utilisateur de Backup Exec System Recovery 2010,

https://origin-symwisedownload.symantec.com/resources/sites/SYMWISE/content/live
/SOLUTIONS/76000/TECH76006/en_US/336237.pdf

[18] Installation de Nagios,

https://www.howtoforge.com/tutorial/ubuntu-nagios/

44
 Annexe 1

[18]
Accés : Root / Sudo

1. Installation des pré-requis :

Nous devons installer les éléments essentiels à la compilation apache2, php et GD
pour l’interface Web Nagios, Sendmail pour envoyer des alertes depuis le serveur
et snmp pour superviser les routeurs et switchs comme le montre la figure 1. Il
nous faut aussi make et gcc pour les compilations.

Figure 1 – Installation des pré-requis

2. Configuration de l’utilisateur et du groupe :

Pour que Nagios fonctionne, nous devons créer un nouvel utilisateur. Nous nom-
merons l’utilisateur "nagios", nous créerons un groupe nommé "nagcmd" et nous
ajoutons le nouvel utilisateur au groupe comme indiqué dans la figure 2.

Figure 2 – Configuration de l’utilisateur et du groupe

3. Installation de Nagios :
Pour installer Nagios, il faut passer par trois étapes comme l’indique la figure 3.
Étape 1- Téléchargement et extraction de noyau Nagios.
Étape 2- Compilation de Nagios : Avant de construire Nagios, nous devons le

45
 configurer avec l’utilisateur et le groupe que nous avons créé précédemment.
Étape 3- Installation des plugins Nagios : téléchargement et extraction des plu-
gins.

Figure 3 – Installation de Nagios

4. Configuration d’Apache :
Pour configurer apache, il faut passer par deux étapes comme l’indique la figure
4.
Étape 1 : Activation des modules Apache et configuration d’un utilisateur "nagios
admin" + password pour l’accés à nagios.
Étape 2 : Démarrage d’apache et Nagios :

Figure 4 – Configuration d’Apache

 5. Test du serveur Nagios :

(a) Nous pouvons accéder au serveur nagios via son adresse IP localhost/nagios/ comme
le montre la figure 5.

(b) Ceci est l’interface Web d’administration de Nagios :

Figure 5 – Test du serveur Nagios

 Annexe 2

L’installation de NSClient++ : il existe deux méthodes à savoir :

•Afin de faciliter le travail et éviter de se déplacer à chaque serveur pour installer
le plugin NSClient : en premier lieu, nous traçons une route statique vers la hôte
cible et nous exécutons un invite de commande en tant qu’administrateur pour
tracer la route : « route add -p @ip-destination mask 255.255.255.255
passrelle metric 5 »
•Sur les machines à superviser, nous installons le logiciel NsClient++ qui
est téléchargeable sur le site http ://sourceforge.net/projects/nscplus et sur
la machine NAGIOS, le plugin check-nt doit être installé dans le dossier
(/etc/usr/local/nagios/libexec).

La configuration de NSClient++ : Au niveau des machines à superviser, la configura-

tion du fichier "Nsclient.ini" est nécessaire. Dans la figure 6, le fichier "Nsclient.ini" est
édité et configuré selon nos besoins. Nous définissons :

— "Le port"="12489" sur lequel NsClient++ doit écouter les requêtes.

— "Allowed Hosts"="L’adresse IP du serveur Nagios" pour avoir le droit de dialoguer

avec NsClient++.

— Un mot de passe doit être fournis pour les machines qui souhaiteront dialoguer
avec Nagios par NsClient++ .

48
Figure 6 – Configuration du NSClient++
 Annexe 3

Pour que Nagios puisse superviser le routeur et le switch, il faut activer notamment
le protocole SNMP sur ceux-ci. En effet, il permet de récupérer des informations
statistiques sur les équipements réseaux.
Dans la suite de cet annexe, vous trouverez les instructions pour activer et configurer
ce service.

1. Configuration de l’agent SNMP sur le switch :

En premier lieu, il est impératif que notre switch supporte SNMP. La figure 7
présente la configuration de SNMP au niveau de notre switch :

Figure 7 – Configuration du SNMP sur le switch

50
 2. Configuration de l’agent SNMP sur le routeur :

En fait, nous configurons SNMP sur le routeur en respectant les commandes décrit
dans la figure 8.

— Nous nous connectons au terminal de routeur via Telnet.

— Nous entrons dans le mode « enable ». Pour modifier la configuration d’un équi-
pement Cisco, il faut être dans le mode privilégié « enable » puis entrer le mot
de passe demandé.

— Nous entrons dans le mode « configuration ». Pour pouvoir configurer cet équi-
pement.

— Nous activons le Read-Only (RO) community string.

— Nous activons le Read-Write (RW) community string.

— Nous quittons le mode configuration de routeur et nous enregistrons les modifi-

cations.

— Nous vérifions la configuration de SNMP et les communautés activée (PUBLIC

et PRIVATE) avec le mode d’activation (RW : Read-Write et RO : Read-Only)

— La communauté PUBLIC est activée, donc il est préférable de la désactiver pour

des raisons de sécurités.

Figure 8 – Configuration de SNMP sur le routeur

Résumé

Ce travail est réalisé dans le cadre d’un projet de fin d’études au sein de Médis pour
l’obtention d’une licence fondamentale en télécommunication. Il consiste à mettre en
place une solution de surveillance réseau ayant pour finalité l’utilisation de l’outil
gratuit "NAGIOS" pour surveiller n’importe quelle ressource de l’infrastructure infor-
matique de l’entreprise Médis.
Le but de notre solution est la facilité de l’administration du réseau informatique et
de garantir le bon fonctionnement du réseau.

Mots clés : NAGIOS, plugin, surveillance, équipements, NSclient, SNMP, hôtes,

services, interface web ...

Abstract

This work is realized as part of a graduation project within Médis to obtain a funda-
mental licence in telecommunication.
The aim of our work is to develop a monitoring solution based on free software "NA-
GIOS". Our solution allows to monitor all resources of Médis IT infrastructure.
The goal of our work is to offer an easy solution for administrators in ordrer to have
a proper network performances.

Keywords : NAGIOS, plugin, monitoring, equipements, NSclient, SNMP, host, ser-

vice, web interface ...