Vous êtes sur la page 1sur 97

Ministère de l’Enseignement Supérieur, de la Recherche Scientifique et de

l’Innovation
(MESRSI)
--------------------
Secrétariat Général
---------------------
Université NAZI BONI (U.N.B)
--------------------
École Supérieure d’Informatique (E.S.I)
---------------------

Option : Ingénierie Réseaux et Systèmes (IRS)

RAPPORT DE STAGE DE FIN DE CYCLE


THEME : « Étude et mise en place d'un outil de
supervision du système d’information de SOFTNET »

Période de stage : du 20 Août 2018 au 18 Novembre 2018


Auteurs : PAMOUSSO Djibril Pierre Clavair & NIKIEMA Amadou
Maître de Stage Superviseur

Manager du département M. ZOUGMORE Téeg-


Wendé, Enseignant à l’ESI
Réseaux et télécom à SOFTNET

Année académique : 2017-2018


I

AVANT-PROPOS
L’université NAZI BONI (UNB) auparavant Université Polytechnique de Bobo-Dioulasso
(UPB) a été créée le 23 mai 1997 par le décret n°97-254/PRES/PN/MESSRS. C’est un
établissement public de l’État à caractère scientifique, culturel et technique, chargé de
l’enseignement supérieur et de la recherche scientifique. Située à une dizaine de kilomètres de
Bobo-Dioulasso, elle est constituée de nos jours de :

• L’École Supérieur d’Informatique (ESI) ;


• Institut de Développement Rural (IDR) ;
• Institut Universitaire de Technologie (IUT) ;
• Institut des Sciences de la santé (INSSA) ;
• L’UFR des Sciences et Technologie (UFR/ST) ;
• L’Unité de Formation et de Recherche en Lettre Moderne, Sociologie et Histoire
(UFR/LSH) ;
• L’Institut des Médias ;
• L’UFR des Sciences Juridiques, Politique, Économiques et de Gestion (SJPEG)
• Le Centre Universitaire Polytechnique de Gaoua et de Banfora

L’École Supérieure d’Informatique (ESI) créée en 1991 comprend deux (02) cycles à savoir le
cycle des Ingénieurs de Travaux en Informatique (CITI) et le Cycle des Ingénieurs de Conception
en Informatique (CICI).

Le premier cycle comprend deux (02) filières qui sont L’Analyse et Programmation (AP) et
Réseaux et Maintenance Informatique (RéMI). Ces deux filières sont devenues de nos jours
Ingénierie des Systèmes d’Information (ISI) et Ingénierie des Réseaux et Systèmes (IRS). La
formation pour chacune de ces filières s’étend sur trois (03) ans à la fin de laquelle un stage d’au
moins trois (03) mois est obligatoire en entreprise. Pour l’IRS, le stage consiste à réaliser un
rapport avec la maintenance et le réseau informatique.

C’est à cet effet que nous avons été reçus à SOFTNET pour notre stage de fin de cycle tenu du
20 Août 2018 au 18 Novembre 2018. A l’issu de ce stage, nous avons élaboré ce présent rapport
qui englobe le déroulement du projet.

I
II

REMERCIEMENTS
Au terme de ce stage qui s’achève sur une note de satisfaction de notre part, et nous l’espérons
aussi de la part de la structure d’accueil. Il est important de remercier un certain nombre d’acteurs
qui ont contribué à l’aboutissement du travail.

• Nous remercions M. BORO Issa grâce à qui nous avons obtenu ce stage à SOFTNET ;
• De l’administration de l’Université NAZI BONI (UNB) en particulier celle de l’École
Supérieure d’Informatique (ESI) ;
• De tout le corps enseignant de l’ESI, pour avoir assuré notre formation ;
• La grande Famille ZERBO à Gounghin ;
• De tous ceux ou toutes celles qui ont contribué d’une manière ou d’une autre à la
réalisation de ce stage.
• De tous les agents de SOFTNET pour l’encadrement, les conseils, le partage
d’expériences et de ressources divers durant ces trois (03) mois au sein de l’Agence
particulièrement à M. NAKOULMA et M. TRAORE qui nous amenais fréquemment sur
le terrain pour nous apprendre bien de chose dans la maintenance des équipements et
aussi M. SAGA qui nous aidais dans notre travail.

Nous adressons tout particulièrement nos sincères remerciements à :

M. OUEDRAOGO Maxime, Manager du département Réseaux et télécom à


SOFTNET qui ont été notre encadrant et part son expérience dans le domaine nous a pousser
à toujours effectuer le meilleur choix.
M. ZOUGMORE Téeg-Wendé, enseignant à l’ESI, notre superviseur pour ses encouragements,
sa disponibilité ; ses remarques pertinentes et enrichissantes.

II
III

RESUME
Pour assurer la disponibilité permanente de leur infrastructure informatique, les entreprises ont
rapidement compris que la supervision était devenue une ressource-clé. Reçus le 20 août 2018,
SOFTNET nous a confié la mise en place d’un outil de supervision de son système d’information
à travers un stage de 03 mois, une solution qui va permettre la supervision complète de son parc
informatique. Ainsi la solution SHINKEN a été retenue. Nous l’avons choisi après une étude
comparative des outils de supervision qu’on trouve sur internet. Certains critères qui ont été
considérés sont : logiciel libre, grandes performances, adaptabilité et fonctionnalités. L’outil
déployé permet de contrôler tout type de système d’information. Cette solution peut se voir
améliorée par l’ajout d’un système d’alerte et aussi une jointure avec le serveur asterisk afin
d’avoir un système de notification très performante. En somme, l'objectif de ce stage est de
coupler la puissance de SHINKEN au système d’information de SOFTNET que ces derniers
pourront proposer à ses clients.

III
IV

ABSTRACT
To ensure the continued availability of their IT infrastructure, businesses quickly realized that
supervision had become a key resource. Received on August 20, 2018, SOFTNET entrusted us
with the implementation of a monitoring tool for its information system through an internship of
03 months, a solution that will allow the complete supervision of its computer park. So, the
SHINKEN solution was chosen. We chose it after a comparative study of the supervision tools
found on the internet. Some criteria that have been considered are: free software, great
performance, adaptability and features. In short, the aim of this internship is to combine the
power of SHINKEN with the SOFTNET information system that they can offer to their clients.

IV
V

TABLE DES MATIERES

AVANT-PROPOS ............................................................................................................................................ I

REMERCIEMENTS ...................................................................................................................................... II

RESUME ....................................................................................................................................................... III

ABSTRACT .................................................................................................................................................... IV

LISTE DES FIGURES ................................................................................................................................. VII

LISTE DES TABLEAUX ............................................................................................................................ VIII

SIGLES ET ABBREVIATIONS .................................................................................................................... IX

INTRODUCTION GÉNÉRALE................................................................................................................... 1

CHAPITRE 1 .................................................................................................................................................. 2

PRESENTATION DU CONTEXTE DE STAGE ............................................................................................. 2


1.1. Introduction .......................................................................................................................................... 2
1.2. Présentation de l’ESI ........................................................................................................................... 2
1.3. Présentation de SOFTNET-BURKINA............................................................................................. 5
1.4. Présentation du projet ........................................................................................................................ 12
1.5. Conclusion .......................................................................................................................................... 14

CHAPITRE 2 ................................................................................................................................................ 16

ANALYSE DE L’EXISTANT ET DEMARCHE DE RESOLUTION........................................................... 16


1.1. Introduction ........................................................................................................................................ 16
1.2. Présentation de l’existant................................................................................................................... 16
1.3. Diagnostique de l’existant ................................................................................................................. 17
1.4. Démarche de résolution du problème .............................................................................................. 19
1.5. Conclusion .......................................................................................................................................... 20

CHAPITRE 3 ................................................................................................................................................ 22

GENERALITES SUR LES SOLUTIONS EXISTANTES .............................................................................. 22


3.1. Introduction ........................................................................................................................................ 22
3.2. Concepts généraux ............................................................................................................................. 22
3.3. Présentation des différentes solutions .............................................................................................. 31
3.4. Conclusion .......................................................................................................................................... 45

V
VI

CHAPITRE 4 ................................................................................................................................................ 46

PRESENTATION DETAILLEE DE LA SOLUTION RETENUE ............................................................... 46


1.1. Introduction ........................................................................................................................................ 46
1.2. Présentation de Shinken .................................................................................................................... 46
1.3. Conclusion .......................................................................................................................................... 55

CHAPITRE 5 ................................................................................................................................................ 57

IMPLEMENTATION TECHNIQUE .............................................................................................................. 57


5.1. Introduction ........................................................................................................................................ 57
5.2. Différentes installations ..................................................................................................................... 57
5.3. Configurations nécessaires ................................................................................................................ 62
5.4. Présentation des tests de fonctionnements ...................................................................................... 76
5.5. Bilan .................................................................................................................................................... 78
5.6. Conclusion .......................................................................................................................................... 79

CONCLUSION GENERALE ...................................................................................................................... 80

Références Bibliographique et webographie .................................................................................................. 81

ANNEXE A .................................................................................................................................................. 83

ANNEXE B .................................................................................................................................................. 84

VI
VII

LISTE DES FIGURES


Figure 2 : Organigramme de SOFTNET .................................................................................................... 7
Figure 3 : Effectif en fonction des pays ................................................................................................... 8
Figure 4 : Planning prévisionnel ............................................................................................................ 14
Figure 5 : Principe de supervision ......................................................................................................... 24
Figure 8: Dashboard Cacti ..................................................................................................................... 34
Figure 9: Zabbix Dashboard.................................................................................................................. 36
Figure 10: Nagios Dashboard ................................................................................................................ 39
Figure 11: Centreon Dashboard ............................................................................................................. 41
Figure 12: EON Dashboard .................................................................................................................. 42
Figure 13 : Représentation de la supervision de SHINKEN .................................................................. 49
Figure 14: Architecture Interne de Shinken............................................................................................ 51
Figure 15 : Architecture de déploiement ................................................................................................ 54
Figure 16 : Résultat commande de vérification de l'état du serveur shinken............................................ 60
Figure 17 : Résultat commande sur l'état du service mongodb ............................................................... 61
Figure 18 : Contenue du fichier brokers-master.cfg................................................................................ 64
Figure 19 : Contenu du fichier admin.cfg .............................................................................................. 65
Figure 20 : Contenu fichier 1 snmpd.conf ............................................................................................. 67
Figure 21 : Contenu fichier 2 snmpd.conf ............................................................................................. 67
Figure 22 : Contenu fichier server_debian.cfg ...................................................................................... 68
Figure 23 : Contenu du fichier de groupe linux.cfg ............................................................................... 68
Figure 24 : Contenu du fichier linux_service.cfg ................................................................................... 69
Figure 25 : Installation de NSClient++ ................................................................................................... 70
Figure 26 : Contenu du fichier host srv-wind.cfg .................................................................................. 71
Figure 27 : Contenu fichier de groupe windows.cfg ............................................................................. 71
Figure 28 : Contenu fichier commande check_nt.cfg ........................................................................... 72
Figure 29 : Contenu fichier service windows_services.cfg .................................................................... 72
Figure 30 : Contenu fichier host imprimante_hp.cfg ............................................................................ 73
Figure 31: Contenu fichier groupe imprimante.cfg............................................................................... 73
Figure 32 : Contenue fichier de service imprimante_service.cfg .......................................................... 74
Figure 33 : Contenu fichier hosts switch.cfg ......................................................................................... 75
Figure 34 : Contenu fichier hosts router-one.cfg .................................................................................. 75
Figure 35: Contenu fichier service router_service.cfg .......................................................................... 76
Figure 36 : Shinken WebUI Login page.................................................................................................. 76
Figure 37 : Supervision Serveur Debian ................................................................................................ 77
Figure 38 : Supervision de Windows ..................................................................................................... 77
Figure 39 : Planning réel........................................................................................................................ 78
Figure 40 : Contenue fichier de notification email.cfg .......................................................................... 83
Figure 41 : Contenu fichier servicegroup bddservice.cfg ...................................................................... 83
Figure 42 : GNS3 VM preferences ......................................................................................................... 84
Figure 43 : Démarrage gns3 VM dans gns3 ........................................................................................... 85
Figure 44 : Machines virtuelles installer dans GNS3 ............................................................................. 85
Figure 45 : Architecture final chap5 ...................................................................................................... 86

VII
VIII

LISTE DES TABLEAUX


Tableau 1 : Tableau des sigles et d'abréviations --------------------------------------------------------------------- IX
Tableau 2 : Ressources matérielles ------------------------------------------------------------------------------------ 17
Tableau 3 : Ressources matérielles ------------------------------------------------------------------------------------ 20
Tableau 4 : Ressources logicielles -------------------------------------------------------------------------------------- 20
Tableau 5: Datagramme IP ----------------------------------------------------------------------------------------------- 29
Tableau 6 : Tableau comparatif des différentes solutions ------------------------------------------------------- 44
Tableau 7 : Coût de réalisation du projet ----------------------------------------------------------------------------- 55
Tableau 8 : Adressage des équipements------------------------------------------------------------------------------ 63

VIII
IX

SIGLES ET ABBREVIATIONS
Le tableau 1 suivant fait référence aux sigles et abréviations que vous rencontrerez tout au long
de la lecture du rapport.

Tableau 1 : Tableau des sigles et d'abréviations


3D 3 Dimensions
AGPL Affero General Public License
ANPTIC Agence Nationale de Promotion des TIC
ANSSI Agence Nationale de Sécurité des Systèmes d’Information
API Application Programming Interface
ASP Application Service Provider
BD Base de Données
CAR Conception et Architecture des Réseaux
CEDEAO Communauté Économique des États de l'Afrique de l'Ouest
CGI Computer Generate Images
Config(s) Configuration(s)
CPAN Comprehensive Perl Archive Network
CPU Central Processing Unit
DNS Domaine Name Service
DT Direction Technique
EON Eyes Of Network
ESI École Supérieure d'Informatique
FTP File Transfert Protocol
Gbic Gigabit Interface Converter
GPL General Public License
HDD Hard Disk Drive
HP Hewlett-Packard
http HyperText Tranfert Protocol
HTTPS HyperText Tranfert Protocol Secure
ICMP Internet Control Message Protocol
IP Internet Protocol
IRC Internet Relay Chat
IRS Ingénierie des Réseaux et Systèmes
ISI Ingénierie de Système d'Information
ISO International Standard Organization
IT Information Technology
ITIL Information Technology Infrastructure Library
LDAP Lightweight Directory Access Protocol
MIB Management Information Base
M.TG Multi Router Traffic Grapher
NCSA National Center for Supercomputing Applictions
NNTP Network News Transfer Protocol

