MONITORING APPLICATIF

Université Mohammed V-Rabat
Ecole Nationale Supérieure d’Informatique et
d’Analyse des Systèmes
RAPPORT DE PFA
PROJET DE FIN DE LA 2EME ANNEE
GENIE LOGICIEL
Sujet :
MONITORING APPLICATIF
Mise en place d’un outil de
supervision
Réalisé par :
- NIDABRAHIM Youssef
- KANGA Dominique Bernard
Encadré par :
- Pr. KARIM BAINA
Année universitaire 2016 - 2017

2
Monitoring applicatif
Remerciements
Il nous est agréable de nous acquitter d’une dette de reconnaissance
auprès de toutes les personnes, dont l’intervention au cours de ce
projet, a favorisé son aboutissement.
Nos sincères remerciements à Monsieur Karim BAINA pour le
suivi interrompu de ce projet, pour ses conseils, et son appui tout au
long de ce travail.
Il nous a fait l’honneur d’être notre encadrant. Nous le remercions
pour son encouragement et aussi d’être toujours là pour nous écouter,
nous aider et nous guidder à trouver le bon chemin par sa sagesse et
ses précieux conseils, ce qui nous a donné la force d’accomplir ce
projet.

3
TABLE DES MATIERES
Remerciements .................................................................................................................................... 2
Introduction générale.............................................................................................................................. 6
Chapitre I : Présentation générale du projet........................................................................................... 8
I. Contexte du projet ........................................................................................................................... 9
II. Architecture applicative .................................................................................................................. 9
III. Cas de la simulation...................................................................................................................... 10
Chapitre II : Gestion du projet............................................................................................................... 12
I. Planification du projet.................................................................................................................... 13
II. Découpage en tâches .................................................................................................................... 13
Chapitre III : Monitoring........................................................................................................................ 15
I. Qu’est-ce que la supervision .......................................................................................................... 16
II. Que peut-on superviser................................................................................................................. 16
III. Pourquoi superviser ..................................................................................................................... 17
IV. Comment Superviser.................................................................................................................... 17
Chapitre IV : Analyse des besoins et spécifications............................................................................... 19
I. Objectif du projet ........................................................................................................................... 20
II. Etude des composants de l'architecture réels .............................................................................. 21
III. Etude du cas de simulation .......................................................................................................... 23
Chapitre V : Etude comparative ............................................................................................................ 24
I. Les différentes solutions ................................................................................................................ 25
1. Zabbix ........................................................................................................................................ 25
2. Cacti........................................................................................................................................... 26
3. Nagios........................................................................................................................................ 27
4. Centreon.................................................................................................................................... 28
5. Graphite..................................................................................................................................... 29
6. Shinken...................................................................................................................................... 36
7. Nagios xi..................................................................................................................................... 37
II. Analyse des outils.......................................................................................................................... 38
III. Choix de l’outil de surveillance..................................................................................................... 39
Chapitre VI : Réalisation et mise en œuvre........................................................................................... 40
I. Les outils utilisés............................................................................................................................. 41

4
1. Support d’installation et de développement ............................................................................ 41
2. Langage utilisé pour le développement applicatif .................................................................... 41
II. Réalisation..................................................................................................................................... 41
1. Serveur Web Apache................................................................................................................. 41
2. Serveur PostgreSQL................................................................................................................... 43
3. Serveur Shinken......................................................................................................................... 44
4. Serveur Nagios XI....................................................................................................................... 45
Chapitre VII : Apport du projet.............................................................................................................. 47
I. Apports scientifiques et techniques............................................................................................... 48
II. Apport sur la gestion de projet ..................................................................................................... 48
III. Apport sur la formation pédagogique.......................................................................................... 48
IV. Apport personnel ......................................................................................................................... 48
Conclusion et Perspective ..................................................................................................................... 50
Webographie

5
TABLE DES FIGURES
Figure 1: Architecture applicative ....................................................................................................... 9
Figure 2 : Schéma de notre simulation.............................................................................................. 11
Figure 3 : Planification du projet....................................................................................................... 13
Figure 4 : Architecture réelle a supervisée........................................................................................ 21
Figure 5 : Interface de Zabbix............................................................................................................ 26
Figure 6 : Interface Cacti.................................................................................................................... 27
Figure 7 : Interface de Nagios............................................................................................................ 28
Figure 8 : Interface de Centreon ....................................................................................................... 29
Figure 9 : Architecture de Graphite................................................................................................... 30
Figure 10 : Architecture de collectd .................................................................................................. 32
Figure 11 : Architecture de JMXTrans ............................................................................................... 33
Figure 12 : Architecture de Logstash................................................................................................. 33
Figure 13 : Architecture de Sensu ..................................................................................................... 34
Figure 14 : Shéma de sFlow hôte ...................................................................................................... 34
Figure 15 : Architecture de Grafana.................................................................................................. 35
Figure 16 : Tableau comparatif des outils de supervision................................................................. 39
Figure 17 : Serveur Apache................................................................................................................ 42
Figure 18 : Page d'accueil hébergée par apache............................................................................... 42
Figure 19 : Postgresql........................................................................................................................ 43
Figure 20 : Application bureau de test.............................................................................................. 43
Figure 21 : Serveur Shinken............................................................................................................... 44
Figure 22 : WebUI de Shinken........................................................................................................... 44
Figure 23 : Serveur Nagios XI............................................................................................................. 45
Figure 24 : WebUI de Nagios XI......................................................................................................... 45
Figure 25 : Monitoring de postgresql par nagios xi........................................................................... 46
Figure 26 : Graphe de monitoring par Nagios XI............................................................................... 46

