MEMOIRE DE STAGE DE FIN D’ETUDES

pour l’obtention du « MASTER PROFESSIONNEL EN TELECOMMUNICATIONS,

RESEAU ET SECURITE>>
ANNEE ACADEMIQUE 2021-2022

MISE EN PLACE D’UN OUTIL DE SUPERVISON

DE RÉSEAU À BASE D’UN LOGICIEL OPEN
SOURCE AU SEIN DE QUALISYS CONSULTING

Spécialité : télécommunications, réseaux et sécurité

Rédigée par :
NOUMEDEM Guyvarch Nelson

SOUS L’ENCADREMENT PROFESSIONNEL DE :

M. Richard NDIOMO M. Console NOUMEDEM
Expert en Infrastructure Système et Développeur senior
Réseaux

SOMMAIRE

1
SOMMAIRE..............................................................................................................................................i
DÉDICACE..............................................................................................................................................iii
REMERCIEMENTS...................................................................................................................................iv
LISTE DES TABLEAUX...............................................................................................................................v
LISTE DES FIGURES.................................................................................................................................vi
RÉSUMÉ................................................................................................................................................vii
ABSTRACT............................................................................................................................................viii
INTRODUCTION GÉNÉRALE....................................................................................................................9
CHAPITRE 1 : PRESENTATION DE QUALISYS CONSULTING ET CADRE DU PROJET.................................10
1.1. Présentation de Qualisys Consulting........................................................................................10
1.1.1. Historique.........................................................................................................................11
1.1.2. Vision et valeur.................................................................................................................11
1.1.3. Ligne de services...............................................................................................................11
1.1.4. Nos bureaux......................................................................................................................12
1.1.5. tructure organisationnelle................................................................................................14
1.1.6. Organisation des directions fonctionnelles.......................................................................15
1.2. Cadre du projet.....................................................................................................................16
1.2.1. Problématique..................................................................................................................16
1.2.2. Contexte...........................................................................................................................16
1.2.3. Motivation et objectif.......................................................................................................16
CHAPITRE 2: ETAT DE L'ART ET CONCEPTS THEORIQUES.....................................................................18
2.1. Présentation de la supervision.............................................................................................18
2.1.1. Définition..........................................................................................................................18
2.1.2. Principe.............................................................................................................................18
2.1.3. Fonctionnement d’une plateforme de supervision..........................................................19
2.1.4. Les méthodes de supervision............................................................................................19
2.2. Protocole de supervision réseau...........................................................................................20
2.2.1. Problématique..................................................................................................................20
2.2.2. Exemple de protocoles de supervision.............................................................................20
2.2.3. SNMP................................................................................................................................20
2.3. Les outils de supervisions.....................................................................................................21
2.3.1. Outils payants...................................................................................................................22
2.3.2. Outils open source............................................................................................................23
2.4. Etude et choix de l’outil........................................................................................................28

2
 2.4.1. Critère de choix.................................................................................................................29
2.4.2. Choix de l’outils................................................................................................................30
CHAPITRE 3 : SPECIFICATION ET CONCEPTION DES BESOINS...............................................................32
3.1. Spécification des besoins...........................................................................................................32
3.1.2. Besoins fonctionnels...............................................................................................................32
3.1.3. Besoins non fonctionnels........................................................................................................33
3.2. Le Langage de modélisation.....................................................................................................33
3.2.1. Diagrammes de structure ou diagrammes statiques..............................................................33
3.2.1. Diagrammes de comportement..............................................................................................34
3.2.2. Diagrammes d'interaction ou diagrammes dynamiques........................................................35
3.3. Conception et modélisation des besoins...................................................................................35
3.3.1. Acteurs...................................................................................................................................35
3.3.2. Diagrammes de cas d’utilisations...........................................................................................36
3.3.3. Diagramme de séquence........................................................................................................38
3.4. Présentation d’icinga2..............................................................................................................39
3.4.1. Architecture............................................................................................................................40
3.4.2. Fonctionnalités et performances d'Icinga.........................................................................43
3.4.3. Que peut-on superviser ?.................................................................................................44
3.4.4. Complément de Icinga2....................................................................................................45
CHAPITRE 4 : MISE EN PLACE DE LA SOLUTION....................................................................................47
4.1. Architecture du travail...............................................................................................................48
4.1.1. Environnement matériel.........................................................................................................48
4.1.2. Environnement logiciel...........................................................................................................48
4.2. Prérequis pour la mise en place de icinga2...............................................................................48
4.2.1. Installation et configuration de Icinga2 sur Ubuntu 20.04......................................................48
4.2.2. Installation et configuration de Icingaweb2...........................................................................51
4.2.3. Ajout et configuration d’hôte et monitoring..........................................................................52
[Link]. Ajout simple d’un hôte........................................................................................................52
[Link]. Ajout d’un hôte par le biais d’un agent...............................................................................53
4.3. Configuration de notification................................................................................................72
a. Notification par mail.................................................................................................................72
4.3.2. Notification par sms..........................................................................................................74
4.4. Les interfaces de icinga.........................................................................................................76
CONCLUSION GÉNÉRALE......................................................................................................................79

3
 DÉDICACE

Je dédie ce travail à mes

parents Tous les membres de
ma famille, mes amis mes
encadreurs Et tous ceux qui
m’ont soutenu de près ou de
loin tout au long de mes études
Merci à tous.

REMERCIEMENTS
Avant d’entamer ce mémoire, IL nous est agréable de témoigner de ma grande
gratitude, ma forte reconnaissance et mon profond sentiment de respect à l’honorable de mes
encadreurs M. Richard NDIOMO et M. Console NOUMEDEM pour leurs pertinentes
recommandations, leurs précieux conseils et leurs suivi continuel tout le long de l’élaboration

4
de cette recherche. Je salue, en termes de ma haute considération, leurs passions de recherche
et leurs engouements pour les études.
Nous tenons à remercier également M. Éric KOUAM, PhD. pour l’opportunité donnée
de découvrir une telle structure.

Nos remerciements s’adressent au personnel de Qualisys Consulting pour leur accueil

chaleureux et leur esprit de collaboration si précieux.

Enfin, nous restons reconnaissants à tous ceux qui m’ont aidé à la bonne conduite du
présent mémoire

5
 LISTE DES TABLEAUX

Tableau 1 : service QC......................................................................................................12

Tableau 2 : avantages et inconvénients des outils open source.........................................28
Tableau 3 : critères de choix..............................................................................................30
Tableau 4 : choix solution................................................................................................30

LISTE DES FIGURES

Figure 1 : structure organisationelle..................................................................................14

Figure 2 : Organigramme..................................................................................................15
Figure 3 : cas d’utilisation générale...................................................................................36
Figure 4 : cas d’utilisation « Authentification »................................................................37
Figure 5 : Diagramme cas d’utilisation Gestion des services............................................37
Figure 6 : Diagramme de cas d'activité Notification.........................................................38
Figure 7 : Diagramme de séquence « Authentification »..................................................39
Figure 9 : architecture de icinga........................................................................................41
Figure 10 : icinga mobile...................................................................................................43

6
 RÉSUMÉ

Le présent rapport, effectué à Qualisys Consulting CAMEROUN, est inscrit dans le

cadre d’un mémoire de stage de fin d’étude pour l’obtention du « Mastère professionnel en
des Télécommunications et Réseaux ». L’objet de ce projet est la Mise en place d’un outil de
monitoring de réseau à base de logiciel libre nommé 1cinga2 cela permet d’avoir une vue
globale et en temps réel sur l’état du réseau informatique.

7
 ABSTRACT

This report, carried out at Qualisys Consulting CAMEROON, is part of an end-of-

study internship dissertation for obtaining the “Professional Masters in Telecommunications
and Networks”. The purpose of this project is the implementation of a free software-based
network monitoring tool named 1cinga2 that provides a global and real-time view of the state
of the computer network.

8
 INTRODUCTION GÉNÉRALE

Ces dernières années le développement de l’internet et des nouvelles technologiques

ne cesse plus d’évoluer pour faciliter de plus en plus la vie quotidienne et professionnelle. Les
entreprises utilisent leurs réseaux pour y mettre ses données, ils doivent alors être toujours
disponible et garantissent la qualité de service. Les réseaux informatiques représentent un
élément de base pour la transmission des données entre les sites distants. Sur les réseaux
physiques de nombreuses composantes sont donc à surveiller : l'utilisation de la largeur de
bande, l'état de fonctionnement des liens, les problèmes de câblage, le bon cheminement de
l'information entre les machines, etc. Pour ce faire différents points stratégiques sont à
observer comme les routeurs, les serveurs, les liens, les postes, les imprimantes. Ainsi, en cas
de panne ou de mauvais fonctionnement sur le réseau, l'administrateur doit pouvoir interpréter
l'information reçue pour identifier la source du problème. Pour cela on a vu l’utilité de
recourir aux outils de supervision des réseaux afin d’accomplir cette tâche. C’est dans ce
cadre que se situe ce projet de fin d'études. Il est conduit et développé au sein de la société
Qualisys Consulting dans le but de mettre en place un outil de supervision du réseau
permettant de vérifier si les routeurs sont fonctionnels, gérer les serveurs, afficher une
cartographie de réseaux, et envoyer en cas de problème une notification à l’administrateur. Le
présent document est structuré en quatre chapitres. Dans le premier chapitre nous décrivons
l’entreprise d’accueil et le cadre du projet. Tout d'abord nous présentons l'organisme d'accueil
et les différentes taches effectués par l’office. Ensuite, nous traitons le sujet de travail à
réaliser ainsi que ses différentes étapes. Dans le second chapitre nous présentons une étude
théorique du sujet. Le troisième chapitre est consacré à la spécification des besoins et les
outils nécessaires à la réalisation de l’application. Le quatrième chapitre est réservé pour la
spécification ;l'implémentation et les interfaces de tests de l’application.