IX
X

NRPE Nagios Remote Plugin Executor


ONG Organisation Non Gouvernementale
OSI Open Systems Interconection
PERL Practical Extraction and Report Language
PHP Hypertext Preprocessor
PNG Portable Network Grapics
PNP Plug-and-play
POP Post Office Protocol
QoS Quality of Service
RAID Redundant Arraf of Inexpensive Disks
RAM Random Access Memory
RFC Request For Comment
RRDTOOL Round Robin Data Tool
SA Société Anonyme
SAD Système d'Aide à la prise de Décision
SGBD Système de Gestion de Base de Données
SMART Self-Monitoring, Analysis and Reporting Technologique
SMS Short Message Service
SMTP Simple Mail Transfert Protocol
SNMP Simple Network Management Protocol
SSH Secure Shell
SSL Secure Socket Layer
SSO Single Sign-On
TB Tera Bytes
TCP Transmission Contrôle Protocole
TLS Transport Layer Security
UDP User Datagram Potocole
UML Unified Modeling Langage
UNB Université NAZI BONI
VPN Virtual Private Network
XML eXtensible Markup Language

X
1

INTRODUCTION GÉNÉRALE
Les notions de science et de technique se transforment à un rythme rapide depuis la
grande révolution scientifique du 18ème siècle. Ces changements ont apporté une
autonomie renouvelée et une forte dose d'innovation. Mais de nos jours, on parle
plutôt des nouvelles technologies de communication et de l'information avec
l'informatique qui devient de plus en plus incontournable. Science du traitement
rationnel de l'information, l'informatique s'impose plus que jamais, comme un outil
précieux dont a besoin toute entreprise qui veut accroître sa productivité et rester
compétitive sur le plan international. Ainsi dans le domaine des entreprises
modernes, l'adoption d'un système d’information facilite énormément les processus
d'administration (personnelle et matérielle) et de productivité. Ce qui est le cas de
notre structure d’accueil SOFTNET. En effet elle est équipée d’un vaste réseau
dans lequel fonctionne un système d’information assez complexe. Cela implique la
surveillance de ce système d’information est une opération indispensable afin de
minimiser la perte d'exploitation et garantir le bon fonctionnement des
équipements de chaque collaborateur de SOFTNET. La maîtrise du système
d’information devient primordiale vu qu’il est au cœur des activités de SOFTNET
et qu’il doit fonctionner pleinement et en permanence pour garantir la fiabilité et
l'efficacité exigées, d'une part. D'autre part, les problèmes liés au système
d’information tels que les défaillances, les pannes, les coupures et les différents
problèmes techniques doivent être réduits, du fait qu'une indisponibilité du système
ou du réseau peut causer des pertes considérables (image de SOFTNET vis-à-vis
de ses clients, l’interruption de services…). Afin de palier à certains risques comme
la perte d’une base de données, Il faut assurer la disponibilité, la pérennité et la pro-
activité des maintenances à travers la mise en place des mécanismes de supervision
du SI. Ainsi le lien étroit existant entre la supervision du système d’information
d'une entreprise et sa productivité suscite notre curiosité et justifie certainement le
choix du thème d’étude : « Étude et mise en place d'un outil de supervision du
système d’information de SOFTNET ».
Ce document est un résumé de toutes les recherches et travaux effectués sur ce
thème. Il est structuré en cinq (05) chapitres. Le premier chapitre présente le
contexte du stage. Le second porte sur l’analyse de l’existant et la démarche de
résolution. Le troisième expose les généralités des solutions de supervision et leur
étude comparative. Le quatrième chapitre traite des détails de la solution retenue et
enfin le cinquième porte sur l’implémentation technique de la solution. Finalement,
nous terminons par une conclusion générale qui récapitule les principales
observations concernant le travail réalisé

1
2

CHAPITRE 1
PRESENTATION DU CONTEXTE DE STAGE
1.1. Introduction

Dans ce chapitre, nous présentons d’abord l’École Supérieure d’Informatique


(ESI), notre école de formation et SOFTNET, la structure d’accueil et initiatrice du
projet. Ensuite, nous mettrons en évidence la problématique liée à la supervision
tout en évoquant les objectifs et les résultats attendus. Enfin, les acteurs du projet
et le planning prévisionnel sont présents.

1.2. Présentation de l’ESI


1.2.1. Présentation générale

L’École Supérieure d’Informatique (ESI) fait partie des huit (08) établissements
d’enseignement et de recherche de l’Université NAZI BONI (Ex Université
Polytechnique de Bobo Dioulasso). Elle est née en 1991 du besoin exprimé par le
Premier Plan Directeur Informatique (1991-1995) « édification de compétences
nationales par la formation de spécialistes (analystes et ingénieurs) concepteurs de
système d’information ».
D’abord implantée à Ouagadougou, l’ESI a ensuite été installée au sein de
l’Université Polytechnique de Bobo-Dioulasso en septembre 1995. La première
promotion de diplômes est sortie en juin 1993. On retrouve désormais des anciens
élèves de l’ESI dans tous les secteurs de la vie économique. Autant les banques que
les entreprises industrielles ou les prestataires de services informatiques, aussi que
les mairies, ONG et administrations diverses.
L’ESI délivre les diplômes de :

Licence en informatique (BAC+3)

• Option Système d’Information (SI)


• Option Réseaux et Systèmes (RS)

2
3

Master en informatique (BAC+5)

• Option Système d’Information parcours Système d’Aide à la Décision (SAD)


• Option RS parcours Conception et Architecture des Réseaux (CAR)

[1]

1.2.2. La licence en informatique


1.2.2.1. Objectifs

Ce cycle a pour objectif de former des cadres moyens opérationnels et évolutifs


dans une diversité de domaines d’application de l’informatique.
La culture générale de ces ingénieurs de travaux informatiques est telle qu’elle leur
permet de :
▪ dialoguer avec des utilisateurs d’horizons divers : concepteurs, gestionnaires,
spécialistes de différents domaines techniques et scientifiques ;
▪ participer efficacement à la conception, la réalisation et la maintenance
d’applications informatiques ;
▪ assurer la formation des utilisateurs ;
▪ gérer des centres informatiques ;
▪ etc.
1.2.2.2. Programme d’études
Le programme d’études se déroule sur trois années académiques de trente
semaines. Les enseignements se répartissent en trois pôles :
▪ Matériels et logiciels de base (23% du volume horaire total). Il concerne les
enseignements portant sur l’architecture des ordinateurs, les principes de base
qui régissent leur fonctionnement interne ainsi que les logiciels qui les
accompagnent
▪ Formation générale (45% du volume horaire total). Il regroupe quatre
disciplines : les mathématiques, l’anglais, les techniques d’expression française et
la gestion/comptabilité/économie ;

3
4

▪ Ingénierie des logiciels d’application (32% du volume horaire total). Il donne


aux élèves les fondements de la programmation et les techniques d’ingénierie
des logiciels d’application. Il se compose de trois groupes de matière :
l’algorithmique, les outils de productivité (bureautique, SGBD etc.), les
méthodes et outils d’aide à l’ingénierie des applications informatiques (UML,
Java, Visual Basic, C…).
[2]

1.2.2.3. Stages et projets en entreprise


Le programme d’études est ponctué d’un stage de programmation en entreprise (8
semaines) à la fin de la deuxième année de formation et d’un projet de fin d’études
(5 mois) portant sur des applications réelles proposées par des entreprises et
administrations de la place en troisième et dernière année de ce cycle.

1.2.3. Le master en informatique

Le Master de l’ESI offre aux étudiants la possibilité de se spécialiser en Système


d’Information option aide à la prise de décision ou RS option architecture des
réseaux. Ce cycle est ouvert aux titulaires d’une Licence en Informatique et la durée
de la formation s’étend sur deux ans.

1.2.4. Mission de l’ESI

L’ESI a pour mission :

▪ La formation fondamentale, appliquée et/ou professionnelle dans les domaines


de l’informatique ;
▪ La recherche scientifique et technologique ainsi que la valorisation des résultats
de la recherche ;
▪ La diffusion de la culture et de l’information dans les domaines relevant de sa
compétence ;

4
5

▪ La collaboration avec d’autres structures de formation et/ou de recherche pour


la préparation des diplômes ;
▪ Et la participation à des programmes internationaux de formation et de
recherche.

L’ESI bénéficie pour la réalisation de ses enseignements du soutien des partenaires


tels que :
▪ Université Ouaga 1 Pr Joseph KI -ZERBO ;
▪ Université Ouaga 2 ;
▪ Université de Norbert ZONGO ;
▪ Université Gaston BERGER (Sénégal) ;
▪ Agence Universitaire de la Francophonie ;
▪ Université Paris Dauphine (France) ;
▪ Université de Poitiers (France) ;
▪ Université Polytechnique de Catalogne (Espagne) ;
▪ Agence Nationale de Promotion des TICs (ANPTIC)
▪ Agence Nationale de Sécurité des Systèmes d’Information (ANSSI)

1.3. Présentation de SOFTNET-BURKINA

SOFTNET-BURKINA SA est une société anonyme de droit Burkinabé inscrite au


registre du commerce sous le N° RCCM BFOUA 2003 B1798. C’est une société
d’Intégration de solutions informatiques disposant de filiales dans quatre (04) pays
d’Afrique de l’Ouest à savoir le Burkina Faso, le Mali, le Niger et la Côte d’Ivoire
mais s’adressant à une clientèle répartie dans la région Ouest et centre de l’Afrique.
Elle est située à Ouagadougou sur 1017, l’avenue Kwamé Nkrumah et a un
détachement à Bobo-Dioulasso.

1.3.1. Présentation

5
6

Créé en 2003, SOFTNET GROUP a capitalisé une somme d’expériences et de


compétences reconnues qui l’ont positionné comme l’un des acteurs majeurs des
solutions intégrées IT en Afrique de l’Ouest et du centre.
SOFTNET intervient principalement dans les domaines des Infrastructures
Réseaux et Télécommunications, de l’ingénierie Logicielle, des infrastructures
Systèmes et Sécurité, des Services à valeur Ajoutée ainsi que dans celui des
Formations et du Consulting. Pour maintenir sa croissance tout en continuant de
fournir des services de qualité, elle s’est dotée d’une organisation à l’échelle du
groupe avec des ressources humaines et techniques de haut niveau (Confère
organigramme). SOFTNET Group a participé à l’amélioration des performances et
de la compétitivité des organisations publiques et des entreprises de l’Afrique en
offrant l’ensemble de ses capacités et de ses services pour accompagner l’essor des
pays où elle opère afin de devenir l’un des acteurs majeurs de leurs dynamiques de
croissance. La vision globale de SOFTNET GROUP est de devenir leader dans
son domaine d’activité afin d’être l’interlocuteur sûr et fiable dans implémentation
de solutions informatiques ainsi que dans la conception d’application spécifique
conforme à l’esprit des chefs d’états de la CEDEAO pour le rayonnement de
l’Afrique.

Ses efforts soutenus, engagés pour répondre aux attentes de ses clients et
partenaires lui ont d’ailleurs valus de recevoir de nombreuses distinctions parmi
lesquelles le prix HP Fastest Growing WCA Partner 2010 et les prix Microsoft
WECA et COUNTRY Partner of the Year 2012, 2014, 2015 & 2016
En permanence disponible pour assurer un suivi technique de haut niveau et
anticiper vos attentes fait partie intégrante de nos engagements. SOFTNET
GROUP travaille chaque jour pour maintenir ses engagements vis-à-vis de sa
clientèle.
[3]
1.3.2. Organisation de SOFTNET

6
7

L’organigramme de SOFTNET représenté ci-dessous par la figure 2

Softnet Busness Solution


(SBS)

SOFTNET Network et
Systeme
Infrastructure(SNSI)
Business Unit
SOFTNET Training Center
(STC)
Directeur de Filiale

SOFTNET Support Et
Managment Services (SSMS)
President Directeur General

DGA

SOFTNET Business Analystis


et Bid Center(SBABC)

SOFTNET product et Cloud


Direction Commerciale
Services(SPCS)

SOFTNET Business Account


Manager(SBAM)

Finance/ Comptabilité

DFC

Administration et Finances Achat/Logistique

DRH

Figure 1 : Organigramme de SOFTNET

1.3.3. Les effectifs

La figure 3 illustre les effectifs par pays

7
8

Effectifs Par pays

4%
9%

10% SOFTNET BF
SOFTNET CI
SOFTNET MALI
SOFTNET NIGER
77%

Figure 2 : Effectif en fonction des pays

SOFTNET Burkina compte à elle seule 62 travailleurs qui sont basés au Burkina
soit 77% de l’effectif total des travailleurs du groupe ; cela s’explique
essentiellement par le fait que SOFTNET Burkina est également le siège du groupe
SOFTNET et aussi elle est la première filiale créée en 2003.

1.3.4. Présentation des activités des différentes directions

Nous distinguons cinq directions dont nous allons essayer de présenter leurs
activités.

1.3.4.1. La direction technique

Elle est chargée de l’exécution de tous les projets obtenus. Pour ce faire elle dispose
de techniciens qualifiés dans les différents domaines tels que le Génie Logiciel, les
infrastructures réseaux et télécom, les infrastructures systèmes et sécurité ainsi que
la maintenance. Pour l’exécution de chaque projet, une équipe projet est définie
mais il n’est pas exclu de voir des personnes travailler sur plusieurs projets à la fois.

8
9

La Direction technique fournit également des formateurs dans le cadre des activités
des différents centres de formations du groupe.

La DT en collaboration avec le Chef de Département Avant-vente fait des


propositions de solutions adaptées aux besoins des clients. La Direction technique
participe à la présentation et aux démos de nouvelles solutions auprès des clients
pour susciter de nouveaux besoins.

La DT assiste la Direction Financière, comptable et du budget dans le sens que ce


sont les techniciens qui communiquent les taux d’exécution des projets pour
pouvoir demander des comptes à la fin du projet, ils doivent veiller à la signature
des différentes attestations pour la clôture du projet.

Nous avions effectué notre stage au niveau de la DT durant tous les 03 mois de
stage.

1.3.4.2. La direction des opérations commerciale

Elle est chargée de la définition et de la mise en œuvre de la stratégie commerciale


et Marketing de la société. Elle est le garant de l’atteinte des objectifs chiffrés de la
société.

La Direction des Opérations commerciales coordonne les activités de réponses aux