6
INTRODUCTION GENERALE
Depuis des années, les formations qu’offrent l’Ecole nationale supérieure
d’informatique et d’analyse des systèmes ENSIAS est la plus réputée dans son
domaine informatique. En effet, à la fin de chaque année universitaire, les
enseignants attribuent aux élèves ingénieurs des projets, nommé projet de fin
d’année PFA, à réaliser par groupe de deux élèves ingénieurs dans le but de
leur inculquer les valeurs de l’esprit d’équipe et de la recherche.
Cependant, le thème soumis à notre projet est intitulé : La mise en place d’un
outil de supervision - Monitoring applicatif.
L’informatique étant devenue l’épine dorsale de l’entreprise quel que soit son
secteur d’activité, le système d’information est au centre de l’activité de
différentes entités métiers et doit fonctionner pleinement et en permanence
pour garantir l’efficacité de l’entreprise. A tous les niveaux, les réseaux, les
terminaux utilisateurs, les serveurs d’applications et les données constituent
autant de maillons sensibles dont la disponibilité et la qualité de service
conditionnent le bon fonctionnement de l’entreprise.
Les problèmes liés à l’informatique doivent donc être réduits au minimum, car
une indisponibilité du système d’information à des impacts très préjudiciables
sur l’activité et sur la notoriété d’une entreprise.
Des lors, ce sujet nous permettra de tenter de prévenir en cas de problème et,
le cas échéant, garantir une remontée d’information rapide et une durée
d’intervention minimale. Nous trouverons une solution qui va permettre de
superviser et d’assurer le bon fonctionnement de différents d’applications en
production.
C'est dans ce contexte que se situe l'objectif de notre projet qui est de coupler
la puissance des outils de supervision à différents niveau des systèmes
d'information.

7
Dans la suite, nous présenterons le projet dans son intégralité puis nous ferons
une étude comparative des outils de supervision, ferons un choix parmi ces
derniers avant d'effectuer un test de monitoring applicatif sur un cas
d'entreprise utilisant les applications et matériels fournis par notre encadrant
pour une supervision, nous dirons par la suite ce que le projet nous a apporté
et finirons par une conclusion générale.

8
Présentation
générale du projet
CHAPITRE
I

9
Introduction
Une bonne présentation d’un sujet a toujours facilité la compréhension et
éclaire sur les différentes tâches à accomplir dans le cadre d’une réalisation
d’un projet. Dans cette partie nous donnerons le contexte de réalisation du
projet et le cahier de charge qui nous a été confié.
I. Contexte du projet
Pour les personnes âgées, les chutes sont le principal risque à domicile
provoquant plus de 8000 décès par an. Chaque année, une personne âgée
sur 3 chute à son domicile. Les conséquences sont souvent dramatiques
(hospitalisation, perte d’autonomie, de confiance en soi, placement en
maison de retraite).
L’attente des premiers secours peut être longue, pénible et aggraver les
conséquences. En cas de chute, la personne peut être dans l’incapacité
d’appeler les secours ou d’appuyer sur un bouton d’alarme. Les dispositifs de
téléalarme portés au poignet ou autour du cou sont alors insuffisants.
Angel Assistance offre, 24h/24 7j/7, une solution d’alerte automatique et rapide
des secours sans intervention de la personne qui a chuté.
Cependant, nous sommes chargés dans ce projet d'apporter d'autres moins
de préventions et d'alertes automatique en proposant un ou plusieurs outils qui
permettent de superviser les caméras, serveur et log des applications de Angel
Assistance afin de recevoir des alertes en temps réel sur les chutes et
éventuellement des pannes d'appareils et d’applications.
Voir : http://www.angel-assistance.fr/
II. Architecture applicative
Le cahier de charge qui nous a été confié doit prenant en compte les
traitements suivants :
o Suivre l'architecture d’application présentée dans cette figure,
Figure 1: Architecture applicative

10
o Effectuer une étude comparée des outils de supervisions prenant en
compte l'architecture applicative ci-dessus.
o Effectuer des tests de supervisions sur l'architecture proposée.
Pour ce dernier, nous proposerons un cas d'entreprise X, utilisant l'architecture
applicative donnée dans le cahier de charge, avec lequel cas, nous
effectuerons des tests de simulation de supervision. Cela est dû au fait que ce
projet ne s'inscrit pas dans le cadre d'un stage au sein de l'entreprise ANGEL
ASSISTANCE, nous n'avons donc pas accès aux matériels et applications réels
de l'entreprise.
III. Cas de la simulation
Soit une entreprise X dont l'architecture d'applications est composée de :
o Un server APACHE :
Le server APACHE héberge un site web nommé BAINA-WEB et utilise une base
de données POSTGRESQL. Ce site a été développé dans le but d'être supervisé
dans la suite des chapitres.
o Un server POSTGRESQL :
Le server POSTGRESQL a été mise en place pour contenir une base de données
utilisé par le site web. Cependant, nous proposerons un test de supervision du
server POSTGRESQL et de la base de données qui le contient.
o Un ordinateur Windows/linux :
L'ordinateur vient en remplacement aux cameras.
o Le réseau utilisé est un wifi :
Nous nous proposons d'utiliser pour cela le wifi de l'école car elle couvre un
vaste champ, dans le cas échant, nous créerons un réseau Wifi.
Le réseau nous servira à accéder aux différents servers et applications à
distance et nous servirait de canal pour le transport des données (métriques,
alertes) en cas d'anomalies constatées.
Voir capture :

11
Figure 2 : Schéma de notre simulation
Conclusion
Ayant présenté le contexte de réalisation du projet et les différentes missions
qui nous ont été assignées à travers le cahier charge, il serait important pour
nous de répartir les tâches dans le temps.

12
Gestion du projet
CHAPITRE
II

13
Introduction
La gestion de projet est une partie indispensable au bon déroulement de celui-
ci. Les compétences techniques de chacun sont à prendre en compte mais
une gestion de projet correcte est aussi capitale pour mener le projet à bien le
plus efficacement possible.
I. Planification du projet
Dans cette partie nous présenterons le diagramme de Gantt qui nous a permis
de modéliser la façon dont nous devrions nous organiser pour effectuer les
taches dans le temps. Voir figure :
Figure 3 : Planification du projet
II. Découpage en tâches
Afin de mener à bien notre projet, il nous a fallu déterminer les différentes
tâches, les découper et les répartir équitablement entre nous.
Pour cela, nous avons, pendant les quatre premières semaines, pris
connaissance du sujet, établi les fonctions nécessaires pour remplir les besoins,
fait des recherches sur les outils que nous pouvions utiliser et déterminé les
tâches à accomplir.
Notre projet est composé de 2 parties essentielles : l’étude comparative des
outils de supervision, choix de la solution et les tests.

14
Les quatre principales tâches que nous avons déterminées et qui vont être la
base du projet sont les suivantes :
- Etude de l’existant : découvrir les outils de supervision existants dans
le marché.
- Etude de cas : comparer entre tous les outils et sortir avec le bon
choix.
- Effectuer des tests.
- Exploiter la solution dans un cas réel.
Conclusion
Au final, nous avons beaucoup travaillé pendant les séances et hors des
séances. Nous avons compris qu’il est important d’évaluer les connaissances
de chacun, et de faire un point sur nos tâches régulièrement.
Notre organisation était plutôt bonne. Il y avait une bonne cohésion de groupe.
Nous avons appris à gérer un projet et à faire face aux difficultés ensemble.
A la suite de cette partie, nous essayerons de présenter les grands principes et
notions de monitoring applicatif.

