Rapport stage onee-be_2

Université Mohammed V-Agdal
Ecole Supérieure de Technologie-Salé
Département : Informatique
Filière : Administration Réseaux Informatiques
Rapport de stage :
La mise en place d’un outil de
supervision réseau : ‘NAGIOS’
Elaboré par : Mounir KAALI
Effectué au sein de : ONEE-Branche Eau
Dans le la division de Réseaux et Télécoms.
Au service de l’ingénierie.
Encadrant du stage: Mme Houda TAHRI
Tutrice de l’ESTS : Mme Naoual BERBICHE
Année universitaire 2013/2014

Dédicaces ONEE -Branche Eau
i
Dédicaces
C’est avec gratitude et développement total que je tiens à dédier ce rapport
A mon honorable père, Ma respectueuse mère qui n’ont jamais cessé de me faire
des sacrifices de toutes nature pour me permettre de suivre mes études dans de
meilleurs conditions.
A mes Professeurs qui ont déployés tous leurs efforts pour me préparer à
affronter la vie professionnelle.
A tous mes Amies
Aussi, à tous ceux qui m’ont soutenu par leurs orientations, leurs conseils durant
la réalisation de ce travail, qu’ils trouvent ici l’expression de ma grande
reconnaissance et l’assurance de mes profonds respects.
A toutes ces personnes que j’ai senti redoutable de leur dédier ce modeste
travail en terme d’amour et de profonde gratitude.
A tous ceux qui sont toujours dans mes pensées.
Mounir KAALI

Remerciements ONEE -Branche Eau
ii
Remerciements
Ce travail a été réalisé à l’Office National de l’Electricité et de l’Eau. Mes remerciements vont
à l’endroit de tout le corps administratif et professoral qui a assuré mon stage, notamment
à:
 La direction de contrôle de gestion et système d’information.
 La division Réseaux et Télécoms.
 Le service ingénierie.
 Mme Houda TAHRI ma encadrant, pour sa disponibilité, son soutien et ces
renseignements enrichissantes.
 Tous les personnels qui m’ont formé au long de cette expérience professionnelle
et grâce à leurs compétences, patience et leurs soutiens
Je remercie également Mme Naoual BERBICHE ma professeur et ma tutrice de l’école qui m’a
encouragé et m’a conseillé pendant la période de stage sans oublier ses bonnes directives.
Je tiens aussi à remercier Mr le directeur de notre Ecole, mes très profonds remerciements à
mes professeurs et à ma famille précisément mes parents qui ont confiance à moi.
Enfin mes reconnaissance ensuite à nos proches, amis et à toutes les personnes de bonne
volonté, qui m’a aidé tout au long de mon parcours.
MERCI BEAUCOUP

Table des matières ONEE -Branche Eau
iii
Table des matières
Dédicaces.............................................................................................................................. i
Remerciements................................................................................................................. ii
Table des matières ......................................................................................................... iii
Liste des figures................................................................................................................vi
Introduction................................................................................................................................. 1
Partie 1 : Présentation de L’ONEE-Branche Eau ............................................................................. 2
1.1 Fiche Technique de L’ONEE-Branche Eau...................................................................................... 2
1.2 Organigramme de L’ONEE-Branche Eau........................................................................................ 2
1.3 Historique de L’ONEE- Branche Eau ............................................................................................. 3
1.4 Les Activités de l’ONEE- Branche Eau............................................................................................ 3
1.4.1 Les activités principales :........................................................................................................ 3
1.4.2 Les Activités particuliers :....................................................................................................... 4
1.5 La structure administrative du l’ONEE- Branche Eau.................................................................... 4
1.6 La direction contrôle de gestion et système d’information......................................................... 5
1.6.1 Organigramme de direction contrôle de gestion et système d’information ........................ 5
1.7 Les missions de L’ONEE-Branche Eau............................................................................................ 6
Partie2 : Présentation du sujet et de son concept.......................................................................... 7
2.1 Objectifs......................................................................................................................................... 7
2.1.1 Cadre et besoins..................................................................................................................... 7
2.1.2 Cahier des charges.................................................................................................................. 7
2.1.3 Réseau à superviser................................................................................................................ 8
Partie 3 : La supervision Réseau.................................................................................................... 9
3.1 Introduction à la supervision et à la métrologie. .......................................................................... 9
3 .1.1 La métrologie......................................................................................................................... 9
3.1.1.1 Définition générale.......................................................................................................... 9
3.1.1.2 Dans le domaine des télécommunications ..................................................................... 9
3.1.2 La supervision....................................................................................................................... 10

iv
3.1.2.1 Définition....................................................................................................................... 10
3.1.2.2 La supervision.. Pourquoi ? ........................................................................................... 10
3.2 Intérêt de la supervision et de la métrologie.............................................................................. 11
3.2.1 Être alerté en temps réel...................................................................................................... 11
3.2.1.1 Les problèmes sont inévitables..................................................................................... 11
3.2.1.2 Les utilisateurs : un moyen de supervision peu fiable et pas toujours agréable .......... 12
3.2.2 Surveiller plus que le système d’information....................................................................... 13
3.2.2.1 Un ordonnanceur ?........................................................................................................ 13
3.2.2.2 Supervision physique d’une salle machine ................................................................... 14
3.3 Les méthodes de la supervision .................................................................................................. 15
3.3.1. Les méthodes actives .......................................................................................................... 15
3.3.2. Les méthodes passives ........................................................................................................ 16
3.4 Les outils disponibles................................................................................................................... 17
3.1.1 Le protocole SNMP et sa MIB.............................................................................................. 17
3.1.1.1 A quoi ca sert ?.............................................................................................................. 17
3.1.1.2 La M.I.B.......................................................................................................................... 19
3.1.1.3 La S.M.I. ......................................................................................................................... 20
3.1.1.4 Fonctionnement............................................................................................................ 21
4.1.6. La sécurité........................................................................................................................ 23
3.2 Conclusion ................................................................................................................................... 25
Partie 4 : Choix d’une solution de supervision : Nagios ................................................................ 26
4.1 Choix d’une licence open source................................................................................................. 26
4.2 Le besoin d’adaptabilité et de modularité .................................................................................. 26
4.3 Transparence du mécanisme de remontée d’alerte................................................................... 27
4.4 Le choix de Nagios....................................................................................................................... 27
4.4.1 Histoire de Nagios ................................................................................................................ 27
4.4.2 Nagios ne fait rien sans ses plug-ins..................................................................................... 28
4.5 Atouts de Nagios par rapport aux autres outils open source ..................................................... 28
4.5.1 Zabbix : la supervision simplement...................................................................................... 28
4.5.2 Cacti : la métrologie avec SNMP........................................................................................... 29
4.5.3 OpenNMS : la supervision très SNMP .................................................................................. 29
4.5.4 Zenoss : très bonne supervision, mais pas complètement libre .......................................... 30
4.6 Orientation vers une totale modularité : tout est plug-in........................................................... 30
4.6.1 La modularité de Nagios : le rôle des plug-ins ..................................................................... 30

v
4.6.2 Des plug-ins pour avertir ou réagir....................................................................................... 31
4.7 Capacité à gérer un parc important de machines....................................................................... 31
4.7.1 Performances de Nagios....................................................................................................... 32
4.7.2 Gestion de la configuration.................................................................................................. 33
4.7.3 Gestion des alertes............................................................................................................... 33
4.7.3.1 De l’intérêt de filtrer correctement les alertes ............................................................. 33
4.7.3.1 Concision des alertes..................................................................................................... 33
4.7.3.2 Bien choisir le niveau d’erreur ...................................................................................... 35
4.8 Architecture générale.................................................................................................................. 36
4.9 Fonctionnement de Nagios ......................................................................................................... 36
4.10 Installation de Nagios................................................................................................................ 38
4.11 Interface graphique de Nagios.................................................................................................. 38
4.12 Les plugins du Nagios ................................................................................................................ 40
4.12.1 Plugins principaux............................................................................................................... 40
4.12.2 Plugins retenus....................................................................................................................... 41
4.13 Configuration de Nagios :.......................................................................................................... 45
4.14 Combinaison de Nagios et Centreon......................................................................................... 48
4.14.1 Pourquoi Centreon ? .......................................................................................................... 48
4.14.2 Installation de Centreon :................................................................................................... 49
4.14.3 Configuration de Centreon :............................................................................................... 49
4.15 NSClient++ ................................................................................................................................. 52
4.15.1 Présentation de NSClient :.................................................................................................. 52
4.15.2 L’installation de l’agent ...................................................................................................... 52
Conclusion ................................................................................................................................. 55
Bibliographie & Webographie..................................................................................................... 56
Annexes..................................................................................................................................... 57

Liste des figures ONEE -Branche Eau
vi
Liste des figures
Figure 1 : L’organigramme de L’ONEE- Branche Eau_______________________________________ 2
Figure 2 : Quelques missions de L’ONEE- Branche Eau ____________________________________ 6
Figure 3 : Le réseau à superviser______________________________________________________ 8
Figure 4 : Exemple d’une opération de la métrologie______________________________________ 9
Figure 5 : Exemple de PING_________________________________________________________ 15
Figure 6 : La supervision passive _____________________________________________________ 16
Figure 7 : Administration de tous les équipements réseaux________________________________ 17
Figure 8 : Echange de trames entre un agent SNMP et la console de gestion(le Client) __________ 19
Figure 9 : Les Objets gérés par le protocole MIB ________________________________________ 20
Figure 10 : Définir un objet dans la SMI _______________________________________________ 20
Figure 11 : L’arborescence de définition de l’objets sysUPTime. ____________________________ 21
Figure 12 : Partie d’une trame de réponse SNMP, la communauté apparaît bien en clair___ 23
Figure 13 : Exemple des variables mis à disposition par Nagios ____________________________ 37
Figure 14 : la page d’accueil du Nagios ________________________________________________ 39
Figure 15 : Fonctionnement du plugin Check_nt ________________________________________ 42
Figure 16 : Fonctionnement du plugin check_nrpe ______________________________________ 43
Figure 17 : redémarrer ou arrêter Nagios par sa interface graphique ________________________ 45
Figure 18 : La page d’accueil du Centreon _____________________________________________ 49
Figure 19 : Logo du NSClient ++______________________________________________________ 52
Figure 20 : le fichier NSC.ini_________________________________________________________ 53

