SlideShare une entreprise Scribd logo
1  sur  72
Télécharger pour lire hors ligne
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
ONEE -Branche Eau
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
Table des matières ONEE -Branche Eau
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
Table des matières ONEE -Branche Eau
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
Partie 1 : Présentation de L’ONEE-Branche Eau ONEE -Branche Eau
3 Partie 1 : Présentation de l’ONEE-Branche Eau | 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 ;
Partie 1 : Présentation de L’ONEE-Branche Eau ONEE -Branche Eau
4 Partie 1 : Présentation de l’ONEE-Branche Eau | ONEE Branche Eau
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.
Partie 1 : Présentation de L’ONEE-Branche Eau ONEE -Branche Eau
5 Partie 1 : Présentation de l’ONEE-Branche Eau | ONEE Branche Eau
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
Partie 1 : Présentation de L’ONEE-Branche Eau ONEE -Branche Eau
6 Partie 1 : Présentation de l’ONEE-Branche Eau | ONEE Branche Eau
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.
Partie 3 : La supervision Réseau ONEE -Branche Eau
10 Partie 3 : La supervision Réseau | ONEE Branche Eau
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.
Partie 3 : La supervision Réseau ONEE -Branche Eau
11 Partie 3 : La supervision Réseau | ONEE Branche Eau
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
Partie 3 : La supervision Réseau ONEE -Branche Eau
12 Partie 3 : La supervision Réseau | ONEE Branche Eau
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...
Partie 3 : La supervision Réseau ONEE -Branche Eau
13 Partie 3 : La supervision Réseau | ONEE Branche Eau
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.
Partie 3 : La supervision Réseau ONEE -Branche Eau
14 Partie 3 : La supervision Réseau | ONEE Branche Eau
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
Partie 3 : La supervision Réseau ONEE -Branche Eau
15 Partie 3 : La supervision Réseau | ONEE Branche Eau
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
Partie 3 : La supervision Réseau ONEE -Branche Eau
16 Partie 3 : La supervision Réseau | ONEE Branche Eau
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
Partie 3 : La supervision Réseau ONEE -Branche Eau
17 Partie 3 : La supervision Réseau | ONEE Branche Eau
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
Partie 3 : La supervision Réseau ONEE -Branche Eau
18 Partie 3 : La supervision Réseau | ONEE Branche Eau
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 :
Partie 3 : La supervision Réseau ONEE -Branche Eau
19 Partie 3 : La supervision Réseau | ONEE Branche Eau
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.
Partie 3 : La supervision Réseau ONEE -Branche Eau
20 Partie 3 : La supervision Réseau | ONEE Branche Eau
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
Partie 3 : La supervision Réseau ONEE -Branche Eau
21 Partie 3 : La supervision Réseau | ONEE Branche Eau
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.
Partie 3 : La supervision Réseau ONEE -Branche Eau
22 Partie 3 : La supervision Réseau | ONEE Branche Eau
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
SNMPv2-MIB::sysUpTime.0 = Timeticks: (3683342256) 426 days, 7:30:22.56
Il est aussi possible de mettre directement le nom de chaque noeud :
# snmpget -v 2c -c public 10.10.100.1 system.sysUpTime.0
SNMPv2-MIB::sysUpTime.0 = Timeticks: (3683349087) 426 days, 7:31:30.87
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…).
Partie 3 : La supervision Réseau ONEE -Branche Eau
23 Partie 3 : La supervision Réseau | ONEE Branche Eau
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
Partie 3 : La supervision Réseau ONEE -Branche Eau
24 Partie 3 : La supervision Réseau | ONEE Branche Eau
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.
Partie 3 : La supervision Réseau ONEE -Branche Eau
25 Partie 3 : La supervision Réseau | ONEE Branche Eau
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.
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
27 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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..
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
28 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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.
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
29 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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.
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
30 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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.
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
31 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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.
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
32 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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.
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
33 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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.
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
34 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
35 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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.
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
36 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
37 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
38 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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).
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
39 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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é.
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
40 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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)
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
41 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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 :
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
42 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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.
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
43 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
44 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
45 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
46 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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.
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
47 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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.
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
48 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
49 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
50 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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.
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
51 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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.
Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau
52 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau
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
Rapport stage onee-be_2
Rapport stage onee-be_2
Rapport stage onee-be_2
Rapport stage onee-be_2
Rapport stage onee-be_2
Rapport stage onee-be_2
Rapport stage onee-be_2
Rapport stage onee-be_2
Rapport stage onee-be_2
Rapport stage onee-be_2
Rapport stage onee-be_2