appels d’offres. Elle est dotée d’un département Gestion des Offres et d’un
département avant-vente qui veillent au bon déroulement du montage des dossiers.
Elle dispose également d’une équipe de commerciaux chargée de conquérir le
marché auprès des certains clients particuliers et aussi de faire la promotion des
produits et services offerts par SOFTNET. La Direction commerciale s’occupe
également de la négociation et du renforcement des partenariats entre SOFTNET
et d’autres sociétés.

9
10

1.3.4.3. La direction financières, comptable et du budget

Elle est chargée de l’élaboration et du contrôle de l’exécution du Budget de la


société ; elle s’occupe également de la gestion financière et comptable de la société
par la disponibilité des ressources financières et l’utilisation adéquate de ces
ressources par la planification des activités. Elle s’assure du recouvrement auprès
des clients pour permettre à la société de faire face à ses engagements vis-à-vis des
fournisseurs et des banques. Elle dispose d’une équipe composée du chef de
département, le chef comptable, un comptable, un agent de recouvrement et une
caissière.

1.3.4.4. La direction administrative et des ressources humaines

Elle est chargée de la gestion administrative de la société notamment le traitement


de l’information, la réponse aux courriers, la gestion administrative quotidienne, la
représentation de la société, la gestion des polices d’assurances, la gestion du parc
roulant ainsi que l’organisation administrative de la société. Elle connait des
questions du personnel notamment le recrutement, la formation, la gestion
carrières, les avancements, la paie, la relation entre la société les institutions de
prévoyance sociales.

1.3.4.5. Le département des achats et logistique

Il est chargé de satisfaire tous les besoins en équipe de la société et pour l’exécution
des projets. Il est le principal interlocuteur des fournisseurs nationaux comme
étrangers. Il veille au bon acheminement des pièces depuis la commande jusqu’à
l’arrivée. Il s’occupe des formalités de transit et de douanes. C’est le département
achat et logistique qui s’occupe également de la facturation des clients ainsi que le
suivi du stock de matériel de la société. Pour la réalisation de ses attributions le

10
11

département est composé d’un chef de Département, d’une Administratrice des


ventes, d’un agent de transit et d’un magasinier.

1.3.5. Services offerts

SOFTNET propose une prestati1on de services professionnels de haut niveau en


matière de systèmes d’information informatisée. La mise en place de solutions
informatiques nécessite une expertise dans chacun des services proposés. De
l’Ingénierie à la Maintenance des Systèmes et Réseaux, sans oublier Internet et les
services connexes, SOFTNET offre l’ensemble des prestations associées à
l’informatique distribuée :

➢ Conseils et conception en architectures systèmes et réseaux : Rédaction de


Cahier de Charges, conduite de projets
▪ Support technique matériel, logiciel et réseaux ;
▪ Assistance informatique sur site ;
▪ Formation (Centre de Formation) ;
▪ Formation et délégation de personnel en régie.
➢ Systèmes d’Information
▪ Test et validation de connaissances métiers (centre de Test) ;
▪ Assistance (Centre de Maintenance agréé HP) ;
▪ Développement d’applications informatiques sur mesure ;
▪ Audit et Sécurité des systèmes et réseaux ;
▪ Câblage réseaux en cuivre et fibre optique.

SOFTNET assiste ses clients dans leur choix d’organisation et d’implémentation.


Elle assure également la mise en œuvre des produits choisis, avec une gamme
complète de services de bout en bout autour de chaque produit. Il ne faut pas non
plus oublier que SOFTNET est également partenaire avec de grandes firmes
comme : HP, Microsoft, CISCO, APC, Symantec… qui lui permet de bien se
positionner pour couvrir les besoins en équipements de hautes technologies et en

11
12

solutions de pointe mais aussi de former et de délivrer des certifications de


compétence des éditeurs, des leaders de logiciels, des leaders de réseaux etc.

[4]

1.4. Présentation du projet


1.4.1. Problématique
Dans le monde de l’entreprise, il existe une multitude de système d’information à
surveiller. Pour autant, l’activité de supervision de ce système d’information n’est
pas toujours remplie efficacement et on préfère souvent se consacrer à des tâches
plus urgentes liées à la production. Tout utilisateur veut pouvoir constamment
accéder à internet, lire ses mails ou encore imprimer. Il faut donc que les éléments
du système d’information communiquent entre eux à l’intérieur de l’entreprise
comme à l’extérieur, avec le client comme entre collègues. Toutes pertes de
données ou interruptions de service peut avoir de graves conséquences qui vont de
la simple perte de temps au lourd impact financier, que ce soit une perte réseau ou
un disque dur plein, on ne peut pas échapper aux erreurs. De plus l’administrateur
système n’a pas la capacité physique de vérifier tous les ordinateurs de tous ses
clients. La supervision des systèmes d’informations est devenue, de par
l’importance croissante des entreprises, un besoin stratégique. Si on se rappelle
qu’un système d’information est un ensemble d’éléments participant à la gestion, au
traitement, au transport et à la diffusion de l’information au sein de l’organisation et
qu’il s’appuie très souvent sur un système d’informatique et toute une infrastructure
réseau. SOFTNET veut tester des solutions de supervision pour les proposer à ses
clients si elles sont concluantes, cela dans le but de permettre à leur client un
meilleur suivi de leurs parc informatique afin de prévenir des pannes et même des
attaques sur leur réseau. C’est ainsi qu’il nous a été confié le travail de mettre en
place un outil de supervision.

1.4.2. Objectif et résultats attendus

12
13

L’objectif de notre étude est la supervision. Il en suit aussi de pouvoir conserver le


contrôle du point de vue technique et applicatif.

Les attentes pour cette étude sont :

➢ Supervision générale des équipements;


➢ Visibilité en temps réel du réseau et des ressources dont dispose un
équipement, ce qui permettra d’avoir des informations rapidement, de
connaitre l’état du réseau et ses performances ;
➢ Garantie de la disponibilité des services ;
➢ Remontées d’alertes en cas de détection d’incidents ;
➢ Proactivité et réaction en cas de panne ;

1.4.3. Gestion du projet


Pour bien mener ce projet tout en respectant l’engagement contracté en tenant
compte des délais impartis et en produisant les résultats escomptés, le projet a été
organisé en fonction des points suivants.

1.4.3.1. Acteurs du projet


Un projet associe un ensemble d’acteurs qui influencent directement ou
indirectement le déroulement de celui-ci. Ils peuvent être moteurs, décideurs mais
aussi opposants. Ils sont répartis en deux groupes dont le groupe de pilotage et le
groupe de projet.

1.4.3.1.1. Groupe de pilotage


Il assure la coordination technique et contrôle la pertinence des solutions
proposées et est composé de :
➢ M. Ouédraogo Maxime, Consultant Ingénieur Réseaux et
Télécommunication à SOFTNET et notre maitre de stage.

13
14

➢ M. Zougmoré Téeg-Wendé G, enseignant à l’ESI, notre superviseur.

1.4.3.1.2. Groupe de projet


C’est la cheville ouvrière du projet. Il est chargé :
➢ De mener à bien les travaux dans les délais impartis ;
➢ D’assurer la cohérence et la faisabilité de la solution retenue ;
➢ Et de rendre compte au comité de pilotage en présentant les rapports
d’évolution.

1.4.3.2. Le planning prévisionnel


Le planning prévisionnel est un outil de communication qui permet d’illustrer de
façon synthétique le planning des travaux et l’affectation des ressources aux
différentes tâches. Nous avons adopté dans les premiers instants de notre projet, le
planning figurant dans le diagramme de Gantt :

Figure 3 : Planning prévisionnel


1.5. Conclusion
Dans ce chapitre, nous avons présenté l’ESI notre école de formation, ensuite la
structure d’accueil et pour finir nous avons fait une présentation de notre projet.

14
15

Dans le chapitre prochain, nous ferons une analyse de l’existant et une présentation
de la démarche de résolution du problème qui a été posé ainsi que les moyens mis à
notre disposition pour la réalisation du projet.

15
16

CHAPITRE 2
ANALYSE DE L’EXISTANT ET DEMARCHE DE RESOLUTION
1.1. Introduction
L’étude de l’existant a eu comme résultat la connaissance du système d’information
actuel de SOFTNET au travers le recensement de ces aspects positifs et aspects
négatifs. Ainsi ce chapitre mettra en exergue d’abord l’évaluation des ressources
(logicielles et matérielles) entrant dans le cadre de notre étude afin de mener une
analyse critique de la situation actuelle. Il s’agira ensuite de faire un diagnostic du
réseau afin de faire ressortir ces atouts et ses faiblesses. Enfin nous présenterons les
démarches suivies afin de résoudre aux problèmes qui seront énumérés.

1.2. Présentation de l’existant


1.2.1. Les ressources logicielles

Les ressources logicielles de SOFTNET se présentent comme suit :

• Les systèmes d’exploitation constituer de : Linux, Windows, MAC


• Les différents services installés sur les serveurs sont : la messagerie, le DNS,
les applications métiers, la téléphonie sur IP.

16
17

1.2.2. Les ressources matérielles

Les éléments qui composent les ressources matérielles de la structure se présentent


comme suit dans le tableau 2 :

Tableau 2 : Ressources matérielles


Désignation Tâche Nombre
Permettre aux utilisateurs d’accéder aux
15
Poste de travail ressources de l’entreprise.
Pour les centres de formations. 30
Serveur Assure la disponibilité des services locaux. 10
Permettre de faire des appels au sein de
Téléphonie IP 1
NR
l’intranet de l’entreprise.
Permettent l’impression, le scannage et la
Imprimantes, scanner
photocopie de tout fichier format numérique NR
et photocopieuses
ou papier.
Switch, routeur, hub, Permet l’interconnexion des différents
NR
antennes équipements du parc informatique.
Protection des équipements contre les
Onduleur microcoupures, les surtensions et les sous- NR
tensions.

1.3. Diagnostique de l’existant


1.3.1. Les aspects positifs

Le système d’information de SOFTNET a une protection physique sur ses


équipements que l’on peut apprécier positivement sur les points suivants :

➢ L’existence d’un locale approprié pour les serveurs ;

11
NR : Non Renseigné

17
18

➢ L’existence d’un système de climatisation permettant de maintenir chaque


salle dans la température ambiante ;
➢ Des caméras de surveillance dans la salle serveur ;
➢ Un capteur de température permettant de notifier l’administrateur réseau
d’une éventuelle surchauffe de la salle serveur ;
➢ L’absence de tout produits ou matières facilement inflammables ;
➢ L’installation électrique composé d’éléments comme des onduleurs, groupe
électrogènes, parafoudre, paratonnerre, fusible. Tous ces éléments protègent les
équipements informatiques contre d’éventuels accidents liés au courant électrique ;
➢ Les sauvegardes : très primordiales surtout pour leurs clients car ils peuvent à
n’importe quel moment faire des restaurations de ces données en cas d’incidents
comme les attaques contre le système et ou le crash d’un de leur disque dur.

Sur le plan logique nous avons pu relever :

➢ La mise en place de pare-feu pour la protection du réseau et des données qui


y transitent ;
➢ Les antivirus contre les attaques à l’interne du réseau.

L’accès au réseau internet est soumis à une restriction de l’accès à certains site web
distractif ou malveillants lors des heures de travail afin d’éviter des
déconcentrations chez les employés et d’évité les intrusions ou attaques des sites
web malveillants.

1.3.2. Les aspects perfectibles

Le système informatif de SOFTNET regorge un certain nombre de faille que l’on a


peut recenser :

➢ Le manque de panneau interdisant l’accès à certains locaux ;


➢ L’absence d’un registre de renseignement papier ou numérique des entrées et
sortie de chaque personne en entreprise ;

18
19

➢ Une meilleure solution d’outil de supervisions du système d’information de


SOFTNET.

1.3.3. Suggestion de solutions

Pour mieux gérer les équipements informatiques de la structure, les mesures


suivantes peuvent être envisagées :

✓ Sensibiliser tout le personnel administratif sur la supervision des


équipements informatique afin de faciliter leur collaboration ;
✓ Mettre en place un canal de connexion pour l’échange de donné entre
SOFTNET et ses clients ;
✓ La mise en place d’un meilleur outil de supervision du système
d’information.

1.4. Démarche de résolution du problème


1.4.1. Méthode utilisée
Dans le but de pouvoir régler le problème de supervision du parc informatique de
la structure, nous avions suivi une étude comparative ayant pour objet de choisir
l’outil de supervision adéquat pour nos besoins. L’outil choisi, nous sommes passés
à son étude et son implémentation sur un environnement de test avant de la tester
sur l’environnement de production.

1.4.2. Moyens technique nécessaires

Afin de mener à bien notre étude, nous avions eu besoin d’un environnement de
travail assez convivial. Ainsi les ressources qui étaient présente sont les suivantes :

Ressources matérielles

19
20

Ci-contre le tableau 3 regroupant les ressources matérielles mises à notre


disposition tout au long du déroulement du stage.

Tableau 3 : Ressources matérielles


Désignation Caractéristiques
HP Laptop Intel Dual core, 4Go de RAM, 500 HDD
HP laptop Core i7, 4Go de RAM, 500 HDD

Ressources logicielles

Ci-dessous le tableau 4 regroupant les ressources logicielles

Tableau 4 : Ressources logicielles


Nom du
Éditeur Licence Fonction
Logiciel
Outil de virtualisation de poste de
travail, utilisé pour mettre en place
un environnement de test pour
VMware
VMware Gratuite développer de nouveaux logiciels,
Workstation
ou pour tester l'architecture
complexe d’un système
d’exploitation
Émulateur permettant la
Plan C virtualisation des équipements
Gns3 Gratuit
Technologies réseaux et la mise en place d’un
réseau physique en milieu virtuel
Navigateur web libre permettant
Mozilla
Mozilla Firefox Gratuit d’effectuer des recherches sur
Foundation
internet
[5]

1.5. Conclusion
Nous pouvons conclure en mettant en exergue le fait que l’étude de l’existant a
permis de connaitre la structure SOFTNET dans la plupart de ses aspects. Quant à
la phase du diagnostic de l’existant, elle a permis de faire ressortir les forces et les
insuffisances de la structure afin de pouvoir éventuellement proposer des solutions
pour la bonne gestion des équipements de système informatiques.

20
21

21
22

CHAPITRE 3
GENERALITES SUR LES SOLUTIONS EXISTANTES
3.1. Introduction

Ce chapitre est rédigé en trois parties et fournit les clés de compréhension du


projet. La première partie expose les concepts généraux entrant dans le cadre de
notre étude. Le second présente les différentes solutions que nous avons trouvées.
Enfin, la troisième partie présente une étude comparative effectuée dans le but de
trouver une solution répondant aux attentes exprimées par SOFTNET.

3.2. Concepts généraux


3.2.1. Définition