Introduction ONEE -Branche Eau
1 Introduction| ONEE Branche Eau
Introduction
Dans le cadre de nos études, et dans le but d’approfondir nos connaissances dans le domaine
informatique, de mettre en pratique nos diverses connaissances théoriques, d’avoir un esprit
de groupe, et aussi un contact avec le milieu professionnel, j’ai effectué un stage de fin
d’études de 7 semaines (du 15/04/2014 au 04/06/2014) au sein de la direction de contrôle de
gestion et de système d’information à l’Office National de L’ELECTRICITE ET l’EAU
POTABLE Branche Eau de RABAT.
Les entreprises d'aujourd'hui sont de plus en plus dépendantes de leur système d'information
et sont par conséquent de plus en plus vulnérables. La perte d'un serveur ou d'un actif réseau
peut ralentir, voire stopper complètement leur activité.
Les besoins en termes de disponibilité et de qualité de service n'ont jamais été aussi
importants. Réagir rapidement en cas de panne devient donc absolument indispensable.
La suite de mon travail au sein du service ingénierie de DSI de l’ONEE-Branche Eau a été
consacrée à l’étude et la mise en place d’une solution de supervision Open Source basée sur
Nagios. En évoquant les principes fondamentaux de la supervision et de la métrologie.
Ce rapport commence par une présentation de l’ONEE-Branche Eau (OFFICE NATIONAL
DE L’ELECTRICITE ET L’EAU POTABLE), l’entreprise dans laquelle j’ai effectué mon
stage, ensuite l’objectif de ce dernier est d'étudier le concept de la supervision réseau après je
vais installer et configurer un serveur de supervision sous Nagios qui nous permettra de
répondre à ces demandes.

Partie 1 : Présentation de L’ONEE-Branche Eau ONEE -Branche Eau
2 Partie 1 : Présentation de l’ONEE-Branche Eau | ONEE Branche Eau
Partie 1 : Présentation de L’ONEE-Branche Eau
1.1 Fiche Technique de L’ONEE-Branche Eau
 Raison sociale : Office National de l’électricité et l’Eau Potable
 Type de société : Public
 Forme juridique : Etablissement a caractère Industriel et commercial doté de la
personnalité morale et l’autonomie financière.
 Capital : 7520000000dh.
 Date de création : Le 3 avril 1972.
 Adresse : ONEP, station de traitement Avenue Belhsessan ELOUAZZANI 10002-
RABAT
 Téléphone : 0637-75-96-00
 Fax : 0637-75-31-28
 Site web : www.onep.org.ma
 E-mail : onepdcc@onep.ma
1.2 Organigramme de L’ONEE-Branche Eau
Figure 1 : L’organigramme de L’ONEE- Branche Eau

1.3 Historique de L’ONEE- Branche Eau
Crée en 1972 en substitution à la Régie des Exploitations Industrielles (R.E.I) par le dahir
N°172103 du 3 avril 1972, l’office national de l’eau potable désigné sous le sigle « O.N.E.P »
est un établissement semi-public à caractère commercial et industriel doté de l’autonomie
financière est placé sous la tutelle du ministère d’aménagement du territoire de l’Eau et de
l’environnement et sous le contrôle du ministère de finance.
La disparition de la REI et son remplacement par l’Office National de l’Eau Potable (ONEP)
ont impulsé une dynamique à l’AEP au milieu urbain autorisant l’extension des réseaux dans
les grandes villes et la couverture des petites villes et des petits centres.
L’O.N.E.P a été crée suite au développement économique de notre pays qui s’est vu accéléré.
Ce dynamisme de croissance n’a pas manqué de s’accompagner d’un changement intégral
dans l’ampleur des besoins en eau et dans la nature même de cette denrée vitale pour
l’hygiène et la santé, si indispensable au bien-être.
1.4 Les Activités de l’ONEE- Branche Eau
1.4.1 Les activités principales :
Le Dahir n°172103 d’avril 1972, a énumère les principales tâches de l’O.N.E.E comme suit
La planification de l’approvisionnement du Royaume en eau potable. Dans ce
cadre :
Il détermine l’évolution des besoins en eau potable et obtient la réservation des
ressources correspondantes.
Il coordonne tous les programmes d’investissement relatifs aux adductions d’eau potable.
L’étude, la réalisation et la gestion des adductions de l’eau potable que le gouvernement
lui confie.
La gestion des distributions de l’eau potable ;

1.4.2 Les Activités particuliers :
L’ONEE- Branche Eau est chargé de :
Adduction régionale.
Système tarifaire et contribution de solidarité.
Contrôle de la qualité de l’eau.
Déminéralisation et dessalement d’eau de mer.
Assainissement.
Formation et coopération.
Sensibilisation.
1.5 La structure administrative du l’ONEE- Branche Eau
Son siège est à Rabat, sa gestion est assurée par un directeur général chargé de l’exécution des
décisions du conseil d’administration et du comité technique permanent.
L’administration de l’O.N.E.E-Branche Eau est assurée par deux organes suprêmes .
Un conseil d’administration : présidé par le Premier ministre ou le ministère
d’aménagement du territoire de l’Eau et de l’environnement, il se réunit au moins deux
fois par an.
Un comité technique : permanent présidé par le ministère d’aménagement du territoire
de l’Eau et de l’environnement. Ce comité est chargé de suivre l’exécution des décisions
arrêtées par le conseil d’administration et se réunit au moins deux fois par trimestre.

1.6 La direction contrôle de gestion et système d’information
La direction contrôle de gestion et système d’information présente les enjeux du pilotage des
coûts et des gains de la fonction système d’information, ainsi que des méthodes et outils de
gestion couramment utilisés en entreprise.
Pour fonctionner, le contrôle de gestion informatique couvre les cinq étapes fondamentales de
tout système de pilotage :
 Planification stratégique et opérationnelle
 Modélisation du système de gestion
 Conception et animation de la procédure budgétaire
 Mesure des performances
 Contrôle de performances
1.6.1 Organigramme de direction contrôle de gestion et système d’information
Direction contrôle de gestion et système d’information
Div. Contrôle de
gestion
Div. Gouvernance et
PMO SI
Div. Administration et
exploitation du système
d’information
Div. Centre
compétences
SI
Div. Réseaux et
Télécoms
Sce. Prévisions
Budgétaires
Sce.
Contractualisati
on interne
Sce. Tableaux
de Bords et
Roporting
Sce. Conseil
d’Administratio
n et Rapports de
gestion
Sce. Gestion
Portefeuille
Projets SI
Sce. Veille
Technologique
et normalisation
Sce. SIG
Sce. Utilities
Sce. Projets SI
Support
Sce.
Administration
Bases de
données et ERP
Sce.
Administration
Systèmes
Sce.
Infrastructure
informatique
utilisateurs
Sce. Support
des utilisateurs
Sce. Conduite
de changement
Sce.
Technique
SAP
Sce. Expertise
FI/CO SAP
Sce. Expertise
RH
Sce. Expertise
PEQ
Sce. Système
Décisionnel
Sce.
Ingénierie
Sce.
Infrastructure
Sce. Sécurité
SI

1.7 Les missions de L’ONEE-Branche Eau
Figure 2 : Quelques missions de L’ONEE- Branche Eau

Partie 2 : Présentation du sujet et de son concept ONEE -Branche Eau
7 Partie 2 : Présentation du sujet et de son concept| ONEE Branche Eau
Partie2 : Présentation du sujet et de son concept
2.1 Objectifs
2.1.1 Cadre et besoins
Le stage se déroule dans un environnement comportant un parc d’une dizaine des machines et
de quelques serveurs plus un routeur et des commutateurs.
L’administrateur ne peut pas déterminer directement d’où vienne le problème lorsqu’une
machine est manquante sur le plan. Est-ce le port qui est désactivé, est-ce la machine qui est
éteinte ou l’interface réseau de cette machine qui est hors-service ? L’administrateur ne peut
pas non plus déterminer si un service particulier sur un serveur donné fonctionne
correctement. Enfin, le simple fait de détecter qu’une anomalie existe derrière tel port de tel
commutateur ne peut se faire sans regarder le plan de façon fréquente ou sans qu’un
utilisateur ne déboule dans le bureau afin d’alerter l’administrateur. L’objet du stage est alors
de trouver une solution afin de devenir < pro-actif > face aux problèmes rencontrés ; de
pouvoir contrôler d’un simple coup d’œil l’état global du réseau, de déterminer l’origine d’un
problème afin d’y remédier le plus rapidement possible. Ces quelques critères rentrent dans le
domaine de la supervision de réseaux, essentiel pour assurer une disponibilité (souvent
indispensable) du système d’information de l’entreprise. Nous définissons dans un premier
temps ce que nous entendons par < supervision de réseaux > avant d’énoncer un comparatif
des solutions actuelles du marché puis à nous pencher sur celle que nous avons choisie de
mettre en place en présentant les notions l’entourant, pour cela on a construit un réseau de
test.
2.1.2 Cahier des charges
L’administrateur réseau devra pouvoir surveiller son réseau via une interface web sécurisée.
N’importe qui ne doit pas pouvoir accéder à cette interface, elle devra donc être protégée par
un mot de passe. L’interface web devra comporter une cartographie du réseau, présentant les
différents postes utilisateurs, les serveurs, les éléments actifs et imprimantes. Cette
cartographie devra explicitement décrire l’état de ces machines ; permettre d’identifier l’état

Partie 2 : Présentation du sujet et de son concept ONEE -Branche Eau
8 Partie 2 : Présentation du sujet et de son concept| ONEE Branche Eau
des ports des commutateurs sur ces mêmes machines serait un plus. L’interface devra
permettre également, étant donné une machine, de vérifier que les services tournent
correctement ou non.
Des renseignements supplémentaires sur les différentes machines (charge CPU, espace
disque, mémoire disponible, etc.) pourront être renseignés. Enfin, lorsque des problèmes
surviendront, l’administrateur devra être notifié par un courriel dont le contenu indiquera le
service et ou la machine défectueuse. La solution devra bien entendu être la moins chère du
monde libre : Nagios.
2.1.3 Réseau à superviser
pour mieux étudier et mettre en place une solution de supervision Open Source basée
sur Nagios et en évoquant les principes fondamentaux de la supervision et de la
métrologie. On va appliquer ses notions de base de l’outil Nagios dans une étude de cas
contenant le petit réseau local suivant :
Figure 3 : Le réseau à superviser
Il sera composé :
- D’un serveur « Nagios » qui s’occupera de la supervision du réseau, de la
centralisation et de l’analyse des informations du réseau.
- D’un poste client « WinXP »
- D’un poste client « Win7 »
- D’un poste client « WinVista »
- D’un Routeur « Cisco »qui permettra de relier le Serveur Nagios à internet.