15
Monitoring
CHAPITRE
III

16
Introduction
Le monitoring, monitorage en français mais on gardera monitoring, désigne le
fait de surveiller, ou garder un œil sur. Cependant, le fait de surveiller quelque
chose revient à connaître son état actuel mais aussi l'historique de ses états
passés, par l'intermédiaire de valeurs (UP/DOWN) et de données chiffrées des
pourcentages par exemple.
I. Qu’est-ce que la supervision
Depuis quelques années la surveillance des infrastructures informatiques est
devenue incontournable. Cette manière de surveiller apporte la possibilité
d’avoir une vue globale sur l’état de l’infrastructure mais aussi sur les possibilités
d’auditer les systèmes, surveiller la disponibilité et les performances et alerter
les responsables.
Une supervision consiste à mesurer diverses métriques permettant de
renseigner les responsables sur la qualité d’un service. Un système de
supervision est composé de fonctions qui consistent à mettre en place des
indicateurs d’état sur une infrastructure informatique.
Il existe deux enjeux majeurs à noter :
- Garantir la disponibilité et les niveaux de service du système en cas
de panne ou de baisse des performances
- Tenter de prévenir l'administrateur des différents problèmes et au
besoin assurer une remontée des informations afin de garantir une
durée d'intervention minimale
II. Que peut-on superviser
La supervision est un vaste domaine de l'informatique qui reprend plusieurs
activités dont les principales sont :
- Surveiller
- Visualiser
- Analyser
- Piloter
- Alerter
La supervision informatique permet de superviser l’ensemble du Système
d’Information de l’entreprise.
 Supervision réseau et matérielle :

17
o Commutateurs et routeurs : disponibilité, interrogation des
sondes, alertes.
o Serveurs : disponibilité, interrogation des sondes matérielles,
alertes.
o Onduleurs : Disponibilité, Charge, Etat.
o imprimantes : disponibilité, état de l’imprimante et des
consommables.
 Supervision des systèmes :
o Commutateurs : utilisation des ressources, métrologie.
o Serveurs : utilisation des ressources.
 Supervision des applications et services :
o Disponibilité.
o Cohérence des réponses aux interrogations.
o Performances.
III. Pourquoi superviser
L’infrastructure informatique comprend de nombreux systèmes qui peuvent
mal fonctionner. Si un problème n’est pas détecté au bon moment, il peut
engendrer des sérieux dégâts à l’entreprise vu que le business dépend
fortement du système informatique. Avec un superviseur nous avons la
possibilité d’anticiper une panne et la résoudre plus rapidement. Cela permet
aussi de surveiller la santé du système.
Prévenir en cas de problème et réduire les délais et coût des interventions sont
les enjeux principaux. Une bonne supervision aide aux responsables
informatiques pour rendre des comptes, être au courant et corriger.
IV. Comment Superviser
Deux grandes méthodes s'opposent lorsque l'on parle de supervision.
- Le polling
- Le heartbeat
Le Polling est un sondage réalisé périodiquement à intervalle de temps régulier
par un superviseur.
 Avantages de polling :
- A l'initiative du superviseur
- Permet un véritable suivi
 Inconvénients de polling :
- Des échanges pour rien

18
- Temps de réaction
- Possibilité de ne pas voir certains changements
Le HeartBeat est un signal émis par un équipement à chaque changement
d'état.
 Avantages de HeartBeat :
- Des échanges si nécessaires
- Temps de réaction
- Tous les changements d'états sont remontés
 Inconvénients de HeartBeat :
- Suivi moins complet
- A l'initiative de l'équipement actif
En conclusion il n'y a pas de meilleure ou de moins bonne solution, mais il faut
penser à orienter le concept en fonction du projet que l'on veut mener.
Conclusion
Après avoir découvrir le monde de monitoring et de comprendre sa notion, ses
objectifs ainsi que ses méthodes, c’est le temps maintenant de mettre le point
sur les besoins à traiter de notre et ses spécifications.

19
Analyse des besoins
et spécifications
CHAPITRE
IV

20
Introduction
Une bonne présentation d’un sujet, dans ses objectifs et ses besoins, a toujours
facilité la compréhension et éclaire sur les différentes tâches à accomplir dans
le cadre d’une réalisation d’un projet.
Une fois avoir compris ce que c'est que la supervision, ces grands principes et
techniques ou méthodes, avoir définir le cahier de charge et repartie les
tâches de réalisations, l'étape suivante serait l'analyse des besoins.
Cette étape qui peut s'avérer assez longue est une phase préparatoire qui va
mener à bien la réussite du projet. En effet, les statistiques ont montré que dans
70 % des cas d'un échec de projet était dû à une mauvais analyse des besoins
ou une analyse des besoins bâclée ou quasi inexistante et non pas à cause
d'un mauvais développement ou une mauvaise conception.
I. Objectif du projet
Dans le cadre de notre projet de fin de la deuxième année à l’ENSIAS, on nous
a confié d’exploiter une solution de monitoring applicatif afin de superviser une
architecture applicative d’une startup.
Les missions qu’on nous a confiées sont sous forme d’étape à réaliser :
o Télécharger et installer graphite
o Télécharger et installer l'architecture sur la figure
o Intégrer graphite avec les composants de l'architecture pour les
superviser.
o Déployer la solution dans un vrai environnement en PROD.
Effet, en début du Mai 2017, notre encadrant Mr. Karim BAINA nous a donné le
libre choix de l'outil de supervision, cela impliquait que GRAPHITE n'était pas
obligatoire et qu'on pouvait utiliser d'autre outils de supervision que GRAPHITE.
Cette dernière modification ne concernait que la première étape à savoir
"télécharger et installer graphite" et non les autres instructions.
Nous effectuerons pour cela une étude comparative des outils de supervisions
et ensuite ferons un choix justifié de l’outil.
Pour ce qui concerne : " télécharger et installer l'architecture sur la figure ",
certains matériels et application ne peuvent être à notre porté, cependant
nous avons installé ceux qui pouvaient être accessible par nous.
Les applications et serveur installés seront analysés dans la partie de l’étude du
cas de simulation.