La supervision informatique est une technique de surveillance, d’analyses et


d’alertes permettant de palier les problèmes liés à tous les niveaux de
fonctionnement informatique d’une entreprise. Elle rend l’entreprise plus
performante et surtout proactive. Elle doit répondre aux préoccupations suivantes :

• Technique : surveillance du réseau informatique, de l’infrastructure de


l’entreprise ;
• Fonctionnelle : surveillance des machines informatiques et de production ;
• Applications : suivis des applications dans le cadre d’un processus métier.

3.2.2. Principes de fonctionnement de la supervision


3.2.2.1. Fonctionnalités de la supervision
3.2.2.1.1. La surveillance

La surveillance informatique résulte de ce que l’on appelle monitoring qui est une
activité de mesure d’une activité informatique. La surveillance des équipements
d’une infrastructure est la fonctionnalité de base, proposée par les différents outils
de supervision du marché. Ils permettent de surveiller :

22
23

• Les ressources d’un équipement informatique


• Le trafic réseaux ;
• Les attaques liées au réseau ;
• Les flux de donnée entre application.

[6]
3.2.2.1.2. Les notifications
La notification est employée pour décrire des fonctions d’alerte automatisées entre
processus. Mais lorsqu’un incident est détecté, il faut autoriser la réception des
notifications informant ainsi qu’un changement d’état vient d’avoir lieu. Ce genre
d’évènements est généralement distribué par messagerie, ou par SMS et/ou 2IRC.
Il est même possible de distribuer sélectivement les notifications à un autre groupe
d’utilisateurs bien défini, en fonction des plages horaires programmées et de répéter
cet envoi plusieurs fois lorsque la réparation, ou l’acquittement, n’est pas réalisé au
bout d’un certain laps de temps.

[7]

3.2.2.1.3. Les sondes


Généralement, les outils de supervision n’effectuent pas eux-mêmes la surveillance
de certains composantes : mémoire, CPU, disques… Ces composantes sont, la
plupart du temps, constitutives de scheduler (ou ordonnanceurs) déléguant cette
tâche à des sondes. Concrètement, les sondes sont des scripts, des programmes ou
plus généralement du code, appelés par le scheduler, qui effectuent l’ensemble des
traitements de vérification et envoient leurs résultats afin de centraliser les
informations récoltées. On doit donc pouvoir ajouter facilement des sondes en
s’appuyant sur les différentes extensions (ou plugins) disponibles.

3.2.2.1.4. Les dépendances

2
IRC : Internet Relay Chat, Serveur permettant de dialoguer en direct avec plusieurs personnes

23
24

Il est primordial que les différents équipements conservent leur interdépendance au


sein de l’outil de supervision. Si l’on prend l’exemple des bases de données, des
switchs et des serveurs : le mode opérationnel est vérifié lorsque les bases de
données hébergées sur les serveurs sont opérationnelles et que les switches
interconnectant les serveurs sont également en fonction. Ainsi, en précisant la
dépendance des serveurs vis-à-vis des bases de données et des switches vis-à-vis
des serveurs, on peut alors notifier les cas de pannes. Et cela facilite la détection
d’incidents en se concentrant sur l’essentiel de l’information, la panne de
l’équipement interdépendant, plutôt que sur l’ensemble des machines en alerte. Cela
permet de mieux mettre en évidence l’équipement ou le service en défaut et de
faciliter le troubleshooting et la maintenance.

3.2.2.2. Principe de la supervision

Le principe de la supervision est de s'assurer du bon fonctionnement d'un système.


En sommes, superviser n’est pas seulement surveiller, encore faut-il pouvoir alerter
et analyser les données collectées sur les équipements afin d’être proactif et plus
uniquement réactif. On peut résumer la supervision par le graphe de la figure 5
suivante :

Surveiller Visualiser

Alerter Analyser

Figure 4 : Principe de supervision


[5]

3.2.2.2.1. Supervision système

24
25

Ce type de supervision s’applique à surveiller essentiellement l’ensemble des


ressources des différents systèmes d’exploitation : mémoire RAM, stockage de
masse, type de RAID.

3.2.2.2.2. Supervision réseau

Ici, on cherche essentiellement à surveiller les équipements réseau tels que les
commutateurs, les routeurs… L’idée est de s’assurer que ces équipements sont
opérationnels, qu’aucun port ou GBic (Gigabit interface Converter) n’est
défectueux et que les interconnexions sont effectives. En outre, elle porte sur la
surveillance de manière continue de la disponibilité des services du
fonctionnement, des débits, de la sécurité mais également du contrôle des flux.

3.2.2.2.3. Supervision sécurité


On peut également aller jusqu’à surveiller les attaques contre le système
d’information de l’entreprise. C’est généralement dans ce cadre qu’intervient ce type
d’activité, mettant en place l’ensemble des contre-mesures, scrutant et analysant les
différents accès et permettant de détecter les tentatives d’intrusions.

3.2.2.2.4. Supervision applicative

La supervision des applications (ou supervision applicative) permet de connaître la


disponibilité des machines en termes de services rendus en testant les applications
hébergées par les serveurs. La supervision applicative passe par des mesures faites
aussi sur le flux de service. On parle alors de validation fonctionnelle. On utilise
souvent un sous-ensemble des tests ayant permis la recette d'une application pour
n'en prendre que les tests qui sont représentatifs de l'activité sans pour autant
générer une charge trop importante ou modifier les données applicatives. La
supervision applicative ne peut se faire sans considérer la sécurité applicative

25
26

3.2.2.2.5. Supervision métier


De façon plus générique, on s’intéresse ici à la supervision des différents processus
métier. En effet, un métier peut dépendre de plusieurs applications. Il faut donc
s’assurer que celles-ci sont bien toutes actives et en bon état de fonctionnement.

3.2.3. La norme ISO

ISO s'intéresse de près à la supervision. Dès 1988, l'organisme a publié la norme


ISO7498/4 définissant les principales fonctions que doivent implémenter les
systèmes de supervision et d'administration. Ces fonctions sont :

➢ Gestion des performances ;


➢ Gestion des configurations (Management configuration) ;
➢ Gestion de la comptabilité (Accounting Management) ;
➢ Gestion des anomalies (Fault Management) ;
➢ Gestion de la sécurité (Security Management).

3.2.3.1. Gestion des performances


Un système de supervision répondant aux normes doit analyser de manière
continue les performances du réseau comme l’état des ports d’un switchs. Il doit
pouvoir évaluer les performances des ressources du système ainsi que leur
efficacité. Le système doit comporter des procédures de collecte de données et de
statistiques qui aboutiront à l’établissement de tableaux de bord. Les informations
recueillies doivent aussi permettre de planifier les évolutions du réseau.

3.2.3.2. Gestion des configurations

26
27

La gestion de configuration doit permettre d’identifier, de paramétrer et de


contrôler les différents objets du réseau. Les procédures requises pour gérer une
bonne configuration sont :

➢ La collecte d’information ;
➢ Le contrôle d’état ;
➢ La sauvegarde historique de configurations de l’état du système.

3.2.3.3. Gestion de la comptabilité

La gestion de la comptabilité mesure l'utilisation des ressources afin de réguler les


accès et d'instaurer une certaine équité entre les utilisateurs du réseau. Ainsi des
quotas d'utilisation peuvent être fixés temporairement ou non sur chacune des
ressources réseaux.

3.2.3.4. Gestion des anomalies


La gestion des anomalies détecte les problèmes réseaux (logiciels ou matériels). Elle
essaie d'isoler le plus précisément le problème en effectuant divers tests. Quand
cela est possible, elle règle elle-même automatiquement l'anomalie. Sinon, elle alerte
les personnes concernées du type de problème afin de solliciter leur intervention.
La gestion des anomalies garde dans une base de données l'ensemble des
problèmes survenus ainsi que leur solution, de manière à être encore plus efficace
face à un incident récurrent. La gestion des anomalies permet donc la détection, la
localisation et la correction d’anomalies passagères ou persistantes.

3.2.3.5. Gestion de la sécurité

27
28

La gestion de la sécurité contrôle l'accès aux ressources en fonction des politiques


de droits d'utilisation établies. Elle veille à ce que les utilisateurs non autorisés ne
puissent pas accéder à certaines ressources protégées. La gestion de la sécurité met
donc en application les politiques de sécurité.

[8]

3.2.4. Les protocoles utilisés [9]


3.2.4.1. Protocole TCP/IP

La suite TCP/IP (Transmission Contrôle Protocole/ Internet Protocol) est


l'ensemble des protocoles utilisés pour le transfert des données sur Internet. Elle a
été créée pour palier à certains problèmes du modèle OSI qui n'offre pas une
richesse suffisante au niveau des couches basses pour représenter la réalité ; il est
nécessaire d'ajouter une couche supplémentaire d'interconnexion de réseaux
(Internet working) entre les couches Transport et Réseau.

Afin de superviser les équipements du parc informatique qui rentre fréquemment


sur internet, il faut en réalité surveiller le bon fonctionnement des ports de services
TCP/IP. Comme on l’a mentionné plus haut, l’art de la supervision consiste non
seulement à surveiller les équipements et leur bon fonctionnement, mais également
l’ensemble des services connus ainsi que leurs ports de communication. Il est donc
essentiel de les connaître et de comprendre le fonctionnement des différentes
fonctions utilisées par les applications pour remonter les notifications en temps
voulu.

L’intérêt du protocole dans la supervision n’est pas vraiment mis en exergue. Je


vois juste une définition de TCP/IP

[10]

28
29

3.2.4.2. Protocole ICMP

Une des commandes les plus utilisées lors de l’exercice de supervision est la
commande ping. Il s’agit d’un petit programme s’appuyant sur le protocole ICMP
(Internet Control Message Protocol) décrit dans la RFC 792, permettant de
déterminer l’accessibilité d’un équipement en analysant ses messages de contrôle et
d’erreur. ICMP est un protocole de niveau 3 sur le modèle OSI, qui permet le
contrôle des erreurs de transmission. En effet, comme le protocole IP ne gère que
le transport des paquets et ne permet pas l'envoi de messages d'erreur, c'est grâce à
ce protocole qu'une machine émettrice peut savoir qu'il y a eu un incident de
réseau.

Bien qu'il soit à un niveau équivalent au protocole IP (si l'on tente de rapprocher le
modèle OSI au modèle TCP/IP), un paquet ICMP est néanmoins encapsulé dans
un datagramme IP. Dans le cadre de l'IPv4, la forme générale d'un tel paquet est
représentée par le tableau 4 suivante :

Tableau 5: Datagramme IP

Bit 0 - 7 Bit 8 - 15 Bit 16 - 23 Bit 24 - 31


Type de
Version/IHL Longueur totale
service
Identification
flags et offset (fragmentation)
(fragmentation)
Durée de vie
Protocole Somme de contrôle de l'en-tête
(TTL)
Adresse IP source
Adresse IP destination
Type de
Code Somme de contrôle
message

Bourrage ou données

29
30

Données (optionnel et de longueur variable)

Un tel datagramme est composé :

• D'un en-tête IP (en bleu), avec Protocole valant 1 et Type de Service valant 0.
• Du type de message ICMP (8 bits)
• Du code de l'erreur (8 bits)
• D'une somme de contrôle (16 bits), calculée sur la partie spécifique à ICMP
(sans l'en-tête IP)
• D'une partie aménagée pour des données relatives aux différents types de
réponses (32 bits), Si elle n'est pas utilisée, on procède à un bourrage (cette
partie peut correspondre aux Identifiant et Numéro de séquence pour un
paquet de type Ping par exemple)
• Du message
[11]

3.2.4.3. Protocole SNMP

Le protocole SNMP (Simple Network Management Protocol) décrit dans la RFC


1157 est également essentiel à la surveillance d’infrastructure. Il s’agit d’un
protocole de communication permettant aux administrateurs du réseau de gérer
l’ensemble des équipements, de les superviser et de diagnostiquer d’éventuels
problèmes à distance. Les systèmes de gestion de réseau sont basés sur trois
éléments principaux : un superviseur (manager), des nœuds (nodes) et des agents. Ce
protocole permet donc de savoir si un équipement est joignable ou non depuis le
réseau d’entreprise. Commutateurs, concentrateurs, routeurs, postes de travail et
serveurs (physiques ou virtuels) sont des exemples d'équipements contenant des
objets gérables. Ces objets gérables peuvent être des informations matérielles, des
paramètres de configuration, des statistiques de performance et autres objets qui
sont directement liés au comportement en cours de l'équipement en question. Ces
équipements sont alors classés dans une espèce de base de données arborescente

30
31

appelée MIB (Management Information Base). Le protocole SNMP autorise ainsi le


dialogue entre le manager et les agents afin de recueillir les objets à gérer au travers
la MIB.

[12]

3.3. Présentation des différentes solutions


3.3.1. Critère de comparaison

Nous allons donc étudier sept (07) solutions open-source en matière de supervision
qui se veulent assez complètes. Cette étude ressemble à un banc d'essai puisque
pour chacun des logiciels nous allons :

• Faire une courte présentation et expliquer son fonctionnement ;


• Faire le tour des fonctionnalités puis finir sur les avantages et inconvénients.

3.3.1.1. NetMRG
3.3.1.1.1. Présentation

Créé en 2001, NetMRG veut se distinguer des autres en proposant des petites
améliorations : Visualisation des graphiques avec historiques et "auto-scroll",
utilisation de modèles (Templates) pour plus facilement ajouter de nouveaux
graphiques, mise à jour du logiciel simplifiée, Gestion des jours de travail.
L'architecture logicielle est découpée en composants :

• Un moteur C++ chargé de récolter les données. Conçu dans le but de


supporter une charge conséquente. Ce moteur est au cœur de l'application, il
ordonnance les tâches et gère les interactions en plus de son rôle de "récolteur".
• RRDTOOL composant vu précédemment qui apporte sa puissante gestion
des données ainsi que ses atouts indéniables en matière de génération de graphique.
• Une base de données MySQL permettant de sauvegarder la configuration.

31
32

• Une interface réalisée grâce à PHP, qui permet de modifier la configuration


et d'afficher les graphiques au format PNG générés par RRDTOOL. Pour
retrouver les graphiques on doit tout d'abord passer par un arbre qui organise les
différentes machines et statistiques associées. Ce "Device Tree" affiche tout
d'abord des groupes (Group) lesquels contiennent des machines (Device), puis on
accède aux différents services ou valeurs monitorées (Sub device) avant de trouver
à l'intérieur les graphiques (Monitors). Des "events" sont également visibles en cas
de problème.