Partie 3 : La supervision Réseau ONEE -Branche Eau
9 Partie 3 : La supervision Réseau | ONEE Branche Eau
Partie 3 : La supervision Réseau
3.1 Introduction à la supervision et à la métrologie.
3 .1.1 La métrologie
3.1.1.1 Définition générale
D’après l’encyclopédie libre Wikipédia : La mesure est l'opération qui consiste à donner une
valeur numérique à une grandeur. Par exemple, la mesure des dimensions d'un objet va
donner les valeurs chiffrées de sa longueur, sa largeur...
La notion de mesure est omniprésente :
Figure 4 : Exemple d’une opération de la métrologie
3.1.1.2 Dans le domaine des télécommunications
Dans mon cas, c’est bien sûr la métrologie appliquée aux réseaux informatiques voir
téléphoniques. La métrologie revient à faire des relevés de valeurs comme relever la bande
passante utilisée sur un lien, la répartition des protocoles et des services… Il doit être aussi
possible de relever des informations précises sur un équipement constituant le réseau comme
la charge du processeur, de la mémoire…
En résumé un système de métrologie efficace permet :
 de détecter d’éventuels engorgements du réseau, des trafics suspects, une machine
piratée…
 de pouvoir redimensionner des liens sous dimensionnés ou surdimensionnés
 de détecter un besoin de redémarrage de certains équipements ou d’augmenter leur
mémoire.

Attention la métrologie consiste à ne remonter que des informations quantitatives comme
le nombre d’utilisateurs connecté sur un serveur Web et non pas quelle page Web Bob
regarde ! Il va donc être nécessaire de définir de manière précise ce que l’on va mesurer.
3.1.2 La supervision
3.1.2.1 Définition
Le terme superviser désigne l’action de regarder au dessus de l’information,
contrairement à celui de surveiller qui signifie veiller sur.
La supervision représente, de manière générale, toute fonction consistant à indiquer et
à commander l'état d'un appel, d'un système ou d'un réseau. Les solutions de supervision
permettent de remonter des informations techniques et fonctionnelles du système
d'information.
La supervision système et réseau a pour but de surveiller le bon fonctionnement des
composants réseaux (commutateurs, routeurs, firewalls, …) et leurs caractéristiques (charge
du réseau, …) ; ainsi que les éléments des systèmes (serveurs, machines UNIX, …) et les
services qu’ils offrent (protocoles, …).
3.1.2.2 La supervision.. Pourquoi ?
Si le réseau ne possède pas de système de supervision :
• Il peut être piraté sans que les administrateurs s’en rendent compte (détection d’un
nouveau service).
• Lors d’une panne, ce sont les utilisateurs qui informent les administrateurs.

Donc pour que les administrateurs soient crédibles et aient une bonne image, il faut un
système de supervision efficace, complet et adapté. En outre un bon système de supervision
permet d’anticiper les pannes et donc de gagner du temps :
3.2 Intérêt de la supervision et de la métrologie.
Le métier d’administrateur devient de plus en plus complexe, d’où l’importance pour l’équipe
de gagner en temps et en efficacité grâce à un bon outil de supervision.
3.2.1 Être alerté en temps réel
Les systèmes d’information étant par nature complexes, leur supervision est indispensable.
3.2.1.1 Les problèmes sont inévitables
Les systèmes d’information sont tous différents de par leur taille, leur nature, leur criticité.
Ils ont cependant pour point commun d’être le théâtre d’incidents, à un moment
ou à un autre.
Si quelque chose peut mal tourner, alors elle finira infailliblement par mal tourner. Un des
rôles des administrateurs est justement de gérer cela. Ils doivent concevoir l’architecture du
système d’information de telle manière qu’une panne ait un impact minimal sur le reste du
système. Ils doivent aussi gérer les éventuels problèmes – ce qui reste une part importante de
leur charge de travail. Même avec des architectures robustes, on estime généralement à 80%
de l’activité d’un administrateur la résolution de problèmes. Voilà pourquoi il vaut la peine de
chercher à diminuer cette part qui, il faut bien l’avouer, est loin d’être la plus intéressante, et
de surcroît n’ajoute aucune valeur aux systèmes

3.2.1.2 Les utilisateurs : un moyen de supervision peu fiable et pas toujours agréable
Les systèmes d’information ont pour but final de servir des utilisateurs et d’être employés par
eux. Ceux-ci ne manquent pas de signaler aux administrateurs les problèmes qu’ils y
rencontrent – problèmes qui surviennent soit par manque de formation des utilisateurs, soit
par réelle carence du système.
Dans ce dernier cas, il n’est pas agréable, pour l’administrateur, de l’apprendre de la bouche
d’un utilisateur car celui-ci n’est généralement ni tendre ni très précis. Cette imprécision peut
faire perdre un temps précieux lors de la résolution du problème. L’administrateur, faute
d’informations pertinentes, cherche le problème au mauvais endroit.
Une solution de supervision permet justement d’éviter ce genre de soucis. L’administrateur
est prévenu rapidement d’une situation anormale, bien souvent en moins de temps qu’il n’en
faut à un utilisateur pour venir se plaindre. Il dispose, de plus, d’informations pertinentes et
peut immédiatement s’atteler à la résolution du problème.
Si ce dernier est mineur, sa résolution est rapide. L’utilisateur qui tente de nouveau d’accéder
à la ressource y parvient et n’appelle pas le support. Il y a gain de temps, de part et d’autre,
sans compter que l’utilisateur finit par se faire une meilleure opinion du service informatique
qu’il appelle moins souvent.
En outre, certaines ressources ne sont utilisées qu’occasionnellement – c’est le cas par
exemple des applications de déclaration au trésor public. En cas de souci en période de non-
utilisation, sans outil de supervision, l’erreur n’est pas remontée ; ce n’est que lors de
l’utilisation de l’application que les utilisateurs s’en aperçoivent et sont bloqués.
Avec un outil de supervision, les administrateurs auraient eu tout le temps nécessaire pour
résoudre le problème en période creuse. Ils ne subiraient pas les foudres des utilisateurs d’une
application comptable en période de clôture...

3.2.2 Surveiller plus que le système d’information
Les outils de supervision ont souvent un champ d’action qui s’étend au-delà du seul périmètre
du système d’information.
3.2.2.1 Un ordonnanceur ?
Un outil de supervision n’est rien de plus qu’un ordonnanceur un peu spécial. En général, il
n’effectue pas d’action mais juste des vérifications. Il est cependant possible de l’instrumenter
pour ordonnancer des traitements – mais avec des limites vite atteintes puisque ordonnancer
des traitements n’est pas sa vocation première.
Par exemple, un outil de supervision est spécialisé dans le lancement de nombreux petits
programmes, chacun récupérant une valeur, tandis que les ordonnanceurs lancent en général
un nombre restreint de traitements, mais qui peuvent durer plusieurs heures. Le paramétrage
et le comportement de l’application sont inadaptés face à une telle utilisation.
Cela dit, face au coût important d’un outil d’ordonnancement, il est tentant de laisser cette
tâche à l’outil de supervision. Mais c’est au risque d’avoir un service de piètre qualité et de
mettre en péril certains traitements, ce qui peut au final se révéler plus coûteux.
Autre phénomène également observable sur bien des outils de supervision, leur périmètre de
surveillance dépasse les limites du système d’information. De tels dépassements peuvent être
justifiables ou au contraire ne pas être pertinents du tout.

3.2.2.2 Supervision physique d’une salle machine
Prenons l’exemple de la supervision physique d’une salle machine. Celle-ci contient en
général un système d’accès à la salle, une climatisation et un groupe électrogène – autant
de systèmes en eux-mêmes indispensable à l’ensemble du système d’information.
Il va sans dire que si une personne parvient à accéder à la salle, le système est en péril
puisqu’il suffirait à l’intrus de prendre un disque ou une bande pour obtenir des informations
confidentielles, en passant outre tous les pare-feux possibles et imaginables.
Dans le cas de la climatisation, une trop forte température ou une humidité trop élevée
peuvent être catastrophiques et rendre le système indisponible. Il en va de même pour
l’électricité.
Les éléments physiques sont donc cruciaux pour le bon fonctionnement du système. Ils
peuvent – ou doivent même – être surveillés par l’outil de supervision. Cette surveillance
dépend, bien sûr, de la manière d’obtenir les informations importantes comme la température
ou l’état des batteries du groupe électrogène. On verra par la suite des exemples d’obtention
de telles informations.
Formes d’alertes
De telles informations (accès, humidité, température, panne courant) sont critiques et doivent
être remontées de toute urgence aux responsables de la salle machine. Un simple courrier
électronique n’est bien souvent pas suffisant – peu de chances en effet que l’administrateur
aille consulter ses messages à 4 heures du matin. Un SMS envoyé sur un téléphone d’astreinte
aura plus d’impact. Ainsi différentes façons d’avertir sont à prévoir dans une solution de
supervision. Elles doivent être étudiées avec soin. Des SMS envoyés à tort n’auront pour effet
que d’inciter les personnes d’astreinte à ne pas les lire, voire à éteindre le téléphone

3.3 Les méthodes de la supervision
Beaucoup de méthodes sont à notre disposition pour superviser un réseau, ces différentes
méthodes peuvent être regroupées en deux grandes catégories :
3.3.1. Les méthodes actives
Cette méthode consiste à exécuter un logiciel afin de relever une caractéristique précise à un
moment précis et non pas une observation globale du réseau. Connexion (exécution d’une
commande par SSH), Ping et Traceroute sur un équipement font partie de cette méthode.
C’est donc soit l’utilisation du protocole ICMP soit l’envoi de commandes par SSH pour faire
des relevés de l’état du système.
Exemple de l’utilisation de l’application ping, se basant sur le protocole ICMP, par un
administrateur voulant tester si ma machine est active :
$PING serveur.onee.ma
ping serveur.onee.ma (192.168.1.1) 56(B4) bytes of data serveur.onee.ma
64 bytes from 192.168.1.1: icmp_seq=1ttl=128 time=1.43 ms
Ce qu’il faut retenir : une méthode active permet de tester à un instant t quelque chose mais ne
permet pas de connaitre le résultat de ce test il y a deux heures.
Figure 5 : Exemple de PING