21
II. Etude des composants de l'architecture réels
La solution qu'on doit proposer doit permettre de bien superviser les
applications en suivant leurs traces, soit en analysant les fichiers de
journalisation les logs ou en envoyant des signaux afin de savoir l’état des
serveurs en temps réel.
En cas d’une anomalie, notre solution doit permettre efficacement d’avertir les
intéressés avant que les serveurs tombent qui va engendrer le blocage de
l’application et cela dans différentes manières à savoir l’envoie d’un mail, un
sms, appel téléphone, etc.
La figure ci-dessous présente l’architecture applicative réelle a supervisée.
Figure 4 : Architecture réelle a supervisée
 Application server : Jboss
Jboss Application Server est un serveur d'application JAVA EE développé à
partir de 1999 par un français Marc FLEURY. Ce serveur est écrit en Java et
distribué sous licence GNU LGPL. Il permet de simplifier le déploiement et
optimiser les performances des applications dans tous les types
d'environnements.
 Server Web : Apache

22
Apache est un serveur HTTP créé et maintenu au sein de la fondation Apache.
C'est le serveur HTTP le plus populaire du World Wide Web. Il est distribué selon
les termes de la Licence Apache.
 Information layer : PostgreSQL
PostgreSQL est un système de gestion de base de données relationnelle et
objet SGBDRO. C'est un outil libre disponible selon les termes d'une licence de
type BSD.
Ce système est concurrent d'autres systèmes de gestion de base de données,
qu'ils soient libres comme MariaDB, MySQL et Firebird ou propriétaires comme
Oracle, Sybase, DB2, Informix et Microsoft SQL Server.
 Entreprise service bus : MuteSoft
Un Enterprise Service Bus s'agit d'un ensemble de règles et de principes qui vont
permettre d'intégrer plusieurs applications du système d’information,
indépendamment des différentes technologies utilisées, qui pourront
communiquer entre elles en s'adressant uniquement à un bus. Donc c’est une
plateforme d’intégration qui permet aux développeurs de connecter
rapidement et facilement des applications, ce qui leur permet d'échanger des
données. Les outils ESB disponibles sur le marché tels que Mule ESB par MuleSoft,
Apache ESB, Sonic ESB.

23
 loT physical layer :
C’est la couche physique de l’architecture qui interagît
directement avec les matérielles à savoir les caméras de
supervision.
III. Etude du cas de simulation
Pour l'architecture présentée ci-dessus, nous avons pu créer deux serveurs pour
effectuer un test sur un environnement de production réels :
 Apache : Le serveur web qui va nous permettre de d’héberger une
application de test à superviser.
 PostgreSQL : La base de données utilisée pour assurer la persistance des
données.
 Un PC : sous Ubuntu et un autre sous Windows
Conclusion
En résumé, nous pourrons affirmer que l’analyse et la spécification des besoins
nous ont permis d’avoir tous les informations nécessaires pour la réalisation de
ce projet.
Cependant, il serait important pour nous de connaitre et de découvrir ce
monde de supervision en effectuant une étude comparée des outils de
supervision existants puis ferons un choix d'outils avant de passer à la réalisation.

24
Etude comparative
CHAPITRE
V

25
Introduction
Une fois l'environnement de travail étudié, il fallait trouver des solutions pour
répondre à notre problématique. Intervient alors l'étape des technologies
existantes dans le domaine étudié. Cette démarche nous a permis de définir
les technologies à utiliser et à appliquer.
Une bonne méthode pour justifier un choix étant souvent de fournir une analyse
comparée des possibilités, nous présenterons donc nos choix d’outils.
I. Les différentes solutions
Voyons à présent les solutions disponibles concernant le domaine de la
supervision.
Il faut savoir qu'il existe des dizaines de solutions dédiées au Monitoring, le
principal critère de choix réside dans les différents cas d'utilisation. Dans cette
partie sont présentées septe solutions parmi les grands noms du Monitoring, à
savoir : Zabbix, Cacti, Nagios, Centreon, Graphite, Shinken et Nagios XI. Ainsi
un comparatif sera établi en définissant correctement quelle solution sera la
plus appropriée en termes de supervision et non de métrologie.
1. Zabbix
Zabbix est une application libre open source de supervision des systèmes et
des réseaux. Par sa polyvalence, Zabbix peut superviser et vérifier les statuts
d'une multitude de services réseaux ou systèmes, ce qui fait de lui un outil
complet proposant des fonctionnalités relatives à la supervision (alertes,
mesures, actions sur conditions, etc). Le principal reproche vient de l'aspect
graphique où dans certains cas la lisibilité laisse à désirer. Certains lui
reprochent également son interface web dite un peu vieillotte et la prise en
main initiale n'est pas forcément intuitive.
a. Avantages
o Facilité d'installation
o 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
o Une entreprise qui pousse le développement, et une communauté
croissante
o Une interface vaste mais claire
o Compatible avec MySQL, PostgreSQL, Oracle, SQLite

26
b. Incovénients
o Interface est un peu vaste, la mise en place des Template n'est pas
évidente au début, nécessite un petit temps de formation
o Commence à être connu mais pas encore auprès des entreprises
o Peu d'interfaçage avec d'autres solutions commerciales
o L'agent zabbix communique par défaut en clair les informations,
nécessité de sécuriser ces données via VPN par exemple
Figure 5 : Interface de Zabbix
2. Cacti
Cacti est un outil de monitoring qui a la particularité d'avoir une " Plugin
architecture" qui va lui permettre l'ajout de fonctionnalités grâce à
l'importation et à la configuration de plugins via l'interface web. L'aspect
supervision proposé ici ne sera pas aussi développé que dans les autres
logiciels (nagios par exemple), on notera par exemple l'absence de panel de
msesures, de groupes d'utilisateurs.
Donc Cacti reste un outil de métrologie intégrant de nombreuses possibilités
grâce aux plugins, avec la possibilité d'une mise en place de supervision mais
uniquement dans les cas les plus simples.
a. Avantages
o Interface beaucoup plus claire, elle permet également plus de modes
d'affichages et plus de possibilités de configuration
o On peut opter pour la performance ou la simplicité avec le choix du
moteur de récolte des données
o Présence d'une dizaine de plugins permettant d'étendre les
fonctionnalités