9
 CHAPITRE 2 : ETAT DE L'ART ET CONCEPTS
THEORIQUES

Introduction
Les réseaux sont devenus indispensables au bon fonctionnement général de nos entreprises et
administrations. Tout problème ou panne sur ces réseaux peut avoir de lourdes conséquences
aussi bien financières qu’organisationnelles. C’est pour cela la supervision des réseaux est une
nécessité primordiale et indispensable. Elle assure une suivie de la disponibilité des services
en ligne, d’avoir une vue globale sur le fonctionnement et les problèmes pouvant survenir sur
un réseau et aussi de disposer des indicateurs sur les performances de son architecture. Nous
consacrons le présent chapitre à la présentation des concepts de base de supervision des
réseaux.

2.1. Présentation de la supervision

10
2.1.1. Définition
La supervision, dénommée aussi surveillance informatique ou monitoring, est le
procédé qui consiste à Contrôler et Vérifier, l’activité d’un système informatique grâce à un
ensemble d'outils logiciels et/ou matériels. Les principales solutions de supervision s’intègrent
dans l’activité quotidienne informatique et permettent de surveiller, analyser, piloter en
agissant directement après avoir reçu des alertes informant de potentielles anomalies.

2.1.2. Principe
La supervision informatique permet de mettre en avant, les anomalies éventuelles du
système d’information de l’entreprise, en alertant et en alarmant dès la connaissance du souci,
l’opérateur concerné pourra intervenir à distance et réparer si besoin l’anomalie constatée.
Tout l’existant informatique et téléphonique de l’entreprise peut être concerné, le courant
électrique, les disponibilités réseaux (fibres, ADSL), les serveurs, les imprimantes et autres
éléments actifs constituant le réseau (hubs, switches, routeurs, etc.).

Surveiller les systèmes d’information, permet de s’assurer d’une bonne disponibilité des
services

2.1.3. Fonctionnement d’une plateforme de supervision

Le fonctionnement d’une telle plateforme se fait à l’aide des tests qui sont envoyées
vers les stations à surveiller dans un réseau, puis les réponses à ces tests sont analysées afin de
voir leurs états. Le superviseur peut être alors informé d’une panne ou bien d’une défaillance
qui survient sur le réseau à l’aide d’un message qui lui est transmis sur son mail ou bien par
SMS.

Il s’agit de répéter de manière séquentielle un processus de test ou de surveillance

d’une personne et/ou d’un bien physique. L’objectif étant d’acquérir très rapidement et
aisément une vision nette et très précise des événements ou dysfonctionnements sur la période
de référence prédéterminée.

11
2.1.4. Les méthodes de supervision
Le monitoring informatique ou la surveillance technique dans le cadre de la mise en
place d’une politique de sécurité des données et des réseaux informatiques, peut-être classé en
trois grandes familles fournissant différents niveaux d’informations :

 Surveillance réseau : Ce genre de supervision active va permettre d’analyser la

disponibilité d’un équipement hard à distance connecté sur un réseau informatique.
Les technologies utilisées pour ce type de supervision sont très simples et le niveau
des informations retournées est filtré.
 Surveillance applicative : A l’aide de cette surveillance, on va disposer d’une
visibilité sur l’ensemble de l’équipement physique mais également sur les applications
qui y sont exécutées et les informations qu’elles renvoient.
 Surveillance système : Situé au cœur du système informatique, il va nous fournir des
informations en temps réel sur l’utilisation Microprocesseur, Mémoire, etc…

Pour les deux premiers cas, il est indispensable que des tests soient effectués directement
par des équipements qui ne sont pas sur la machine elle-même mais délocalisé à distance et le
fait de les réaliser depuis des sites déportés prend son sens si le serveur est destiné à des
utilisateurs externes (connections à Internet).

2.2. Protocole de supervision réseau 

2.2.1. Problématique
La base de la supervision, est les équipements d’interconnexion et de communication
(Routeur, switch, …). Afin de contrôler et gérer le parc informatique, il faut interconnecter la
totalité des hôtes. Le véritable obstacle dans ce cas, est comment faire communiquer et
essentiellement contrôler efficacement en temps réel, les équipements à superviser ? C’est là
où nous pouvons parler du protocole de supervision réseau.

2.2.2. Exemple de protocoles de supervision

Les systèmes de supervision utilisent des protocoles, très réglementés par la DMTF
depuis 2005, parmi les principaux utilisés, nous relèverons :

12
  IPMI : Intelligent Platform Management Interface, c’est une interface intelligente
intégré à certains matériel (serveurs) qui permet la gestion et le contrôle de certains
paramètre à distance (comme température, sonde, …).
 Syslog : C’est un protocole qui permet la transmission d’évènements systèmes de
chaque équipement et les centralisés dans une seule machine dans le but d’archivage,
d’analyse et la production d’alerte.
 JMX : Java Management Interface
 CIM : Common Information Model
 SNMP : Simple Network Management Protocol est le protocole de communication et
de gestion simplifiée du réseau.
 ICMP : Internet Control Message Protocol est un protocole de gestion des
informations concernant les erreurs des hôtes qui lui sont connectées
 ITIL : Information Technology Infrastructure Library
 SBLIM : Standard Based Linux Instrumentation For Manageability
 WBEM : Web Based Enterprise Management
 WS-Management : Web Services For Management
 Windows Management Instrumentation

Principalement ici il s’agira de présenter SNMP

2.2.3. SNMP
 Principe de fonctionnement

SNMP fonctionne avec les technologies utilisant les protocoles TCP/IP et s’appuie sur
le protocole UDP (User Datagram Protocol). Il permet aux administrateurs de contrôler et de
gérer (diagnostiquer) tous les éléments actifs du réseau. En langage SNMP on ne supervise
pas, on manage, mais le résultat est similaire. C’est le SNMP qui permet de dialoguer entre le
superviseur et les agents pour recueillir les objets dans la MIB.

SNMP est basé sur trois éléments le superviseur, les nodes (ou nœuds en français) et
les agents :

 Un équipement à superviser qui contient des objets à gérer : informations de

configuration, sur le matériel, statistiques. . .
 Il exécute un agent, c’est-à-dire un logiciel qui agrège les données locales,

13
  Une console de supervision qui permet d’interroger les agents accessibles par le réseau
ou de recevoir des alertes émises par les agents

Chaque équipement sur lequel intervient l’administrateur via SNMP doit disposer d’un
agent SNMP qui y soit installé. L’interrogation d’un agent se fait en lui envoyant des
messages sur le port UDP 161. L’agent envoie des alertes à la console sur le port UDP 162.
Les objets collectés sont des informations matérielles, des paramètres de configuration, des
statistiques de performance ou bien d’autres sont regrouper dans la base de données MIB.

 MIB

La MIB (Management Information Base) est la base de données utilisée par le

protocole SNMP pour stocker des informations de gestion maintenue par l’agent. Elle est
utilisée par la plate-forme comme source d’information sur le réseau.

2.3. Les outils de supervisions

La surveillance de la santé du réseau est l’une des tâches essentielles de la
maintenance des infrastructures. La bonne nouvelle est qu’il existe pour cette tâche des
logiciels gratuits qui sont aussi performants que leurs équivalents payants. Ils permettent de
monitorer tous les aspects de votre infrastructure, de recevoir des alertes pour tout problème,
voire de prédire les évolutions de trafic. Ces outils s’intègrent généralement à toute
technologie ou tout système en place, et sont disponibles sous plusieurs formats, ce qui les
rend très faciles à déployer en production. Leur gratuité permet à l’équipe informatique de
réorienter les budgets vers d’autres projets nécessitant un financement, ou alors de dépenser
moins tout en offrant le même niveau de service et de support qu’avec des outils payants.

2.3.1. Outils payants

 ITM est le nom du logiciel de supervision, intégré au "Framework" Tivoli d'IBM. Il

permet la surveillance des systèmes informatiques (OS, réseau, applications, matériel,
etc.), et l'envoi d'alertes vers une console de supervision (particulièrement vers Tivoli
Enterprise Console). Le module de supervision Tivoli a d'abord été nommé "Tivoli

14
 Distributed Monitoring" (versions 3.6 et 3.7). Il est devenu "IBM Tivoli Monitoring"
(ITM) en version 5. La version de Tivoli Monitoring (version 6.1) ne repose plus sur
le Framework Tivoli, mais est basée sur l'outil Omegamon de Candle (racheté par
IBM).
 BMC Patrol est l'un des plus anciens logiciels de supervision du marché. C’est un