3.3.2. Les méthodes passives
Ces méthodes ne consistent plus à lancer un logiciel de façon ponctuel pour connaître l’état
d’un équipement, mais de le mettre en tant que service système pour qu’il puisse fonctionner
en continu. L’administrateur peut ainsi accéder aux relevés par le biais d’une interface
graphique ouverte en permanence ou par une interface web. Grâce à cette méthode, on peut
mettre en place un système de graphique (flux, temps de réponse, occupation de la
mémoire…) permettant de mieux voir l’évolution d’un paramètre. La surveillance du réseau
se fait en continue, elle met en oeuvre des sondes, utilise un protocole de management
(SNMP) ou utilise des agents à placer sur les équipements. Reprenons l’exemple précédent
mais avec une méthode passive :
Requêtes PING toutes les 5 minutes de la station
serveur.onee.ma
servreur.onee.ma
Ce qu’il faut retenir : la supervision passive permet de revenir dans le temps pour mieux
comprendre un phénomène de pannes en cascades (services qui « tombent » les un après les
autres) par exemple. Mais cette méthode nous oblige à laisser fonctionner constamment une
application qui génère une utilisation du réseau et des équipements qu’il ne faut pas négliger
surtout pour un grand réseau.
Figure 6 : La supervision passive

3.4 Les outils disponibles
3.1.1 Le protocole SNMP et sa MIB
3.1.1.1 A quoi ca sert ?
Imaginez un moyen qui permettrait d’administrer tous les équipements d’un réseau et de
connaître les informations internes d’un switch, d’une imprimante, d’un routeur, d’un
serveur…
Figure 7 : Administration de tous les équipements réseaux
Le protocole de supervision le plus répandu est SNMP (Simple Network Management
Protocol), défini dans la RFC 4789. Ce protocole a pour l’instant connu trois versions (v1,
v2c, v3), où la troisième version permet d’avoir plus de sécurité mais la plus répandue est
encore la deuxième version, qui améliore les opérations du protocole en version1.
Les clients à superviser contiennent un agent SNMP qui est un logiciel permettant de modifier
en partie ou intégralement la configuration via des requêtes. Il envoie également des
informations concernant l’état de l’équipement au manager. Ce dernier est un logiciel sur la

station de supervision qui réalise la lecture d’informations d’éléments du réseau en
interrogeant cet agent et permet de modifier les paramètres de cet élément et de visualiser les
statistiques qui lui sont liées.
Dans un souci de rapidité, le protocole SNMP ne transporte que des variables par le biais du
protocole de transport UDP. Il sert à instaurer le dialogue entre les agents installés sur les
machines supervisées et le serveur de supervision. L’agent reçoit les requêtes sur le port 161
et le superviseur reçoit les alarmes sur le port 162.
les équipements supportant ce protocole sont cher mais la quasi-totalité des équipements
administrables (par telnet, interface web ou encore par le port console) le supporte. Si ce n’est
pas le cas il est possible de pouvoir installer un agent SNMP sur un système d’exploitation
mais pas sur un équipement fermé que l’on ne peut mettre à jour, comme un simple
commutateur non administrable. Avec ce protocole on peut par exemple sur un équipement:
 Connaître son état : nombre de trames passées, charge du processeur…
 Configurer certains paramètres (on peut ainsi imaginer un système d’équilibrage des
charges)
 Etre alerté par l’équipement d’un disfonctionnement interne (surchauffe, permet
d’alimentation…)
Bâti au dessus de TCP/IP, voici SNMP dans le modèle OSI :

SNMP utilise le protocole UDP pour sa simplicité et son poids : 8 octets (20 octets pour
TCP). Ce protocole permet à SNMP d’être rapide mais ça a l’inconvénient d’être un protocole
en mode non connecté et non fiable, il est donc possible qu’un message SNMP n’arrive
jamais, ce qui est embêtant si c’est une alarme…
Figure 8 : Echange de trames entre un agent SNMP et la console de gestion(le Client)
3.1.1.2 La M.I.B.
La Management Information Base, qui peut se traduire par : la base d’information de gestion,
elle est spécifique à chaque équipement mais aussi à chaque constructeur car c’est lui qui
définie les informations consultables, les paramètres modifiables et les alertes à envoyer (Les
traps). La MIB est une structure arborescente où chaque feuille correspond à une information
sur l’équipement. La MIB permet donc de définir les données à envoyer dans la trame
d’interrogation pour récupérer les données voulues. Le nom de chaque nœud est normalisé
mais un équipement compatible SNMP n’est exploitable qu’avec sa MIB car il est impossible
de deviner les objets disponibles dans chacune des branches et comprendre leurs
significations ainsi que leurs valeurs.

Figure 9 : Les Objets gérés par le protocole MIB
3.1.1.3 La S.M.I.
La Structure of Management Information définie les règles de description et d’identification
pour chaque objet de la MIB. Un objet est défini en langage ASN.1 (langage de représentation
des données (Abstract Syntax Notation 1) défini par l’ISO 8824), voici quelques types utilisés
• IPAddress : pour l’adresse IP.
• PhysAddress : pour l’adresse matérielle (MAC).
• TimeTicks : pour un compteur de temps en 1/100 de seconde.
• OCTET STRING : pour une chaîne de caractères.
Figure 10 : Définir un objet dans la SMI

3.1.1.4 Fonctionnement
Pour mieux comprendre le fonctionnement prenons l’exemple suivant de récupérer l’uptime
(temps écoulé depuis le démarrage du système d’exploitation) d’un routeur . Dans un premier
temps il a fallu aller chercher sur le site du constructeur (ici Cisco par exemple ) le MIB de ce
routeur pour savoir où se situe cette donnée.
Voici un extrait, plus particulièrement une feuille, de la MIB d’un équipement Cisco :
system OBJECT IDENTIFIER ::= { mib-2 1 } […]
sysUpTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read only
STATUS current
DESCRIPTION
"The time (in hundredths of a second) since the network management
portion of the system was last re-initialized."
::= { system 3 }
[…]
Chaque branche est repérée par un numéro, SNMP utilise cette façon de faire pour accéder à
un paramètre : de la racine jusqu'au paramètre d’un objet. Dans l’encadré cidessous on voit
que la branche system(1) fait partie de la branche mib-2(1) qui fait à son tour partie d’une
autre branche… C’est l’espace de nommage qui reprend une grande partie d protocole de
gestion défini par l’ISO 9596 :
Figure 11 : L’arborescence de définition de l’objets sysUPTime.

Donc pour accéder au paramètre de la feuille étudiée, il faut passer par les
nœuds.1.3.6.1.2.1.1.3 (c’est l’OID de l’objet : Object Identifier) et rajouter 0 pour obtenir la
valeur de l’objet ‘sysUpTime’.
Essai avec le chemin complet grâce à l’outil snmpget :
# snmpget -v 2c -c public 10.10.100.1 .1.3.6.1.2.1.1.3.0
SNMPv2-MIB::sysUpTime.0 = Timeticks: (3683053517) 426 days, 6:42:15.17
Comme la suite des noeuds .1.3.6.1.2.1 est très souvent utilisée, il est possible d’utiliser un
chemin relatif en omettant le point de début, on obtient donc la suite : 1.3.0, cela donne :
# snmpget -v 2c -c public 10.10.100.1 1.3.0
Il est aussi possible de mettre directement le nom de chaque noeud :
# snmpget -v 2c -c public 10.10.100.1 system.sysUpTime.0
Dans la ligne de commande on peut voir que plusieurs paramètres sont entrés pour snmpget :
 -v 2c pour désigner la version du protocole SNMP installé sur l’hôte.
 -c public pour définir le nom de la communauté à utiliser.
 10.10.100.1 qui correspond à l’adresse IP de l’équipement à interroger.
Il faut savoir que les objets présents dans la branche mib-2 (nœuds .1.3.6.1.2.1) respects un
standard, une autre branche est utilisée par les constructeurs qui ajoutent des objets, cette
branche se situe aux nœuds .1.3.6.1.4.1.x, x étant un numéro attribué au constructeur. Une
autre branche est destinée à la version 3 du protocole SNMP.
On vient de le voir, SNMP a choisi l’espace de nommage de l’ISO, le langage utilisé pour
définir les objets est ASN.1 (Abstract Syntax Notation Number 1), les primitives de ces objets
sont définies dans la SMI (Structure of Management Information).
Malgré le fait que la MIB contienne énormément d’informations techniques, SNMP ne permet
pas de remonter des informations capitales pour la supervision comme l’état d’un service
(Web, base de données…).

4.1.6. La sécurité
L’aspect sécurité doit être pris en compte dans le choix d’une solution d’administration du
réseau puisque si la solution utilise le protocole SNMP, celui-ci devra être implanté et/ou
activé sur les serveurs, les routeurs, les pare-feux…Il est donc nécessaire de voir si
l’utilisation du protocole SNMP ne crée pas de failles importantes.
En revanche l’utilisation de SNMP implique l’ouverture d’un service (sur le port 161),
voyons l’impact :
 Du point de vu d’Internet, la sécurité n’est pas modifiée puisqu’un pare-feu filtre tout
et que seul quelques protocoles (FTP, HTTP, HTTPS et Z3950 : communication du
catalogue du fond bibliographique) fournis par 2 serveurs sont disponibles ; il ne sera
donc pas possible d’interroger un agent SNMP.
 En interne ça se complique car toutes les stations de travail peuvent accéder aux
serveurs et aux équipements du réseau, il faut voir comment le protocole SNMP est
sécurisé puisque l’on a vu que l’agent SNMP nous permet d’accéder à un grand
nombre d’informations.
La première version du protocole la sécurité est basée sur la connaissance d’une chaîne de
caractères (c’est la communauté) pour pouvoir accéder à la MIB. Cette chaîne de caractères
est donc présente dans toutes les requêtes faites par le logiciel d’administration du réseau à
l’agent SNMP, le problème c’est que la chaîne de caractères n’est pas cryptée et donc si
quelqu’un intercepte une trame de requête il pourra sans aucune difficulté obtenir le nom de la
communauté et interroger à son tour les équipements.
Figure 12 : Partie d’une trame de réponse SNMP, la communauté apparaît
bien en clair

La seconde version avait pour but de corriger les limitations imposées par la SMI (par
exemple la taille des compteurs limitée à 32 bits) mais aussi l’aspect sécurité quasiment
absent dans la première. La mise à jour de la SMI a bien été réalisée (nouvelle version :
SMIv2) mais pas l’aspect sécurité. Les bénéfices apportés par la nouvelle SMI seront utilisés
dans la version SNMPv2c avec c pour community puisque le mécanisme de sécurité reste
celui de la première version.
La version 3 achevée en 1999 met enfin en place une stratégie de sécurité consultable sur la
RFC2574 (User-based Security Model for version 3 of SNMP), voici les 4 axes principaux :
 L’estampillage du temps pour empêcher la réutilisation d’un paquet .
 L’encryption pour ne plus pouvoir lire les informations de gestions contenues dans un