3.3.1.1.2. Avantages
✓ Performances : L'application semble pouvoir tenir la charge avec
énormément de machines surveillées grâce au moteur multi-threadé ;
✓ Alarmes : Il est possible de configurer des évènements qui avertissent
l'administrateur d'un fonctionnement anormal ;
✓ Gestion des utilisateurs dans la surveillance de leurs activités.

3.3.1.1.3. Inconvénients
o Interface : L'interface n'est pas très accueillante et est déroutante au début ;
o Configuration : Il n'est pas très aisé d'ajouter de nouveaux équipements à
surveiller si l'on sort du cadre du Template prédéfinie ;
o Un développement lent, peu de versions et très espacées dans le temps ;
o Aucune gestion de carte de réseau, et aspect rudimentaire des alarmes.
Aucune gestion de panne.

3.3.1.2. Cacti
3.3.1.2.1. Présentation

32
33

Tout comme NetMRG, Cacti se base sur RRDTOOL et se présente lui-même


comme étant l'interface la plus complète à celui-ci. Cacti utilise également une base
MySQL pour stocker la configuration.

Depuis la version 0.8.6, Cacti propose un moteur de récolte des données en C,


nommé Cactid, utilisant avantageusement les Threads POSIX. Une stratégie qui
ressemble étrangement à celle réalisée par NetMRG sauf que Cacti propose de
l'utiliser seulement si vous avez réellement besoin de performances (dans le cas
contraire c'est le moteur PHP qui prend le relais).

On retrouve les mêmes fonctionnalités que NetMRG : Sources de données


multiples via scripts dans de multiples langages, gestion des utilisateurs et ajout
d'équipement à partir de modèles (templates)de configuration.

L'interface est divisée en deux, une partie nommée "Console" permettant de tout
configurer et une autre nommée "Graphs" permettant d'afficher les graphiques.
L'originalité réside dans le fait que la partie affichage de graphiques possède trois
modes d'affichages :

• Tree mode : Ressemble à l'interface de NetMRG, classement en arbre des


différentes machines par groupes. Utile pour gérer un grand nombre de
machines ou équipements ;
• List mode : Permet de lister les graphiques présents sur une machine
sélectionnée dans la liste ;
• Preview mode : Ressemble à List Mode excepté que les graphiques sont
affichés directement au lieu d'un lien vers celui-ci. Utile pour avoir un aperçu
rapide de l'état d'une machine et de ses services.

La figure 8 illustre la page d’accueil de Cacti

33
34

Figure 5: Dashboard Cacti

3.3.1.2.2. Avantages
✓ Interface : Beaucoup plus claire que celle de NetMRG elle permet également
beaucoup plus de choses ;
✓ Configuration : Avec l'utilisation des templates pour les machines, les
graphiques, et la récupération des données tout se configure aisément et
entièrement via l'interface web. Import/ Export très simple des templates au
format XML.
✓ Performance : Avec le choix du moteur de récolte des données, On peut opter
pour la performance ou la simplicité ;
✓ Communauté sur le web, présence d'une dizaine de plugins

3.3.1.2.3. Inconvénients
o Pas de gestion d'alarmes, sauf avec un plugin nommé Thold ;
o Pas de gestion de panne et absence d'une cartographie de réseau ;
o Un développement lent tout comme NetMRG.

34
35

3.3.1.3. Zabbix
3.3.1.3.1. Présentation

Créé en 2001, puis donnant naissance à une entreprise nommée Zabbix SIA en
2005, Zabbix est une solution de supervision open-source de plus en plus prisée.
L'entreprise vise à faire de Zabbix un logiciel reconnu dans le milieu de la
supervision et créer une communauté autour de lui pour permettre une évolution
plus rapide. A côté de cela, cette société propose un service de maintenance
commercial.

Zabbix permet plusieurs moyens d'acquérir les données :

• Via SNMP : comme tous ses concurrents ;


• Via test de service : Il n'y a rien à installer sur l'équipement surveillé, mais les
tests sont limités à des ping ou test de protocoles (SMTP, HTTP...) ;
• Via l'agent Zabbix local : C'est une originalité, installer un agent permet
d'obtenir toute information sur l'équipement sans utiliser le protocole
SNMP.

L'architecture logicielle est découpée en composants dans le but de faciliter le


monitoring distribué :

• Serveur : Le serveur est le cœur de l'application Zabbix. Il centralise les


données et permet de les attendre (trapping) ou d'aller les chercher (polling).
Il centralise aussi toutes les informations de configuration et permet d'alerter
les administrateurs en cas de problème ;
• Le proxy : Élément optionnel de l'architecture, il permet de bufferiser les
données reçus des différents sites dans le but d'alléger les traitements pour le
serveur ;
• L'agent : Une fois installé sur un système, l'agent va collecter les données
locales et les envoyer au serveur ;

35
36

• L'interface Web : Celle-ci est une partie du serveur bien qu'il ne soit pas
obligatoire qu'elle se trouve sur la même machine que le serveur. L'interface
permet de configurer entièrement Zabbix, d'accéder aux statistiques ainsi
qu'à d'autres informations.

Tous ces composants sont écrits en C afin de garder de hautes performances,


hormis bien évidemment l'interface Web développée en PHP.
L'interface est divisée en cinq parties :

• Monitoring : La partie affichage des statistiques, graphiques, alertes,


cartographie, etc… ;
• Report : Statistiques sur le serveur Zabbix et rapport de disponibilité des
services sur les machines supervisées ;
• Administration : Permet de gérer les moyens d'alertes (SMS, Jabber, Email,
...) et les utilisateurs. La figure 9 illustre le tableau de bord de Zabbix

Figure 6: Zabbix Dashboard

36
37

3.3.1.3.2. Avantages
✓ Une solution très complète : cartographie de réseaux, gestion poussée
d'alarmes via SMS, Jabber ou Email, gestion des utilisateurs, gestion de
pannes, statistiques et reporting ;
✓ Une entreprise qui pousse le développement, et une communauté
croissante ;
✓ Une interface vaste mais claire ;
✓ Une gestion des templates poussée, avec import/export xml, modifications
via l'interface
✓ Des performances au rendez-vous : l'application a été testée avec succès avec
10000 équipements supervisés ;
✓ Compatible avec MySQL, PostgreSQL, Oracle, SQLite.

3.3.1.3.3. Inconvénients
o Interface est un peu vaste, la mise en place des templates n'est pas évidente
au début : petit temps de formation nécessaire ;
o L'agent Zabbix communique par défaut en clair les informations, nécessité
de sécuriser ces données (via VPN par exemple) ;
o Commence à être connu, mais pas encore auprès des entreprises : Peu
d'interfaçage avec d'autres solutions commerciales.

3.3.1.4. Nagios
3.3.1.4.1. Présentation

Successeur de NetSaint, Nagios est certainement le logiciel libre le plus connu dans
le milieu de la supervision réseau. Appréciée des entreprises ainsi que des
particuliers, cette application possède une très grande communauté qui participent

37
38

activement au développement. L'architecture logicielle est modulaire comme chez


ses concurrents :

• Le moteur qui gère l'ordonnancement de la supervision, écrit en C ;


• L'interface Web réalisé à l'aide des CGI ;
• Des greffons, ou plugins qui étendent les possibilités de Nagios.

Il existe notamment des plugins Nagios nommée NRPE et NCSA qui fonctionnent
un peu sur le même principe que ceux de Zabbix. NRPE est un agent esclave qui
attend les ordres du moteur Nagios (polling) et NCSA envoi de lui-même les
données (trapping). L'interface est divisée en trois :

• Partie monitoring, qui permet plusieurs vues : vue globale, vue précise, vue
de la carte du réseau, vue des problèmes, ... même une vue "3D" ;
• Partie reporting regroupant les tendances des statistiques, les alertes et
évènements ainsi qu'un rapport de disponibilités des services ;
• Partie configuration classique permettant de tout configurer.

Ci-dessous le tableau de bord de Nagios par la figure 10.

38
39

Figure 7: Nagios Dashboard


3.3.1.4.2. Avantages
✓ Reconnu auprès des entreprises, grande communauté ;
✓ Pléthore de plugins qui permettent d'étendre les possibilités (agents comme
Zabbix, reporting amélioré, etc.…) ;
✓ Une solution complète permettant le reporting, la gestion de panne et
d'alarmes, gestion utilisateurs, ainsi que la cartographie du réseau ;
✓ Beaucoup de documentations sur le web ;
✓ Performances du moteur.

3.3.1.4.3. Inconvénients

• Interface non ergonomique et peu intuitive ;


• Configuration fastidieuse via beaucoup de fichiers ;

39
40

• Pour avoir toutes les fonctionnalités il faut installer des plugins, de base c'est
assez limité.

3.3.1.5. Centreon
3.3.1.5.1. Présentation

Centreon, basé sur Nagios, se présente comme une évolution de celui-ci pour tout
d'abord son interface mais aussi ses fonctionnalités. Créé en 2003 par des français
souhaitant améliorer Nagios et son interface très austère, Centreon (anciennement
Oréon) a été repris par une nouvelle entreprise nommée Merethis.

Centreon reprend donc les avantages du moteur de Nagios et permet ainsi d'être
entièrement compatible avec des solutions existantes. Son interface reprend un
découpage classique :

• Home : Page d'accueil avec Le "Tactical Overview" de Nagios permettant un


coup d'œil rapide aux problèmes survenus et accès aux statistiques des
performances du moteur et de ses composants ;
• Monitoring : Possède plusieurs vues, mais reprend la grande idée de l'arbre
des groupes d'équipements. Reprend également la vue Nagios ;
• Views : Permet d'accéder à tous les graphiques avec un menu arborescent.
Accès à une cartographie du réseau en applet Java ;
• Reporting : Un Dashboard ressemblant à celui de Zabbix en ajoutant une
frise chronologique de la disponibilité de l'équipement ;
• Configuration : Pour tout configurer de A à Z ;
• Administration : Configuration des accès utilisateurs.

Toujours visibles en haut à gauche, un tableau récapitulatif du nombre de machines


actives et des éventuelles machines ne répondant plus pour toujours garder un œil
sur l'ensemble du réseau.

40
41

La figure 11 montre le tableau de bord de centreon

Figure 8: Centreon Dashboard

3.3.1.5.2. Avantages

✓ La robustesse et la renommée de Nagios ;


✓ Une interface beaucoup plus sympathique, permettant de tout configurer, de
garder un œil sur tout le réseau en permanence ;
✓ Les utilisateurs de Nagios ne seront pas perdus pour autant, l'interface
reprenant avantageusement certaines vues Nagios ;
✓ Une solution complète permettant le reporting, la gestion de panne et
d'alarmes, gestion utilisateurs, ainsi que la cartographie du réseau ;
✓ Une entreprise qui pousse le développement ;
✓ Peut-être décorrélé du serveur Nagios et tourner tout seul sur un autre
serveur.

3.3.1.5.3. Inconvénients

41
42

• L'interface peut paraître complexe car il existe beaucoup d'options, de


vues…cela nécessite une petite formation ;
• Un développement qui n'est pas encore en phase avec celui de Nagios :
Parfois des problèmes de compatibilité ;
• Un peu plus lourd que du Nagios pur.

3.3.1.6. Eyes Of Network


3.3.1.6.1. Présentation

Eyes Of Network (EON) est la solution Open Source réunissant de manière


pragmatique les processus ITIL (Information Technology Infrastructure Library)
avec l’interface technologique permettant leur application. La solution EON est
une solution complète de supervision. C’est est une distribution Linux basée sur
CentOS. Elle est actuellement distribuée sous licence GPL, sa version actuelle est la
5.1.

Le tableau de bord de Eyes Of Network par la figure 12

Figure 9: EON Dashboard

42
43

3.3.1.6.2. Avantages

Les fonctionnalités d’EON sont nombreuses. Elle Permet de regrouper tous les
outils ITIL et de supervision dans une même distribution, d’ajouter un gestionnaire
de performance et une interface de configuration web qui facilite sa configuration.
En plus EON permet de faciliter le déploiement des outils de supervision et
dispose d’un SSO (Single Sign-On) permettant de se loguer une seule fois et
d’accéder à tous les outils d’administration. Enfin EON dispose de la fonctionnalité
Auto-Discovery qui permet d’ajouter des hôtes automatiquement et une possibilité
d’administrer ses périphériques via SSH/Telnet depuis son interface web.

3.3.1.6.3. Inconvénients

L’inconvénient d’EON est lié à son outil Wheathermap nécessitant une


cartographie sur papier au préalable avant d’établir la cartographie de notre réseau
et d’une interface qui déborde d’onglet.

[13]

3.3.1.7. Shinken
3.3.1.7.1. Présentation

Shinken est une solution libre open source présenter comme le petit frère de
Nagios. Elle est sous licence AGPL et est beaucoup oriente « distribuer » que son
prédécesseur. En effet l’auteur de shinken a fait le constat que Nagios était très
performant uniquement sur de petite infrastructure d’où l’idée de créer un outil de
supervision assez complet qui palliera aux problèmes de NAGIOS.

43
44

3.3.1.7.2. Avantages

➢ Confrontation du trinôme corrélation, règles applicatives, importance métier,


facilitant la tâche des administrateurs et rendant un service apprécié des
utilisateurs ;

➢ Application installable et opérationnelle sous Microsoft Windows :


permettant de couvrir tout le spectre fonctionnel, du plus petit parc au plus gros ;

➢ Apte à fonctionner sur des équipements GSM Android.

3.3.1.7.3. Inconvénients

• Méconnue du monde de l’entreprise

3.3.2. Tableau comparatif des solutions et choix de la solution

Les solutions présentées ci-dessus, dressons le tableau 6 qui est un tableau


comparatif

Tableau 6 : Tableau comparatif des différentes solutions


Besoins NetM.G Cacti Zabbix Nagios Centreon EON Shinken
Authentifications
et rôles ✓ ✓   ✓ ✓ ✓
Graphes
complexes ✓ ✓ ✓   ✓ ✓
Vue en temps réel
✓  ✓ ✓ ✓ ✓ ✓
Simplicité du
Paramétrage
✓ ✓ ✓  ✓ ✓ ✓
Multiplateforme
✓  ✓  ✓ ✓ ✓
Modularité
✓ ✓ ✓ ✓ ✓ ✓ ✓
Adaptabilité
✓ ✓ ✓ ✓  ✓ ✓
Proactive et
réaction en cas de       ✓
44
45

panne
Supervision
distribué       ✓
Solution libre
✓ ✓ ✓ ✓ ✓ ✓ ✓
Parmi ces solutions libres, SHINKEN est la solution la plus adaptée permettant de
satisfaire pratiquement tous nos besoins, par les différentes fonctionnalités qu’elle
offre.