système de gestion basé sur la technologie des agents. Il comprend une console et
plusieurs agents. Chaque hôte à surveiller dispose d’un agent BMC Patrol, ainsi que
des modules de connaissances requis. Un module de connaissances est un périphérique
de plug-in pour l’agent et est utilisé pour surveiller les événements. Les agents
envoient des événements à l’API BMC Patrol et la console collecte les événements de
l’API. Les opérateurs peuvent spécifier sur la console ce qu’il faut surveiller et quels
seuils définir. BMC Patrol permet jusqu’à trois plages de seuils : fonctionnement
normal, seuil 1 dépassé et seuil 2 dépassé.
La sonde pour BMC Patrol se connecte directement aux agents BMC Patrol et utilise
l’API Patrol pour acquérir des données d’événement à l’aide de la même méthode que
la console BMC Patrol.
 Cisco Works (Network Connectivity Monitor NCM) constitue le plus récent
développement de la gamme de solutions de gestion Cisco Works, conçues pour faire
des réseaux Cisco les plus faciles à administrer et les plus disponibles du marché. Sur
un réseau Cisco, NCM est immédiatement prêt à localiser les problèmes de
connectivité en temps réel et à identifier leurs répercussions. À mesure que le réseau
s'étend et évolue, Cisco Works NCM détecte les modifications apportées aux
périphériques Cisco et ajuste son analyse en conséquence.
 HP OpenView est à l’heure actuelle, un des logiciels majeurs de la supervision. Il
permet le management d’équipements réseaux. Une interface graphique permet un
affichage de l’état courant des équipements. Il est basé sur SNMP pour dialoguer avec
les différentes machines. HP OpenView permet de gérer des composants d'une
infrastructure informatique d’une manière standardisée. Il est principalement utilisé
pour la surveillance de serveurs, périphériques, réseaux, bases de données et
applications pour assurer que les défauts sont détectés et alertés dans les meilleurs
délais

15
2.3.2. Outils open source
 Présentation
 Nagios est un outil de surveillance continue open source qui surveille le réseau, les
applications et les serveurs. Il peut trouver et réparer les problèmes détectés dans
l'infrastructure et arrêter les problèmes futurs avant qu'ils n'affectent les utilisateurs
finaux. Il donne l'état complet de votre infrastructure informatique et ses
performances.
 Zabbix surveille le réseau et rend compte de sa santé comme de ses performances.
Elle détecte les problèmes au niveau des équipements et des connexions. Elle vérifie
s’ils fonctionnent normalement, comment ils utilisent la bande passante, s’ils perdent
des paquets, ou encore comment le processeur et la RAM sont utilisés. Elle fournit
même des prédictions sur l’évolution du trafic.
 Cacti exploite les fonctions d’interrogation et de collecte de relevés des équipements
réseaux. Il remonte des informations sur les réseaux de toutes tailles via RRDTool, un
système Open source qui représente les métriques sous forme de graphiques. Il permet
de visualiser la santé et les performances du réseau sur des tableaux de bord très
faciles à comprendre et qui peuvent être personnalisés. Icinga L’outil de surveillance
Icinga mesure la disponibilité et les performances au travers d’une interface web. Il est
configurable pour s’adapter à tout équipement et dispose de modules pour étendre la
surveillance à un cluster VMware vSphere, à des applications ou à l’accès des
certificats de sécurité. On trouve aussi des outils de modélisation des processus métier.
 Shinken, est un logiciel de supervision réseau libre, sous licence GNU AGPL, créé en
2009 par Jean Gabès. Shinken, surveille les hôtes et les services spécifiés, en alertant
les fonctionnements normaux et anormaux des systèmes. Shinken, a pour but
d'apporter une supervision distribuée et hautement disponible facile à mettre en place.
Il permet donc d'avoir une vision claire en temps réel, de l'état du réseau (système,
services et applications) et aussi d'être prévenu directement en cas de défaillance (par
mail, sms, …).
 Icinga est une plateforme logicielle de surveillance et d’alerte aussi ouverte et
extensible que Nagios. La principale différence réside dans le processus de
configuration : Icinga peut être configuré via l’interface Web, alors que Nagios utilise
des fichiers de configuration et la ligne de commande. Cette fonctionnalité est une
aubaine pour ceux qui préfèrent gérer leur logiciel de surveillance sans la ligne de

16
 commande. Icinga s’intègre avec de nombreux packages logiciels de surveillance, tels
que PNP4Nagios, in Graph et Graphite, pour une visualisation fiable de votre réseau.
 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.
 Centreon est un logiciel libre de supervision, édité par la société française Merethis. Il
permet de générer des rapports sur les incidents. Les données sont stockées dans une
base de données MySQL. L'interface web, est multiutilisateur et gère des listes de
contrôle d'accès, pouvant être paramétrées de manière très précise. Bien qu'il
fonctionne par défaut avec Nagios

 Avantages et Inconvénients

Logiciels Avantages Inconvénients

Nagios  Surveillance des services réseaux (SMTP, POP3,  Configuration compliquée

HTTP, PING, etc.) qui oblige une très bonne
connaissance de Nagios.
 Surveillance des ressources des équipements
(serveur, routeur, etc.) comme la charge du  Graphes pas assez clairs.
processeur, des informations sur l’utilisation des
 Administration compliquée
disques durs, les processus en cours.

 Interface web, pour voir l’état actuel du réseau,

notification et historique des Problèmes, fichiers
log, etc.

 Surveillance des données environnementales

comme par exemple la température.

 Système simple de plugins permettant aux

utilisateurs de développer facilement leurs
propres vérifications de services.

Zabbix  Facilité d'installation  Chaque machine à superviser

17
  Génération facile des graphs doit disposer du client Zabbix

 Facilité de consultation des graphs en fonction  Problème de configuration

du temps sur le switch

 Affichage clair des erreurs sur le Dashboard  Limité au ping sans le client

 Une solution très complète : cartographie de  Interface est un peu vaste, la

réseaux, gestion poussée d'alarmes via SMS, mise en place des Templates
Jabber ou Email, gestion des utilisateurs, gestion n'est pas évidente au début :
de pannes, statistiques et reporting petit temps de formation
nécessaire
 Une entreprise qui pousse le développement, et
une communauté croissante  L'agent Zabbix communique
par défaut en clair les
 Une interface vaste mais claire