message.
 L’authentification pour empêcher la modification du message par quelqu’un.
 La localisation des mots de passe permet de ne pas compromettre la sécurité du
domaine même si l’un des agents est compromis.
3 niveaux de sécurité sont ainsi offerts :
• noAuthNoPriv : authentification par l’échange d’une chaîne de caractères :
community (v1 et v2c) ou username pour la version 3.
• authNoPriv : authentification par la technique de cryptographie à clé
symétrique HMAC-MD5 ou HMAC-SHA, l’authentification en passe plus en
clair sur le réseau.
• authPriv : reprend le système d’authentification à clé symétrique mais ajoute
un chiffrement des informations sensibles (les réponses demandées et
l’identifiant de contexte : le port du routeur par exemple) contenus dans les
trames SNMP pour les rendre illisibles sur le réseau, chiffrement par
l’algorithme DES en 56 bits.

3.2 Conclusion
Pour conclure on peut dire que, les outils de supervision et de métrologie sont indispensables
à la bonne administration d’un système d’information. Sans eux, l’administrateur est privé de
moyens fiables et rapides de vérifier que les éléments de l’infrastructure et les applications
sont opérationnels.

Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
26 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
Partie 4 : Choix d’une solution de supervision : Nagios
Sur quels critères juger une solution de supervision ? Quel est le fonctionnement de Nagios,
référence open source en matière de supervision ?
4.1 Choix d’une licence open source
En ces périodes où les budgets des services informatiques fondent comme neige au soleil, la
gestion des licences est de plus en plus contraignante. Les demandes des utilisateurs
augmentent et conduisent à une accumulation de licences. Les outils de supervision ne font
pas exception à cette règle. On peut, dans certains cas, arriver à ces situations où seuls les
environnements critiques sont supervisés, faute de moyens pour acquérir les licences
nécessaires aux autres environnements. Cette situation est dommageable à la qualité du
service fourni aux utilisateurs – l’outil risque par exemple de ne pas être utilisé pour signaler
un problème sur un environnement de test avant mise en production. L’utilisation d’un outil
open source est tout indiquée dans ce genre de situation.
4.2 Le besoin d’adaptabilité et de modularité
Le choix d’une licence open source permet de répondre à un second besoin : l’adaptabilité.
Comme nous l’avons vu, tous les environnements informatiques sont différents. La
supervision doit s’adapter à chaque situation. Elle ne doit pas se comporter de la même
manière sur un petit site que sur un système réparti sur plusieurs sites distants. Les
applications à gérer sont également extrêmement variées. La modularité de l’outil est
primordiale pour ne pas laisser de côté tout un pan du système.
Avec un outil de supervision propriétaire, dans bien des situations, même si les
administrateurs savent comment superviser un élément non pris en compte, ils ne peuvent
pas, contractuellement ou techniquement, l’ajouter dans l’outil. Dans le cas d’un outil open
source, il n’y a pas de limitation. Les administrateurs peuvent l’adapter librement.

4.3 Transparence du mécanisme de remontée d’alerte
Un autre besoin des administrateurs est de savoir comment est recueillie l’information. Les
alertes qu’ils ne comprennent pas ne peuvent guère leur inspirer confiance. S’ils savent
précisément comment est récupérée l’information, ils la prendront immédiatement en
considération. Ils pourront même essayer de l’améliorer. C’est tout l’intérêt des solutions
open source ! Un autre besoin des administrateurs est de savoir comment est recueillie
l’information.
Les alertes qu’ils ne comprennent pas ne peuvent guère leur inspirer confiance. S’ils savent
précisément comment est récupérée l’information, ils la prendront immédiatement en
considération. Ils pourront même essayer de l’améliorer. C’est tout l’intérêt des solutions
open source !
4.4 Le choix de Nagios
Si l’on retient tous ces critères dans le choix d’une solution open source stable, performante
et ayant une forte communauté, Nagios sort largement vainqueur. Cette solution est en effet la
référence en matière de supervision dans le monde de l’open source.
4.4.1 Histoire de Nagios
L’histoire d’un outil peut nous en apprendre beaucoup sur lui.
Nagios est développé par Ethan Galstad et débute son histoire en 1999 sous le nom de
NetSaint. Quelque temps plus tard, à cause d’un problème de propriété intellectuelle sur le
nom, il devient Nagios. Actuellement en version 4.0, il a plus de quinze ans d’existence.
Comme nous le verrons par la suite, il se bonifie avec l’âge, à l’image d’un grand vin. Il a
évolué depuis ses tous débuts afin de s’adapter à des parcs de plus en plus importants, tout en
améliorant ses performances et ses capacités de gestion de configuration..

4.4.2 Nagios ne fait rien sans ses plug-ins
Il est le digne héritier du principe KISS (Keep It Simple, Stupid) d’Unix : il ne fait qu’une
chose, mais la fait bien. Son rôle est d’ordonnancer les vérifications sur les éléments à
superviser et de lancer une alerte si besoin. Il ne fait rien d’autre, pas même aller vérifier lui-
même l’état des éléments à surveiller.
Ceci peut paraître étonnant, mais Nagios ne sait rien faire tout seul. Il ne peut même pas
vérifier le bon état du serveur sur lequel il est hébergé. Son auteur a en effet considéré qu’il ne
pouvait prévoir toutes les vérifications qu’un tel outil doit intégrer. Il a donc décidé de n’en
mettre aucune au sein de Nagios et de laisser la responsabilité des vérifications à des plug-ins
que l’utilisateur devra fournir à l’outil.
4.5 Atouts de Nagios par rapport aux autres outils open source
Nagios n’est pas le seul outil de supervision open source. Par rapport à ses concurrents, sa
plus grande force réside dans sa modularité complète. Il n’a pas de domaine de prédilection et
peut observer tout ce que ses plug-ins sont capables de rapporter.
D’autres outils open source de supervision existent, mais ils ne sont pas aussi modulaires ou
performants que Nagios. On trouve aussi sur le marché des outils de même envergure, mais
non complètement libres.
4.5.1 Zabbix : la supervision simplement
Ce premier outil est très orienté système et s’occupe en interne de la métrologie. Il n’est pas
aussi modulaire que Nagios. Il est beaucoup plus orienté tout-en-un, avec des agents dédiés
qu’il faut déployer sur les éléments distants.
Si ce choix permet de gagner du temps lors de la première mise en place, il se révèle gênant
lorsqu’il s’agit de superviser des éléments non prévus par la solution.

Quant aux possibilités de configuration elles sont moins étoffées que celles de Nagios, ce qui
peut être contraignant lorsque le nombre d’éléments commence à devenir important. Il
manque à Zabbix des solutions simples pour gérer les pertes massives de connexion et tout ce
qui concerne la gestion des dépendances entre éléments. Ce dernier point est, encore une fois,
problématique lorsque la supervision couvre un nombre élevé d’éléments.
4.5.2 Cacti : la métrologie avec SNMP
Cacti, quant à lui, est bien plus orienté réseaux et métrologie. Il repose principalement sur
l’utilisation du protocole SNMP .
La supervision n’est pas le rôle premier de Cacti. Elle est basée principalement sur des
indicateurs qui doivent rester en deçà de seuils fixés. Nagios préfère laisser le choix au plug-
in de se baser ou non sur des valeurs. Cacti est cependant très efficace dans la gestion des
données de performances. C’est pour cela qu’il est parfois utilisé pour gérer les données
issues de Nagios.
4.5.3 OpenNMS : la supervision très SNMP
Cet outil de supervision est globalement moins avancé que Nagios. Sa configuration est très
lourde à gérer, même lorsque le nombre d’éléments supervisés est réduit. Il nepossède pas de
fonctionnalité de gestion des dépendances, ce qui représente un handicap lourd dans les
environnements complexes.
Hors des tests SNMP classiques, OpenNMS est très vite limité. Il est possible d’inclure des
tests supplémentaires, mais c’est une solution relativement lourde à gérer.

4.5.4 Zenoss : très bonne supervision, mais pas complètement libre
Concurrent très sérieux de Nagios, il a comme particularité de ne pas être complètement libre.
Là où Nagios est entièrement en GPL, Zenoss est disponible sous trois versions différentes,
dont deux non libres et soumises à licences. La version libre est assez limitée dans ses
possibilités. Les fonctionnalités de haute disponibilité ou de supervision des environnements
virtualisés ne sont tout simplement pas accessibles dans cette version.
Si les versions sous licences possèdent des avantages face à Nagios, comme la possibilité
native d’avoir une découverte du réseau, elles sont moins avancées sur certains points tels que
l’envoi d’alertes, limité aux e-mails et aux SMS, ou, à l’instar de Zabbix, sur les possibilités
de configuration qui restent limitées.
Zenoss ressemble fortement à Zabbix au sens où il gère aussi lui-même la métrologie et
propose une interface web complète, là où Nagios délègue ces aspects à des outils tiers.
4.6 Orientation vers une totale modularité : tout est plug-in
Rappelons que la force principale de Nagios réside dans sa modularité.
4.6.1 La modularité de Nagios : le rôle des plug-ins
Nagios laisse la supervision à des plug-ins, ou sondes, que va lui fournir l’utilisateur. Il se
contente de les lancer et de gérer les informations recueillies par ce biais.
La communauté fournit la plupart de ces plug-ins. Ils couvrent, en règle générale, plus de 95%
des besoins des utilisateurs. En outre ils évoluent au fil du temps afin de gérer de plus en plus
de systèmes.
Leur conception est très simple, comme nous le verrons par la suite. Cette simplicité permet
aux non-développeurs d’apporter leur pierre à l’édifice. Cette facilité d’adaptation a un autre
avantage majeur : elle permet de capitaliser sur les scripts de vérification déjà mis au point et
utilisés par les administrateurs avant la mise en place de Nagios. La plupart du temps, changer
une seule ligne suffit à les rendre compatibles avec Nagios. En effet, les règles de Nagios sont
standards dans le monde des administrateurs et bien des scripts d’administrateurs sont déjà
compatibles avec Nagios.