27
o Facilité de configuration et d’installation
b. Inconvénients
o Pas de gestion d'alarmes sauf avec un plugin nommé Thold
o Pas de gestion de panne
o Limité de base
o Peut mettre un certain temps à générer les graphs
Figure 6 : Interface Cacti
3. Nagios
Nagios est ce que l'on appelle un ordonnanceur, c'est-à-dire qu'il va lancer les
différents tests de supervision, appelés contrôles, sur les hosts et services. Il reste
l'outil de supervision le plus utilisé à l'heure actuelle, sa configuration sous forme
de fichiers, peut s'avérer vite repoussante mais en fait cependant un candidat
idéal pour l'automatisation. L'inconvénient de Nagios reste son IHM 1 très
basique. Il faut avouer que son interface ne donne pas spécialement envie
d'être consultée, en effet au-delà de la pertinence de l'information, il faut de
la compréhension et de l'interprétation. C'est sur ce constat que vient se
greffier la prochaine solution décrite : Centreon.
a. Avantages
o Grosse communauté et bonne réputation
o Très puissant et modulaire assez de plugins qui permettent d'étendre les
possibilités agents comme zabbix, reporting amélioré, etc
o Une solution complète permettant le reporting, la gestion de panne et
d'alarmes, gestion utilisateurs, ainsi que la cartographie du réseau
o Beaucoup de documentations sur le web
b. Inconvénients

28
o Difficile à installer et à configurer
o Interface non ergonomique et peu intuitive
o Nagios n'affiche pas de graphs en natif
o Pour avoir toute les fonctionnalités il faut installer des plugins de base
c'est assez limité
Figure 7 : Interface de Nagios
4. Centreon
Centreon, une interface à Nagios. Première précision à apporter, le coeur de
Centreon est basé sur Nagios. Centreon propose une interface web différente
de celle de Nagios et y ajoute des fonctionnalités (génération de la
configuration de Nagios, stockage des données de performance, interface
ergonomique...). En résumé, Centreon est considéré comme un outil à part
entière même s’il est basé sur Nagios comme ordonnanceur. Il propose donc
au sein d'une même interface tout ce qui est nécessaire à la surveillance de
l'infrastructure et donc à faire de la supervision pure et dure. Malgré tout il ne
propose que le minimum concernant la métrologie, on ne pourra pas par
exemple remonter des informations orientées services comme celle d'une base
de données, que l'on pourrait avoir sous Cacti ou Munin
a. Avantages
o La robustesse et la renommée de Nagios
o Peut-être décorée du serveur Nagios et tourner tout seul sur un autre
serveur
o Une solution complète permettant le reporting, la gestion de panne et
d'alarmes, gestion utilisateurs, ainsi que la cartographie du réseau
b. Inconvénients

29
o Un peu plus lourd
o Un développement qui n'est pas encore en phase avec celui de Nagios,
parfois des problèmes de compatibilité
o Nécessite une petite formation car l'interface peut paraître complexe
Figure 8 : Interface de Centreon
5. Graphite
Le graphite est un outil de métrologie prêt pour les entreprises. En effet, les outils de
métrologie sont utiles pour mesurer et garder un historique des données de
performances des serveurs afin de les analyser en cas d’état dégradé, de
pouvoir comprendre tout ce qui se passe. Graphite est le plus utilisé et conseillé
comme outil de métrologie, il donne des graphiques assez compréhensibles
avec des périodes.
Les équipes utilisent graphite pour suivre les performances de leurs sites Web,
des applications, des services d'affaires et des serveurs. Il a marqué le début
d'une nouvelle génération d'outils de surveillance, ce qui rend plus facile que
jamais pour stocker, récupérer, partager et visualiser les données de séries
chronologiques en temps réel, qui est une séquence de valeurs recueillies à
intervalles réguliers, espacés uniformément.
En effet, le logiciel Graphite est séparé en deux activités :
 Le stockage des données de série chronologiques numériques
 Le rendu des graphiques de ces données
a. Architecture de graphite
Graphite fonctionne à l'aide de plusieurs composants Back-end et front-
end. Les composants Back-end sont utilisés pour stocker des données de
séries chronologiques numériques et les éléments Front-end sont utilisés

30
pour récupérer les données de mesure et éventuellement rendre les
graphiques.
Back-end :
o Carbon : Il fait référence à une série de démons qui composent
le back-end de stockage d'une installation de graphite. C’est un
service de haute performance qui écoute les nouvelles données
de séries chronologiques
o Whisper : C’est une simple base de données qui offre un
stockage rapide et fiable des données numériques au fil du temps
Font-end :
C’est Graphite-web qui est une application web Django pour la création
de graphique qui fonctionne sous un serveur Web Apache ou Nginx.
Les métriques entre dans la pile via le Carbon service, qui écrit les données
dans la base de données Whisper pour le stockage à long terme. Les utilisateurs
interagissent avec l’interface Web graphite, qui interroge à son tour avec
carbone et Whisper afin d’avoir les données nécessaires pour construire les
graphiques demandés.
Figure 9 : Architecture de Graphite
Graphites en lui-même n'a pas de moteur de métriques, il ne recueille pas
des données et il ne fait pas de l’alerte, il ne fait que recevoir, stocker et
redistribuer les données. Mais il y a des outils complémentaires qui
peuvent nous aider à contourner ces problèmes.

31
Les outils qui fonctionnent avec Graphite :
Outils
Collection Brubeck – Bucky – Collectd – Collectl – Diament –
Ganglia – Graphite-pollers – HoardD – sFlow hôte
– jmx2graphite – jmxtrans – Logster – Sensu –
snort2graphite - Logstash
Expéditeur Antidévireur - carbone-c-relais - carbone-relais-ng -
evenflow - Grafsy - Graphite-Newrelic - Graphite-
relais - Graphios - Graphout - Grockets - Gruffalo -
Ledbetter - conduit à graphite - Polymur - statsd
Visualisation Chabron – Descartes – Crépuscule – Luciole –
Gdash – Girafe – Grafana – Graphène – Graphite
dashboardcli – Graphite-Tattle – Graphiti –
Graphitoid – Graphitus – Graphsky – Graphique
Index – Hubot – Leonardo – Orion – Crayon –
Cibles-io – Tasseo – Terphite – Tessère –
TimeseriesWidget
Alertement Cabot – graphite balise - graphite à zabbix - icinga -
Moira - vue arrière - Solide comme un roc - Seyren -
Shinken
Stockage alterne BigGraphite - Ceres - cyanite - InfluxDB - KairosDB -
OpenTSDB
b. Outils qui fonctionnent avec Graphite
Logster
Logster est un outil pour lire des fichiers journaux et générer des métriques de
sorties configurables comme Graphite. Il est idéal pour visualiser les tendances
des événements qui se produisent dans les journaux d'application, système ou
d’erreur.
Cet outil est composé d’un ensemble de classes d'analyse syntaxique qui sont
écrits pour répondre au format de journal spécifique. Les classes d'analyseur
lisent essentiellement une ligne de fichier journal, appliquent une expression
régulière pour extraire des données utiles à partir des lignes qui vous intéressent,
puis agrègent ces données dans des mesures qui seront soumis à la sortie