Contenu connexe

Tendances

Présentation projet de fin d'étude
Présentation projet de fin d'étudePrésentation projet de fin d'étude
Présentation projet de fin d'étudeDonia Hammami
 
Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiquejihene Ab
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...Hajer Dahech
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Ben Abdelwahed Slim
 
Rapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIARapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIAAhmed BEN JEMIA
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Anouar Kacem
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...Mohamed Amine Mahmoudi
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stageL Mehdi
 
Rapport PFE faten_chalbi
Rapport PFE faten_chalbiRapport PFE faten_chalbi
Rapport PFE faten_chalbiFaten Chalbi
 
Rapport de projet de fin d'études - SIEMENS 2016
Rapport de projet de fin d'études - SIEMENS 2016Rapport de projet de fin d'études - SIEMENS 2016
Rapport de projet de fin d'études - SIEMENS 2016Soufiane KALLIDA
 
Plateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesPlateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesMajdi SAIBI
 
Rapport de Stage -Finale.pdf
Rapport de Stage -Finale.pdfRapport de Stage -Finale.pdf
Rapport de Stage -Finale.pdfWaelTOUMI2
 
rapport de stage
rapport de stagerapport de stage
rapport de stageMarouane Gh
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Addi Ait-Mlouk
 
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed AmineRapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed AmineMohamed Amine Mahmoudi
 

Tendances (20)

Rapport de PFE
Rapport de PFERapport de PFE
Rapport de PFE
 
Présentation projet de fin d'étude
Présentation projet de fin d'étudePrésentation projet de fin d'étude
Présentation projet de fin d'étude
 
Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatique
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
 
Rapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFERapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFE
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2
 
Rapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIARapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIA
 
Rapport pfe licence
Rapport pfe licenceRapport pfe licence
Rapport pfe licence
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
 
Rapport PFE faten_chalbi
Rapport PFE faten_chalbiRapport PFE faten_chalbi
Rapport PFE faten_chalbi
 
Rapport de projet de fin d'études - SIEMENS 2016
Rapport de projet de fin d'études - SIEMENS 2016Rapport de projet de fin d'études - SIEMENS 2016
Rapport de projet de fin d'études - SIEMENS 2016
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
 
Page de garde
Page de gardePage de garde
Page de garde
 
Plateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesPlateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'études
 
Rapport de Stage -Finale.pdf
Rapport de Stage -Finale.pdfRapport de Stage -Finale.pdf
Rapport de Stage -Finale.pdf
 
rapport de stage
rapport de stagerapport de stage
rapport de stage
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...
 
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed AmineRapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
 

Similaire à Rapport stage onee-be_2

Système de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans filSystème de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans filSamia HJ
 
Dvp chaine mesure gsm
Dvp chaine mesure gsmDvp chaine mesure gsm
Dvp chaine mesure gsmMohamed Jacem
 
Mesure de la performance du SI de camtel nguimo hermann 5.0
Mesure de la performance du SI de camtel  nguimo hermann 5.0Mesure de la performance du SI de camtel  nguimo hermann 5.0
Mesure de la performance du SI de camtel nguimo hermann 5.0Hermann NGUIMO
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESTombariAhmed
 
Gestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distanceGestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distanceahmed oumezzine
 
Rapport PFE : Cloud Insights
Rapport PFE : Cloud InsightsRapport PFE : Cloud Insights
Rapport PFE : Cloud Insightsahmed oumezzine
 
Mémoire : Cloud iaas Slim Hannachi
Mémoire :  Cloud iaas Slim HannachiMémoire :  Cloud iaas Slim Hannachi
Mémoire : Cloud iaas Slim Hannachislim Hannachi
 