C’est cette capacité d’adaptation qui a fait de Nagios la solution la plus prisée dans le monde
de l’open source. La communauté qui s’est formée autour est la plus importante en matière de
supervision open source. Les administrateurs n’ayant pas besoin d’être développeurs, le
nombre de scripts de vérification proposés par la communauté est véritablement
impressionnant. La communauté s’est organisée afin de fournir le plus simplement possible
aux utilisateurs les plug-ins dont ils ont besoin. Ces plugins sont également open source.
4.6.2 Des plug-ins pour avertir ou réagir
Nagios permet également de définir des plug-ins qui vont alerter les utilisateurs en cas de
problème, ce qui permet d’être inventif en matière d’avertissement. On peut penser de suite
aux e-mails, mais nous verrons par la suite que beaucoup d’autres possibilités s’offrent à
nous.
Lorsque quelque chose se passe mal, d’autres plug-ins peuvent tenter de corriger le problème.
Il n’est pas possible de prévoir tous les cas de réparations possibles, sinon l’administrateur
n’aurait plus de raison d’être. Il est donc préférable de lui laisser le soin de définir lui-même
les commandes pour résoudre le problème sur son environnement.
4.7 Capacité à gérer un parc important de machines
Nous avons vu qu’un outil de supervision doit pouvoir gérer des parcs importants.
Sur ce point, trois critères principaux entrent en jeu :
1 les performances ;
2 la gestion de la configuration ;
3 les alertes.

4.7.1 Performances de Nagios
En matière de performances, Nagios n’a rien à envier aux outils de supervision propriétaires.
Il permet, avec un serveur modeste, de surveiller près de 10 000 éléments. Si cette
performance est déjà tout à fait honorable, Nagios propose des options pouvant sensiblement
augmenter cette valeur.
L’architecture même de Nagios permet de surveiller autant de noeuds que souhaite
l’utilisateur. La supervision peut être distribuée entre plusieurs serveurs, tout en centralisant
l’administration sur une unique console.
Le serveur Nagios a besoin d’être correctement dimensionné. Il doit supporter la charge de la
supervision et de la métrologie. Ces deux activités n’ont pas forcément les mêmes besoins. La
supervision consiste à lancer un nombre élevé de vérifications sur les hôtes distants. La
métrologie doit, quant à elle, conserver un nombre plus restreint d’éléments, mais sur une
durée très longue.
La supervision rencontre principalement des problèmes de temps de calcul pour
ordonnancer les tests. Si le serveur n’est pas capable de suivre, les tests sont lancés en retard.
S’il ne peut pas rattraper ce retard, l’écart se creuse. Les tests sont de plus en plus décalés et
ne se font pas aussi rapidement que le souhaitait l’administrateur. Un serveur qui dispose de
ressources suffisantes lance les tests en temps et en heure.
Les principaux problèmes de la métrologie concernent, quant à eux, les disques. Les
informations devant être conservées sur une longue durée, l’espace est une ressource critique.
Si le volume nécessaire est plutôt simple à estimer, l’impact des disques sur le traitement des
données est plus complexe à suivre et à prévoir. Une métrologie mal taillée peut rapidement
ralentir la supervision, avec toutes les conséquences que nous venons d’évoquer.

4.7.2 Gestion de la configuration
Un point délicat concernant la plupart des outils d’administration, mais touchant tout
particulièrement les solutions de supervision, est la gestion de la configuration. Plus on a de
points à surveiller, plus la configuration devient lourde, avec les risques, si elle devient trop
dure à gérer, d’être laissée de côté. Nagios propose diverses solutions pour faciliter la gestion
d’un nombre élevé de points surveillés, et c’est même une de ses grandes forces !
4.7.3 Gestion des alertes
Les alertes remontées aux administrateurs sont au cœur même des outils de supervision. Nous
allons voir comment assurer leur précision et leur pertinence.
4.7.3.1 De l’intérêt de filtrer correctement les alertes
la solution de la supervision doit faciliter leur travail. Les informations doivent leur arriver
déjà filtrées. Dans le cas contraire, ils perdent du temps.
Le seuil de tolérance est variable suivant les administrateurs. On peut considérer qu’une
vingtaine d’alertes par jour est acceptable pour une grande majorité. Au dessus, certains vont
commencer à se plaindre. Cette limite est notre marge haute. Si l’on arrive à faire mieux, il ne
faut pas s’en priver.
4.7.3.1 Concision des alertes
La solution de supervision doit faire gagner du temps aux administrateurs. La concision des
alertes est un premier pas dans cette direction.
Concision et précision
Les administrateurs n’aiment pas perdre de temps lorsqu’il s’agit d’alertes sur leurs serveurs
ou éléments réseau. Ils veulent que l’information soit énoncée rapidement et clairement. Le
responsable de la solution de supervision doit donc particulièrement veiller à la concision des
alertes, sans pour autant tomber dans le travers inverse : l’alerte doit être suffisamment
explicite pour permettre à l’administrateur de savoir d’où vient le problème. Trop court, un
descriptif n’indique pas d’où vient la panne.

Les informations généralement nécessaires sont les suivantes :
• le nom de la machine sur laquelle le problème est survenu ;
• l’élément qui est en faute sur la machine ;
• la criticité de l’alerte ;
• l’heure où le problème a été détecté ;
• un petit texte explicatif du problème (une ligne ou deux maximum) ;
• un lien vers la résolution du problème si elle est disponible.
Il n’est pas nécessaire d’ajouter des formules de politesse dans le texte, les administrateurs ne
s’en vexeront pas. Ils ne trouveront les informations recherchées que plus rapidement.
Il ne faut pas oublier que les messages d’alerte sont souvent envoyés par plusieurs biais. Les
textes ne devront pas être les mêmes entre un envoi par e-mail et un envoi par SMS. Ce
dernier est de taille limitée : il faut être très concis. Les seules informations à y placer sont le
nom de la machine, l’élément qui est en faute, la criticité et l’heure du problème.
Exemple d’e-mail d’alerte
Voici un exemple d’e-mail d’alerte pour un incident survenu sur le serveur srv-web2
concernant une utilisation trop importante de la mémoire.
Message par e-mail bien formaté
***** Nagios Notification *****
State: WARNING
Host: srv-web2
Service: Memory
Date/Time: 16-12-2008 15:35
Additional Info : WARNING: 92% Used Memory - Total: 8116 MB, used: 7503
MB, free : 613 MB
Documentation : clic here.
Exemple de SMS
Dans le cas d’un SMS envoyé pour le même problème, on peut envoyer ce qui suit :
Message dans le cas d’un SMS
WARNING: srv-web2/Memory at 16-12-2008 15:35

4.7.3.2 Bien choisir le niveau d’erreur
Toujours dans le but de faire gagner du temps, la pertinence des alertes est importante.
Le niveau d’erreur permet d’améliorer cette pertinence.
Criticité
L’information de criticité des alertes est l’une des plus importantes. Un administrateur doit
savoir en priorité si l’alerte est importante ou non. Il peut être en train d’effectuer une
opération sur un serveur et doit pouvoir déterminer rapidement s’il a besoin de s’interrompre.
Différents niveaux d’alerte sont définis. Ces niveaux changent suivant différents critères
comme la criticité de la machine et l’impact du problème. Ces niveaux se traduisent sur la
console par différentes couleurs. Celles-ci sont visibles et simples à comprendre, et ce sans
même avoir lu la moindre documentation :
• critique : rouge ;
• avertissement : orange ;
• tout va bien : vert.
Difficulté de définir les niveaux de criticité
Les administrateurs qui utilisent la solution sont les plus à même de fixer les différents
niveaux d’alerte. Lorsqu’ils définissent les éléments à superviser, ils doivent faire une liste
des problèmes qu’ils cherchent à détecter. Pour chaque problème, l’information de criticité est
importante.
Les administrateurs ont tendance à tout transformer en erreur critique. C’est une situation à
éviter. Les erreurs critiques seraient très courantes. La console de supervision serait
constamment rouge vif. Une alerte réellement critique passerait alors inaperçue. Le rouge doit
être signe qu’un service aux utilisateurs est en danger et qu’une intervention immédiate est
nécessaire.
L’inverse est également dommageable. Si le problème a un impact sur les utilisateurs et les
empêche de travailler, c’est l’objectif même du service informatique qui est touché. Si ce
dernier est soumis à contrats avec les autres services, les implications d’un tel problème
peuvent être importantes.
Dans ce genre de situation, le niveau critique est nécessaire. Les administrateurs ne doivent
pas chercher à cacher des problèmes qui peuvent être perçus par les utilisateurs.

L’information ne reste pas longtemps protégée. Des retours au service se font entendre. Si les
responsables apprennent qu’un problème n’a pas été remonté, ils demandent à l’ajouter dans
l’outil de supervision. Si le niveau de criticité n’est pas correct, ils demanderont à le faire
changer. S’ils apprennent que quelqu’un a essayé de faire disparaître l’erreur en douce, les
conséquences peuvent être fâcheuses…
4.8 Architecture générale
Un outil de supervision peut paraître un monstre de complexité lorsqu’on commence à
l’étudier : il n’en est rien. Le fonctionnement de Nagios est très simple... à condition d’en
étudier les parties une par une.
L’administrateur définit la configuration de Nagios dans des fichiers plats. Nous étudierons
par la suite leur structure. Nagios est un simple programme écrit en langage C. Si on exclut la
partie interface web de visualisation, il ne fait pas plus de 60 000 lignes de code, ce qui est
assez faible pour un outil d’une telle renommée. Nagios se lance en tant que processus
d’arrière-plan sur un serveur Unix, GNU/ Linux de préférence. Il lit la configuration fournie
par l’utilisateur et commence à ordonnancer ses vérifications. Lorsqu’il s’aperçoit d’une
erreur sur un élément supervisé, il notifie les utilisateurs concernés.
4.9 Fonctionnement de Nagios
Le principe de supervision de Nagios repose sur l'utilisation de plugins, l'un installé sur la
machine qui supporte Nagios, et l'autre sur la machine que l'on souhaite superviser. Un plugin
est un programme modifiable, qui peut être écrit dans plusieurs langages possibles, selon les
besoins, et qui servent à récupérer les informations souhaitées.
Nagios, par l'intermédiaire de son plugin, contact l'hôte souhaité et l'informe des informations
qu'il souhaite recevoir.
Le plugin correspondant installé sur la machine concernée reçoit la requête envoyée par
Nagios et ensuite va chercher dans le système de sa machine les informations demandées. Il
renvoi sa réponse au plugin Nagios, qui ensuite le transmet au moteur de Nagios afin
d'analyser le résultat obtenu et ainsi mettre à jour l'interface web.
Il existe deux types de récupération d'informations: La récupération active et la récupération
passive.
La différence entre les deux types est l'initiative de la récupération. Dans le premier type, à
savoir le type actif, c'est Nagios qui a toujours cette initiative. C'est lui qui décide quand il