3.4. Conclusion

Ce chapitre vient de receler des points touchants des exemples de solutions en


évoquant leurs caractéristiques d’abord, en sus elle a mis en évidence un tableau
comparatif en fonction de nos besoins et cela nous a permis de choisir l’outil de
supervision SHINKEN. Le prochain chapitre donne une étude approfondie afin
de facilité sa mise en œuvre.

45
46

CHAPITRE 4
PRESENTATION DETAILLEE DE LA SOLUTION RETENUE
1.1. Introduction

Dans ce chapitre, nous mettrons en évidence une présentation assez exhaustif de


l’outil de supervision SHINKEN tout en donnant beaucoup plus ample
informations sur sa mise en œuvre sur dans l’environnement de teste et sur
l’environnement de distribution de SOFTNET. A la fin du chapitre nous ferons un
récapitulatif des différents coûts de déploiement.

1.2. Présentation de Shinken


1.2.1. Définitions

Shinken est une application permettant d’effectuer de la supervision complète. Elle


surveille les hôtes et services spécifiés. C'est un logiciel libre sous licence GNU
AGPL Elle a pour but d'apporter une supervision distribuée et hautement
disponible facile à mettre en place. Démarrée comme une preuve de concept pour
Nagios sur les architectures distribuées, le programme a rapidement démontré des
performances et une flexibilité bien plus importante que son aîné Nagios. Son
auteur est Jeans GABES et sa première version est apparue le 1er décembre 2009 en
tant que simple outil de monitoring. Sa version actuelle est le 2.4.3.

Il assure les fonctionnalités de supervisions principales suivantes :

• La surveillance des équipements du système d’information ;


• Les notifications informatives en cas d’incident détecter sur un
équipement.

Les protocoles utilisés sont les suivants :

• Le protocoles TCP/IP ;
• Le protocole ICMP ;

46
47

• Le protocole SNMP.
1.2.2. Caractéristiques et architecture de Shinken

L’outil SHINKEN fonctionne sur les systèmes d’exploitation UNIX sur la plupart
des distribution linux et sur WINDOWS. Les interfaces graphiques comme
WEBUI, LIVESTATUS ou THURK permette d’accéder de façon visuelle à
SHINKEN et cela à travers une interfaces web. L’objectif de ce type d’accès à
SHINKEN permet de réunir les différents acteurs du par cet d’obtenir tout type
d’information de chacun d’eux et de stocker ces informations sur une base de
données.

Shinken possède une architecture novatrice :

• Architecture distribuée, hautement disponible avec répartition de charge


automatique.
• Supporte la notion de multi-sites/clients grâce aux realms (royaumes).
• Peut être exécuté sous Windows, Linux et Android.

Shinken permet d'effectuer de l'acquisition active de données de façon parallèle et


balancé sur plusieurs processus et plusieurs hôtes. Les méthodes actives suivantes
sont supportées :

• Superviser des services


réseaux : SMTP, POP3, HTTP, NNTP, ICMP, SNMP, LDAP, etc.
• Superviser les ressources des serveurs (charge du processeur, occupation
des disque durs, utilisation de la mémoire paginée) et ceci sur les systèmes
d'exploitation les plus répandus.
• Interface avec le protocole SNMP par l'intermédiaire des sondes.
• La supervision à distance peut utiliser SSH ou un tunnel SSL (notamment via
un agent NRPE).

Shinken possède aussi des caractéristiques de traitement puissantes :

47
48

• Possibilité de définir une hiérarchie dans le réseau pour pouvoir faire la