32
configurée. Donc on a besoin d’un parseur pour chaque type de fichier journal
écrit en python.
Collectd
Collectd est un démon qui rassemble des mesures et statistiques provenant
de diverses sources, par exemple le système d'exploitation, des applications,
des fichiers journaux et des périphériques externes, il stocke ces informations ou
le rend disponible sur le réseau.
Il est facile à configurer dans chaque serveur à surveiller et possède un nombre
élevé de plugins, par exemple ‘write_graphite’ qui est utilisé pour envoyer des
données au serveur Graphite.
Figure 10 : Architecture de collectd
Jmxtrans
Jmxtrans est un outil de surveillance puissant et populaire pour les applications
basées sur Java. Il nécessite très peu de configuration. Il se connecte à une
machine virtuelle Java via JMX, collecte un certain nombre de métriques
applicatives de la JVM, du serveur d’application, etc. Il envoie les données au
back-end. Très souvent, un back-end de graphite est utilisé.

33
Figure 11 : Architecture de JMXTrans
Logstash
Logstash est Un outil open source qui gère les événements et les journaux.
C’est un moteur de collecte qui rassembler des statistiques sur les journaux et
les envoyer à Graphite. Il possède Plus de 200 plugins.
Sur le serveur qu’on veut surveiller, on configure un agent Logstash simple qui
lit le fichier journal, le filtre avec quelques filtres qu’on écrit, puis expédie ces
métriques à Graphite.
Figure 12 : Architecture de Logstash
Sensu
Sensu est un cadre de surveillance distribué pour toute entreprise, qui exécute
des vérifications de santé pour les applications ou services et collecte des
métriques sur tous les clients Sensu connectés, qui sont transmis à un serveur
Sensu. Il possède un grand nombre de plugins communautaires. Ça peut être
intégré avec Graphite en lui envoyant les métriques.

34
Figure 13 : Architecture de Sensu
Snort2graphite
Snort2graphite lit, analyse et envoie toutes les métriques récupérées de fichier
snort.stats à un serveur Graphite. Ce fichier snort.stats est généré par Snort, qui
est un système de détection d'intrusion de réseau open source capable
d’analyse de trafic en temps réel et enregistrement de paquets sur IP Réseaux.
Il peut effectuer une analyse de protocole, une recherche / correspondance
de contenu et peut être utilisé pour détecter une variété d'attaques et de
sondes.
sFlow hôte
L'agent Host SFlow open source est un complément exact de Graphite, qui
fournit un agent léger et portable qui expédie des mesures standard à partir
d'une grande variété de systèmes. Il exporte des métriques de performance
de serveur physique et virtuel à l'aide du protocole sFlow. Le déploiement
d'agents sFlow hôte avec un collecteur de graphite offre une solution de
surveillance complète et hautement évolutive.
Figure 14 : Shéma de sFlow hôte
Le schéma montre les composants essentiels de la solution. Les agents Host
sFlow envoient continuellement des mesures au collecteur Graphite. Le script

35
sflow2graphite convertit les données binaires sFlow en messages textuels basés
sur le texte et les soumet au serveur Graphite.
HoardD
HoardD est un outil pour envoyer des métriques à Graphite. Il envoie des
données de serveur telles que les statistiques de disque, le réseau, la CPU, qui
peuvent ensuite être utilisées pour des graphiques à l'aide d'une application
Web Graphite.
Les données sont recueillies à l'aide d'une série de scripts écrits en café-script.
Il existe d'autres projets qui font de même : collectd a quelques plugins pour
envoyer des données au graphite et diamond-gmond est un démon python
qui fait exactement la même chose que celui-ci.
Grafana
Grafana est un tableau de bord compatible avec de nombreuses sources de
métriques comme Graphite. Il fournit un moyen puissant pour visualiser ses
données et est entièrement configurable. Il est développé en Go et Javascript.
C’est l'une des meilleures interfaces disponibles pour Graphite.
Figure 15 : Architecture de Grafana
Seyren
Seyren est un outil d’alerting dédié à Graphite, il s’intègre très bien au graphite.
Il prend en charge les canaux de notification suivants : Email, Flowdock,
HipChat, HTTP, Hubot, IRCcat, PagerDuty, Pushover, SLF4J, Slack, SNMP, Twilio.

36
Cabot
Cabot est une plate-forme de surveillance qui permet d’envoyer des alertes
par téléphone, sms ou email à l’équipe en service si ces services commencent
à se déformer ou à descendre. On peut utiliser les données que vous poussez
déjà à Graphite à générer des alertes, plutôt que de mettre en œuvre et de
maintenir un tout nouveau système de collecte de données.
Graphite-to-Zabbix
Cet outil permet de gérer les alertes en fonction des métriques de graphite. Il
fonctionne comme proxy entre graphite et zabbix. Il utilise le graphite comme
source de données et zabbix comme système d'alerte.
L'idée de base est programmée cronjob pour exécuter un script, qui demande
au serveur zabbix, obtient une liste filtrée de métriques surveillées, fait des
requêtes appropriées au graphite et envoie une métrique à zabbix.
6. Shinken
Shinken est récent et en plein de développement et il y a du suivi, il consiste en
une refonte complète du cœur de Nagios en Python, lui apportant une
nouvelle architecture plus souple et plus facile à maintenir que le daemon
actuel et il est carrément mieux optimisé. Contrairement à Nagios qui gère tout
le processus avec un seul service, Shinken sépare les différentes taches en
plusieurs daemons (services) simples qui coopèrent afin de proposer les
mêmes fonctionnalités que Nagios.
Le principal avantage est que la solution est relativement rapide à
déployer, de plus les ajustements nécessaires pour avoir une supervision
plus précise peuvent se faire indépendamment du fonctionnement de
l’application ce qui permet de ne pas couper la supervision lors des
différentes interventions.
La solution dispose également d’autres avantages tels que la facilité de
mise en place d’architecture distribuée hautement disponible, des
meilleures performances que le Nagios classique. Presque 5 fois plus de
performances. Multiplateforme, il peut se tourner nativement sur GNU/Linux et
Windows. Il est même possible de mixer les deux dans une même architecture.
En plus de ça, Il existe plusieurs façons de configurer Shinken pour envoyer des
notifications. Voici quelques méthodes de notification possibles :
Email, Téléphone (SMS), Message WinPopup, Message instantané Yahoo, ICQ
ou MSN, Alertes audio, etc.
Shinken a été développé pour devenir une solution complète de supervision
mais à l’heure actuelle l’équipe préfère l’intégration des outils comme les outils