envoie une requête lorsqu'il veut récupérer une information. Alors que lors d'une récupération
passive, l'envoi d'information est planifié en local, soi à partir d'une date, soit en réaction à un
événement qui se déroule sur la machine administrée.
Pour notre projet, nous avons décidé d'utiliser le type de récupération active, c’est-à-dire que
Nagios prend l'initiative d'envoyer une requête pour obtenir des informations. Ceci évite donc
de configurer les postes à superviser
La demande d'informations se fait grâce à l'exécution d'une commande de la part de Nagios.
Une commande doit obligatoirement comporter des arguments afin de pouvoir chercher les
bonnes informations sur les bonnes machines.
Ces arguments sont l'adresse IP de l'hôte sur lequel aller chercher l'information, la limite de la
valeur de l'information recherchée pour laquelle l'état 'attention' sera décidé, idem pour la
valeur 'critique', et enfin d'autres options qui varient selon le plugin utilisé.
Pour ne pas devoir à créer une commande par machine supervisée et par information
recherchée, nous pouvons remplacer les arguments par des variables, et ainsi réutiliser la
commande plusieurs fois, en remplaçant la bonne variable. Nous avons alors la possibilité de
travailler avec des services. Lors de la création d'un service, il faut l'associer à un ou plusieurs
hôtes puis à une commande.
Ensuite Nagios remplace automatiquement la variable de l’adresse IP dans la commande,
grâce à la liste d’hôtes associé au service.
Puis on doit définir manuellement dans le service les autres variables nécessaires à la
commande.
Figure 13 : Exemple des variables mis à disposition par Nagios

Un fois que Nagios a reçu les informations dont il avait besoin sur l'état des hôtes, celui-ci
peut construire des notifications sur l'état du réseau, afin d'en informer l'administrateur.
Lorsque Nagios effectue une notification, il attribut des états aux hôtes, ainsi qu'aux services.
Un hôte peut avoir les états suivants :
-Up : en fonctionnement
-Down : éteint
-Inaccessible
-En attente
Les différents états d'un service sont:
- OK
- Attention
- Critique
- En attente
- Inconnu
4.10 Installation de Nagios
Nous avons installé Nagios en suivant la documentation fournie par Nagios.
Les étapes de l’installation sont fournies en annexe. Afin de sécuriser l’interface web de
Nagios, nous avons mis en place le protocole « HTTPS » (web sécurisé). Ceci permet de
crypter les échanges entre le serveur et l’utilisateur. Pour cela nous avons ajouté un certificat
SSL à apache.
4.11 Interface graphique de Nagios
Pour accéder à l’interface de Nagios depuis l’extérieur de notre réseau, il suffit de taper dans
un navigateur web http://192.168.2.2/nagios puis de s’identifier.
Après l’identification en sera directement rediriger vers la page d’accueil de l’interface
graphique de Nagios ou on visualiser la version de Nagios utiliser utilise et aussi si on veut
faire un mise à jour pour cette version (check for updates).

Figure 14 : la page d’accueil du Nagios
L'interface graphique de Nagios est utilisée uniquement pour visualiser l'état du réseau
supervisé. Cette interface ne peut en aucun cas servir pour la configuration de Nagios.
L'interface se compose d'une partie "menu" à gauche, et une partie centrale, beaucoup plus
grande sur le reste de l'écran, qui servira à afficher les informations souhaitées Des captures
d'écran sont disponibles en annexe.
Dans le menu, nous retrouvons en premier des liens vers le site de Nagios, et vers la
documentation de ce logiciel. Ces liens sont dans la partie 'General'.
Puis une partie 'Monitoring' dans laquelle il est possible de sélectionner les informations que
l'on souhaite visualiser. Il y a de nombreux sous-menus dans cette partie ce qui permet
d'afficher vraiment les informations précises qui nous intéressent. Il y a également la
possibilité de visualiser des statistiques que Nagios a construit, ce qui est très intéressant pour
l'administrateur.
Dans la partie "Reporting" il y a la possibilité de créer des rapports et des historiques des
évènements qui se sont produits sur le réseau.
Et enfin dans la dernière partie "Configuration", il est possible de visualiser toute les
configuration grâce à laquelle Nagios sait qui et quoi supervisé.

4.12 Les plugins du Nagios
4.12.1 Plugins principaux
Nagios possède une importante communauté sur Internet. Grâce à celle-ci, de nombreux
utilisateurs ont créés des plugins permettant à Nagios d'aller récupérer des informations sur
des équipements du réseau (PC, routeurs, serveurs, …)
Les plugins n'utilisent pas tous le même protocole pour échanger les informations. Le
protocole utilisé est dans la plupart des cas un facteur décisif sur le choix des plugins à
utiliser.
Un seul plugin Nagios ne peut pas aller chercher toutes les informations sur les équipements
du réseau: En effet, chaque plugin n'a accès qu'à certaines informations (exemple: un plugin
peut aller chercher l'occupation du disque dur, et un autre l'occupation du processeur d'un
PC). Pour superviser un parc informatique, il est donc nécessaire de mettre en place plusieurs
plugins.
De plus, certains plugins peuvent aller chercher des informations sur des clients uniquement
sur certains systèmes d'exploitation (c'est le cas du plugin check_nt qui peut chercher des
informations uniquement sur des équipements Windows).
Les principaux plugins utilisés par Nagios sont :
- Check_disk : Vérifie l’espace occupé d’un disque dur.
- Check-http : Vérifie le service « http »d’un hôte
- check_ftp : Vérifie le service "ftp" d'un hôte
- check_mysql : Vérifie l'état d'une base de données MYSQL
- check_nt : Vérifie différentes informations (disque dur, processeur …) sur un système
d'exploitation Windows
- check_nrpe: Permet de récupérer différentes informations sur les hôtes
- check_ping: Vérifie la présence d'un équipement, ainsi que sa durée de réponse
- check_pop: Vérifie l'état d'un service POP (serveur mail)
- check_snmp : Récupère divers informations sur un équipement grâce au protocole
SNMP (Simple Network Management Protocol)
Il est possible de créer son propre plugin. Dans ce cas, il faudra les créer de la sorte que celui
renvoie à nagios :
- L'état du résultat (OK, CRITICAL, DOWN, UP, …)
- Une chaine de caractères (pour donner le détail du résultat)

4.12.2 Plugins retenus
Après avoir consulté les différents plugins existants, nous avons choisi ceux qui
correspondaient à notre cahier des charges.
Nous avons retenus les plugins suivants :
- Check_nt
- Check_nrpe
- Check_ping
1. Ckeck –nt
Le plugin Check_nt est un plugin récent qui permet de superviser très facilement des PC dont
le système d'exploitation est Windows.
Check_nt permet de récupérer sur un système Windows les informations suivantes :
L'espace occupé sur le disque dur, le temps depuis le démarrage de l'ordinateur, la version du
plugin NSClient ++ (voir ci-dessous), occupation du processeur, occupation de la mémoire,
état d'un service.
 Mise en place de check_nt :
i. Le plugin check-net est à installer sur la machine NAGIOS. Dans notre cas, check_nt
a été installé automatiquement (dans le dossier /etc/usr/local/nagios/libexex) lors de
l’installation de Nagios.
ii. Sur les machines à superviser, on doit installer le logiciel NSCLIENT++,
téléchargeable sur le site http://sourceforge.net/projects/nscplus
iii. Sur les machine à superviser, on doit configurer le fichier « NSC.ini ». c’est dans ce
fichier que l’on doit définir :
- Le port sue lequel NSCLIENT++ doit écouter les requetés.
- Les adresses des machines qui ont le droit de dialoguer avec NSCLIENT++(les
machines qui ont le droit de récupérer les informations sur ce poste).
- Un mot de passe (les machines qui souhaiteront dialoguer avec celle-ci par
NSCLIENT++ devront fournir ce mot de passe).
 Le fichier de configuration NSC.ini est fourni en annexe.
 Fonctionnement de check_nt :

Figure 15 : Fonctionnement du plugin Check_nt
Lorsque Nagios veut connaître une information sur un PC, il exécute le plugin check_nt.
Celui envoie une requête au PC. Sur le PC, le programme NsClient++ reçoit la requête, va
chercher les informations dans les ressources du PC et renvoie le résultat au serveur Nagios.
Usage :
Pour aller chercher les informations sur un PC grâce à check_nt, Nagios exécute une
commande ayant la syntaxe suivante :
Check_nt -H host -v variable [ -p port] [-w warning] [-c critical] [-l params]
Avec:
- H : Adresse IP de l’hôte à superviser
- v: Ce qu’il faut superviser (ex : CPULOAD)
- p: Port sur lequel il faut envoyer la requête
- w: Seuil pour lequel le résultat est considéré comme une alerte
- c: Seuil pour lequel le résultat est considéré comme critique
- l : Paramètres supplémentaires (nécessaire ou non en fonction du paramètre "v")
Pour notre projet, nous utiliserons ce plugin pour superviser tous les postes
Windows (client XP/VISTA/7/8/8.1 + Windows server 2003/2008 ) sauf pour contrôler
l'espace des dossiers des profils des utilisateurs. En effet, ce plugin ne permet pas d'effectuer
cette vérification. Nous utiliserons un autre plugin pour cela.

2. Check_nrpe
Le plugin Check_nrpe est un plugin qui permet de superviser des PC dont le système
d'exploitation est Windows ou Linux.
Check_nrpe utilise une connexion SSL (Secure Socket Layout) pour aller chercher les
informations sur les postes. Ceci permet de crypter les trames d'échanges.
 Mise en place de check_nrpe (sur Windows) :
i. le plugin check_nrpe est à installer sur la machine NAGIOS. Dans notre cas,
check_nrpe a été installé automatiquement (dans le dossier
/etc/usr/local/nagios/libexec) lors de l’installation de Nagios
ii. Sur les machines à superviser, on doit installer un logiciel permettant de dialoguer
avec check_nrpe. Le programme le plus couramment utilisé est "nrpe pluging".
Seulement, le logiciel NsClient++ permet aussi de faire des échanges avec le plugin
check_nrpe. Comme nous utilisons déjà ce programme pour check_nt, nous le
conservons aussi pour check_nrpe.
iii. Sur les machine à superviser, on doit configurer le fichier « NSC.ini ».c’est dans ce
fichier que l’on doit définir :
- Le port sur lequel NSCLIENT++ doit écouter les requêtes de check_nrpe
(différent de celui check_nt)
- Les adresses des machines qui ont le droit de dialoguer avec NSCLIENT++(les
machines qui ont le droit de récupérer les informations sur ce poste)
 Le fichier de configuration NSC.ini est fourni en annexe
 Fonctionnement de check_nrpe :