informations, nécessité de
 Une gestion des Templates poussée, avec sécuriser ces données (via
import/export xml, modifications via l'interface VPN par exemple)

 Des performances au rendez-vous : l'application  Commence à être connu,

a été testée avec succès avec 10000 équipements mais pas encore auprès des
supervisés entreprises : Peu d'interfaçage

 Compatible avec MySQL, PostgreSQL, Oracle, avec d'autres solutions

SQLite commerciales

Cacti  Interface : Beaucoup plus claire que celle de  Pas de gestion d'alarmes, sauf
NetMRG elle permet également beaucoup plus avec un plugin nommé Thold
de choses (Plus de modes d'affichages et plus de
 Pas de gestion de panne et
possibilités de configuration)
absence d'une cartographie de
 Configuration : Avec l'utilisation des Templates réseau
pour les machines, les graphiques, et la
 Un développement lent tout
récupération des données tout se configure
comme NetMRG
aisément et entièrement via l'interface web.
Import/ Export très simple des Templates au
format XML. On peut aussi très facilement

18
 utiliser des options poussées de RRDTOOL

 Performance : Avec le choix du moteur de

récolte des données, On peut opter pour la
performance ou la simplicité

 Gestion des utilisateurs

 Communauté sur le web, présence d'une dizaine

de plugins permettant d'étendre les
fonctionnalités

Shinken  Facile à installer : l’installation se fait  Très incomplet en version

principalement avec pip mais certains paquets out-the-box
sont disponibles (deb / rpm)  Niveau maintenance/mise à
jour pas évident
 Facile pour les nouveaux utilisateurs : une fois
installé, Shinken fournit une interface de ligne de
commande simple pour installer de nouveaux
modules et packs

 Facile à migrer depuis Nagios : nous voulons

que la configuration et les plugins Nagios
fonctionnent dans Shinken afin qu’il s’agisse
d’un remplacement « en place »

Icinga2  Mesure la disponibilité et les performances au  Installation sur tous les

travers d’une interface web ; clients d’Icinga2 lightweight
obligatoire + plugins désirés
 Configurable pour s’adapter à tout équipement
pour que le master puisse les
 Dispose de modules pour étendre la surveillance utiliser
à un cluster VMware vSphere, à des applications  Difficile d’importer des
ou à l’accès des certificats de sécurité définitions existantes créés
sous forme de fichiers plats
vers Director…

19
NetMRG  Performances : L'application semble pouvoir  Interface : L'interface n'est
tenir la charge avec énormément de machines pas très accueillante et est
surveillées grâce au moteur multi-threadé. déroutante au début.

 Alarmes : Il est possible de configurer des  Configuration : Il n'est pas

évènements qui avertissent l'administrateur d'un très aisé d'ajouter de
fonctionnement anormal. nouveaux équipements à
surveiller si l'on sort du cadre
 Interface : L'interface permet de gérer un grand
du Template prédéfinie.
nombre de machines, classées dans des groupes.
 Un développement lent, peu
 Gestion des utilisateurs
de versions et très espacées
dans le temps (environ une
année).

 Aucune gestion de carte de

réseau, et aspect rudimentaire
des alarmes. Aucune gestion
de panne.

Centréon  La robustesse et la renommée de Nagios  L'interface peut paraître

complexe car il existe
 Une interface beaucoup plus sympathique,
beaucoup d'options, de
permettant de tout configurer, de garder un œil
vues…cela nécessite une
sur tout le réseau en permanence
petite formation
 Les utilisateurs de Nagios ne seront pas perdus
 Un développement qui n'est
pour autant, l'interface reprenant
pas encore en phase avec
avantageusement certaines vues Nagios
celui de Nagios : Parfois des
 Une solution complète permettant le reporting, la problèmes de compatibilité
gestion de panne et d'alarmes, gestion
 Un peu plus lourd que du
utilisateurs, ainsi que la cartographie du réseau
Nagios pur
 Une entreprise qui pousse le développement

 Peut-être décorrélé du serveur Nagios et tourner

20
 tout seul sur un autre serveur

Tableau 2 : avantages et inconvénients des outils open source

2.4. Etude et choix de l’outil
L'ISO s'intéresse de près à la supervision. Et, dès 1988, l'organisme publie la norme
ISO7498/4 2 définissants les principales fonctions que doivent implémenter les systèmes de
supervision et d'administration. Ces fonctions sont la gestion des performances, la gestion de
la comptabilité, la gestion des configurations, la gestion des anomalies et la gestion de la
sécurité.

 La gestion des performances analyse de manière continue les performances du réseau

afin de les maintenir dans un état de performance acceptable.
 La gestion de la comptabilité a pour but de mesurer l'utilisation des ressources,
l’établissement des coûts d'utilisation ainsi qu'une facturation de l'utilisation des
ressources
 La gestion des configurations effectue un suivi des différentes configurations des
éléments présents sur le réseau. Elle stocke dans une base de données les versions des
systèmes d'exploitation et des logiciels installés sur chaque machine du parc réseau.
 La gestion des anomalies détecte les problèmes réseaux. Elle essaie d'isoler le plus
précisément possible 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
 La gestion de la sécurité contrôle l'accès aux ressources en fonction des politiques de
droits d'utilisation établies.

2.4.1. Critère de choix

Dans le Tableau suivant, nous proposerons des paramètres de choix d’un outil open
source (OS, Interface web, performance, …) qui nous permettrons de faire le bon choix d’une
solution, entre les solutions citées précédemment.

21
Base Interface Installation Perfor Dépendanc Protocole Ecriture Monitoring Utilis OS
de web et mance e entre SNMP et ajout distribué ation
Nagio configuratio services des des
s n plugins resso
urces

1= 1= de 5 = très 1= 1= non 1= non 1= non 1= non 1= 1=

non base simple Faible peu linux
ou
Wind
ows

2= oui 2= 4= facile 2= 2= oui 2= oui 2= oui 2= oui 2= 2=

moderne moyen moye linux
n et
Wind
ows

3= moyen 3= bon 3=
bon

2= 4= très 4=
compliqué bon très
bon

1= très 5= 5=
difficile excellent excell
ent

Tableau 3  : critères de choix

2.4.2. Choix de l’outils

Zabbix Shinke Nagios Cacti NetMRG Centreon Icinga2
n
Base de Nagios 1 2 2 1 1 2 2
Interface web 1 2 1 1 1 2 2
Installation et 3 4 4 3 3 4 2

22
configuration
Performance 3 4 3 4 4 4 5
Dépendance entre 1 2 2 2 1 2 2
services
Protocole SNMP 2 2 2 2 2 2 2
Ecriture et ajout des 2 2 2 2 2 2 2
plugins
Monitoring distribué 1 2 2 2 2 2 2
Utilisation des ressources 3 2 2 2 2 2 4
TOTAL 17 22 20 19 18 22 23

Tableau 4  : choix solution

Le tri des solutions, en se basant sur le Tableau, nous a permet, de faire l’ordre du
premier au dernier : Icinga2, Shinken, Centreon, Nagios, Cacti et en fin Zabbix. Tout d’abord
nous excluons Centreon, car il a beaucoup de versions ce qui provoque des problèmes de
compatibilités, ainsi il a certains modules qui sont payants. Nagios reconnu auprès des
entreprises, mais, il maintienne à une partie payante, dérivante de sa partie libre, ce qui exige
son élimination. Après cette étude, nous semble qu’Icinga2 est la solution adéquate à notre
projet, au sein Qualisys Consulting.

 Icinga2 est libre ;

 Icinga à une interface plus moderne ;

Icinga2est un outil flexible, puissant, peut gérer un parc de plus de 200 serveurs grâce à son
daemon qui peut être partagé en plusieurs parties contrairement aux autres outils.

Conclusion

Des solutions citées ci-dessus, HP OpenView, CiscoWork, Zabbix et Nagios sont les
plus connues. Qu’elles soient « Open Source » et gratuites ou propriétaires, chacune a ses
particularités qui lui sont propres. Ces outils ont principalement pour objectif de connaître à
tout instant l’état des nœuds critiques (serveurs, switch, routeurs), l’état des services tournant
sur les différents serveurs, d’envoyer des alarmes, de générer des comptes rendus graphiques.
Ils doivent également être capables d’analyser le trafic réseau afin de permettre une meilleure
répartition des ressources réseaux. Certains outils sont également des solutions payantes, donc
à écarter de nos choix. Après avoir décrit les plateformes de supervision existantes sur le

23
marché, nous entamerons dans le chapitre suivant les différents besoins nécessaires à la
réalisation de notre application.

CHAPITRE 3 : SPECIFICATION ET
CONCEPTION DES BESOINS
Introduction
L’ingénierie de besoins, est l’une des activités importantes, parce qu’elle permet de
déterminer, les besoins des utilisateurs d’une telle application et de définir les contraintes
envisagées. Dans ce chapitre, nous présenterons, la spécification et la conception des besoins,
de notre solution Icinga2. D’abord, nous étudierons, les besoins fonctionnels, en présentant
les modules de nôtre application, ainsi que les besoins non fonctionnels, en représentant les
critères de l’environnement pour implémenter la solution Icinga2. Ensuite, nous ferons, une
conception, en citant les acteurs de la solution et quelques diagrammes de cas d’utilisation.

24
3.1. Spécification des besoins
3.1.2. Besoins fonctionnels
L'objectif de ce projet est de mettre en place une solution de monitoring sur une machine
virtuelle grâce à l’outil de virtualisation VMWare. Cette application doit permettre de
collecter des informations concernant une infrastructure informatique à plusieurs niveaux :

 La supervision des ressources des serveurs (charge du processeur, occupation des

disques durs, utilisation de la mémoire paginée) sur la plupart des systèmes
d’exploitation.
 La supervision des services réseau (SMTP, HTTP, NNTP, ICMP, SNMP, LDAP,
etc…) en local ou sur des machines distantes ;
 L’interfaçage avec le protocole SNMP ;
 La vérification des services se fait en parallèle ;
 La remontée des alertes est entièrement paramétrable grâce à l'utilisation de plugins ;
 L’authentification : L’utilisateur doit s’authentifier pour se connecter à l’interface de
la solution en introduisant l’URL de son serveur et son login et mot de passe.
 La gestion des utilisateurs : La gestion d’utilisateurs nous permet d’ajouter, chercher,
modifier ou supprimer un utilisateur.
 La gestion d’installation : Installer des modules et des plugins Icinga2 (mise à jour,
ajout de nouvelle fonctionnalité, …)
 Acquittement des alertes par les administrateurs.

3.1.3. Besoins non fonctionnels

Afin d’offrir une solution complète et performante à différents niveaux, notre plateforme doit
couvrir les besoins non fonctionnels suivants :

 Facilité d’utilisation : Le système offre une interface simple facile à utiliser en

donnant à l’administrateur la possibilité d’agir sur les ressources qu’il manipule.
 Sécurité : L’accès aux données doit être authentifié et autorisé par des moyens de
sécurité.
 Fiabilité : Il faut garantir la qualité du contenu et la pertinence des informations. Le
produit doit fonctionner correctement.
 Rapidité : Le logiciel de supervision prévient dès qu’un problème survient avant
même que la plupart des utilisateurs en aient conscience.

25
  Extensibilité : Le système doit être extensible et permet d'ajouter et de supporter
d'autres fonctionnalités et d’intégrer tout type d’équipement réseau.
 La performance : une application doit être avant tout performant c'est à dire à travers
ses fonctionnalités, elle répond à toutes les exigences des usagers d’une manière
optimale.

3.2. Le Langage de modélisation

Pour modéliser les fonctionnalités que doit offrir notre système et représenter les
interactions entre ses déférents composants, nous avons choisi le langage de modélisation
unifié UML. UML, c’est l’acronyme anglais pour « Unified Modeling Language ». On le
traduit par « Langage de modélisation unifié », est un langage visuel constitué d’un ensemble
de schémas, appelés des diagrammes, qui donnent chacun une vision différente du projet à
traiter. UML fournit un moyen astucieux permettant de représenter diverses projections d’une
même représentation grâce aux vues.

Une vue est constituée d’un ou de plusieurs diagrammes pour représenter l’application
(son fonctionnement, sa mise en place, …).

3.2.1. Diagrammes de structure ou diagrammes statiques

Les diagrammes de structure (structure diagrams) ou diagrammes statiques (static diagrams)

rassemblent :

 Diagramme de classes (class diagram) : représentation des classes intervenant

dans le système.
 Diagramme d'objets (object diagram) : représentation des instances de classes
(objets) utilisées dans le système.
 Diagramme de composants (component diagram) : représentation des composants
du système d'un point de vue physique, tels qu'ils sont mis en œuvre
(fichiers, bibliothèques, bases de données…)
 Diagramme de déploiement (deployment diagram) : représentation des éléments
matériels (ordinateurs, périphériques, réseaux, systèmes de stockage…) et la
manière dont les composants du système sont répartis sur ces éléments matériels et
interagissent entre eux.

26
  Diagramme des paquets (package diagram) : représentation des dépendances entre
les paquets (un paquet étant un conteneur logique permettant de regrouper et
d'organiser les éléments dans le modèle UML), c'est-à-dire entre les ensembles de
définitions.
 Diagramme de structure composite (composite structure diagram) : représentation
sous forme de boîte blanche des relations entre composants d'une classe (depuis
UML 2.x).
 Diagramme de profils (profile diagram) : spécialisation et personnalisation pour
un domaine particulier d'un meta-modèle de référence d'UML (depuis UML 2.2).

3.2.1. Diagrammes de comportement

Les diagrammes de comportement (behavior diagrams) rassemblent :

 Diagramme des cas d'utilisation (use-case diagram) : représentation des

possibilités d'interaction entre le système et les acteurs (intervenants extérieurs au
système), c'est-à-dire de toutes les fonctionnalités que doit fournir le système.
 Diagramme états-transitions (state machine diagram) : représentation sous forme