37
de métrologie à la place de tout développer dans le projet Shinken et l’intérêt
majeur est d’en faciliter la liaison, cela à travers le module Livestatus qui permet
de aux outil de métrologie, comme Graphite, de récupérer les données depuis
Shinken.
Shinken a mise beaucoup sur son architecture qui le différencie des outils de
supervision, Il est composé de six démons (daemon - service) par exemple, le
démon Broker peut exporter des données de métrologie vers Graphite via le
module Livestatus.
7. Nagios xi
Nagios xi est l’une des solutions de supervision d’infrastructures réseaux parmi
les plus puissantes du marché. Développée afin de combiner la flexibilité et
l’adaptabilité, XI permet de gérer des problématiques de supervisions
complexes de manière simples, tout en conservant son efficacité. Allant au-
delà des fonctionnalités de bases de supervision, Nagios xi est une solution
d’alerte et de contrôle qui fournit à votre entreprise une vue complète de son
infrastructure informatique, afin d’anticiper et de résoudre des problèmes
pouvant affecter celle-ci. Nagios Xi comporte de nombreux avantages,
notamment :
o Supervision complète de l’environnement informatique, tous les
composants de votre infrastructure sont pris en charge à savoir les
applications, services, systèmes d’exploitation, protocoles réseau,
paramètres des systèmes et de l’infrastructure réseau.
o Utilisant Nagios Core Engine 4, Nagios XI garantie des performances
monitoring efficaces et évolutives. L’ajout de worker processes dans
l’architecture centrale permet de maximiser les ressources des serveurs
et de facilement surveiller les infrastructures réseaux.
o Apporte une vue centralisée de l’ensemble de processus informatiques.
Des tableaux de bords complets fournissent instantanément l’accès à
de nombreuses informations permettant un meilleur contrôle de
l’infrastructure. Un affichage riche et varié donne la possibilité à
l’utilisateur de visualiser les informations qui lui seront le plus utiles en
détails.
o Information en temps réel, des alertes détaillées sont envoyées aux
départements informatiques, aux actionnaires, etc, Via mail ou SMS, afin
de rapidement résoudre de possibles problèmes.
o Une interface graphique puissante permet la personnalisation de la mise
en page, du design et des préférences pour chaque utilisateur, donnant
aux clients et collègues la flexibilité qu’ils veulent.

38
o Une interface web de configuration permet aux administrateurs de
donner le contrôle des configurations et des préférences de supervision
aux utilisateurs finaux. Des assistants de configuration performants
permettent aux utilisateurs de mettre en place de la supervision sur de
nouveaux équipements, le tout sans avoir besoin de connaissances
avancées dans le domaine.
II. Analyse des outils
Un outil de supervision doit répondre aux critères suivants :
- Des mécanismes pour déterminer l'état d'une ressource/processus
- Une console de monitoring
- Des remontées d'alertes
La supervision se caractérise d'ailleurs par son système d'alerte, conséquence
directe de la vision à l'instant t. On peut alors avertir l'administrateur si un
système passe de UP à DOWN et inversement. Au contraire, dans le concept
pur de la métrologie, le système d'alerte n'est pas pris en compte car la
récupération des valeurs/charges n'est pas forcément faite à l'instant t.
À l'inverse de Nagios qui est bien une solution de supervision, des solutions
comme graphite, Munin ou Cacti ne possèdent aucune fonctionnalité
permettant de connaître l'état UP/DOWN d'un service à l'instant t, mais sont
capables de tracer un ensemble de graphiques afin de retracer la charge de
différents services/serveurs et de leurs ressources.
Enfin, les outils comme graphite, Munin et Cacti ne sont pas des outils de
supervision mais des outils de métrologie.
Voici ci-dessous un tableau comparatif entre les outils de supervision qui reste :

39
Performance Plateforme
utilisatrice Extensibilité
Evolution Configuration
simple
Création
de graphs
Zabbix Moyenne Win + Linux
Moins de
modules
Évolutive
Oui Oui
Nagios Haut Linux Trop de plugin Moins évolutive
Non Non
Centreon Moyenne Linux
Moins de
modules
Évolutive
Oui Oui
Shinken Haut Win + Linux Trop de plugin
Communauté très
actif
Oui Oui
Nagios XI Haut Win + Linux Trop de plugin
Evolutive
(Communauté très grande :
forum, vidéos, site-web …)
Oui Oui
Figure 16 : Tableau comparatif des outils de supervision
III. Choix de l’outil de surveillance
De ces dernières années, le monde informatique retiendra que c'est la
recherche de fiabilité et de la réduction des coûts qui dessinent l'avenir du
système informatique en entreprise. La supervision est un des domaines qui
permet de répondre à ces deux besoins. Et cela du fait que ce domaine
apporte une visibilité simplifiée et une possibilité de centralisation de
l'information.
Comme dis dans les parties précédentes, la mise en place d'un tel outil doit
être réfléchie et repose aussi sur les besoins exprimés. On retiendra que le
critère suivant influent sur la mise en place d'un outil de supervision :
- La taille de l'infrastructure à gérer
- Le niveau de qualité de service voulu
- Le besoin de reporting vit à vis du décisionnel
Notre choix donc se porte, après une bonne analyse, sur Shinken et Nagios XI.
En plus de leurs qualités mentionnées dans le tableau, il est reconnu par
graphite comme une référence en termes de surveillance et très compatible
avec ce dernier.
Conclusion
Tous projets informatiques nécessitent la connaissance des outils à utiliser et
nous avons jugé bon de choisir les outils énoncés précédemment.

40
Réalisation et mise en
œuvre
CHAPITRE
VI