Medical openerp
Medical openerpMedical openerp
Medical openerpHORIYASOFT
 
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...Karima Torkhani
 
Pfe master fst_final_decembre2015
Pfe master fst_final_decembre2015Pfe master fst_final_decembre2015
Pfe master fst_final_decembre2015Ghali Rahma
 
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...karimatorkhani
 
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...Karima Torkhani
 
rapport fin d'etude
rapport fin d'etuderapport fin d'etude
rapport fin d'etudesihem-med
 
Mise en place d'une infrastructure basée sur OpenStack
Mise en place d'une infrastructure basée sur OpenStack Mise en place d'une infrastructure basée sur OpenStack
Mise en place d'une infrastructure basée sur OpenStack Ahmed Slim
 
Rapport_PFE_Securite (1).pdf
Rapport_PFE_Securite (1).pdfRapport_PFE_Securite (1).pdf
Rapport_PFE_Securite (1).pdfAhmedDhib6
 
AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...
AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...
AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...RidhaChayeh1
 
Rapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdf
Rapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdfRapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdf
Rapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdfLARAFA Mohamed Akram
 
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...YounesAGABI
 

Similaire à Rapport stage onee-be_2 (20)

Système de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans filSystème de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans fil
 
Dvp chaine mesure gsm
Dvp chaine mesure gsmDvp chaine mesure gsm
Dvp chaine mesure gsm
 
Mesure de la performance du SI de camtel nguimo hermann 5.0
Mesure de la performance du SI de camtel  nguimo hermann 5.0Mesure de la performance du SI de camtel  nguimo hermann 5.0
Mesure de la performance du SI de camtel nguimo hermann 5.0
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
 
Gestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distanceGestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distance
 
Rapport PFE : Cloud Insights
Rapport PFE : Cloud InsightsRapport PFE : Cloud Insights
Rapport PFE : Cloud Insights
 
Rapport finiale
Rapport finialeRapport finiale
Rapport finiale
 
Mémoire : Cloud iaas Slim Hannachi
Mémoire :  Cloud iaas Slim HannachiMémoire :  Cloud iaas Slim Hannachi
Mémoire : Cloud iaas Slim Hannachi
 
Medical openerp
Medical openerpMedical openerp
Medical openerp
 
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
 
Pfe master fst_final_decembre2015
Pfe master fst_final_decembre2015Pfe master fst_final_decembre2015
Pfe master fst_final_decembre2015
 
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
 
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
 
rapport fin d'etude
rapport fin d'etuderapport fin d'etude
rapport fin d'etude
 
pfe final.docx
pfe final.docxpfe final.docx
pfe final.docx
 
Mise en place d'une infrastructure basée sur OpenStack
Mise en place d'une infrastructure basée sur OpenStack Mise en place d'une infrastructure basée sur OpenStack
Mise en place d'une infrastructure basée sur OpenStack
 
Rapport_PFE_Securite (1).pdf
Rapport_PFE_Securite (1).pdfRapport_PFE_Securite (1).pdf
Rapport_PFE_Securite (1).pdf
 
AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...
AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...
AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...
 
Rapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdf
Rapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdfRapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdf
Rapport_Memoire_Mastère_SRT_LARAFA_Mohamed_Akram.pdf
 
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
 