de machine à états finis du comportement du système ou de ses composants.
 Diagramme d'activité (activity diagram) : représentation sous forme de flux ou
d'enchaînement d'activités du comportement du système ou de ses composants.

3.2.2. Diagrammes d'interaction ou diagrammes dynamiques

Les diagrammes d'interaction (interaction diagrams) ou diagrammes dynamiques (dynamic

diagrams) rassemblent :

 Diagramme de séquence (sequence diagram) : représentation de façon séquentielle

du déroulement des traitements et des interactions entre les éléments du système
et/ou de ses acteurs.
 Diagramme de communication (communication diagram) : représentation de façon
simplifiée d'un diagramme de séquence se concentrant sur les échanges de
messages entre les objets (depuis UML 2.x).

27
  Diagramme global d'interaction (interaction overview diagram) : représentation
des enchaînements possibles entre les scénarios préalablement identifiés sous
forme de diagrammes de séquences (variante du diagramme d'activité) (depuis
UML 2.x).
 Diagramme de temps (timing diagram) : représentation des variations d'une
donnée au cours du temps (depuis UML 2.3).

3.3. Conception et modélisation des besoins

Après avoir spécifié les différents besoins fonctionnels et non fonctionnels de notre projet,
nous aborderons la partie analyse et modélisation des besoins. Cette partie consiste à faire une
étude conceptuelle. Il s’agit, d’une part, de définir les acteurs de l’application, leurs rôles,
ainsi que les différents diagrammes d’UML. Dans notre cas, nous nous serons limités, aux
acteurs et quelques diagrammes de cas d’utilisation.

3.3.1. Acteurs
Un acteur, est toute entité qui interagit avec notre système, pour que l’acteur réponde à ses
besoins. Ces acteurs sont l’administrateur et les superviseurs.

 L’administrateur : c’est le principal acteur auquel le système s’adresse, il est le

responsable au bon fonctionnement de l’application de supervision, ses rôles sont :
 Gérer la plateforme et les comptes utilisateurs
 Etudier les hôtes, les services et les routeurs et commutateurs
 Communiquer avec la base de données du serveur
 Le superviseur : C’est l’acteur qui a comme rôle :
 La consultation de l’état des hôtes
 La consultation de l’état des équipements réseaux (Routeurs, Switch, etc.)
 Et la consultation de l’état des services

3.3.2. Diagrammes de cas d’utilisations

Afin de décrire les exigences fonctionnelles de notre système, voici une description du cas
d’utilisation globale ainsi que d’autres qui sont les principaux.

 Diagramme de cas d’utilisation générale

28
Figure 3 : cas d’utilisation générale

 Diagramme de cas d’utilisation « s’authentifier »

29
Figure 4 : cas d’utilisation « Authentification »
 Diagramme de cas d’utilisation « Gestion des services »

Figure 5 : Diagramme cas d’utilisation Gestion des services

3.3.1 Diagramme d’activité « Notification »

Ce diagramme décrit les différentes activités que prend le système lorsqu’il détecte un
service ou équipement non fonctionnel. A ce stade le système commence par vérifier l’état du
service correspondant à l’hôte jusqu'à la validation de l’état non-ok. Ensuite, il récupère la
liste des contacts afin d’en choisir un et le notifier par un [Link] l’intervalle de temps de la
prochaine notification est écoulé et que l’état du service est encore non-ok, le système
recommence la vérification des services.

30
Figure 6 : Diagramme de cas d'activité Notification
3.3.3. Diagramme de séquence
Un diagramme de séquence est un diagramme d'interaction qui montre comment les
processus fonctionnent entre eux et dans quel ordre. Il est une construction d'un graphique de
séquence de message. Un diagramme de séquence montre les interactions d'objets disposés
selon un ordre chronologique. Il représente les objets et les classes impliquées dans le
scénario. Les diagrammes de séquence sont généralement associés aux diagrammes de cas
d'utilisation dans la vue logique du système.

 Diagramme de séquence cas d’utilisation « Authentification »

31
Figure 7 : Diagramme de séquence « Authentification »
 Diagramme de séquence modification d’un service

Figure 8 : Diagramme de séquence « Gestion d'un service »

3.4. Présentation d’icinga2

Lancé le 15 mai 2009, Icinga fait partie des projets de Supervision Open Source
dérivée du cœur du célèbre outil de supervision Nagios. Il est à l’époque le

32
premier fork dans ce domaine, née du mécontentement des développeurs et contributeurs de
Nagios qui ne voient plus évoluer le projet.
L’équipe recomposée fait évoluer le fork pendant 5 ans avant de sortir une nouvelle
version baptisée Icinga 2 en juin 2014. Construit à partir de zéro, Icinga 2 est une réécriture
complète de l’outil de supervision basé sur le langage C++ qu’on ne pourra alors plus
qualifier de fork. En effet, plutôt que de continuer de développer à partir du Nagios Core,
comme c’est le cas des versions 1.x, l’équipe de développement a décidé de repartir à zéro
afin de repartir sur de nouvelles bases et notamment pouvoir construire une architecture
modulaire comme par exemple avec Shinken.

3.4.1. Architecture

Icinga2 se base sur une Platform puissante et très riche soit au niveau de la présentation, le
core manager, documentation et les rapports.
Icinga de base est écrit en C et a une architecture modulaire avec un noyau autonome,
l'interface utilisateur et la base de données sur laquelle les utilisateurs peuvent intégrer divers
add-ons et des plug-ins.

Ce dernier communique via Doctrine de la couche d'abstraction d’icinga, REST et

les API de plug-in assurent la médiation entre les données externes et les structures internes.
Ce regroupement de composants permet aux utilisateurs de distribuer le système icinga pour
la surveillance redondante. Il offre également la liberté des utilisateurs de personnaliser icinga
pour répondre à leurs besoins. 

33
Figure 9 : architecture de icinga

 Icinga core :
Icinga core gère les tâches de surveillance, reçoit les résultats des contrôles de différents plug-
ins. Il communique ensuite ces résultats à l’IDODB (Icinga Data Out Database) à travers
l’interface IDOMOD (Icinga Data Out Module) et IDO2DB (Icinga  Data Out to Database)
démon de service sur SSL crypte les sockets TCP. Bien que les deux viennent emballer
(également connu sous le nom IDOUtils) avec le noyau ; ils sont des éléments permanents
simples, qui peuvent être séparés pour distribuer les données et les processus sur plusieurs
serveurs pour la surveillance des systèmes distribués.
L'interface utilisateur icinga classique est également livrée avec icinga core et peut être utilisé
comme une interface Web.

 Icinga Web :
Basé sur AGAVI et PHP Web 2.0 inspiré pour l'interface utilisateur principale (front-end) qui
utilise Cronks (widgets) pour offrir drag-n-drop des tableaux de bord personnalisés.
Contrairement à l'interface classique d’icinga, Icinga Web est une pièce autonome du logiciel.
Il communique avec le noyau, la base de données et la 3ème partie add-ons à travers les
couches composantes : couche d'abstraction Doctrine (Entrée/base de données), API REST

34
(scripts externes) et l'interface de contrôle de commande (création des pipes, l'exécution des
commandes).
Icinga Web 2 : est actuellement développé en parallèle à l'interface utilisateur classique et
Web et a été annoncé lors de la Conférence sur la surveillance open source en Novembre
2013 à Nuremberg (Allemagne).

 Icinga DOD (Data Out Database) :

Icinga Data Out Database (IDODB) est un point d’enregistrement pour les données de
surveillance historique pour add-ons. Contrairement à son prédécesseur Nagios, Icinga
supporte PostgreSQL et Oracle bases de données en plus de MySQL.

 Icinga rapports (Reporting) :