Figure 16 : Fonctionnement du plugin check_nrpe

Lorsque Nagios veut connaître une information sur un PC, il exécute le plugin check_nrpe.
Celui envoie une requête au PC. Sur le PC, le programme NsClient++ (ou nrpe si linux) reçoit
la requête, va chercher les informations dans les ressources du PC et renvoie le résultat au
serveur Nagios.
Usage :
Pour aller chercher les informations sur un PC grâce à check_nrpe, Nagios exécute une
commande ayant la syntaxe suivante :
Check_nrpe -H <adresse de l’hôte à superviser> -c <nom de la commande à exécuter sue
le serveur>
Puis sur les postes à superviser, dans le fichier de configuration (NSC.ini pour Windows,
nrpe.conf pour Linux), on doit définir la commande à exécuter pour chaque nom de
commande.
Exemple pour Windows :
Commande [check_cpu] = inject checkCPU warn=80 crit=90 5 10 15
Exemple pour Linux :
Command [check_cpu]=/usr/local/nagios/libexec/check_load -w 15,10,5
–c 30,25,20
Ces deux commandes vérifient la charge du processeur.
On remarque alors que la mise en place de nrpe dans une grande entreprise est très complexe
car il faut configurer toutes les commandes sur chaque hôte à superviser (contrairement à
check_nt qui ne nécessite pas de configuration). En revanche, nrpe offre une meilleure
sécurité puisque les échanges client – serveur sont sécurisés (grâce à SSL).
Pour notre projet, nous utilisons chec_nrpe pour :
- Superviser les clients Linux
- Recuperer la taille des dossiers de profils sous Windows

3. Check_ping
Le plugin Check_ping est un plugin qui permet de vérifier qu'un hôte est bien joignable.
Usage :
Pour vérifier qu'un hôte est joignable, Nagios exécute une commande ayant la syntaxe
suivante :
check_ping -H <adresse de l'hote> -w <temps maxi de réponse>, <Pourcentage de
réussite des pings> -c <temps maxi de réponse>, <Pourcentage de réussite des pings>
Avec :
- w : Seuil pour lequel le résultat est considéré comme une alerte
- c : Seuil pour lequel le résultat est considéré comme critique
4.13 Configuration de Nagios :
Les commandes permettant de démarrer, d'arrêter, de recharger Nagios sont les suivantes:
- Démarrer Nagios : /etc/rc.d/init.d/nagios start
- Arrêter Nagios : /etc/rc.d/init.d/nagios stop
- Recharger Nagios: /etc/rc.d/init.d/nagios reload
Après avoir modifié les fichiers de configuration de Nagios, il est très important de recharger
Nagios pour que les modifications soient prises en compte.
Il est possible de réaliser ces mêmes commandes, en mode graphique, sur l'interface de
Nagios :
Figure 17 : redémarrer ou arrêter Nagios par sa interface graphique

Pour respecter notre cahier des charges, nous devons configurer dans Nagios :
- les hôtes à superviser
- les groupes d'hôtes
- les commandes de supervision
- les services de supervision
- les contacts (les personnes qui reçoivent les alertes)
L'interface graphique de Nagios ne permet pas de configurer celui-ci. La seule manière de le
configurer, (sans utiliser d'autres outils) est de remplir les fichiers de configurations
manuellement (dans le dossier /etc/usr/local/nagios/etc/) :
Pour commencer nous allons définir le contact à notifier en cas d'alarme. Pour cela, il faut
aller dans le fichier contacts.cfg
Voici un exemple de commande que j'ai utilisé pour mon envoyer de notification des services
par e-mail. Comme on peut le voir le nom de la commande utilisée dans la définition du
contact est vient en fait du nom défini au-dessus. J'utilise mail avec les options de Nagios
pour le contact et le service qui a provoqué l'alarme.
Pour pouvoir utiliser correctement les notifications, il faiy s’assurer d’avoir installé au
préalable les applications tierces permettant d’envoyer soit des e-mail, soit des sms, puis de
modifier le fichier commands.cfg et de mettre les bonnes commandes.
Une fois nos contacts créés, il faut à présent les affecter à des groupes. La définition des
groupes se trouve dans le fichier contactgroups.cfg
Nous avons fini de configurer la première partie de Nagios. Il nous reste à présent la
configurer des différents équipements appartenant à notre réseau ainsi qur les services à
surveiller pour chaque.

Commençons tout d'abord par éditer la liste des équipements dans le fichier hosts.cfg :
On peut également définir des groupes de machines. Cela permet d’avoir une meilleure
visibilité surtout au niveau de l’interface web de Nagios.
Il ne reste plus qu’à definir les services que l’on désire surveiller.

On remarque alors que la configuration de Nagios est très complexe pour une grande
entreprise. En effet, si le parc informatique à superviser est grand, il faudra du temps pour
remplir l'intégralité des fichiers de configuration.
De plus, plus ces fichiers sont grands, plus il sera difficile pour l'administrateur réseau de s'y
retrouver.
Comme dans la plupart des cas, on supervise un réseau lorsque celui a une taille assez
importante, , la configuration de Nagios telle qu'elle sera rarement facile.
4.14 Combinaison de Nagios et Centreon
4.14.1 Pourquoi Centreon ?
Centreon est un logiciel qui s'installe par-dessus Nagios et qui permet d'améliorer l'interface
graphique, mais surtout le très gros avantage de Centreon est de pouvoir configurer Nagios
par l'interface graphique. En effet la configuration de Nagios, qui s'effectue par modification
de fichiers de configuration, devient très vite trop complexe lorsque le parc informatique à
superviser prend de l’importance.
Le principe de fonctionnement de centreon est simple. L’administrateur configure les options
de supervisions, hôtes, services, plugins, etc grâce à l’interface de centreon.
Ensuite toutes les configurations effectuées par l'administrateur sont stockées dans une base
de données, mais elles ne sont pas immédiatement appliquées au moteur Nagios.
Lorsqu'il veut appliquer ces modifications, il doit relancer Centreon, qui va alors modifier
automatiquement les fichiers de configuration de Nagios, grâce aux informations stockées
dans la base de données.
De plus, si l'administrateur réseau configure Nagios depuis les fichiers et que celui-ci fait une
faute de frappe, Nagios ne pourra pas fonctionner; dans certains cas, l'administrateur peut
mettre du temps avant de retrouver son erreur. Centreon évite ce problème car il contrôle les
données entrées par l'administrateur avant de les valider.
Cela permet de configurer Nagios avec une interface intuitive, plaisante, et moins complexe
que les fichiers de configuration que l'administrateur devait modifier lui-même, et en même

temps pouvoir visualiser l'état complet du parc informatique. C'est donc un outil complet et
indispensable lorsque le parc informatique à gérer devient complexe, comme cela est très
souvent le cas dans les entreprises.
4.14.2 Installation de Centreon :
Nous avons installé Centreon en suivant les étapes de l'installation qui sont fournies en
annexe.
Lors, de l'installeur va poser un certain nombre de questions concernant les emplacements des
différents fichiers, quelques avertissements sur certains fichiers qui risquent d'être effacés.
Pour la plupart des questions, il faut conserver la réponse par défaut.
Nous avons configuré l'interface web de Centreon de la même manière que celle de nagios :
Ensuite Centreon va installer ses plugins, puis pour finaliser l'installation, il faut se rendre sur
l’interface graphique, à l'adresse http://192.168.2.2/Centreon depuis le réseau local.
Une fois sur l'interface, il faut vérifier que tous les composants soient bien installés, puis
attribuer les mots de passes et les login pour accéder à l'interface et à la base de données..
4.14.3 Configuration de Centreon :
la page d’accueil de centreon après l’authentification
Figure 18 : La page d’accueil du Centreon

Nous avons ensuite crée les services.
Les services doivent avoir une commande (dans notre exemple ci-dessous : Ping) et doivent
être associés à des hôtes (les hôtes dont lesquels on supervisera avec ce service).Il faut ensuite
donner les valeurs des variables de la commande.
Enfin, une fois que la configuration est faite, il faut régénérer les fichiers de configuration de
Nagios.
En effet, toute la configuration crée jusqu'à présent a été stockée dans une base de données
mais n'était pas effective dans Nagios. Il faut donc transférer cette configuration dans les
fichiers de configuration Nagios.

Grace à cet outil, Centreon crée lui-même, à notre place, les fichiers de configuration cités
dans le paragraphe "Installation et configuration de Nagios".
Après avoir comparé entre la configuration de Nagios faite en remplissant manuellement les
fichiers de configuration puis entre la configuration de Nagios faite par l'interface de Centreon
nous confirmons que la deuxième méthode est beaucoup plus facile. Elle permet à
l'administrateur de mieux se repérer, de gagner du temps et d'éviter des erreurs.

4.15 NSClient++
4.15.1 Présentation de NSClient :
NSClient est un service pour toutes versions de Windows (NT, 2000, 2003, XP et Vista) 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 32 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 Nagios pour plateformes Windows.
Figure 19 : Logo du NSClient ++
L’installation de NSClient++ ne pose pas de problème grâce au format d’installation .msi
fourni Il suffit de valider par le bouton next chacun des écrans présentés. Le logiciel est
installé par défaut dans le répertoire C:Program FilesNSClient++. Il contient le fichier
exécutable de service nsclient++, le répertoire modules contenant les extensions de
NSClient++ et le fichier de configuration NSC.ini. Une entrée dans le menu Démarrer est
également créée, permettant de stopper et démarrer le service.
Nous allons installer l'addon NSClient++ sur la machine Windows et utiliser le greffon
check_nt pour communiquer avec NSCLient++. Ce greffon check_nt est déjà installé vu que
Nagios l'est. Vous pouvez le trouver dans le fichier "commands.cfg".
Il est possible d'utiliser d'autres agents Windows (comme NC_Net) mais il faudra dans ce cas
modifier les commandes et les définitions de services... Mais nous, nous utiliserons
NSClient++.
4.15.2 L’installation de l’agent
Une fois télécharger il faut dézipper l’archive par exemple dans C: Maintenant il fautouvrir
une invite de commande dans C:NSClient Et tapez ce qui suit :
Nsclient++.exe /install
Nstray.exe

Rapport stage onee-be_2

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Rapport stage onee-be_2

Semelhante a Rapport stage onee-be_2 (20)

Rapport stage onee-be_2