Rapport stage onee-be_2

  • 1. 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. Table des matières ONEE -Branche Eau 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
  • 7. Table des matières ONEE -Branche Eau 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
  • 8. 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
  • 9. 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.
  • 10. 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
  • 11. Partie 1 : Présentation de L’ONEE-Branche Eau ONEE -Branche Eau 3 Partie 1 : Présentation de l’ONEE-Branche Eau | 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 ;
  • 12. Partie 1 : Présentation de L’ONEE-Branche Eau ONEE -Branche Eau 4 Partie 1 : Présentation de l’ONEE-Branche Eau | ONEE Branche Eau 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.
  • 13. Partie 1 : Présentation de L’ONEE-Branche Eau ONEE -Branche Eau 5 Partie 1 : Présentation de l’ONEE-Branche Eau | ONEE Branche Eau 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
  • 14. Partie 1 : Présentation de L’ONEE-Branche Eau ONEE -Branche Eau 6 Partie 1 : Présentation de l’ONEE-Branche Eau | ONEE Branche Eau 1.7 Les missions de L’ONEE-Branche Eau Figure 2 : Quelques missions de L’ONEE- Branche Eau
  • 15. 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
  • 16. 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.
  • 17. 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.
  • 18. Partie 3 : La supervision Réseau ONEE -Branche Eau 10 Partie 3 : La supervision Réseau | ONEE Branche Eau 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.
  • 19. Partie 3 : La supervision Réseau ONEE -Branche Eau 11 Partie 3 : La supervision Réseau | ONEE Branche Eau 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
  • 20. Partie 3 : La supervision Réseau ONEE -Branche Eau 12 Partie 3 : La supervision Réseau | ONEE Branche Eau 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...
  • 21. Partie 3 : La supervision Réseau ONEE -Branche Eau 13 Partie 3 : La supervision Réseau | ONEE Branche Eau 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.
  • 22. Partie 3 : La supervision Réseau ONEE -Branche Eau 14 Partie 3 : La supervision Réseau | ONEE Branche Eau 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
  • 23. Partie 3 : La supervision Réseau ONEE -Branche Eau 15 Partie 3 : La supervision Réseau | ONEE Branche Eau 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
  • 24. Partie 3 : La supervision Réseau ONEE -Branche Eau 16 Partie 3 : La supervision Réseau | ONEE Branche Eau 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
  • 25. Partie 3 : La supervision Réseau ONEE -Branche Eau 17 Partie 3 : La supervision Réseau | ONEE Branche Eau 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
  • 26. Partie 3 : La supervision Réseau ONEE -Branche Eau 18 Partie 3 : La supervision Réseau | ONEE Branche Eau 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 :
  • 27. Partie 3 : La supervision Réseau ONEE -Branche Eau 19 Partie 3 : La supervision Réseau | ONEE Branche Eau 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.
  • 28. Partie 3 : La supervision Réseau ONEE -Branche Eau 20 Partie 3 : La supervision Réseau | ONEE Branche Eau 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
  • 29. Partie 3 : La supervision Réseau ONEE -Branche Eau 21 Partie 3 : La supervision Réseau | ONEE Branche Eau 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.
  • 30. Partie 3 : La supervision Réseau ONEE -Branche Eau 22 Partie 3 : La supervision Réseau | ONEE Branche Eau 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 SNMPv2-MIB::sysUpTime.0 = Timeticks: (3683342256) 426 days, 7:30:22.56 Il est aussi possible de mettre directement le nom de chaque noeud : # snmpget -v 2c -c public 10.10.100.1 system.sysUpTime.0 SNMPv2-MIB::sysUpTime.0 = Timeticks: (3683349087) 426 days, 7:31:30.87 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…).
  • 31. Partie 3 : La supervision Réseau ONEE -Branche Eau 23 Partie 3 : La supervision Réseau | ONEE Branche Eau 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
  • 32. Partie 3 : La supervision Réseau ONEE -Branche Eau 24 Partie 3 : La supervision Réseau | ONEE Branche Eau 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.
  • 33. Partie 3 : La supervision Réseau ONEE -Branche Eau 25 Partie 3 : La supervision Réseau | ONEE Branche Eau 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.
  • 34. 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.
  • 35. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 27 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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..
  • 36. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 28 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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.
  • 37. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 29 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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.
  • 38. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 30 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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.
  • 39. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 31 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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.
  • 40. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 32 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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.
  • 41. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 33 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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.
  • 42. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 34 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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
  • 43. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 35 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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.
  • 44. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 36 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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
  • 45. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 37 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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
  • 46. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 38 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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).
  • 47. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 39 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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é.
  • 48. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 40 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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)
  • 49. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 41 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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 :
  • 50. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 42 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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.
  • 51. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 43 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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
  • 52. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 44 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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
  • 53. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 45 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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
  • 54. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 46 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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.
  • 55. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 47 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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.
  • 56. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 48 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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
  • 57. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 49 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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
  • 58. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 50 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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.
  • 59. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 51 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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.
  • 60. Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau 52 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau 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