Le projet icinga propose un module optionnel Icinga Reporting base sur l’open
source Jasper Reports. Il peut être intégré dans les deux interfaces utilisateur Icinga Classic
et Icinga Web. Le module fournit des rapports basés sur un modèle (par exemple Top 10 des
hôtes ou problématiques des services, rapports de disponibilité, etc.) qui peuvent être
sauvegardées dans un référentiel avec différents niveaux d'accès et génération automatique de
rapports et de la distribution. Les rapports peuvent également être consultés dans les deux
interfaces utilisateur en option d’icinga.

 Icinga mobile :
Icinga Mobile est une interface utilisateur pour les smartphones et les navigateurs de tablettes
qui fonctionnent sur WebKit (dérivé de KHTML). Ceux-ci sont généralement disponibles sur
iOS, Android, BlackBerry Tablet OS et webOS. Sur la base de Javascript et de Sencha Touch,
Icinga mobile est téléchargé sur un serveur pour l'accès par les utilisateurs autorisés via leurs
appareils mobiles. L’administration et les mises à jour peuvent ainsi être prises de façon
centralisée, pour l’appliquer automatiquement à tous les utilisateurs d'un réseau informatique. 

35
Figure 10 : icinga mobile

3.4.2. Fonctionnalités et performances d'Icinga

Icinga 2 gère les tâches classiques de ce que nous pouvons attendre d’un outil de
supervision : exécution des contrôles, envoi de notifications d’alerte, enregistrement des
événements… De ce côté-là, le système est axé sur la performance avec une conception
multithread. L’équipe annonce avoir fait tourner sur une machine 1 million de contrôles actifs
pour 60 000 hôtes supervisés, sans problèmes. En comparaison avec la version 1, il faut 100
fois plus de contrôles à lcinga 2 pour arriver au même niveau de latence.

36
Modularité :
La conception modulaire permet d’éclater les rôles sur différentes machines afin de répartir
les charges. Quand on voit les performances annoncées, je ne suis pas sûr que ce soit la
fonctionnalité la plus utilisée 

Distribution :
Dans les fonctionnalités les plus alléchantes à mon gout, c’est la surveillance distribuée. En
mode distribué, on peut créer plusieurs instances de serveurs satellites qui effectueront leurs
surveillances sur une zone et remonter les données à la zone centrale. Également distribuer
toute la supervision en équipant les satellites de certains rôles, grâce à la modélisation.

Clusterisation :
Suivant les cas, la clusterisation de l’infrastructure peut être intéressante pour assurer un
service haut disponibilité. Là encore, Icinga 2 met en avant sa flexibilité en donnant la
possibilité de mixer clusterisation, modélisation et distribution !

Historisation :
Concernant la base de données, Icinga prend en charge Oracle et PostgreSQL en plus de
MySQL pour l’historisation des données.

Notification :
Notification des personnes de contact en cas de problème de service ou de l'hôte se produisent
et sont résolues (via email, ou une méthode définie par l'utilisateur)

3.4.3. Que peut-on superviser ?

• General Monitoring : ping4, ping6, fping4, fping6, hostalive /tcp, udp, ssl
/ntp_time
• Linux Monitoring : disk /mem, swap /procs /users /running_kernel /package
Management : apt, yum, etc. /ssh /performance : iostat, check_sar_perf
• Windows Monitoring : check_wmi_plus /NSClient++ (in combination with
the Icinga 2 client and either check_nscp_api or nscp-local check commands)

37
/Icinga 2 Windows Plugins (disk, load, memory, network, performance
counters, ping, procs, service, swap, updates, uptime, users /vbs and
Powershell scripts
• DataBase Monitoring : MySQL/MariaDB : mysql_health, mysql,
mysql_query /PostgreSQL : postgres /Oracle : oracle_health /MSSQL :
mssql_health /DB2 : db2_health /MongoDB : mongodb /Elasticsearch:
elasticsearch /Redis: redis)
• SNMP Monitoring : Manubulon plugins (interface, storage, load, memory,
process) /snmp, snmpv3)
• Network Monitoring :
• Web Monitoring (http /ftp /webinject /squid /apache-status /nginx_status
/kdc /rbl)
• Java Monitoring (jmx4perl)
• DNS Monitoring (dns /dig /dhcp
• Backup Monitoring (check_bareos)
• Log Monitoring (check_logfiles /check_logstash /check_graylog2_stream)
• Virtualisation Monitoring
• VMware Monitoring
• SAP Monitoring (check_sap_health /SAP CCMS)
• Mail Monitoring (smtp, ssmtp /imap, simap /pop, spop /mailq)
• Hardware Monitoring (hpasm / ipmi-sensor)
• Metrics Monitoring (graphite)
3.4.4. Complément de Icinga2
NSClient++ est un service pour toutes versions de Windows (NT, 2010, 2008, XP,
Vista, 7 ; …) qui combine les fonctionnalités d’un agent de supervision dédié à
l’environnement Windows ainsi que les fonctions de transport NRPE et NSCA pour cet
environnement. Il est disponible en version 86 et 64 bits. Du fait de ces triples fonctions, le
fichier de configuration de NSClient++ est assez long mais également assez simple. Il est
aujourd’hui considéré comme l’agent de supervision standard pour plateformes Windows.

La supervision des machines Windows se fait grâce à l'agent NSClient++ qui doit être
installé sur la machine distante à superviser.

38
 Conclusion

Dans ce chapitre, nous avons présenté, la spécification et la conception des besoins, la

solution de supervision réseau Icinga2. D’abord, nous avons étudié, les besoins fonctionnels,
en présentant les modules et ses fonctions principales traitées dans l’application. Ensuite, nous
avons fait, une conception des besoins, en introduisant le langage de modélisation UML. Puis,
nous avons cité les acteurs intervenants, dans la gestion de la solution de supervision réseau,
avec l’étude de quelques diagrammes de cas d’utilisation. Enfin, nous avons présenté la
solution Icinga2.

39
 CHAPITRE 4 : MISE EN PLACE DE LA
SOLUTION
Introduction
Icinga est un système de surveillance qui vérifie la disponibilité de vos ressources
réseau, informe les utilisateurs des pannes et génère des données de performance pour les
rapports. Évolutif et extensible, Icinga peut surveiller des environnements complexes et de
grande taille sur plusieurs sites. Icinga 2 est le serveur de surveillance et nécessite Icinga Web
2 sur le dessus dans votre pile Icinga. La configuration peut être facilement gérée avec Icinga
Director, des outils de gestion de configuration ou du texte brut dans Icinga DSL.

40
4.1. Architecture du travail
4.1.1. Environnement matériel
Tout au long de notre projet, nous avons eu à notre disposition un ordinateur portable avec
la configuration suivante :

 Intel(R) Core (TM) i5-3210M CPU @ 2.50GHz 2.50 GHz

 8,00 Go (7,88 Go utilisable) de RAM
 Disque dur de capacité 500 Go.
 Système d’exploitation : Windows 10 64 bits, processeur x64

4.1.2. Environnement logiciel

 VMware Workstation 16 Player Ce logiciel permet de créer des machines virtuelles et
d'installer sur chacune un système invité, indépendant du système hôte. Vous pourrez
donc, par exemple, travailler sous Mac OS X (votre système d'exploitation principal,
le système hôte) tout en utilisant une machine virtuelle sous Linux ou Windows
(système invité), sous la forme d'une fenêtre.
 La distribution Ubuntu 20.04 sur laquelle on a installé icinga2
 La distribution Ubuntu 20.04 comme machine distante à superviser sur laquelle on a
installé icinga-agent
 Windows 8.1 comme machine distante à superviser sur laquelle on a installé
NSClient++ est un service pour toutes versions de Windows qui combine les
fonctionnalités d’un agent de supervision dédié à l’environnement Windows ainsi que
les fonctions de transport NRPE et NSCA pour cet environnement.

4.2. Prérequis pour la mise en place de icinga2

1Z2E3684.2.1. Installation et configuration de Icinga2 sur Ubuntu

20.04
 Installation des paquets requis.
#apt-get update
#apt-get install apt-transport-https wget gnupg
 Téléchargeons et installons la clé de dépôt Icinga2.

41
#wget -O - [Link] | apt-key add -
 Utilisons la commande suivante pour découvrir votre nom de code Linux
Ubuntu.
#. /etc/os-release; if [ ! -z ${UBUNTU_CODENAME+x} ]; then DIST="$
{UBUNTU_CODENAME}"; else DIST="$(lsb_release -c| awk '{print $2}')"; fi;
set | grep DIST
Dans notre cas, le code linux Ubuntu est FOCAL.
 Ajoutons le référentiel official Icinga2 à votre base de données APT
# nano /etc/apt/[Link].d/[Link]

deb [Link] icinga-focal main

deb-src [Link] icinga-focal main

 Mettons à jour votre base de données APT et installons-le package Icinga2.

#apt-get update
#apt-get install icinga2
 Installons les plugins de surveillance standard du Icinga2.
#apt-get install monitoring-plugins
 Activons le service Icinga2 pour démarrer automatiquement pendant le temps de
démarrage.
#systemctl enable icinga2

 Installer MySQL Server 

#apt-get install mariadb-server mariadb-client

 Installer la fonction IDO 

L’étape suivante consiste à installer le package à l’aide du gestionnaire de packages de votre

distribution icinga2-ido-mysql

#apt-get install icinga2-ido-mysql

42
  Configurer la base de données MySQL pour Icinga 2

# mysql -u root -p

>CREATE DATABASE icinga ;

>GRANT SELECT, INSERT, UPDATE, DELETE, DROP, CREATE VIEW, INDEX,
EXECUTE ON icinga.* TO 'icinga'@'localhost' IDENTIFIED BY 'icinga’ ;
>quit
Après avoir créé la base de données, vous pouvez importer le schéma IDO Icinga 2 à l’aide de
la commande suivante. Entrez le mot de passe root dans l’invite lorsque vous y êtes invité.

#mysql -u root -p icinga -h localhost < /usr/share/icinga2-ido-mysql/schema/[Link]

 Activer la fonctionnalité IDO MySQL 

# icinga2 feature enable ido-mysql

Module 'ido-mysql' was enabled.

Make sure to restart Icinga 2 for these changes to take effect.
Redémarrez Icinga 2.

#systemctl restart icinga2

 Configurer l’API REST Icinga 2

#icinga2 api setup

Modifiez le fichier et ajoutez un nouvel objet ApiUser. Spécifiez l’attribut permissions avec
les autorisations minimales requises par Icinga Web [Link]

#nano /etc/icinga2/conf.d/[Link]

object ApiUser "icingaweb2" {

password = "icingaweb2"
permissions = [ "status/query", "actions/*", "objects/modify/*", "objects/query/*" ] }

Redémarrez Icinga 2 pour activer la configuration.

43
#systemctl restart icinga2

4.2.2. Installation et configuration de Icingaweb2

 Installez Icinga Web 2 

#apt-get install icingaweb2 libapache2-mod-php icingacli

Le paquet supplémentaire est nécessaire sur Ubuntu pour installer automatiquement un

serveur Web et PHP et faire fonctionner Icinga Web 2 prêt à l’emploi.libapache2-mod-php

 Installer le serveur Web 

Assurez-vous d’avoir un serveur Web avec PHP opérationnel avant de continuer. Reportez-
vous à la configuration requise pour l’installation pour plus de détails sur les versions prises
en charge. Selon votre système d’exploitation, vous devrez peut-être installer et configurer le
serveur Web séparément.

 Préparer la configuration Web 

Vous pouvez configurer Icinga Web 2 rapidement et facilement avec l’assistant de

configuration Icinga Web 2 qui est disponible la première fois que vous visitez Icinga Web 2
dans votre navigateur. Lorsque vous utilisez la configuration Web, vous devez vous
authentifier à l’aide d’un jeton. Pour générer un jeton, utilisez-le : icingacli

#icingacli setup token create

Si vous ne vous souvenez pas du jeton, vous pouvez le montrer en utilisant le :icingacli

#icingacli setup token show

Vous devez créer manuellement une base de données et un utilisateur de base de données
avant de démarrer l’assistant Web. Cela est dû à des restrictions de sécurité locales alors que
l’assistant Web ne peut pas créer une base de données/un utilisateur via un socket de domaine
Unix local.

MariaDB [mysql]> CREATE DATABASE icingaweb2 ;

44
MariaDB [mysql]> GRANT ALL ON icingaweb2.* TO icingaweb2@localhost IDENTIFIED
BY 'web2’ ;

 Démarrer la configuration Web 

Enfin, visitez Icinga Web 2 dans votre navigateur pour accéder à l’assistant de configuration
et terminer l’installation : adresse-local /icingaweb2/setup

Utilisez les mêmes informations de base de données, d’utilisateur et de mot de passe créées
ci-dessus lorsque vous y êtes invité.

L’assistant d’installation détecte automatiquement les packages requis. Dans le cas où l’un
d’eux est manquant, par exemple un module PHP, veuillez installer le package, redémarrer
votre serveur Web et recharger la page de configuration.

4.2.3. Ajout et configuration d’hôte et monitoring

La supervision des machines distantes peut s’effectuer de deux manières.

 À distance et sans rien installer sur la machine à distance, ce qui n’offre que des
possibilités de contrôle très limitées (ping, ssh, http).
 En installant un agent Icinga sur les serveurs, ce qui permet beaucoup plus de
flexibilité dans la supervision.

[Link]. Ajout simple d’un hôte

À noter que tout ceci est en mode utilisateur

 Tout abord rassurons-nous si l’Object ``generic service`` a été ajouté lors de

l’installation de Icinga2
 Sinon suivre la procédure suivante tout en ajoutant différent service tel que ping4,
http, ping6, ssh
 Ajoutons les hôtes à superviser dans le fichier

#nano /etc/icinga2/conf.d/[Link]

45
 Host A Host B Host C
object Host "nelson-virtual- object Host "DESKTOP- object Host "router" {
machine" { T3OAQSK" { check_command =
address = "[Link]" address = "[Link]" "hostalive"
check_command = check_command = "hostalive" address = "[Link]"
"hostalive" } }
} object Service "ping4" {
object Service "ping4" { host_name = "DESKTOP-
host_name = " nelson-virtual- T3OAQSK
machine " check_command = "ping4"
check_command = "ping4" }
} object Service "http" {
object Service "http" { host_name = "DESKTOP-
host_name = " nelson-virtual- T3OAQSK"
machine " check_command = "http"
check_command = "http" }
}