41
Introduction
Dans cette partie, on va vous présenter notre environnement de travail et les
outils utilisés afin de mettre en place notre solution de supervision. Après vous
allez voir un ensemble de tests.
I. Les outils utilisés
La phase de réalisation et de mise en œuvre a nécessité l'installation de
plusieurs outils dont voici un aperçu :
1. Support d’installation et de développement
o VMware Workstation 10 : machine virtuel contenant les PC
o VirtualBox : Machine virtuelle contenant les serveurs
o Linux Debian : système d’exploitation dans lequel sont installés les
serveurs
o NetBeans : pour développer une application bureau pour alimenter la
base de données, il s’agit d’un plus de notre part.
2. Langage utilisé pour le développement applicatif
o PHP pour le site web
o JAVA pour l’application bureau
II. Réalisation
Nous avons créé 4 serveurs, deux d’entre eux concernent l’architecture
(Serveur web Apache et PostgreSQL) et les deux autres sont des serveurs pour
la supervision. Nous avons aussi développé deux applications :
o Un site web hébergé par le serveur web Apache et qui affiche les
données contenues dans la base de données PostgreSQL
o Application est une application bureau pour remplir la base de données
PostgreSQL.
1. Serveur Web Apache
Ici, le serveur web Apache héberge un site web développé en PHP et ce
dernier est alimenté par une base de données de type PostgreSQL.
Voir capture du server :

42
Figure 17 : Serveur Apache
Figure 18 : Page d'accueil hébergée par apache
Voici un aperçu du site web hébergé par Apache :

43
Figure 19 : Postgresql
Figure 20 : Application bureau de test
2. Serveur PostgreSQL
Le serveur PostgreSQL contient une base de données nommé db_pfa dans
laquelle est inscrite une table des auteurs. Cette table est remplie par une
application bureau développé par nous.
Voici un aperçu de l’application Bureau permettant d’alimenter la base de
données sur PostgreSQL.

44
Figure 21 : Serveur Shinken
Figure 22 : WebUI de Shinken
3. Serveur Shinken
Le serveur Shinken servira quant à lui à monitorer les applications et serveur
d’applications.
Voici un aperçu web de shinken, elle se nomme le webUI de shinken et elle
permet d’afficher l’état des serveurs et applications en temps réels :

45
Figure 23 : Serveur Nagios XI
Figure 24 : WebUI de Nagios XI
4. Serveur Nagios XI
Le serveur Nagios XI servirait également à la supervision des serveurs
d’applications et application mais cette version de Nagios est complète et
contient un outil de métrologie pour les graphes.
Voici un aperçu web de Nagios XI, elle se nomme le webUI de Nagios XI et elle
permet d’afficher l’état des serveurs et applications et les monitorés
également en temps réels :

46
Figure 25 : Monitoring de postgresql par nagios xi
Figure 26 : Graphe de monitoring par Nagios XI
Voici un exemple de supervision du serveur PostgreSQL :

47
Apport du projet
CHAPITRE
VI

48
Introduction
Ce projet est une bonne expérience, il nous a apporté beaucoup, tant au
niveau technique qu’en terme de gestion de projet.
I. Apports scientifiques et techniques
Ce projet nous a permis de découvrir le monde de supervision applicatif, un
monde complexe mais passionnant de par les débouchés auxquels il mène.
Nous avons également acquis de nouvelle notion et connaissances. Les acquis
de ce projet nous serviront dans le futur.
II. Apport sur la gestion de projet
Nous avons confirmé le fait que la communication est primordiale lorsque l’on
travaille ensemble. Un dialogue par mail ou messagerie instantanée ne
remplacera jamais une entrevue en face à face.
Il faut toujours réussir à motiver l’autre par les idées que l’on apporte et réfléchir
avant de se lancer dans une voie.
III. Apport sur la formation pédagogique
Ce projet nous a permis de consolider nos connaissances sur le monde de
supervision applicatif.
Nous sommes satisfaits d’avoir choisi ce sujet car nous répondons à une
problématique qui est celle de l’entreprenariat.
IV. Apport personnel
Chaque membre de l’équipe a eu des apports personnels durant le projet.
 NIDABAHIM YOUSSEF :
Expérience intéressante qui m’a permis de coréaliser un projet abouti et qui
m’a appris à être plus à l’écoute des autres. Que du positif, expérience à
renouveler.
 KANGA DOMINIQUE BERNARD :
Bon travail, bonne ambiance de groupe. Que d’émotion et de souvenir
inoubliable, très bonne expérience à renouveler.

49
Conclusion
Nous sommes en général satisfaits de tous ce que nous avons appris à travers
ce projet.

50
Conclusion et Perspective
De l’avis général, nous avons consolidé nos connaissances générales et appris
à faire de monitoring. Nous sommes globalement satisfaits de ce que nous
avons réalisé.
On a appris qu'au sein d'une entreprise on ne peut se permettre de tester une
solution dont on ne connait pas les résultats ni l'efficacité, il faut se baser sur
l'existant.
Au niveau de la gestion du projet en équipe, nous avons réussi à bien nous
répartir les tâches afin de réaliser nos objectifs dans les temps et l'ambiance
générale du groupe était très bonne. Une bonne expérience à renouveler.
Et nous profitons pour remercier le corps enseignant de l’Ecole nationale
supérieure d’informatique et d’analyse des systèmes ENSIAS qui ont été tout
temps ouvert pour nous et qui nous ont toujours encouragés et apporter la
connaissance nécessaire pour nos différentes recherches. Nous n’oublions pas
de remercier notre encadrant Mr. Karim BAINA qui nous a pousser à découvrir
ce monde de monitoring à travers son apport pédagogique.
Nous envisageons améliorer le travail en y apportant d’autres ingrédients et en
faisant des tests en cas réel en prod.

51
Webographie
Outils de supervision :
http://igm.univ-
mlv.fr/~dr/XPOSE2010/supervision/conclusion_mise_en_place.html
Shinken :
https://wiki.monitoring-fr.org/shinken/shinken-work
http://shinken.readthedocs.io/en/latest/
Installation de Shinken :
http://shinken.readthedocs.io/en/latest/02_gettingstarted/installations/shinke
n-installation.html
Nagios XI :
https://www.youtube.com/watch?v=ZkteFpKooxw&list=PLRtTUgsucZH6v4LDhl
UzgyspewltATeUO
Installation de Nagios XI :
https://www.nagios.com/downloads/nagios-xi/linux/manual/
https://assets.nagios.com/downloads/nagiosxi/docs/Installing-Nagios-XI-
Manually-on-Linux.pdf
Graphite :
http://graphite.readthedocs.io/en/latest/overview.html

MONITORING APPLICATIF

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à MONITORING APPLICATIF

Similaire à MONITORING APPLICATIF (20)

MONITORING APPLICATIF