différence entre un serveur en panne et un serveur injoignable.
• Possibilité de définir des dépendances entre des services.
• Capacité de gestion des oscillations (nombreux passages d'un état normal à un
état d'erreur dans un temps court).
• Recherche native des problèmes sources et suppression très efficace de faux
positifs.
• Associer un impact d'affaire à un équipement ou service.
• Association automatique de l'impact d'affaire à des éléments parents ayant fait
défaut.
• Règles métiers pour les états, afin d'associer des règles logiques pour un
ensemble d'états.

Shinken permet de rendre disponibles les données de performance et d'état à des


tiers :

• Shinken possède une interface graphique native afin d'interagir avec le système.
• Exportation de données de performance vers la BD de métrologie Graphite ou
PNP4Nagios (RRDtool).
• Intégration native à même l'interface graphique Shinken WebUI, Thruk ou
Multisite de la visualisation des données de performance de PNP ou Graphite.
• API interactif Livestatus afin de rendre disponibles les états.
• Acquittement des alertes par les administrateurs.
• La remontée des alertes est entièrement paramétrable grâce à l'utilisation de
plugins.

Shinken permet de créer ses propres plugins, dans le langage désiré. Il suffit de
respecter la norme Nagios des codes retour :

• 0 OK (tout va bien) ;
• 1 WARNING (le seuil d'alerte est dépassé) ;

48
49

• 2 CRITICAL (le service a un problème) ;


• 3 UNKNOWN (impossible de connaître l'état du service).

La création de nouveaux plugins permet de répondre de façon personnalisée à tout


besoin.

Shinken possède aussi un mécanisme simple de « Pack » de supervision qui


simplifie beaucoup sa mise en place. Ils sont disponibles sur le site communautaire
de Shinken, sont gérés par le gestionnaire graphique SkonfUI en même temps que
la découverte, sont inclus de base dans Shinken et peuvent être dynamiquement
mis à jour par le gestionnaire Graphite de Shinken SkonfUI. Nous pouvions donc
représenter la supervision de SHINKEN avec la figure 13 suivante :

Supervision de SHINKEN

Interface graphique (WEBUI,


LIVESTATUS, THURK)

Systèmes de surveillances (systèmes, réseaux,


applicatif, métier) et plugins

Système de gestion de Base de Donnée (MySQL, MongoDB)

Système d’exploitation (UNIX, Windows)

Figure 10 : Représentation de la supervision de SHINKEN


[14]

La différence entre Shinken et Nagios réside plus dans son architecture que le
langage de programmation utilisé. En effet son architecture suit le principe
d’UNIX : à une tâche un outil. Et donc Shinken est hétérogène différemment de
Nagios qui est monolithique. Shinken utiliser six (06) processus différent travaillant
ensemble et permettant d’obtenir une flexibilité bien supérieure au Nagios original.

C'est cette architecture qui permet d'obtenir la mise en place facile d'une
supervision distribuée : un processus s'occupe de lire la configuration de l'utilisateur
et la découpe intelligemment (en respectant les relations entre les éléments) afin de

49
50

distribuer les morceaux vers des processus chargés d'absorber la charge de


supervision. De cette manière, en cas de nouvelle charge, l'utilisateur peut rajouter
des processus sans avoir à modifier sa configuration en profondeur.

C'est de ce choix architectural que vient le nom de logiciel. Shinken, un nom de


katana très tranchant à savoir de découper la configuration pour la renvoyer sur
des daemons.

Les six (06) modules se présente donc ainsi :

• L’arbiter : le chef d’orchestre de tous les processus de supervision, c’est lui


qui distribue le travail à réaliser et gère les configurations. Il est responsable de la
validation et du chargement de la configuration, la découpe en différentes parties
(N ordonnanceurs = N parties), et l’envoie aux autres éléments. Il gère également la
haute disponibilité : si un élément devient injoignable, il redirige la configuration
sur un autre.

• Le scheduler (planificateur) : en charges des fils de traitements qui doit


interagir avec les autres éléments. Ce n’est pas lui qui lance les checks ou les
notifications, il ne fait que rediriger les informations. Il garde juste dans une file
d’attente les checks en attente (pending) et notification pour les autres éléments
(collecteurs ou "Réactionneur).

• Le collecteur (Poller) : Son rôle est de lancer les plugins en fonction des
requêtes des ordonnanceurs. Ces plugins vont aller interroger le système surveillé et
retourner un résultat indiquant l'état. Lorsqu’un plugin renvoie un résultat, il le
transmet à l’ordonnanceur.

• Le reactionner : il est aussi appelé l’exécutant vue qu’il interroge le


planificateur afin de connaitre les tâches à exécuter en fonction des résultats de
contrôles. Il est chargé de l'envoi des notifications et de lancer les
« event_handlers » (action automatique programmable).

50
51

• Le broker : est en charge de stocker tout résultats dans une base de données
ou fichier de stockage. Son rôle est de prendre des données sur les scheduler
(comme les statuts par exemple) et de les rendre disponibles à l'externe de Shinken.
Il fonctionne avec des modules

• Le receiver :il est un service optionnel, Son rôle est de recevoir les données
d'acquisition passive et de les acheminer vers le bon scheduler responsable de faire
la corrélation et le traitement des statuts

On peut avoir une illustration de l’architecture final suivant avec la figure 14

Figure 11: Architecture Interne de Shinken

[15]

1.2.3. Prérequis

Pour répondre aux différents objectifs lors du déploiement de la solution, il faut au


préalable avoir une certaine connaissance sur la supervision et aussi les outils de

51
52

supervision tel que NAGIOS, CACTI ou mieux SHINKEN. Il faut aussi avoir des
notions sur l’administration réseaux sur UNIX.

Pour commencer l’installations il est primordial d’avoir ces utilitaires ou services


avant de lancer l’installation :

• Python (par préférence une version ≥ 2.7) et certaines de ses branches


comme :
o Python-pycurl primordial pour les daemons de SHINKEN

o Python-cherrypy3 beaucoup recommander

o Python-pip permet d’installer SHINKEN avec la commande pip install

o Python-setuptools

o Python-paramik

• Les Monitorings Plugins qui sont des programmes externes au serveur, des
exécutables qui peuvent se lancer en ligne de commande afin de tester une station
ou service. Sans eux, SHINKEN est totalement incapable de superviser et se
résume en un simple noyau.

1.2.4. Répertoire et sous-répertoires de configuration

SHINKEN s’appuie sur un certain nombre de répertoire qui contienne des fichiers
textes de configuration pour construire son infrastructure de supervision. Parmi ces
répertoires nous avons :

• Le répertoire shinken est le répertoire principal et contient le fichier


shinken.cfg qui est le fichier dans lequel on établit toutes les règles de supervision
d’un système informatique, il est considéré comme le tronc sur lequel gisent les
branches tel que :

52
53

◦ Le sous répertoire brokers qui contient le fichier brokers-master.cfg, ce fichier


permet de donner certaines spécificités au daemons brokers.

◦ Le sous répertoire modules qui contient les différents modules permettant


la bonne supervision des équipements. Comme les modules sont chargés par les
démons, les fichiers de modules sont référencés dans des fichiers de démons.

◦ Le sous répertoire commands dans lequel nous pouvions créer nos fichiers
xxx.cfg pour pouvoir contrôler les éléments surveiller par shinken à travers un
module et de ses arguments ;

◦ Le sous répertoire contactgroups permets de créer un groupe contacte que


l’on peut répertorier dans un fichier contact_groupe_name.cfg, ce fichier permettra
d’envoyer des notifications au contacts répertorier dans le fichier de manière
simultanément.

◦ Le sous répertoire contacts permet de crée des contacts grâce au


nom_de_contact.cfg ;

◦ Le sous répertoire hostgroup a les mêmes fonctionnalités que le sous


répertoire contactgroup mais ici il gère les équipements ;

◦ Le sous répertoire hosts permet d’enregistrer un équipement et de le


paramétré nom_dequipemtent.cfg ;

◦ Le sous répertoire notificationway est ce répertoire permettant d’envoyer


des messages de notifications électroniques ;

◦ Le sous répertoire services enregistre un service d’un équipement, les


différents services peuvent être le SSH SNMP NTP CPU PING.

53
54

1.2.5. Architecture de déploiement

Dans le cadre de notre étude, le déploiement de la solution se fera sur le serveur de


supervision installer sur un système d’exploitation linux la distribution Ubuntu
version 18.04.01LTS. La figure 15 suivante présente l’architecture du système
d’information dans l’environnement de test du système d’information de
SOFTNET.

Figure 12 : Architecture de déploiement

L’architecture est constituée de :

• 6 Serveurs (Shinken, SMTP, Hyper-V, BD, Linux, Windows) ;


• 2 imprimantes ;
• 1 commutateurs ;
• 2 Switch ;
• 5 postes utilisateurs.

54
55

1.2.6. Estimation du coût de déploiement

La solution que nous avons proposée, peut être déployée en une semaines
minimum en fonction des ressources disponible. Ces ressources se compose d’un
apport en ressource humaine, matérielle et financière consigne dans le tableau
suivant :

Couts de réalisation du projet

Le tableau 7 contient les données des coûts de réalisation

Tableau 7 : Coût de réalisation du projet


Désignation Cout en Franc CFA
1 Processeur Intel Xeon X5670, 12 Mo cache,
85 137 046
2,93 GHz, Intel QPI à 6,4GT/s
Formation de l’administrateur pour le
300 000
transfert de compétences
Installation et Configuration du serveur de
supervision par 2 ingénieures en réseau et 1 500 000
système
Total 86 937 046
Ces coûts de réalisations sont des estimations au cours des prestation d'installation
chez les particuliers car ici en entreprise toutes les ressources sont déjà disponibles.
La formation de l’administrateur réseau se fera sur trois (03) jours à raison de
100 000 franc CFA/jr.

1.3. Conclusion

En sommes, dans ce chapitre nous avions présenté l’outil de supervision Shinken


de fond en comble, tout en passant par un aperçue approfondie sur ses
caractéristiques et de son architectures internes, ensuite nous avions montré
l’architecture de l’environnement de teste sur lequel la solution a été déployé et

55
56

enfin nous avions estimé les coûts de déploiement. Le chapitre prochain présentera
les détails sur la mise en place de l’implémentation de l’outil shinken.

56
57

CHAPITRE 5
IMPLEMENTATION TECHNIQUE
5.1. Introduction
Le chapitre présent est dédié aux différentes étapes de déploiement de la solution.
Elle partira d’une présentation des différents prérequis à installer, ensuite les
configurations nécessaires de supervisions d’un hôte sur Unix et sur un Windows
puis nous allons présenter des tests de fonctionnement sur l’outil et enfin faire un
bilan général sur le déploiement de la solution.

5.2. Différentes installations


5.2.1. Prérequis

Avant tout début d’installation, il faudrait rappeler qu’il faut avoir une certaine base
en administration réseau et aussi des notions en supervision, ce qui est primordial
dans la suite de la lecture de ce rapport.

La plupart des utilitaires pour la réalisation de la phase de réalisation et de mise en


œuvre ont été énumérer dans la partie 2.4.2 Moyens technique nécessaires mais
à cela s’ajoute aussi :

• PuTTY : un émulateur de terminal UNIX qui permet de se connecter à


distance à une machine ou un serveur, en utilisant les protocoles SSH, Telnet
ou Rlogin.
• Python : est un langage portable, dynamique, extensible, gratuit, qui permet
une approche modulaire et orientée objet de la programmation. Elle sera
primordiale pour l’installation de l’outil de supervision shinken.

57
58

5.2.2. Installation de la solution

Les différentes installations suivantes se font sur une machine virtuelle installer sur VMWare.

Dès le démarrage de la machine virtuelle il faut se mettre en super utilisateur et


mettre à jours les paquets de votre distribution avec les commandes suivantes :

$sudo su
#apt-get update

Ensuite Il faut télécharger python (version ≥2.7) avec la commande

#apt-get install python

Python installer il faut installer toutes ses dépendances afin que l’installation de
shinken n’ai pas de problème.

#apt-get install python-setuptools python-pip python-pycurl

• python-setuptools : permettant de régler ou installer certains paramètres de


python ;
• python-pip :permet de télécharger les paquets affiler a python comme
shinken avec les commande pip ;
• python-pycurl : idem à python-pip, mais le téléchargement se fait ici avec le
commande curl.

On crée un nouvel utilisateur et on l’alloue un Shell de connexion avec la


commande :

#useradd -m -s /bin/bash shinken

A la fin de cette commande nous pourrions opérer des actions sur l’interface
shinken.

Une commande permettant de gérer des paquets sur la communauté GitHub est
l’utilitaire git qu’il faut prendre le soin de télécharger.

58
59

Après juste la création de l’utilisateur shinken on peut passer au téléchargement de


la source de shinken sur GitHub avec la commande :

#git clone https://github.com/naparuba/shinken.git

Après s’être placé dans le répertoire principal shinken avec la commande cd shinken/
on va chercher à mettre à jour les fichiers de l'arborescence de travail pour qu'ils
correspondent à la version actuelle de shinken :

#cd shinken/
#git checkout 2.4.3

On installe et on configure dès à présent shinken avec la commande :

#python setup.py install

Comme recommandation après son installation, nous allons installer un autre


utilitaire de python pour avoir de meilleure performance de shinken :

#apt-get install python-cherrypy3

• CherryPy est un cadriciel de développement web pythonien et orienté objet.


Il fournit l’assise sur laquelle des applications complexes basées sur le web peuvent
être écrites, sans ou avec peu de connaissances des protocoles sous-jacents. [16]

Après que l’installation ait réussi on permet au serveur de shinken de pouvoir


démarrer à chaque démarrage de son système d’exploitation, il faut démarrer les
daemons et vérifier si le serveur est actif

#update-rc.d shinken defaults


#systemctl start shinken

La capture suivante représenté par la figure 16 montre l’état actif du serveur


shinken prouvant qu’elle a été bien installée

59
60

Figure 13 : Résultat commande de vérification de l'état du serveur shinken

L’installation terminer, on passera à l’installation d’une interface graphique ici qui


est webui2. Tout d’abord on se log en tant que shinken et on initialise la
configuration de shinken pour pouvoir installer le module de l’interface graphique
webui2 grâce aux commandes suivantes :

#su – shinken
$shinken --init
$shinken install webui2

L’avant dernière étape de l’installation de l’outil shinken est l’installation sa base de


données. Cette base de données est MongoDB, Webui2 l’utilise pour la gestion de
ses données. Nous devons installer MongoDB et un autre paquet python avec pip

60
61

#apt-get install mongodb


#pip install pymongo>=3.0.3 requests arrow bottle==0.12.8

La figure 17 montre l’état du service mongodb après son installation

Figure 14 : Résultat commande sur l'état du service mongodb

Pour rendre assez complet l’installation de shinken il faut y ajouter un élément


important qui est les modules de monitoring de Nagios. A cela on ajoute certain
modules Perl qui ont pour but d’améliorer les performances de la supervision de
ces modules. Perl est un langage interprété optimisé pour le traitement du texte et
le développement de scripts.

La commande suivante permet d’installer les plugins de Nagios et cpanminus ce qui


est requis pour la configuration et l’installation des modules de Perl

#apt-get install nagios-plugins* cpanminus

Il en suivra l’installation de ces modules de Perl avec la commande cpanm.

Installation des module Perl avec la commande cpanm

61
62

#cpanm Net::SNMP
#cpanm Time::HiRes
#cpanm DBI

cpanm est un client qui tente de rendre la puissance de CPAN accessible à tous les
utilisateurs, en particulier ceux qui ne sont pas des développeurs Perl, mais qui ont
une expérience du Shell CPAN. En effet, CPAN, le réseau d'archives complet Perl,
est la principale source de publication et de récupération des derniers modules et
bibliothèques pour le langage de programmation Perl.
Les installations terminées il faut maintenant crée un lien entre ces modules
télécharger et shinken.

Pour cela il faut exécuter ces commandes suivantes séquentiellement

#chmod u+s /usr/lib/nagios/plugins/check_icmp


#ln -s /usr/lib/nagios/plugins/utils.pm /var/lib/shinken/libexec/
#mkdir -p /var/log/rhosts/
#touch /var/log/rhosts/remote-hosts.log

Enfin il faut installer des packages ssh et linux-snmp pour la supervision des service
SSH et SNMP sui seront télécharger depuis le site de shinken.io.

#su – shinken
$shinken install ssh
$shinken install linux-smmp

Cette méthode d’installation énumérer ci-dessus n’est pas la seule méthode


d’installation de shinken. En effet il existe d’autres méthodes mais celle-ci est la
plus simple. Vous pouviez vous référer au site web shinken.io pour une installation
complète de l’outil.

[17]

5.3. Configurations nécessaires

Dans cette partie nous montrerons comment configurer à travers les fichiers de
configs. Elle commencera par une configuration globale, ensuite nous montrerons
les configs pour des types de supervision que l’on a pu étudier.

62
63

5.3.1. Prérequis

Les partie supervisions d’équipements ont de titres en commun : ajout d’hôte,


ajout de groupe et ajout de service. Et donc il faut savoir que pour la partie
Ajout d’hôte il faut se rendre dans le répertoire /etc/shinken/hosts/, pour Ajout de
groupe il faut se rendre dans le répertoire /etc/shinken/hostsgroup et enfin pour Ajout
de services il faut se rendre au niveau du répertoire /etc/shinken/services.

Le redémarrage du service de shinken se fait de plusieurs manières parmi lesquels :

• #service shinken restart


• #/etc/init.d/shinken restart
• #systemctl restart shinken

Tous les équipements auront une adresse IP du réseau 192.168.6.0/24 et sont


énumérer dans le tableau 8 suivant

Tableau 8 : Adressage des équipements


Nom équipement Adresse IP
Serveur Shinken 192.168.6.3/24
Serveur Debian 192.168.6.2/24
Windows 192.168.6.4/24
Imprimante 192.168.6.5/24
Switch Cisco 192.168.6.6/24
Routeur 192.168.6.1/24

5.3.2. Configurations de supervision


5.3.2.1. Configurations de Webui2

La première config à réaliser est celle de la gestion d’une interface graphique juste
après son installation. Nous avions installé Webui2 et donc c’est elle que l’on
choisira comme interface par défaut.

63
64

Le fichier de configuration à éditer pour cela est le fichier broker-master.cfg que l’on
retrouve en suivant ce chemin absolu /etc/shinken/brokers/.

Pour l’éditer nous allons utiliser nano qui est un petit éditeur gratuit et convivial
qui vise à remplacer Pico, un autre éditeur non libre.
Ci-dessous les pour atteindre le fichier :

#cd /etc/shinken/brokers/
#nano -c broker-master.cfg

L’option -c permet d’ouvrir le fichier et d’afficher les numéros de lignes


Vous pouviez défiler le fichier jusqu’à la ligne 40 et y ajouter cette ligne :
Modules webui2
La figure 18 montre le contenu du fichier broker-master.cfg

Figure 15 : Contenue du fichier brokers-master.cfg

En orange la ligne là ou doit être insérer le nom du module à être utilisé

La flèche en bleu indique le ruban contenant le numéro de ligne.

Vous enregistrer le fichier avec le raccourcie clavier ctrl+o et vous quittez avec le
raccourcie ctrl+x.

Il faut aller maintenant dans le répertoire contacts auquel on accède par le chemin
absolu /etc/shinken/contacts/ pour éditer le fichier admin.cfg et cela de la même
manière que l’on a faite précédemment.

64
65

Là-bas il faut juste changer les valeurs par défaut et y mettre les valeurs de notre
choix. Les valeurs à changer pour le moment sont souligner en orange. La figure
19 montre le contenu du fichier

Figure 16 : Contenu du fichier admin.cfg


Enregistrer le fichier, puis redémarrons le service Shinken. Si tout marche bien
vous pouvez maintenant accéder à l’interface web de Shinken avec l’adresse :

http://adresse_ip_serveur_shinken:7767

5.3.2.2. Supervision d’un serveur Debian

Maintenant que les plugins Nagios sont installés, nous allons pouvoir superviser
notre premier appareil, c’est-à-dire un serveur Debian. Pour cela nous allons
installer le plugins NRPE (Nagios Remote PluginExecutor) qui permet de
superviser les serveurs Linux/Unix ou Windows à distance. Sur le serveur shinken
on va faire ceci :

#apt-get install nagios-nrpe-plugin

Puis sur celui du serveur Debian

#apt-get install nagios-plugins


#apt-get install nagios-nrpe-server

65
66

Nous pouvons maintenant modifier le fichier de configure de NRPE pour ajouter


l’IP du serveur Shinken et autoriser les commandes de supervision.

#nano /etc/nagios/nrpe.cfg

Le fichier ouvert il faut :

• Modifier la ligne du « allowed_hosts=127.0.0.1 » en


« allowed_hosts=address_ip_server_shinken »

• Décommenter les lignes contenant « command[check_disk]


=/usr/lib/nagios/plugins/check_disk » ce qui permettra de récupérer les
informations d’espace disque.

Après cela il faut rendre automatique le démarrage du service NRPE et juste apres
redémarrer le service avec les commandes :

#chkconfig -add nagios-nrpe-server


#/etc/init.d/nagios-nrpe-server restart

Parallèlement il ne faut pas oublier le SNMP sinon vous aurez des erreurs après.

#apt-get install snmp snmpd

Les services snmp installer, nous devons éditer le fichier snmp.conf

#nano /etc/snmp/snmpd.conf

Commenter la ligne 15 et décommenté la ligne 17 comme le montre la figure 20


suivante

66
67

Figure 17 : Contenu fichier 1 snmpd.conf


Commente la ligne 51 et 53, puis ajouter une nouvelle ligne juste après comme la
figure 21 suivante

Figure 18 : Contenu fichier 2 snmpd.conf


[17]

5.3.2.2.1. Ajout d’hôte

Nous allons ajouter l’hôte du serveur Debian sur le serveur shinken et pour cela il
faut créer un fichier nommer srv-debian.cfg dans le répertoire des hôtes

#nano /etc/shinken/hosts/srv-debian.cfg

La figure 22 suivante montre la config qui soit être faite dans le fichier srv-
debian.cfg

67
68

Figure 19 : Contenu fichier server_debian.cfg


5.3.2.2.2. Ajout de groupe de Serveur Linux

Nous allons créer un groupe pour ces serveurs linux qui nous permettra d’attribuer
directement des services identiques pour éviter les redondances. Un fichier linux.cfg
est déjà créer dans le répertoire /etc/shinken/hostgroups. Ouvrer le et faite la config de
la figure 23 suivante :

Figure 20 : Contenu du fichier de groupe linux.cfg

5.3.2.2.3. Ajout de services

Nous allons maintenant ajouter des services. Créez un fichier linux_service.cfg et


appliquer les configs de la figure 24 suivante :

68
69

Figure 21 : Contenu du fichier linux_service.cfg


Cela terminer il faut redémarrer le serveur shinken.

5.3.2.3. Supervision d’un serveur Windows

Pour faire la supervision d’un serveur Windows il faut installer le clients


NSClient++.

A l’avant dernière fenêtre du début de l’installation il y a une configuration à


effectuer et c’est celle de la figure 25 suivante :

69
70

Figure 22 : Installation de NSClient++


Il faut mettre l’adresse IP du serveur shinken au niveau de Allowed Hosts avec le
port NRPE qui est 5666 et mettre le mot de passe que vous vouliez au niveau de
Password. Cocher la partie Enable nsclient server (check_nt) et Enable Web server.

5.3.2.3.1. Ajout de l’hôte

Il suffit de créer un autre fichier nommer srv-wind.cfg et y appliquer la config de la


figure 26 suivante :

70
71

Figure 23 : Contenu du fichier host srv-wind.cfg

5.3.2.3.2. Ajout du groupe Serveur Windows

Créer le fichier windows.cfg dans le dossier de groupe et appliquer la config de la


figure 27 suivante :

Figure 24 : Contenu fichier de groupe windows.cfg

5.3.2.3.3. Ajout des services

Au préalable il faut vérifier que la connexion se fait entre notre serveur Windows et
notre serveur shinken. Pour cela il faut taper la commande suivante :

#/usr/lib/nagios/plugins/check_nt -H 192.168.6.4 -v CLIENTVERS


ION -p 12489 -s passe

Si tout va bien cette commande doit vous retourner la version de nsclient installer

71
72

Nous allons maintenant créer une nouvelle commande « check_nt » dans Shinken
au niveau du dossier /etc/shinken/commands en mettant le mot de passe du serveur
Windows et le port utilisé. Ci-dessous la figure 28 montrant le contenue du fichier
check_nt.cfg

Figure 25 : Contenu fichier commande check_nt.cfg


Puis nous créons les services Windows à superviser à travers le fichier
windows_services.cfg à créer. Ci-dessous la figure 29 montrant le contenue du
fichier

Figure 26 : Contenu fichier service windows_services.cfg


Les configs terminer il faut redémarrer le serveur shinken

72
73

5.3.2.4. Supervision d’une imprimante


5.3.2.4.1. Ajout d’un hôte

La supervision d’une imprimante consistera à savoir si est bien allumée et accessible


sur le réseau. Pour cela nous allons créer un nouvel hôte appelé imprime-hp.cfg

La figure 30 montre la config à réaliser pour l’imprimante

Figure 27 : Contenu fichier host imprimante_hp.cfg

5.3.2.4.2. Ajout d’un groupe

Pour cela il faut juste créer un groupe imprimante HP dans le dossier des groupes,
la config est dans le fichier imprimante.cfg et son contenue se trouve dans la figure
31 suivante :

Figure 28: Contenu fichier groupe imprimante.cfg

73
74

5.3.2.4.3. Ajout de service

Il suffit juste de créer un fichier pour tester sa connectivité dans le réseau, ci-
dessous la figure 32 montrant le contenue du fichier de service.

Figure 29 : Contenue fichier de service imprimante_service.cfg


Puis redémarrez le service shinken.

5.3.2.5. Supervision d’un Switch Cisco

Le switch cisco à superviser est celui de la serie 3750, il faut donc installer les packs
« cisco » et « switch » sur le serveur shinken en se logan sous l’utilisateur shinken.

#su – shinken
$shinken install cisco
$sinken install switch

Pour configurer le plugin du switch il faut installer la commande


« check_nwc_health » téléchargeable de la manière suivante :

#cd /var/lib/shinken
#wget https://labs.consol.de/assets/downloads/nagios/check_nwc
_health-7.0.1.1.tar.gz
#tar -xvf check_nwc_health-7.0.1.1.tar.gz
#cd check_nwc_health-7.0.1.1
#./configure --prefix=/var/lib/shinken/ --with-nagios-user=shi
nken --with-nagios-group=shinken --withperl=/usr/bin/perl

74
75

#make
#make install

Nous devons configurer le SNMP sur le switch et pour cela il faut vous connecter
grâce à PuTTY sur le switch et tapez les commandes suivantes :

Switch>en
Switch# conf t
Switch(config)#snmp-server community public RO

Il faut ajouter le nouvel hôte en créant un nouveau fichier nommé switch.cfg et on y


applique la config suivante de la figure 33 :

Figure 30 : Contenu fichier hosts switch.cfg

5.3.2.6. Supervision d’un routeur


5.3.2.6.1. Ajout de l’hôte

On crée un fichier nommer router-one.cfg dans le répertoire des hosts et la figure


34 montre la config à y mettre

Figure 31 : Contenu fichier hosts router-one.cfg

75
76

5.3.2.6.2. Ajout du service

On crée un fichier nommer router_service.cfg dans le répertoire des services et la


figure 35 montre la config à mettre dans le fichier

Figure 32: Contenu fichier service router_service.cfg


Et enfin il faut redémarrer le service de shinken.

5.4. Présentation des tests de fonctionnements

Ce point sera beaucoup axé au niveau des commande que l’on a pu effectuer, elle
fera office uniquement que de figure.

La figure 36 suivante montre l’interface de Webui2

Figure 33 : Shinken WebUI Login page

76
77

La supervision de l’hôte et des services du serveur Debian à travers la figure 37

Figure 34 : Supervision Serveur Debian


Supervision de l’hôte et des services de Windows avec la figure 38

Figure 35 : Supervision de Windows


[18]

77
78

5.5. Bilan
5.5.1. Points des réalisations

Au niveau de ce point, nous pouvions affirmer que la solution shinken a été bien
étudier. L’installation a été bien faite et la solution répond aux attentes de notre
structure d’accueil. Au moment de la rédaction du rapport, la solution était toujours
en phase de déploiements virtuel. Malheureusement un retard a été accusé dans la
réalisation du projet. Le prochain point évoquera la question de cet écart.

5.5.2. Explication des écarts

La comparaison entre le planning prévisionnel et le planning réel a évoqué un écart


très remarquable lors de l’étude et de l’implémentation de l’outils de supervision.
Cette remarque se fait au niveau des dates de fin de chaque figure, en effet le projet
devant finir le 19/09/2018 se voit finir jusqu’au 08/03/2019 ce qui a pour
conséquence le bouleversement total sur le planning prévisionnel. Ce décalage
temporel se justifie essentiellement par la difficulté d’implémentation de l’outil, de
son installation, de son maniement et de nombreuses dépendances insatisfaites et
aussi à nos capacités matérielles qui ne supportais pas le déploiement de l’outil en
virtuel. Il y a aussi l’ajout de plusieurs tâches de l’entreprise auxquelles nous étions
partie prenante. Le planning réel est représenté dans la figure à l’aide d’un
diagramme de GANTT :

Figure 36 : Planning réel

78
79

5.5.3. Présentation des limites des solutions

La solution que l’on a étudiée est une solution de supervision complète cependant
nous avions recensé 03 limites lors de son déploiement, la première est qu’elle
consomme beaucoup en CPU, cela s’explique par le fait qu’elle duplique 06 du
processus père et chaque processus récupère de la ressource pour exécuter sa tâche.
La seconde se trouve au niveau de l’installation du produit, elle a beaucoup de
dépendances et un élément important mal installer revient à reprendre toute
l’installation de shinken voir au pire du système d’exploitation. La troisième
faiblesse réside au niveau de la sécurité, elle ne permet pas de faire des
configurations en interface web rn utilisant le HTTPS.

Comme suggestions pour les deux dernières limites, il ne faut pas lancer des mises a
jours des paquets du système de sa propre initiative car elle pourrait causer des
problèmes d’incompatibilités et des dépendances non satisfaite avec les autres
rendant le système inutilisable. Le mieux sera d’installer que les mises à jour
officielles.

5.6. Conclusion

Dans ce chapitre, nous avons présenté les principales parties de la solution à mettre
en place, des exemples de configurations de supervision d’équipement ont été
démontrer pas-à-pas pour démontrer la réussite du déploiement de la solution. Un
bilan a été établi dans le but de mettre en exergue les points sur la réalisation du
projet des limites de la solution et des perspectives en cours de réflexions.

79
80

CONCLUSION GENERALE
En sommes, ce stage de trois mois se termine par ce rapport de stage, ayant pour
thème : « Etude et mise en place d’une solution de supervision pour le système
d’information de SOFTNET » , qui nous a permis de nous exprimer à travers cinq
grands chapitres qui sont les suivantes : le premier donne une présentation du
contexte de stage à travers la présentation de notre cher Ecole, la structure
d’accueil SOFTNET ou nous avions été placés sous la tutelle de M. Maxime
OUEDRAOGO. Le second chapitre parle de l’Analyse de l’existant qui a été
présenté par la présentation des différentes ressources de l’existant d’abord, ensuite
nous avions effectué le diagnostic de ses ressources énumérer et enfin nous avons
élaborer une démarche à suivre pour résoudre les problèmes énumérer. Le
troisième chapitre met beaucoup l’accent sur les généralité des solutions, elle n’a
parler que de deux point à savoir les concepts généraux et la présentation des
différentes solutions qui s’est terminée par un tableau de comparaison :Le
quatrième chapitre parle de la présentation détailler de la solution choisie qui
est SHINKEN : Enfin le chapitre cinq déroule l’implémentation technique de
la solution à travers une méthode d’installation de la solutions shinken en plus de
ses prérequis d’abord, ensuite des exemples de configurations de supervision
système et réseaux ont été montré avec des captures des tests à l’appui, et enfin un
reporting a été réaliser pour l’ensemble de l’étude. Cette étude fut très intéressante
surtout coacher par notre maitre de stage et le personnel de la structure qui nous
ont aidés de leur mieux avec de petits apports et des astuces afin que nous
puissions apprendre beaucoup dans le domaine de la supervision et surtout avec
l’outils shinken l’outil de supervision complet aux vues de ses nombreuses capacité
de pouvoir répondre aux différents besoins d’un administrateur réseau. A l’instar de
cela, nous pouvions dire que ce stage de fin d’étude de licence fut une première
véritable expérience en entreprise car la formation théorique reçu au cursus
universitaire a été complète par les formations pratique reçu à SOFTNET.

80
81

Références Bibliographique et webographie

[1] «Historique | Ecole Supérieure d'Informatique,» 2018. [En ligne]. Available: http://www.esi-
upb.bf/. [Accès le 10 Novembre 2019].

[2] «Licence en Informatique | Ecole Supérieure d'Informatique,» 2018. [En ligne]. Available:
http://www.esi-upb.bf/?page_id=23. [Accès le 10 Novembre 2018].

[3] «Présentation | SOFTNET GROUP SOLUTION INFORMATIQUE,» 2019. [En ligne]. Available:
http://softnet-group.com/presentation/. [Accès le 26 Fevrier 2019].

[4] O. Sararé, Mise en place par simulation d'une conexion VPN entre agences d'une entreprise,
OUAGADOUGOU: SOFTNET, 2018, pp. 10-32.

[5] P. IRSAPOULLE, Mise en place d'un outil de supervision et de contrôle distant, Saint Denis:
Université de la Reunion, 2014, pp. 24-48.

[6] «Surveillance (informatique),» 13 Décembre 2018. [En ligne]. Available:


https://fr.wikipedia.org/wiki/Surveillance_(informatique). [Accès le 18 Septembre 2018].

[7] «Notification,» 27 Decembre 2018. [En ligne]. Available:


https://fr.wikipedia.org/wiki/Notification#Informatique. [Accès le 26 Fevrier 2019].

[8] R. G. CISSE, Mise en place d'un système de supervisionet de reprise de service dans un point
d'échange Internet, Bobo-Dioulasso: Ecole Superieur d'Informatique, 2017, pp. 1-65.

[9] «Suite des protocoles Internet,» 20 Janvier 2019. [En ligne]. Available:
https://fr.wikipedia.org/wiki/Suite_des_protocoles_Internet. [Accès le 26 Fevrier 2019].

[10] «Les différences entre le modèle OSI et TCP/IP,» 26 Février 2016. [En ligne]. Available:
http://albertoalvarez95.wixsite.com/prblog/single-post/2016/02/25/Les-diff%C3%A9rences-
entre-le-mod%C3%A8le-OSI-et-TCPIP. [Accès le 06 Mars 2019].

[11] «Internet Control Message Protocol,» 01 Février 2019. [En ligne]. Available:
https://fr.wikipedia.org/wiki/Internet_Control_Message_Protocol. [Accès le 06 Mars 2019].

[12] «Simple Network Management Protocol,» 30 Novembre 2018. [En ligne]. Available:
https://fr.wikipedia.org/wiki/Simple_Network_Management_Protocol. [Accès le 06 Mars 2019].

[13] «Etude des outils de surveillance (monitoring) réseau,» 2008-2009. [En ligne]. Available:
http://www.o00o.org/monitoring/solutions.html. [Accès le 14 Novembre 2018].

[14] «Shinken (logiciel),» 21 Février 2019. [En ligne]. Available:


https://fr.wikipedia.org/wiki/Shinken_(logiciel). [Accès le 24 Fevrier 2019].

[15] Stella, Shinken, vol. I, Source ENI Edition, 2018, pp. 1-210.

[16] «Debian -- Détails du paquet python-cherrypy3 dans sid,» 2019. [En ligne]. Available:
https://packages.debian.org/fr/sid/python-cherrypy3. [Accès le 26 Février 2019].

81
82

[17] «Server Monitoring with Shinken on Ubuntu 16.04,» 2017. [En ligne]. Available:
https://www.howtoforge.com/tutorial/server-monitoring-with-shinken-on-ubuntu-16-04/.
[Accès le Octobre 2018].

[18] R. Andrieu, Supervision de matériel informatique avec Shinken, ARCONIC, 2017, pp. 1-18.

[19] A. Coleman, «GNS3 Setup Wizard - Local server - GNS3,» 29 Juin 2018. [En ligne]. Available:
https://docs.gns3.com/. [Accès le 01 Octobre 2018].

[20] «Cisco Call manager SNMP Overview » snmp architecture,» 02 Mai 2011. [En ligne]. Available:
https://smbitsolutions.wordpress.com/2011/05/02/2-may-2011-1341/snmp-architecture/.
[Accès le 01 Mars 2019].

82
83

ANNEXE A
CONFIGURATIONS SUPPLEMENTAIRES
Configuration d’une notification

Pour pouvoir envoyer des e-mails, messages ou alertes, il faut préciser quelles
plages d’horaire et a quelle commande cette opération se rapport. Pour configurer
l’envoie d’une notification il faut prendre en compte un certain nombre de champ
obligatoire comme dans l’exemple de la figure 40 suivante :

Figure 37 : Contenue fichier de notification email.cfg

Configuration pour les groupes de services

Selon un ou plusieurs critères identiques comme la fonctionnalité ou un realm, il est


possible de définir un groupe de services qui obéi à un certain nombre de règles
comme le montre la figure 41 suivante :

Figure 38 : Contenu fichier servicegroup bddservice.cfg

83
84

ANNEXE B
CONFIGURATION DE GNS3 D’UNE ARCHITECTURE RESEAU
Cette annexe montre comment utiliser GN3 pour concevoir une architecture
réseau avec le logiciel de virtualisation VMware. Tout d’abord il faut se munir de la
machine virtuelle GNS3 VM téléchargeable sur le site web www.gns3.com et
exporter le sur VMware. L’importation terminer vous deviez vous rendre sur le
logiciel gns3 et déclarer le en suivant le chemin suivant :
Edit>preferences>GNS3 VM. De là-bas appliquez les modifications nécessaires
pour avoir la capture suivante :

Figure 39 : GNS3 VM preferences


Appliquer la modification et normalement votre serveur gns3 doit démarrer dans
gns3 et VMware et se mettre en vert comme les figures 43 et 44 suivantes :

84
85

Figure 40 : Démarrage gns3 VM dans gns3

Figure 41 : Machines virtuelles installer dans GNS3

85
86

La prochaine étape est d’ajouter une machine virtuelle sur gns3. La méthode est
pareille que pour gns3VM à la différence qu’il faut suivre ce lien :
Edit>preferences> VMware VM templates> New>Next et choisissez votre
machine virtuelle à être importer et appliquer. Si elle est bien importée vous la
verrez afficher au niveau des périphérique finaux comme la montrer la figure 44 ci-
dessus suivante avec l’importation de la machine U_shinken :

Clique et glisser le sur l’espace vide juste au milieu. Vous pouviez le faire avec
d’autre équipements et vous les interconnecter à l’aide de votre machine hôte qui
fera office de switch dans votre architecture. Les routeurs sont installables en
suivant ce chemin :

Icone routeur>new appliance template>, cocher add an IOS routeur using a


real Ios image, >ok>, cocher new image>browse, allez chercher votre ISO qui
doit avoir l’extension .bin>YES>Next, indiquer le nom de votre routeur au
niveau de name, valider avec Next*2 et votre routeur est installer. [19]

La figure 45 suivante montre l’architecture de configurations des équipements dans


le chapitre 5. Les points en rouge montrent que leurs interfaces réseaux ne sont pas
connecter ou que l’équipement est hors tension. Pour le premier cas il suffit juste
de faire un bon adressage IP et les équipements communiquerons et vous pourriez
faire vos tests.

Figure 42 : Architecture final chap5

86