#systemctl restart icinga2

[Link]. Ajout d’un hôte par le biais d’un agent

 L’agent Icinga communique avec le serveur de supervision via le port 5665. Avant
toute chose, je vais donc songer à ouvrir ce port.
#allow utf8
 Après cela installer et configurer le Master
# icinga2 node wizard
# icinga2 pki ticket --cn icinga2-agent. Localdomain
# systemctl restart icinga2

46
  Cas01 installation de l’agent sur Windows 10
xécutez le package MSI-Installer et suivez les instructions indiquées dans les captures
d’écran.

47
 

48
 

49
  

Remplissez les informations requises et cliquez pour ajouter une nouvelle connexion
principale. Add

50
51
Si nécessaire, vous pouvez ajouter une zone globale supplémentaire (les zones sont ajoutées
par défaut) :global-templatesdirector-global

52
Vérifiez le certificat à partir de l’instance maître/satellite à laquelle ce nœud doit se connecter.

53
Configuration NSClient++ groupée ¶
Si vous avez choisi d’installer/mettre à jour le package NSClient++, l’assistant d’installation
d’Icinga 2 vous demande de le faire.

54
Choisissez la [Link]

55
Choisissez le type de [Link]

NSClient++ n’installe pas d’exemple de configuration par défaut. Modifiez cela comme
indiqué dans la capture d’écran.

56
Générez un mot de passe sécurisé et activez le module de serveur Web. Remarque : Le
module serveur Web est disponible à partir de NSClient++ 0.5.0. Icinga 2 v2.6+ est requis qui
inclut cette version.

Terminez l’installation.

57
Ouvrez un navigateur Web et accédez à Https://localhost:8443 ;Entrez le mot de passe que
vous avez configuré lors de l’installation. Si vous l’avez perdu, examinez le fichier de
configuration. C:\Program Files\NSClient++\[Link]

58
 L’API REST NSClient++ peut être utilisée pour interroger des
métriques. Check_nscp_api utilise cette méthode de transport.
Terminer l’installation de l’agent Windows 

59
Si vous n’avez pas fourni de ticket d’installation, vous devez signer la demande de certificat
sur le maître. Les assistants d’installation vous demandent de le faire. Le service Icinga 2 est
déjà en cours d’exécution à ce stade et recevra et mettra à jour automatiquement un certificat
client signé.

60
Icinga 2 est automatiquement démarré en tant que service Windows.

61
  Cas02 installation de l’agent sur Ubuntu 20.04

Démarrez l’assistant sur l’agent :[Link]

# icinga2 node wizard

Welcome to the Icinga 2 Setup Wizard!

We will guide you through all required configuration details.

Appuyez sur Entré

Appuyez ou choisissez d’établir une connexion au nœud [Link]

Do you want to establish a connection to the parent node from this node? [Y/n]:

62
 Si ce nœud ne peut pas se connecter au nœud parent, choisissez. L’assistant
d’installation fournit des instructions pour ce scénario – les questions de signature sont alors
désactivées.n

Ajoutez les détails de connexion pour .[Link]

Please specify the master/satellite connection information:

Master/Satellite endpoint host (IP address or FQDN): [Link]
Master/Satellite endpoint port [5665]: 5665

Vous pouvez ajouter d’autres nœuds parents si nécessaire. Appuyez ou choisissez si

vous ne souhaitez pas en ajouter. Cela est pratique si vous avez plus d’un nœud parent, par
exemple deux maîtres ou deux [Link]

Add more master/satellite endpoints? [y/N]:

Vérifiez le certificat du nœud parent :

Parent certificate information:

Subject: CN = [Link]
Issuer: CN = Icinga CA
Valid From: Sep 7 [Link] 2017 GMT
Valid Until: Sep 3 [Link] 2032 GMT
Fingerprint: AC 99 8B 2B 3D B0 01 00 E5 21 FA 05 2E EC D5 A9 EF 9E AA E3

Is this information correct? [y/N]: y

L’assistant d’installation récupère le certificat du nœud parent et vous demande de

vérifier ces informations. Il s’agit d’empêcher les attaques MITM ou tout type de relation
parentale non fiable.

Vous pouvez vérifier l’empreinte digitale en exécutant la commande suivante sur le

nœud auquel vous souhaitez vous connecter :

openssl x509 -noout -fingerprint -sha256 -in \

63
"/var/lib/icinga2/certs/$(hostname --fqdn).crt"

Ajoutez le ticket client facultatif pour la signature automatique :

Please specify the request ticket generated on your Icinga 2 master (optional).
4f75d2ecd253575fe9180938ebff7cbca262f96e

Vous pouvez éventuellement spécifier un hôte et/ou un port de liaison différent.

Please specify the API bind host/port (optional):

Bind Host []:
Bind Port []:
Accept config from parent node? [y/N]: y
Accept commands from parent node? [y/N]: y

Ensuite, vous pouvez éventuellement spécifier les noms des zones locales et parentes.
Cela sera reflété dans le fichier de configuration de zone généré.

Définissez le nom de la zone locale sur autre chose, si vous installez une instance
satellite ou une instance principale secondaire.

Local zone name [[Link]]:

Définissez le nom de la zone parente sur autre chose que si cet agent se connecte à une
instance satellite au lieu du maî[Link]

Parent zone name [master]:

Vous pouvez ajouter d’autres zones globales en plus et si nécessaire. Appuyez ou

choisissez, si vous ne souhaitez pas ajouter d’autres élé[Link]-templatesdirector-
globalEntern

Reconfiguring Icinga...

Default global zones: global-templates director-global

Do you want to specify additional global zones? [y/N]: N

64
 Enfin, l’assistant vous demande si vous souhaitez désactiver ou non l’inclusion du
répertoire de configuration local dans, ou non. La valeur par défaut est désactivée, car les
agents sont vérifiés via le point de terminaison de commande ou reçoivent une configuration
synchronisée à partir de la zone [Link].d

Do you want to disable the inclusion of the conf.d directory [Y/n]: Y

Disabling the inclusion of the conf.d directory...

L’assistant procède et vous êtes prêt à partir.

Done.

Now restart your Icinga 2 daemon to finish the installation!

# systemctl restart icinga2

4.3. Configuration de notification

a. Notification par mail

#nano /etc/icinga2/conf.d/[Link]

apply Notification "mail-icingaadmin" to Host {

import "mail-host-notification"
user_groups = [ "icingaadmins" ]
users = [Link]
assign where [Link] != " users = [Link]"}

apply Notification "mail-icingaadmin" to Service {

import "mail-service-notification"
user_groups = [ "icingaadmins" ]
users = [Link]
assign where [Link] != ""}

#nano /etc/icinga2/conf.d/[Link]

65
object Host "svr_testblade" {
import "generic-host"
address = "[Link]"
check_command = "hostalive"
[Link] = "Servers"

[Link]["mail"] = {
groups = ["icingaadmins"]
users = ["icingaadmin"]

#nano /etc/icinga2/conf.d/[Link]

object User "icingaadmin" {

import "generic-user"

display_name = "Icinga2 Admin"

groups = [ "icingaadmins" ]

email = "myemail@[Link]"}
object UserGroup "icingaadmins" {
display_name = "Icinga2 Admin Group"}

#nano /etc/icinga2/scripts/[Link]

## Send the mail using the $MAILBIN command.

## If an explicit sender was specified, try to set it.
if [ -n "$MAILFROM" ] ; then

## Modify this for your own needs!

## Debian/Ubuntu use mailutils which requires `-a` to append the header

if [ -f /etc/debian_version ]; then
/usr/bin/printf "%b" "$NOTIFICATION_MESSAGE" | $MAILBIN -a "From:
$MAILFROM" -s "$SUBJECT" $USEREMAIL

66
 ## Other distributions (RHEL/SUSE/etc.) prefer mailx which sets a sender address with `-
r`
else
## /usr/bin/printf "%b" "$NOTIFICATION_MESSAGE" | $MAILBIN -r "$MAILFROM" -s
"$SUBJECT" $USEREMAIL
/usr/bin/printf "%b" "$NOTIFICATION_MESSAGE" | $MAILBIN -r
"icinga2@[Link]" -s "$SUBJECT" $USERMAIL
fi

else
/usr/bin/printf "%b" "$NOTIFICATION_MESSAGE" \
| $MAILBIN -s "$SUBJECT" $USEREMAIL
fi

template=`cat <<TEMPLATE
***** Icinga EPAY *****
Notification Type: $NOTIFICATIONTYPE
Host: $HOSTALIAS
Address: $HOSTADDRESS
State: $HOSTSTATE
Date/Time: $LONGDATETIME
Additional Info: $HOSTOUTPUT
Comment: [$NOTIFICATIONAUTHORNAME] $NOTIFICATIONCOMMENT
TEMPLATE
`
echo "TEST" | msmtp=myemail@[Link] -s "$NOTIFICATIONTYPE -
$HOSTDISPLAYNAME is $HOSTSTATE" $USEREMAIL
#!/bin/sh

4.3.2. Notification par sms

Téléchargez [Link] dans le répertoire scripts.

[Link]
const SmsUsername "demo"

67
const SmsPassword "demo"
[Link]
object NotificationCommand "sms-host-notification" {
import "plugin-notification-command"

command = [ SysconfDir + "/icinga2/scripts/[Link]" ]

env = {
NOTIFICATIONTYPE = "$[Link]$"
HOSTALIAS = "$host.display_name$"
HOSTADDRESS = "$address$"
HOSTSTATE = "$[Link]$"
LONGDATETIME = "$icinga.long_date_time$"
HOSTOUTPUT = "$[Link]$"
NOTIFICATIONAUTHORNAME = "$[Link]$"
NOTIFICATIONCOMMENT = "$[Link]$"
HOSTDISPLAYNAME = "$host.display_name$"
SMS_USERNAME = SmsUsername
SMS_PASSWORD = SmsPassword
SMS_PHONE = "$[Link].sms_phone$"}
}
[Link]
apply Notification "sms-notification" to Host {
import "sms-host-notification"

user_groups = [Link]
users = [Link]

interval = 0

assign where [Link]}

[Link]

template Notification "sms-host-notification" {

command = "sms-host-notification"

states = [ Down ]
types = [ Problem, Recovery ]

period = "24x7"}
[Link]

object User "icingaadmin" {

import "generic-user"

display_name = "Icinga 2 Admin"

groups = [ "icingaadmins" ]

68
 vars.sms_phone = "<phonenumber>"}

 Mettez cela aux hôtes

[Link]["sms"] = {
users = [ "icingaadmin" ]}

4.4. Les interfaces de icinga

L’application développée est destinée à des administrateurs de réseaux, il permet de
réaliser des tests sur les machines distantes pour vérifier s’ils sont en fonction. D’abord
l’administrateur doit s’authentifier en entrant son login et son mot de passe, préconfiguré lors
de l’installation et la configuration de icingaweb2, pour accéder à la page d’accueil de
Centreon via l’adresse IP « localhost/icingaweb2/authentication/login ».

La première vue après authentification est présentée dans la figure si dessous. Elle donne
une idée générale sur l’état de fonctionnement des hôtes ainsi que les services qui lui sont
associés.

69
 L’interface Tactical Overview permet d’avoir une vue globale sur les statuts des
équipements supervisés et des services qui lui sont liés. Cette vue donne un aperçu rapide sur
l’état du réseau.

Conclusion

Dans ce chapitre nous avons mis l’intérêt sur l’aspect pratique de notre projet, en
détaillant les étapes de la mise en place, la configuration et l’utilisation de ma solution, en

70
mettant l’accent sur l’importance de l’apport de ICINGA2, concernant la facilité de la
configuration et la livraison des comptes rendus et d’analyses plus rapidement.

71
 CONCLUSION GÉNÉRALE
Dans ce rapport nous avons décrit le travail effectué durant la période du projet. Nous
avons atteint presque l’objectif initial de ce projet, ainsi l’administrateur peut contrôler les
routeurs de son réseau à travers l’outil de supervision effectué. Par contre aucun ne peut
accéder à cette application sans avoir permission. Notre application comporte une
cartographie présentant les différents équipements surveillés et elle permet de renseigner
l’administrateur sur l’état des machines, le trafic écoulant, etc. Enfin, l’administrateur peut
être averti par un message textuel, sous forme SMS et par Mail, dont le contenu indiquera la
machine défectueuse. Au terme de ce travail élaboré dans le cadre de mon projet de fin
d’études, Nous avons considéré que ce projet nous a été bénéfique vu qu’il nous a permis de
consolider nos connaissances vers la manipulation d’une application qui sera utile dans le
domaine de la supervision informatique. En effet, l’apport de ce projet se résume surtout dans
la découverte d’un nouveau domaine vaste et innovant qui est le contrôle et l’administration
des réseaux des entreprises. De même, il nous a apporté énormément de connaissances tant au
niveau du protocole SNMP qu’au niveau des équipements réseau. Enfin nous considérons que
le travail effectué au cours de ce projet peut être davantage enrichi et amélioré par de
nouvelles fonctionnalités. En effet, nous pourrons envisager de :

 Implémenter d’autres stations (routeurs) dans d’autres sites afin de couvrir toutes
les zones ou QC est situé et ainsi d’améliorer la précision des donnes reçus.
 Implémenter un ensemble de traps spécifiques : tels que la définition des seuils de
déclenchement des alarmes pour distinguer un état opérationnel normal du réseau
d’un état congestionné.
 Intégrer le Serveur icinga satellite pour pouvoir ajouter des graphiques
correspondant à notre infrastructure réseau.

72