rapport stage onee-be_2

Université Mohammed V-Agdal

Ecole Supérieure de Technologie-Salé

Département : Informatique

Filière : Administration Réseaux Informatiques

Rapport de stage :

La mise en place d’un outil de

supervision réseau : ‘NAGIOS’

Elaboré par : Mounir KAALI

Effectué au sein de : ONEE-Branche Eau

Dans le la division de Réseaux et Télécoms.

Au service de l’ingénierie.

Encadrant du stage: Mme Houda TAHRI

Tutrice de l’ESTS : Mme Naoual BERBICHE

Année universitaire 2013/2014

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


iv

3.1.2.1 Définition ....................................................................................................................... 10

3.1.2.2 La supervision.. Pourquoi ? ........................................................................................... 10

3.2 Intérêt de la supervision et de la métrologie. ............................................................................. 11

3.2.1 Être alerté en temps réel ...................................................................................................... 11

3.2.1.1 Les problèmes sont inévitables ..................................................................................... 11

3.2.1.2 Les utilisateurs : un moyen de supervision peu fiable et pas toujours agréable .......... 12

3.2.2 Surveiller plus que le système d’information ....................................................................... 13

3.2.2.1 Un ordonnanceur ? ........................................................................................................ 13

3.2.2.2 Supervision physique d’une salle machine ................................................................... 14

3.3 Les méthodes de la supervision .................................................................................................. 15

3.3.1. Les méthodes actives .......................................................................................................... 15

3.3.2. Les méthodes passives ........................................................................................................ 16

3.4 Les outils disponibles ................................................................................................................... 17

3.1.1 Le protocole SNMP et sa MIB .............................................................................................. 17

3.1.1.1 A quoi ca sert ? .............................................................................................................. 17

3.1.1.2 La M.I.B. ......................................................................................................................... 19

3.1.1.3 La S.M.I. ......................................................................................................................... 20

3.1.1.4 Fonctionnement ............................................................................................................ 21

4.1.6. La sécurité........................................................................................................................ 23

3.2 Conclusion ................................................................................................................................... 25

Partie 4 : Choix d’une solution de supervision : Nagios ................................................................ 26

4.1 Choix d’une licence open source ................................................................................................. 26

4.2 Le besoin d’adaptabilité et de modularité .................................................................................. 26

4.3 Transparence du mécanisme de remontée d’alerte ................................................................... 27

4.4 Le choix de Nagios ....................................................................................................................... 27

4.4.1 Histoire de Nagios ................................................................................................................ 27

4.4.2 Nagios ne fait rien sans ses plug-ins ..................................................................................... 28

4.5 Atouts de Nagios par rapport aux autres outils open source ..................................................... 28

4.5.1 Zabbix : la supervision simplement ...................................................................................... 28

4.5.2 Cacti : la métrologie avec SNMP........................................................................................... 29

4.5.3 OpenNMS : la supervision très SNMP .................................................................................. 29

4.5.4 Zenoss : très bonne supervision, mais pas complètement libre .......................................... 30

4.6 Orientation vers une totale modularité : tout est plug-in ........................................................... 30

4.6.1 La modularité de Nagios : le rôle des plug-ins ..................................................................... 30


v

4.6.2 Des plug-ins pour avertir ou réagir ....................................................................................... 31

4.7 Capacité à gérer un parc important de machines ....................................................................... 31

4.7.1 Performances de Nagios ....................................................................................................... 32

4.7.2 Gestion de la configuration .................................................................................................. 33

4.7.3 Gestion des alertes ............................................................................................................... 33

4.7.3.1 De l’intérêt de filtrer correctement les alertes ............................................................. 33

4.7.3.1 Concision des alertes ..................................................................................................... 33

4.7.3.2 Bien choisir le niveau d’erreur ...................................................................................... 35

4.8 Architecture générale .................................................................................................................. 36

4.9 Fonctionnement de Nagios ......................................................................................................... 36

4.10 Installation de Nagios ................................................................................................................ 38

4.11 Interface graphique de Nagios .................................................................................................. 38

4.12 Les plugins du Nagios ................................................................................................................ 40

4.12.1 Plugins principaux ............................................................................................................... 40

4.12.2 Plugins retenus ....................................................................................................................... 41

4.13 Configuration de Nagios : .......................................................................................................... 45

4.14 Combinaison de Nagios et Centreon ......................................................................................... 48

4.14.1 Pourquoi Centreon ? .......................................................................................................... 48

4.14.2 Installation de Centreon : ................................................................................................... 49

4.14.3 Configuration de Centreon : ............................................................................................... 49

4.15 NSClient++ ................................................................................................................................. 52

4.15.1 Présentation de NSClient :.................................................................................................. 52

4.15.2 L’installation de l’agent ...................................................................................................... 52

Conclusion ................................................................................................................................. 55

Bibliographie & Webographie ..................................................................................................... 56

Annexes ..................................................................................................................................... 57

Liste des figures ONEE -Branche Eau

vi

Liste des figures

Figure 1 : L’organigramme de L’ONEE- Branche Eau _______________________________________ 2

Figure 2 : Quelques missions de L’ONEE- Branche Eau ____________________________________ 6

Figure 3 : Le réseau à superviser ______________________________________________________ 8

Figure 4 : Exemple d’une opération de la métrologie ______________________________________ 9

Figure 5 : Exemple de PING _________________________________________________________ 15

Figure 6 : La supervision passive _____________________________________________________ 16

Figure 7 : Administration de tous les équipements réseaux ________________________________ 17

Figure 8 : Echange de trames entre un agent SNMP et la console de gestion(le Client) __________ 19

Figure 9 : Les Objets gérés par le protocole MIB ________________________________________ 20

Figure 10 : Définir un objet dans la SMI _______________________________________________ 20

Figure 11 : L’arborescence de définition de l’objets sysUPTime. ____________________________ 21

Figure 12 : Partie d’une trame de réponse SNMP, la communauté apparaît bien en clair ___ 23

Figure 13 : Exemple des variables mis à disposition par Nagios ____________________________ 37

Figure 14 : la page d’accueil du Nagios ________________________________________________ 39

Figure 15 : Fonctionnement du plugin Check_nt ________________________________________ 42

Figure 16 : Fonctionnement du plugin check_nrpe ______________________________________ 43

Figure 17 : redémarrer ou arrêter Nagios par sa interface graphique ________________________ 45

Figure 18 : La page d’accueil du Centreon _____________________________________________ 49

Figure 19 : Logo du NSClient ++ ______________________________________________________ 52

Figure 20 : le fichier NSC.ini _________________________________________________________ 53

Introduction ONEE -Branche Eau

1 Introduction| ONEE Branche Eau

Introduction

Dans le cadre de nos études, et dans le but d’approfondir nos connaissances dans le domaine

informatique, de mettre en pratique nos diverses connaissances théoriques, d’avoir un esprit

de groupe, et aussi un contact avec le milieu professionnel, j’ai effectué un stage de fin

d’études de 7 semaines (du 15/04/2014 au 04/06/2014) au sein de la direction de contrôle de

gestion et de système d’information à l’Office National de L’ELECTRICITE ET l’EAU

POTABLE Branche Eau de RABAT.

Les entreprises d'aujourd'hui sont de plus en plus dépendantes de leur système d'information

et sont par conséquent de plus en plus vulnérables. La perte d'un serveur ou d'un actif réseau

peut ralentir, voire stopper complètement leur activité.

Les besoins en termes de disponibilité et de qualité de service n'ont jamais été aussi

importants. Réagir rapidement en cas de panne devient donc absolument indispensable.

La suite de mon travail au sein du service ingénierie de DSI de l’ONEE-Branche Eau a été

consacrée à l’étude et la mise en place d’une solution de supervision Open Source basée sur

Nagios. En évoquant les principes fondamentaux de la supervision et de la métrologie.

Ce rapport commence par une présentation de l’ONEE-Branche Eau (OFFICE NATIONAL

DE L’ELECTRICITE ET L’EAU POTABLE), l’entreprise dans laquelle j’ai effectué mon

stage, ensuite l’objectif de ce dernier est d'étudier le concept de la supervision réseau après je

vais installer et configurer un serveur de supervision sous Nagios qui nous permettra de

répondre à ces demandes.

Partie 1 : Présentation de L’ONEE-Branche Eau ONEE -Branche Eau

2 Partie 1 : Présentation de l’ONEE-Branche Eau | ONEE Branche Eau

Partie 1 : Présentation de L’ONEE-Branche Eau

1.1 Fiche Technique de L’ONEE-Branche Eau

Raison sociale : Office National de l’électricité et l’Eau Potable

Type de société : Public

Forme juridique : Etablissement a caractère Industriel et commercial doté de la

personnalité morale et l’autonomie financière.

Capital : 7520000000dh.

Date de création : Le 3 avril 1972.

Adresse : ONEP, station de traitement Avenue Belhsessan ELOUAZZANI 10002-

RABAT

Téléphone : 0637-75-96-00

Fax : 0637-75-31-28

Site web : www.onep.org.ma

E-mail : [email protected]

1.2 Organigramme de L’ONEE-Branche Eau

Figure 1 : L’organigramme de L’ONEE- Branche Eau



1.3 Historique de L’ONEE- Branche Eau

Crée en 1972 en substitution à la Régie des Exploitations Industrielles (R.E.I) par le dahir

N°172103 du 3 avril 1972, l’office national de l’eau potable désigné sous le sigle « O.N.E.P »

est un établissement semi-public à caractère commercial et industriel doté de l’autonomie

financière est placé sous la tutelle du ministère d’aménagement du territoire de l’Eau et de

l’environnement et sous le contrôle du ministère de finance.

La disparition de la REI et son remplacement par l’Office National de l’Eau Potable (ONEP)

ont impulsé une dynamique à l’AEP au milieu urbain autorisant l’extension des réseaux dans

les grandes villes et la couverture des petites villes et des petits centres.

L’O.N.E.P a été crée suite au développement économique de notre pays qui s’est vu accéléré.

Ce dynamisme de croissance n’a pas manqué de s’accompagner d’un changement intégral

dans l’ampleur des besoins en eau et dans la nature même de cette denrée vitale pour

l’hygiène et la santé, si indispensable au bien-être.

1.4 Les Activités de l’ONEE- Branche Eau

1.4.1 Les activités principales :

Le Dahir n°172103 d’avril 1972, a énumère les principales tâches de l’O.N.E.E comme suit

La planification de l’approvisionnement du Royaume en eau potable. Dans ce

cadre :

Il détermine l’évolution des besoins en eau potable et obtient la réservation des

ressources correspondantes.

Il coordonne tous les programmes d’investissement relatifs aux adductions d’eau potable.

L’étude, la réalisation et la gestion des adductions de l’eau potable que le gouvernement

lui confie.

La gestion des distributions de l’eau potable ;



1.4.2 Les Activités particuliers :

L’ONEE- Branche Eau est chargé de :

Adduction régionale.

Système tarifaire et contribution de solidarité.

Contrôle de la qualité de l’eau.

Déminéralisation et dessalement d’eau de mer.

Assainissement.

Formation et coopération.

Sensibilisation.

1.5 La structure administrative du l’ONEE- Branche Eau

Son siège est à Rabat, sa gestion est assurée par un directeur général chargé de l’exécution des

décisions du conseil d’administration et du comité technique permanent.

L’administration de l’O.N.E.E-Branche Eau est assurée par deux organes suprêmes .

Un conseil d’administration : présidé par le Premier ministre ou le ministère

d’aménagement du territoire de l’Eau et de l’environnement, il se réunit au moins deux

fois par an.

Un comité technique : permanent présidé par le ministère d’aménagement du territoire

de l’Eau et de l’environnement. Ce comité est chargé de suivre l’exécution des décisions

arrêtées par le conseil d’administration et se réunit au moins deux fois par trimestre.



1.6 La direction contrôle de gestion et système d’information

La direction contrôle de gestion et système d’information présente les enjeux du pilotage des

coûts et des gains de la fonction système d’information, ainsi que des méthodes et outils de

gestion couramment utilisés en entreprise.

Pour fonctionner, le contrôle de gestion informatique couvre les cinq étapes fondamentales de

tout système de pilotage :

Planification stratégique et opérationnelle

Modélisation du système de gestion

Conception et animation de la procédure budgétaire

Mesure des performances

Contrôle de performances

1.6.1 Organigramme de direction contrôle de gestion et système d’information

Direction contrôle de gestion et système d’information

Div. Contrôle de

gestion

Div. Gouvernance et

PMO SI

Div. Administration et

exploitation du système

d’information

Div. Centre

compétences

SI

Div. Réseaux et

Télécoms

Sce. Prévisions

Budgétaires

Sce.

Contractualisati

on interne

Sce. Tableaux

de Bords et

Roporting

Sce. Conseil

d’Administratio

n et Rapports de

gestion

Sce. Gestion

Portefeuille

Projets SI

Sce. Veille

Technologique

et normalisation

Sce. SIG

Sce. Utilities

Sce. Projets SI

Support

Sce.

Administration

Bases de

données et ERP

Sce.

Administration

Systèmes

Sce.

Infrastructure

informatique

utilisateurs

Sce. Support

des utilisateurs

Sce. Conduite

de changement

Sce.

Technique

SAP

Sce. Expertise

FI/CO SAP

Sce. Expertise

RH

Sce. Expertise

PEQ

Sce. Système

Décisionnel

Sce.

Ingénierie

Sce.

Infrastructure

Sce. Sécurité

SI



1.7 Les missions de L’ONEE-Branche Eau

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

Partie 2 : Présentation du sujet et de son concept ONEE -Branche Eau

7 Partie 2 : Présentation du sujet et de son concept| ONEE Branche Eau

Partie2 : Présentation du sujet et de son concept

2.1 Objectifs

2.1.1 Cadre et besoins

Le stage se déroule dans un environnement comportant un parc d’une dizaine des machines et

de quelques serveurs plus un routeur et des commutateurs.

L’administrateur ne peut pas déterminer directement d’où vienne le problème lorsqu’une

machine est manquante sur le plan. Est-ce le port qui est désactivé, est-ce la machine qui est

éteinte ou l’interface réseau de cette machine qui est hors-service ? L’administrateur ne peut

pas non plus déterminer si un service particulier sur un serveur donné fonctionne

correctement. Enfin, le simple fait de détecter qu’une anomalie existe derrière tel port de tel

commutateur ne peut se faire sans regarder le plan de façon fréquente ou sans qu’un

utilisateur ne déboule dans le bureau afin d’alerter l’administrateur. L’objet du stage est alors

de trouver une solution afin de devenir < pro-actif > face aux problèmes rencontrés ; de

pouvoir contrôler d’un simple coup d’œil l’état global du réseau, de déterminer l’origine d’un

problème afin d’y remédier le plus rapidement possible. Ces quelques critères rentrent dans le

domaine de la supervision de réseaux, essentiel pour assurer une disponibilité (souvent

indispensable) du système d’information de l’entreprise. Nous définissons dans un premier

temps ce que nous entendons par < supervision de réseaux > avant d’énoncer un comparatif

des solutions actuelles du marché puis à nous pencher sur celle que nous avons choisie de

mettre en place en présentant les notions l’entourant, pour cela on a construit un réseau de

test.

2.1.2 Cahier des charges

L’administrateur réseau devra pouvoir surveiller son réseau via une interface web sécurisée.

N’importe qui ne doit pas pouvoir accéder à cette interface, elle devra donc être protégée par

un mot de passe. L’interface web devra comporter une cartographie du réseau, présentant les

différents postes utilisateurs, les serveurs, les éléments actifs et imprimantes. Cette

cartographie devra explicitement décrire l’état de ces machines ; permettre d’identifier l’état

Partie 2 : Présentation du sujet et de son concept ONEE -Branche Eau

8 Partie 2 : Présentation du sujet et de son concept| ONEE Branche Eau

des ports des commutateurs sur ces mêmes machines serait un plus. L’interface devra

permettre également, étant donné une machine, de vérifier que les services tournent

correctement ou non.

Des renseignements supplémentaires sur les différentes machines (charge CPU, espace

disque, mémoire disponible, etc.) pourront être renseignés. Enfin, lorsque des problèmes

surviendront, l’administrateur devra être notifié par un courriel dont le contenu indiquera le

service et ou la machine défectueuse. La solution devra bien entendu être la moins chère du

monde libre : Nagios.

2.1.3 Réseau à superviser

pour mieux étudier et mettre en place une solution de supervision Open Source basée

sur Nagios et en évoquant les principes fondamentaux de la supervision et de la

métrologie. On va appliquer ses notions de base de l’outil Nagios dans une étude de cas

contenant le petit réseau local suivant :

Figure 3 : Le réseau à superviser

Il sera composé :

- D’un serveur « Nagios » qui s’occupera de la supervision du réseau, de la

centralisation et de l’analyse des informations du réseau.

- D’un poste client « WinXP »

- D’un poste client « Win7 »

- D’un poste client « WinVista »

- D’un Routeur « Cisco »qui permettra de relier le Serveur Nagios à internet.

Partie 3 : La supervision Réseau ONEE -Branche Eau

9 Partie 3 : La supervision Réseau | ONEE Branche Eau

Partie 3 : La supervision Réseau

3.1 Introduction à la supervision et à la métrologie.

3 .1.1 La métrologie

3.1.1.1 Définition générale

D’après l’encyclopédie libre Wikipédia : La mesure est l'opération qui consiste à donner une

valeur numérique à une grandeur. Par exemple, la mesure des dimensions d'un objet va

donner les valeurs chiffrées de sa longueur, sa largeur...

La notion de mesure est omniprésente :

Figure 4 : Exemple d’une opération de la métrologie

3.1.1.2 Dans le domaine des télécommunications

Dans mon cas, c’est bien sûr la métrologie appliquée aux réseaux informatiques voir

téléphoniques. La métrologie revient à faire des relevés de valeurs comme relever la bande

passante utilisée sur un lien, la répartition des protocoles et des services… Il doit être aussi

possible de relever des informations précises sur un équipement constituant le réseau comme

la charge du processeur, de la mémoire…

En résumé un système de métrologie efficace permet :

de détecter d’éventuels engorgements du réseau, des trafics suspects, une machine

piratée…

de pouvoir redimensionner des liens sous dimensionnés ou surdimensionnés

de détecter un besoin de redémarrage de certains équipements ou d’augmenter leur

mémoire.



Attention la métrologie consiste à ne remonter que des informations quantitatives comme

le nombre d’utilisateurs connecté sur un serveur Web et non pas quelle page Web Bob

regarde ! Il va donc être nécessaire de définir de manière précise ce que l’on va mesurer.

3.1.2 La supervision

3.1.2.1 Définition

Le terme superviser désigne l’action de regarder au dessus de l’information,

contrairement à celui de surveiller qui signifie veiller sur.

La supervision représente, de manière générale, toute fonction consistant à indiquer et

à commander l'état d'un appel, d'un système ou d'un réseau. Les solutions de supervision

permettent de remonter des informations techniques et fonctionnelles du système

d'information.

La supervision système et réseau a pour but de surveiller le bon fonctionnement des

composants réseaux (commutateurs, routeurs, firewalls, …) et leurs caractéristiques (charge

du réseau, …) ; ainsi que les éléments des systèmes (serveurs, machines UNIX, …) et les

services qu’ils offrent (protocoles, …).

3.1.2.2 La supervision.. Pourquoi ?

Si le réseau ne possède pas de système de supervision :

• Il peut être piraté sans que les administrateurs s’en rendent compte (détection d’un

nouveau service).

• Lors d’une panne, ce sont les utilisateurs qui informent les administrateurs.



Donc pour que les administrateurs soient crédibles et aient une bonne image, il faut un

système de supervision efficace, complet et adapté. En outre un bon système de supervision

permet d’anticiper les pannes et donc de gagner du temps :

3.2 Intérêt de la supervision et de la métrologie.

Le métier d’administrateur devient de plus en plus complexe, d’où l’importance pour l’équipe

de gagner en temps et en efficacité grâce à un bon outil de supervision.

3.2.1 Être alerté en temps réel

Les systèmes d’information étant par nature complexes, leur supervision est indispensable.

3.2.1.1 Les problèmes sont inévitables

Les systèmes d’information sont tous différents de par leur taille, leur nature, leur criticité.

Ils ont cependant pour point commun d’être le théâtre d’incidents, à un moment

ou à un autre.

Si quelque chose peut mal tourner, alors elle finira infailliblement par mal tourner. Un des

rôles des administrateurs est justement de gérer cela. Ils doivent concevoir l’architecture du

système d’information de telle manière qu’une panne ait un impact minimal sur le reste du

système. Ils doivent aussi gérer les éventuels problèmes – ce qui reste une part importante de

leur charge de travail. Même avec des architectures robustes, on estime généralement à 80%

de l’activité d’un administrateur la résolution de problèmes. Voilà pourquoi il vaut la peine de

chercher à diminuer cette part qui, il faut bien l’avouer, est loin d’être la plus intéressante, et

de surcroît n’ajoute aucune valeur aux systèmes



3.2.1.2 Les utilisateurs : un moyen de supervision peu fiable et pas toujours agréable

Les systèmes d’information ont pour but final de servir des utilisateurs et d’être employés par

eux. Ceux-ci ne manquent pas de signaler aux administrateurs les problèmes qu’ils y

rencontrent – problèmes qui surviennent soit par manque de formation des utilisateurs, soit

par réelle carence du système.

Dans ce dernier cas, il n’est pas agréable, pour l’administrateur, de l’apprendre de la bouche

d’un utilisateur car celui-ci n’est généralement ni tendre ni très précis. Cette imprécision peut

faire perdre un temps précieux lors de la résolution du problème. L’administrateur, faute

d’informations pertinentes, cherche le problème au mauvais endroit.

Une solution de supervision permet justement d’éviter ce genre de soucis. L’administrateur

est prévenu rapidement d’une situation anormale, bien souvent en moins de temps qu’il n’en

faut à un utilisateur pour venir se plaindre. Il dispose, de plus, d’informations pertinentes et

peut immédiatement s’atteler à la résolution du problème.

Si ce dernier est mineur, sa résolution est rapide. L’utilisateur qui tente de nouveau d’accéder

à la ressource y parvient et n’appelle pas le support. Il y a gain de temps, de part et d’autre,

sans compter que l’utilisateur finit par se faire une meilleure opinion du service informatique

qu’il appelle moins souvent.

En outre, certaines ressources ne sont utilisées qu’occasionnellement – c’est le cas par

exemple des applications de déclaration au trésor public. En cas de souci en période de non-

utilisation, sans outil de supervision, l’erreur n’est pas remontée ; ce n’est que lors de

l’utilisation de l’application que les utilisateurs s’en aperçoivent et sont bloqués.

Avec un outil de supervision, les administrateurs auraient eu tout le temps nécessaire pour

résoudre le problème en période creuse. Ils ne subiraient pas les foudres des utilisateurs d’une

application comptable en période de clôture...



3.2.2 Surveiller plus que le système d’information

Les outils de supervision ont souvent un champ d’action qui s’étend au-delà du seul périmètre

du système d’information.

3.2.2.1 Un ordonnanceur ?

Un outil de supervision n’est rien de plus qu’un ordonnanceur un peu spécial. En général, il

n’effectue pas d’action mais juste des vérifications. Il est cependant possible de l’instrumenter

pour ordonnancer des traitements – mais avec des limites vite atteintes puisque ordonnancer

des traitements n’est pas sa vocation première.

Par exemple, un outil de supervision est spécialisé dans le lancement de nombreux petits

programmes, chacun récupérant une valeur, tandis que les ordonnanceurs lancent en général

un nombre restreint de traitements, mais qui peuvent durer plusieurs heures. Le paramétrage

et le comportement de l’application sont inadaptés face à une telle utilisation.

Cela dit, face au coût important d’un outil d’ordonnancement, il est tentant de laisser cette

tâche à l’outil de supervision. Mais c’est au risque d’avoir un service de piètre qualité et de

mettre en péril certains traitements, ce qui peut au final se révéler plus coûteux.

Autre phénomène également observable sur bien des outils de supervision, leur périmètre de

surveillance dépasse les limites du système d’information. De tels dépassements peuvent être

justifiables ou au contraire ne pas être pertinents du tout.



3.2.2.2 Supervision physique d’une salle machine

Prenons l’exemple de la supervision physique d’une salle machine. Celle-ci contient en

général un système d’accès à la salle, une climatisation et un groupe électrogène – autant

de systèmes en eux-mêmes indispensable à l’ensemble du système d’information.

Il va sans dire que si une personne parvient à accéder à la salle, le système est en péril

puisqu’il suffirait à l’intrus de prendre un disque ou une bande pour obtenir des informations

confidentielles, en passant outre tous les pare-feux possibles et imaginables.

Dans le cas de la climatisation, une trop forte température ou une humidité trop élevée

peuvent être catastrophiques et rendre le système indisponible. Il en va de même pour

l’électricité.

Les éléments physiques sont donc cruciaux pour le bon fonctionnement du système. Ils

peuvent – ou doivent même – être surveillés par l’outil de supervision. Cette surveillance

dépend, bien sûr, de la manière d’obtenir les informations importantes comme la température

ou l’état des batteries du groupe électrogène. On verra par la suite des exemples d’obtention

de telles informations.

Formes d’alertes

De telles informations (accès, humidité, température, panne courant) sont critiques et doivent

être remontées de toute urgence aux responsables de la salle machine. Un simple courrier

électronique n’est bien souvent pas suffisant – peu de chances en effet que l’administrateur

aille consulter ses messages à 4 heures du matin. Un SMS envoyé sur un téléphone d’astreinte

aura plus d’impact. Ainsi différentes façons d’avertir sont à prévoir dans une solution de

supervision. Elles doivent être étudiées avec soin. Des SMS envoyés à tort n’auront pour effet

que d’inciter les personnes d’astreinte à ne pas les lire, voire à éteindre le téléphone



3.3 Les méthodes de la supervision

Beaucoup de méthodes sont à notre disposition pour superviser un réseau, ces différentes

méthodes peuvent être regroupées en deux grandes catégories :

3.3.1. Les méthodes actives

Cette méthode consiste à exécuter un logiciel afin de relever une caractéristique précise à un

moment précis et non pas une observation globale du réseau. Connexion (exécution d’une

commande par SSH), Ping et Traceroute sur un équipement font partie de cette méthode.

C’est donc soit l’utilisation du protocole ICMP soit l’envoi de commandes par SSH pour faire

des relevés de l’état du système.

Exemple de l’utilisation de l’application ping, se basant sur le protocole ICMP, par un

administrateur voulant tester si ma machine est active :

$PING serveur.onee.ma

ping serveur.onee.ma (192.168.1.1) 56(B4) bytes of data serveur.onee.ma

64 bytes from 192.168.1.1: icmp_seq=1ttl=128 time=1.43 ms

Ce qu’il faut retenir : une méthode active permet de tester à un instant t quelque chose mais ne

permet pas de connaitre le résultat de ce test il y a deux heures.

Figure 5 : Exemple de PING



3.3.2. Les méthodes passives

Ces méthodes ne consistent plus à lancer un logiciel de façon ponctuel pour connaître l’état

d’un équipement, mais de le mettre en tant que service système pour qu’il puisse fonctionner

en continu. L’administrateur peut ainsi accéder aux relevés par le biais d’une interface

graphique ouverte en permanence ou par une interface web. Grâce à cette méthode, on peut

mettre en place un système de graphique (flux, temps de réponse, occupation de la

mémoire…) permettant de mieux voir l’évolution d’un paramètre. La surveillance du réseau

se fait en continue, elle met en oeuvre des sondes, utilise un protocole de management

(SNMP) ou utilise des agents à placer sur les équipements. Reprenons l’exemple précédent

mais avec une méthode passive :

Requêtes PING toutes les 5 minutes de la station

serveur.onee.ma

servreur.onee.ma

Ce qu’il faut retenir : la supervision passive permet de revenir dans le temps pour mieux

comprendre un phénomène de pannes en cascades (services qui « tombent » les un après les

autres) par exemple. Mais cette méthode nous oblige à laisser fonctionner constamment une

application qui génère une utilisation du réseau et des équipements qu’il ne faut pas négliger

surtout pour un grand réseau.

Figure 6 : La supervision passive



3.4 Les outils disponibles

3.1.1 Le protocole SNMP et sa MIB

3.1.1.1 A quoi ca sert ?

Imaginez un moyen qui permettrait d’administrer tous les équipements d’un réseau et de

connaître les informations internes d’un switch, d’une imprimante, d’un routeur, d’un

serveur…

Figure 7 : Administration de tous les équipements réseaux

Le protocole de supervision le plus répandu est SNMP (Simple Network Management

Protocol), défini dans la RFC 4789. Ce protocole a pour l’instant connu trois versions (v1,

v2c, v3), où la troisième version permet d’avoir plus de sécurité mais la plus répandue est

encore la deuxième version, qui améliore les opérations du protocole en version1.

Les clients à superviser contiennent un agent SNMP qui est un logiciel permettant de modifier

en partie ou intégralement la configuration via des requêtes. Il envoie également des

informations concernant l’état de l’équipement au manager. Ce dernier est un logiciel sur la



station de supervision qui réalise la lecture d’informations d’éléments du réseau en

interrogeant cet agent et permet de modifier les paramètres de cet élément et de visualiser les

statistiques qui lui sont liées.

Dans un souci de rapidité, le protocole SNMP ne transporte que des variables par le biais du

protocole de transport UDP. Il sert à instaurer le dialogue entre les agents installés sur les

machines supervisées et le serveur de supervision. L’agent reçoit les requêtes sur le port 161

et le superviseur reçoit les alarmes sur le port 162.

les équipements supportant ce protocole sont cher mais la quasi-totalité des équipements

administrables (par telnet, interface web ou encore par le port console) le supporte. Si ce n’est

pas le cas il est possible de pouvoir installer un agent SNMP sur un système d’exploitation

mais pas sur un équipement fermé que l’on ne peut mettre à jour, comme un simple

commutateur non administrable. Avec ce protocole on peut par exemple sur un équipement:

Connaître son état : nombre de trames passées, charge du processeur…

Configurer certains paramètres (on peut ainsi imaginer un système d’équilibrage des

charges)

Etre alerté par l’équipement d’un disfonctionnement interne (surchauffe, permet

d’alimentation…)

Bâti au dessus de TCP/IP, voici SNMP dans le modèle OSI :



SNMP utilise le protocole UDP pour sa simplicité et son poids : 8 octets (20 octets pour

TCP). Ce protocole permet à SNMP d’être rapide mais ça a l’inconvénient d’être un protocole

en mode non connecté et non fiable, il est donc possible qu’un message SNMP n’arrive

jamais, ce qui est embêtant si c’est une alarme…

Figure 8 : Echange de trames entre un agent SNMP et la console de gestion(le Client)

3.1.1.2 La M.I.B.

La Management Information Base, qui peut se traduire par : la base d’information de gestion,

elle est spécifique à chaque équipement mais aussi à chaque constructeur car c’est lui qui

définie les informations consultables, les paramètres modifiables et les alertes à envoyer (Les

traps). La MIB est une structure arborescente où chaque feuille correspond à une information

sur l’équipement. La MIB permet donc de définir les données à envoyer dans la trame

d’interrogation pour récupérer les données voulues. Le nom de chaque nœud est normalisé

mais un équipement compatible SNMP n’est exploitable qu’avec sa MIB car il est impossible

de deviner les objets disponibles dans chacune des branches et comprendre leurs

significations ainsi que leurs valeurs.



Figure 9 : Les Objets gérés par le protocole MIB

3.1.1.3 La S.M.I.

La Structure of Management Information définie les règles de description et d’identification

pour chaque objet de la MIB. Un objet est défini en langage ASN.1 (langage de représentation

des données (Abstract Syntax Notation 1) défini par l’ISO 8824), voici quelques types utilisés

• IPAddress : pour l’adresse IP.

• PhysAddress : pour l’adresse matérielle (MAC).

• TimeTicks : pour un compteur de temps en 1/100 de seconde.

• OCTET STRING : pour une chaîne de caractères.

Figure 10 : Définir un objet dans la SMI



3.1.1.4 Fonctionnement

Pour mieux comprendre le fonctionnement prenons l’exemple suivant de récupérer l’uptime

(temps écoulé depuis le démarrage du système d’exploitation) d’un routeur . Dans un premier

temps il a fallu aller chercher sur le site du constructeur (ici Cisco par exemple ) le MIB de ce

routeur pour savoir où se situe cette donnée.

Voici un extrait, plus particulièrement une feuille, de la MIB d’un équipement Cisco :

system OBJECT IDENTIFIER ::= { mib-2 1 } […] sysUpTime OBJECT-TYPE

SYNTAX TimeTicks MAX-ACCESS read only STATUS current

DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized."

::= { system 3 } […]

Chaque branche est repérée par un numéro, SNMP utilise cette façon de faire pour accéder à

un paramètre : de la racine jusqu'au paramètre d’un objet. Dans l’encadré cidessous on voit

que la branche system(1) fait partie de la branche mib-2(1) qui fait à son tour partie d’une

autre branche… C’est l’espace de nommage qui reprend une grande partie d protocole de

gestion défini par l’ISO 9596 :

Figure 11 : L’arborescence de définition de l’objets sysUPTime.



Donc pour accéder au paramètre de la feuille étudiée, il faut passer par les

nœuds.1.3.6.1.2.1.1.3 (c’est l’OID de l’objet : Object Identifier) et rajouter 0 pour obtenir la

valeur de l’objet ‘sysUpTime’.

Essai avec le chemin complet grâce à l’outil snmpget :

# snmpget -v 2c -c public 10.10.100.1 .1.3.6.1.2.1.1.3.0 SNMPv2-MIB::sysUpTime.0 = Timeticks: (3683053517) 426 days, 6:42:15.17

Comme la suite des noeuds .1.3.6.1.2.1 est très souvent utilisée, il est possible d’utiliser un

chemin relatif en omettant le point de début, on obtient donc la suite : 1.3.0, cela donne :

# snmpget -v 2c -c public 10.10.100.1 1.3.0 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…).



4.1.6. La sécurité

L’aspect sécurité doit être pris en compte dans le choix d’une solution d’administration du

réseau puisque si la solution utilise le protocole SNMP, celui-ci devra être implanté et/ou

activé sur les serveurs, les routeurs, les pare-feux…Il est donc nécessaire de voir si

l’utilisation du protocole SNMP ne crée pas de failles importantes.

En revanche l’utilisation de SNMP implique l’ouverture d’un service (sur le port 161),

voyons l’impact :

Du point de vu d’Internet, la sécurité n’est pas modifiée puisqu’un pare-feu filtre tout

et que seul quelques protocoles (FTP, HTTP, HTTPS et Z3950 : communication du

catalogue du fond bibliographique) fournis par 2 serveurs sont disponibles ; il ne sera

donc pas possible d’interroger un agent SNMP.

En interne ça se complique car toutes les stations de travail peuvent accéder aux

serveurs et aux équipements du réseau, il faut voir comment le protocole SNMP est

sécurisé puisque l’on a vu que l’agent SNMP nous permet d’accéder à un grand

nombre d’informations.

La première version du protocole la sécurité est basée sur la connaissance d’une chaîne de

caractères (c’est la communauté) pour pouvoir accéder à la MIB. Cette chaîne de caractères

est donc présente dans toutes les requêtes faites par le logiciel d’administration du réseau à

l’agent SNMP, le problème c’est que la chaîne de caractères n’est pas cryptée et donc si

quelqu’un intercepte une trame de requête il pourra sans aucune difficulté obtenir le nom de la

communauté et interroger à son tour les équipements.

Figure 12 : Partie d’une trame de réponse SNMP, la communauté apparaît

bien en clair



La seconde version avait pour but de corriger les limitations imposées par la SMI (par

exemple la taille des compteurs limitée à 32 bits) mais aussi l’aspect sécurité quasiment

absent dans la première. La mise à jour de la SMI a bien été réalisée (nouvelle version :

SMIv2) mais pas l’aspect sécurité. Les bénéfices apportés par la nouvelle SMI seront utilisés

dans la version SNMPv2c avec c pour community puisque le mécanisme de sécurité reste

celui de la première version.

La version 3 achevée en 1999 met enfin en place une stratégie de sécurité consultable sur la

RFC2574 (User-based Security Model for version 3 of SNMP), voici les 4 axes principaux :

L’estampillage du temps pour empêcher la réutilisation d’un paquet .

L’encryption pour ne plus pouvoir lire les informations de gestions contenues dans un

message.

L’authentification pour empêcher la modification du message par quelqu’un.

La localisation des mots de passe permet de ne pas compromettre la sécurité du

domaine même si l’un des agents est compromis.

3 niveaux de sécurité sont ainsi offerts :

• noAuthNoPriv : authentification par l’échange d’une chaîne de caractères :

community (v1 et v2c) ou username pour la version 3.

• authNoPriv : authentification par la technique de cryptographie à clé

symétrique HMAC-MD5 ou HMAC-SHA, l’authentification en passe plus en

clair sur le réseau.

• authPriv : reprend le système d’authentification à clé symétrique mais ajoute

un chiffrement des informations sensibles (les réponses demandées et

l’identifiant de contexte : le port du routeur par exemple) contenus dans les

trames SNMP pour les rendre illisibles sur le réseau, chiffrement par

l’algorithme DES en 56 bits.



3.2 Conclusion

Pour conclure on peut dire que, les outils de supervision et de métrologie sont indispensables

à la bonne administration d’un système d’information. Sans eux, l’administrateur est privé de

moyens fiables et rapides de vérifier que les éléments de l’infrastructure et les applications

sont opérationnels.

Partie 4 : Choix d’une solution de supervision : Nagios ONEE -Branche Eau

26 Partie 4 : Choix d’une solution de supervision : Nagios | ONEE Branche Eau

Partie 4 : Choix d’une solution de supervision : Nagios

Sur quels critères juger une solution de supervision ? Quel est le fonctionnement de Nagios,

référence open source en matière de supervision ?

4.1 Choix d’une licence open source

En ces périodes où les budgets des services informatiques fondent comme neige au soleil, la

gestion des licences est de plus en plus contraignante. Les demandes des utilisateurs

augmentent et conduisent à une accumulation de licences. Les outils de supervision ne font

pas exception à cette règle. On peut, dans certains cas, arriver à ces situations où seuls les

environnements critiques sont supervisés, faute de moyens pour acquérir les licences

nécessaires aux autres environnements. Cette situation est dommageable à la qualité du

service fourni aux utilisateurs – l’outil risque par exemple de ne pas être utilisé pour signaler

un problème sur un environnement de test avant mise en production. L’utilisation d’un outil

open source est tout indiquée dans ce genre de situation.

4.2 Le besoin d’adaptabilité et de modularité

Le choix d’une licence open source permet de répondre à un second besoin : l’adaptabilité.

Comme nous l’avons vu, tous les environnements informatiques sont différents. La

supervision doit s’adapter à chaque situation. Elle ne doit pas se comporter de la même

manière sur un petit site que sur un système réparti sur plusieurs sites distants. Les

applications à gérer sont également extrêmement variées. La modularité de l’outil est

primordiale pour ne pas laisser de côté tout un pan du système.

Avec un outil de supervision propriétaire, dans bien des situations, même si les

administrateurs savent comment superviser un élément non pris en compte, ils ne peuvent

pas, contractuellement ou techniquement, l’ajouter dans l’outil. Dans le cas d’un outil open

source, il n’y a pas de limitation. Les administrateurs peuvent l’adapter librement.



4.3 Transparence du mécanisme de remontée d’alerte

Un autre besoin des administrateurs est de savoir comment est recueillie l’information. Les

alertes qu’ils ne comprennent pas ne peuvent guère leur inspirer confiance. S’ils savent

précisément comment est récupérée l’information, ils la prendront immédiatement en

considération. Ils pourront même essayer de l’améliorer. C’est tout l’intérêt des solutions

open source ! Un autre besoin des administrateurs est de savoir comment est recueillie

l’information.

Les alertes qu’ils ne comprennent pas ne peuvent guère leur inspirer confiance. S’ils savent

précisément comment est récupérée l’information, ils la prendront immédiatement en

considération. Ils pourront même essayer de l’améliorer. C’est tout l’intérêt des solutions

open source !

4.4 Le choix de Nagios

Si l’on retient tous ces critères dans le choix d’une solution open source stable, performante

et ayant une forte communauté, Nagios sort largement vainqueur. Cette solution est en effet la

référence en matière de supervision dans le monde de l’open source.

4.4.1 Histoire de Nagios

L’histoire d’un outil peut nous en apprendre beaucoup sur lui.

Nagios est développé par Ethan Galstad et débute son histoire en 1999 sous le nom de

NetSaint. Quelque temps plus tard, à cause d’un problème de propriété intellectuelle sur le

nom, il devient Nagios. Actuellement en version 4.0, il a plus de quinze ans d’existence.

Comme nous le verrons par la suite, il se bonifie avec l’âge, à l’image d’un grand vin. Il a

évolué depuis ses tous débuts afin de s’adapter à des parcs de plus en plus importants, tout en

améliorant ses performances et ses capacités de gestion de configuration..



4.4.2 Nagios ne fait rien sans ses plug-ins

Il est le digne héritier du principe KISS (Keep It Simple, Stupid) d’Unix : il ne fait qu’une

chose, mais la fait bien. Son rôle est d’ordonnancer les vérifications sur les éléments à

superviser et de lancer une alerte si besoin. Il ne fait rien d’autre, pas même aller vérifier lui-

même l’état des éléments à surveiller.

Ceci peut paraître étonnant, mais Nagios ne sait rien faire tout seul. Il ne peut même pas

vérifier le bon état du serveur sur lequel il est hébergé. Son auteur a en effet considéré qu’il ne

pouvait prévoir toutes les vérifications qu’un tel outil doit intégrer. Il a donc décidé de n’en

mettre aucune au sein de Nagios et de laisser la responsabilité des vérifications à des plug-ins

que l’utilisateur devra fournir à l’outil.

4.5 Atouts de Nagios par rapport aux autres outils open source

Nagios n’est pas le seul outil de supervision open source. Par rapport à ses concurrents, sa

plus grande force réside dans sa modularité complète. Il n’a pas de domaine de prédilection et

peut observer tout ce que ses plug-ins sont capables de rapporter.

D’autres outils open source de supervision existent, mais ils ne sont pas aussi modulaires ou

performants que Nagios. On trouve aussi sur le marché des outils de même envergure, mais

non complètement libres.

4.5.1 Zabbix : la supervision simplement

Ce premier outil est très orienté système et s’occupe en interne de la métrologie. Il n’est pas

aussi modulaire que Nagios. Il est beaucoup plus orienté tout-en-un, avec des agents dédiés

qu’il faut déployer sur les éléments distants.

Si ce choix permet de gagner du temps lors de la première mise en place, il se révèle gênant

lorsqu’il s’agit de superviser des éléments non prévus par la solution.



Quant aux possibilités de configuration elles sont moins étoffées que celles de Nagios, ce qui

peut être contraignant lorsque le nombre d’éléments commence à devenir important. Il

manque à Zabbix des solutions simples pour gérer les pertes massives de connexion et tout ce

qui concerne la gestion des dépendances entre éléments. Ce dernier point est, encore une fois,

problématique lorsque la supervision couvre un nombre élevé d’éléments.

4.5.2 Cacti : la métrologie avec SNMP

Cacti, quant à lui, est bien plus orienté réseaux et métrologie. Il repose principalement sur

l’utilisation du protocole SNMP .

La supervision n’est pas le rôle premier de Cacti. Elle est basée principalement sur des

indicateurs qui doivent rester en deçà de seuils fixés. Nagios préfère laisser le choix au plug-

in de se baser ou non sur des valeurs. Cacti est cependant très efficace dans la gestion des

données de performances. C’est pour cela qu’il est parfois utilisé pour gérer les données

issues de Nagios.

4.5.3 OpenNMS : la supervision très SNMP

Cet outil de supervision est globalement moins avancé que Nagios. Sa configuration est très

lourde à gérer, même lorsque le nombre d’éléments supervisés est réduit. Il nepossède pas de

fonctionnalité de gestion des dépendances, ce qui représente un handicap lourd dans les

environnements complexes.

Hors des tests SNMP classiques, OpenNMS est très vite limité. Il est possible d’inclure des

tests supplémentaires, mais c’est une solution relativement lourde à gérer.



4.5.4 Zenoss : très bonne supervision, mais pas complètement libre

Concurrent très sérieux de Nagios, il a comme particularité de ne pas être complètement libre.

Là où Nagios est entièrement en GPL, Zenoss est disponible sous trois versions différentes,

dont deux non libres et soumises à licences. La version libre est assez limitée dans ses

possibilités. Les fonctionnalités de haute disponibilité ou de supervision des environnements

virtualisés ne sont tout simplement pas accessibles dans cette version.

Si les versions sous licences possèdent des avantages face à Nagios, comme la possibilité

native d’avoir une découverte du réseau, elles sont moins avancées sur certains points tels que

l’envoi d’alertes, limité aux e-mails et aux SMS, ou, à l’instar de Zabbix, sur les possibilités

de configuration qui restent limitées.

Zenoss ressemble fortement à Zabbix au sens où il gère aussi lui-même la métrologie et

propose une interface web complète, là où Nagios délègue ces aspects à des outils tiers.

4.6 Orientation vers une totale modularité : tout est plug-in

Rappelons que la force principale de Nagios réside dans sa modularité.

4.6.1 La modularité de Nagios : le rôle des plug-ins

Nagios laisse la supervision à des plug-ins, ou sondes, que va lui fournir l’utilisateur. Il se

contente de les lancer et de gérer les informations recueillies par ce biais.

La communauté fournit la plupart de ces plug-ins. Ils couvrent, en règle générale, plus de 95%

des besoins des utilisateurs. En outre ils évoluent au fil du temps afin de gérer de plus en plus

de systèmes.

Leur conception est très simple, comme nous le verrons par la suite. Cette simplicité permet

aux non-développeurs d’apporter leur pierre à l’édifice. Cette facilité d’adaptation a un autre

avantage majeur : elle permet de capitaliser sur les scripts de vérification déjà mis au point et

utilisés par les administrateurs avant la mise en place de Nagios. La plupart du temps, changer

une seule ligne suffit à les rendre compatibles avec Nagios. En effet, les règles de Nagios sont

standards dans le monde des administrateurs et bien des scripts d’administrateurs sont déjà

compatibles avec Nagios.



C’est cette capacité d’adaptation qui a fait de Nagios la solution la plus prisée dans le monde

de l’open source. La communauté qui s’est formée autour est la plus importante en matière de

supervision open source. Les administrateurs n’ayant pas besoin d’être développeurs, le

nombre de scripts de vérification proposés par la communauté est véritablement

impressionnant. La communauté s’est organisée afin de fournir le plus simplement possible

aux utilisateurs les plug-ins dont ils ont besoin. Ces plugins sont également open source.

4.6.2 Des plug-ins pour avertir ou réagir

Nagios permet également de définir des plug-ins qui vont alerter les utilisateurs en cas de

problème, ce qui permet d’être inventif en matière d’avertissement. On peut penser de suite

aux e-mails, mais nous verrons par la suite que beaucoup d’autres possibilités s’offrent à

nous.

Lorsque quelque chose se passe mal, d’autres plug-ins peuvent tenter de corriger le problème.

Il n’est pas possible de prévoir tous les cas de réparations possibles, sinon l’administrateur

n’aurait plus de raison d’être. Il est donc préférable de lui laisser le soin de définir lui-même

les commandes pour résoudre le problème sur son environnement.

4.7 Capacité à gérer un parc important de machines

Nous avons vu qu’un outil de supervision doit pouvoir gérer des parcs importants.

Sur ce point, trois critères principaux entrent en jeu :

1 les performances ;

2 la gestion de la configuration ;

3 les alertes.



4.7.1 Performances de Nagios

En matière de performances, Nagios n’a rien à envier aux outils de supervision propriétaires.

Il permet, avec un serveur modeste, de surveiller près de 10 000 éléments. Si cette

performance est déjà tout à fait honorable, Nagios propose des options pouvant sensiblement

augmenter cette valeur.

L’architecture même de Nagios permet de surveiller autant de noeuds que souhaite

l’utilisateur. La supervision peut être distribuée entre plusieurs serveurs, tout en centralisant

l’administration sur une unique console.

Le serveur Nagios a besoin d’être correctement dimensionné. Il doit supporter la charge de la

supervision et de la métrologie. Ces deux activités n’ont pas forcément les mêmes besoins. La

supervision consiste à lancer un nombre élevé de vérifications sur les hôtes distants. La

métrologie doit, quant à elle, conserver un nombre plus restreint d’éléments, mais sur une

durée très longue.

La supervision rencontre principalement des problèmes de temps de calcul pour

ordonnancer les tests. Si le serveur n’est pas capable de suivre, les tests sont lancés en retard.

S’il ne peut pas rattraper ce retard, l’écart se creuse. Les tests sont de plus en plus décalés et

ne se font pas aussi rapidement que le souhaitait l’administrateur. Un serveur qui dispose de

ressources suffisantes lance les tests en temps et en heure.

Les principaux problèmes de la métrologie concernent, quant à eux, les disques. Les

informations devant être conservées sur une longue durée, l’espace est une ressource critique.

Si le volume nécessaire est plutôt simple à estimer, l’impact des disques sur le traitement des

données est plus complexe à suivre et à prévoir. Une métrologie mal taillée peut rapidement

ralentir la supervision, avec toutes les conséquences que nous venons d’évoquer.



4.7.2 Gestion de la configuration

Un point délicat concernant la plupart des outils d’administration, mais touchant tout

particulièrement les solutions de supervision, est la gestion de la configuration. Plus on a de

points à surveiller, plus la configuration devient lourde, avec les risques, si elle devient trop

dure à gérer, d’être laissée de côté. Nagios propose diverses solutions pour faciliter la gestion

d’un nombre élevé de points surveillés, et c’est même une de ses grandes forces !

4.7.3 Gestion des alertes

Les alertes remontées aux administrateurs sont au cœur même des outils de supervision. Nous

allons voir comment assurer leur précision et leur pertinence.

4.7.3.1 De l’intérêt de filtrer correctement les alertes

la solution de la supervision doit faciliter leur travail. Les informations doivent leur arriver

déjà filtrées. Dans le cas contraire, ils perdent du temps.

Le seuil de tolérance est variable suivant les administrateurs. On peut considérer qu’une

vingtaine d’alertes par jour est acceptable pour une grande majorité. Au dessus, certains vont

commencer à se plaindre. Cette limite est notre marge haute. Si l’on arrive à faire mieux, il ne

faut pas s’en priver.

4.7.3.1 Concision des alertes

La solution de supervision doit faire gagner du temps aux administrateurs. La concision des

alertes est un premier pas dans cette direction.

Concision et précision

Les administrateurs n’aiment pas perdre de temps lorsqu’il s’agit d’alertes sur leurs serveurs

ou éléments réseau. Ils veulent que l’information soit énoncée rapidement et clairement. Le

responsable de la solution de supervision doit donc particulièrement veiller à la concision des

alertes, sans pour autant tomber dans le travers inverse : l’alerte doit être suffisamment

explicite pour permettre à l’administrateur de savoir d’où vient le problème. Trop court, un

descriptif n’indique pas d’où vient la panne.



Les informations généralement nécessaires sont les suivantes :

• le nom de la machine sur laquelle le problème est survenu ;

• l’élément qui est en faute sur la machine ;

• la criticité de l’alerte ;

• l’heure où le problème a été détecté ;

• un petit texte explicatif du problème (une ligne ou deux maximum) ;

• un lien vers la résolution du problème si elle est disponible.

Il n’est pas nécessaire d’ajouter des formules de politesse dans le texte, les administrateurs ne

s’en vexeront pas. Ils ne trouveront les informations recherchées que plus rapidement.

Il ne faut pas oublier que les messages d’alerte sont souvent envoyés par plusieurs biais. Les

textes ne devront pas être les mêmes entre un envoi par e-mail et un envoi par SMS. Ce

dernier est de taille limitée : il faut être très concis. Les seules informations à y placer sont le

nom de la machine, l’élément qui est en faute, la criticité et l’heure du problème.

Exemple d’e-mail d’alerte

Voici un exemple d’e-mail d’alerte pour un incident survenu sur le serveur srv-web2

concernant une utilisation trop importante de la mémoire.

Message par e-mail bien formaté

***** Nagios Notification ***** State: WARNING Host: srv-web2 Service: Memory Date/Time: 16-12-2008 15:35 Additional Info : WARNING: 92% Used Memory - Total: 8116 MB, used: 7503 MB, free : 613 MB Documentation : clic here.

Exemple de SMS

Dans le cas d’un SMS envoyé pour le même problème, on peut envoyer ce qui suit :

Message dans le cas d’un SMS

WARNING: srv-web2/Memory at 16-12-2008 15:35



4.7.3.2 Bien choisir le niveau d’erreur

Toujours dans le but de faire gagner du temps, la pertinence des alertes est importante.

Le niveau d’erreur permet d’améliorer cette pertinence.

Criticité

L’information de criticité des alertes est l’une des plus importantes. Un administrateur doit

savoir en priorité si l’alerte est importante ou non. Il peut être en train d’effectuer une

opération sur un serveur et doit pouvoir déterminer rapidement s’il a besoin de s’interrompre.

Différents niveaux d’alerte sont définis. Ces niveaux changent suivant différents critères

comme la criticité de la machine et l’impact du problème. Ces niveaux se traduisent sur la

console par différentes couleurs. Celles-ci sont visibles et simples à comprendre, et ce sans

même avoir lu la moindre documentation :

• critique : rouge ;

• avertissement : orange ;

• tout va bien : vert.

Difficulté de définir les niveaux de criticité

Les administrateurs qui utilisent la solution sont les plus à même de fixer les différents

niveaux d’alerte. Lorsqu’ils définissent les éléments à superviser, ils doivent faire une liste

des problèmes qu’ils cherchent à détecter. Pour chaque problème, l’information de criticité est

importante.

Les administrateurs ont tendance à tout transformer en erreur critique. C’est une situation à

éviter. Les erreurs critiques seraient très courantes. La console de supervision serait

constamment rouge vif. Une alerte réellement critique passerait alors inaperçue. Le rouge doit

être signe qu’un service aux utilisateurs est en danger et qu’une intervention immédiate est

nécessaire.

L’inverse est également dommageable. Si le problème a un impact sur les utilisateurs et les

empêche de travailler, c’est l’objectif même du service informatique qui est touché. Si ce

dernier est soumis à contrats avec les autres services, les implications d’un tel problème

peuvent être importantes.

Dans ce genre de situation, le niveau critique est nécessaire. Les administrateurs ne doivent

pas chercher à cacher des problèmes qui peuvent être perçus par les utilisateurs.



L’information ne reste pas longtemps protégée. Des retours au service se font entendre. Si les

responsables apprennent qu’un problème n’a pas été remonté, ils demandent à l’ajouter dans

l’outil de supervision. Si le niveau de criticité n’est pas correct, ils demanderont à le faire

changer. S’ils apprennent que quelqu’un a essayé de faire disparaître l’erreur en douce, les

conséquences peuvent être fâcheuses…

4.8 Architecture générale

Un outil de supervision peut paraître un monstre de complexité lorsqu’on commence à

l’étudier : il n’en est rien. Le fonctionnement de Nagios est très simple... à condition d’en

étudier les parties une par une.

L’administrateur définit la configuration de Nagios dans des fichiers plats. Nous étudierons

par la suite leur structure. Nagios est un simple programme écrit en langage C. Si on exclut la

partie interface web de visualisation, il ne fait pas plus de 60 000 lignes de code, ce qui est

assez faible pour un outil d’une telle renommée. Nagios se lance en tant que processus

d’arrière-plan sur un serveur Unix, GNU/ Linux de préférence. Il lit la configuration fournie

par l’utilisateur et commence à ordonnancer ses vérifications. Lorsqu’il s’aperçoit d’une

erreur sur un élément supervisé, il notifie les utilisateurs concernés.

4.9 Fonctionnement de Nagios

Le principe de supervision de Nagios repose sur l'utilisation de plugins, l'un installé sur la

machine qui supporte Nagios, et l'autre sur la machine que l'on souhaite superviser. Un plugin

est un programme modifiable, qui peut être écrit dans plusieurs langages possibles, selon les

besoins, et qui servent à récupérer les informations souhaitées.

Nagios, par l'intermédiaire de son plugin, contact l'hôte souhaité et l'informe des informations

qu'il souhaite recevoir.

Le plugin correspondant installé sur la machine concernée reçoit la requête envoyée par

Nagios et ensuite va chercher dans le système de sa machine les informations demandées. Il

renvoi sa réponse au plugin Nagios, qui ensuite le transmet au moteur de Nagios afin

d'analyser le résultat obtenu et ainsi mettre à jour l'interface web.

Il existe deux types de récupération d'informations: La récupération active et la récupération

passive.

La différence entre les deux types est l'initiative de la récupération. Dans le premier type, à

savoir le type actif, c'est Nagios qui a toujours cette initiative. C'est lui qui décide quand il



envoie une requête lorsqu'il veut récupérer une information. Alors que lors d'une récupération

passive, l'envoi d'information est planifié en local, soi à partir d'une date, soit en réaction à un

événement qui se déroule sur la machine administrée.

Pour notre projet, nous avons décidé d'utiliser le type de récupération active, c’est-à-dire que

Nagios prend l'initiative d'envoyer une requête pour obtenir des informations. Ceci évite donc

de configurer les postes à superviser

La demande d'informations se fait grâce à l'exécution d'une commande de la part de Nagios.

Une commande doit obligatoirement comporter des arguments afin de pouvoir chercher les

bonnes informations sur les bonnes machines.

Ces arguments sont l'adresse IP de l'hôte sur lequel aller chercher l'information, la limite de la

valeur de l'information recherchée pour laquelle l'état 'attention' sera décidé, idem pour la

valeur 'critique', et enfin d'autres options qui varient selon le plugin utilisé.

Pour ne pas devoir à créer une commande par machine supervisée et par information

recherchée, nous pouvons remplacer les arguments par des variables, et ainsi réutiliser la

commande plusieurs fois, en remplaçant la bonne variable. Nous avons alors la possibilité de

travailler avec des services. Lors de la création d'un service, il faut l'associer à un ou plusieurs

hôtes puis à une commande.

Ensuite Nagios remplace automatiquement la variable de l’adresse IP dans la commande,

grâce à la liste d’hôtes associé au service.

Puis on doit définir manuellement dans le service les autres variables nécessaires à la

commande.

Figure 13 : Exemple des variables mis à disposition par Nagios



Un fois que Nagios a reçu les informations dont il avait besoin sur l'état des hôtes, celui-ci

peut construire des notifications sur l'état du réseau, afin d'en informer l'administrateur.

Lorsque Nagios effectue une notification, il attribut des états aux hôtes, ainsi qu'aux services.

Un hôte peut avoir les états suivants :

-Up : en fonctionnement

-Down : éteint

-Inaccessible

-En attente

Les différents états d'un service sont:

- OK

- Attention

- Critique

- En attente

- Inconnu

4.10 Installation de Nagios

Nous avons installé Nagios en suivant la documentation fournie par Nagios.

Les étapes de l’installation sont fournies en annexe. Afin de sécuriser l’interface web de

Nagios, nous avons mis en place le protocole « HTTPS » (web sécurisé). Ceci permet de

crypter les échanges entre le serveur et l’utilisateur. Pour cela nous avons ajouté un certificat

SSL à apache.

4.11 Interface graphique de Nagios

Pour accéder à l’interface de Nagios depuis l’extérieur de notre réseau, il suffit de taper dans

un navigateur web http://192.168.2.2/nagios puis de s’identifier.

Après l’identification en sera directement rediriger vers la page d’accueil de l’interface

graphique de Nagios ou on visualiser la version de Nagios utiliser utilise et aussi si on veut

faire un mise à jour pour cette version (check for updates).

http://192.168.2.2/nagios



Figure 14 : la page d’accueil du Nagios

L'interface graphique de Nagios est utilisée uniquement pour visualiser l'état du réseau

supervisé. Cette interface ne peut en aucun cas servir pour la configuration de Nagios.

L'interface se compose d'une partie "menu" à gauche, et une partie centrale, beaucoup plus

grande sur le reste de l'écran, qui servira à afficher les informations souhaitées Des captures

d'écran sont disponibles en annexe.

Dans le menu, nous retrouvons en premier des liens vers le site de Nagios, et vers la

documentation de ce logiciel. Ces liens sont dans la partie 'General'.

Puis une partie 'Monitoring' dans laquelle il est possible de sélectionner les informations que

l'on souhaite visualiser. Il y a de nombreux sous-menus dans cette partie ce qui permet

d'afficher vraiment les informations précises qui nous intéressent. Il y a également la

possibilité de visualiser des statistiques que Nagios a construit, ce qui est très intéressant pour

l'administrateur.

Dans la partie "Reporting" il y a la possibilité de créer des rapports et des historiques des

évènements qui se sont produits sur le réseau.

Et enfin dans la dernière partie "Configuration", il est possible de visualiser toute les

configuration grâce à laquelle Nagios sait qui et quoi supervisé.



4.12 Les plugins du Nagios

4.12.1 Plugins principaux

Nagios possède une importante communauté sur Internet. Grâce à celle-ci, de nombreux

utilisateurs ont créés des plugins permettant à Nagios d'aller récupérer des informations sur

des équipements du réseau (PC, routeurs, serveurs, …)

Les plugins n'utilisent pas tous le même protocole pour échanger les informations. Le

protocole utilisé est dans la plupart des cas un facteur décisif sur le choix des plugins à

utiliser.

Un seul plugin Nagios ne peut pas aller chercher toutes les informations sur les équipements

du réseau: En effet, chaque plugin n'a accès qu'à certaines informations (exemple: un plugin

peut aller chercher l'occupation du disque dur, et un autre l'occupation du processeur d'un

PC). Pour superviser un parc informatique, il est donc nécessaire de mettre en place plusieurs

plugins.

De plus, certains plugins peuvent aller chercher des informations sur des clients uniquement

sur certains systèmes d'exploitation (c'est le cas du plugin check_nt qui peut chercher des

informations uniquement sur des équipements Windows).

Les principaux plugins utilisés par Nagios sont :

- Check_disk : Vérifie l’espace occupé d’un disque dur.

- Check-http : Vérifie le service « http »d’un hôte

- check_ftp : Vérifie le service "ftp" d'un hôte

- check_mysql : Vérifie l'état d'une base de données MYSQL

- check_nt : Vérifie différentes informations (disque dur, processeur …) sur un système

d'exploitation Windows

- check_nrpe: Permet de récupérer différentes informations sur les hôtes

- check_ping: Vérifie la présence d'un équipement, ainsi que sa durée de réponse

- check_pop: Vérifie l'état d'un service POP (serveur mail)

- check_snmp : Récupère divers informations sur un équipement grâce au protocole

SNMP (Simple Network Management Protocol)

Il est possible de créer son propre plugin. Dans ce cas, il faudra les créer de la sorte que celui

renvoie à nagios :

- L'état du résultat (OK, CRITICAL, DOWN, UP, …)

- Une chaine de caractères (pour donner le détail du résultat)



4.12.2 Plugins retenus

Après avoir consulté les différents plugins existants, nous avons choisi ceux qui

correspondaient à notre cahier des charges.

Nous avons retenus les plugins suivants :

- Check_nt

- Check_nrpe

- Check_ping

1. Ckeck –nt

Le plugin Check_nt est un plugin récent qui permet de superviser très facilement des PC dont

le système d'exploitation est Windows.

Check_nt permet de récupérer sur un système Windows les informations suivantes :

L'espace occupé sur le disque dur, le temps depuis le démarrage de l'ordinateur, la version du

plugin NSClient ++ (voir ci-dessous), occupation du processeur, occupation de la mémoire,

état d'un service.

Mise en place de check_nt :

i. Le plugin check-net est à installer sur la machine NAGIOS. Dans notre cas, check_nt

a été installé automatiquement (dans le dossier /etc/usr/local/nagios/libexex) lors de

l’installation de Nagios.

ii. Sur les machines à superviser, on doit installer le logiciel NSCLIENT++,

téléchargeable sur le site http://sourceforge.net/projects/nscplus

iii. Sur les machine à superviser, on doit configurer le fichier « NSC.ini ». c’est dans ce

fichier que l’on doit définir :

- Le port sue lequel NSCLIENT++ doit écouter les requetés.

- Les adresses des machines qui ont le droit de dialoguer avec NSCLIENT++(les

machines qui ont le droit de récupérer les informations sur ce poste).

- Un mot de passe (les machines qui souhaiteront dialoguer avec celle-ci par

NSCLIENT++ devront fournir ce mot de passe).

Le fichier de configuration NSC.ini est fourni en annexe.

Fonctionnement de check_nt :

http://sourceforge.net/projects/nscplus



Figure 15 : Fonctionnement du plugin Check_nt

Lorsque Nagios veut connaître une information sur un PC, il exécute le plugin check_nt.

Celui envoie une requête au PC. Sur le PC, le programme NsClient++ reçoit la requête, va

chercher les informations dans les ressources du PC et renvoie le résultat au serveur Nagios.

Usage :

Pour aller chercher les informations sur un PC grâce à check_nt, Nagios exécute une

commande ayant la syntaxe suivante :

Check_nt -H host -v variable [ -p port] [-w warning] [-c critical] [-l params]

Avec:

- H : Adresse IP de l’hôte à superviser

- v: Ce qu’il faut superviser (ex : CPULOAD)

- p: Port sur lequel il faut envoyer la requête

- w: Seuil pour lequel le résultat est considéré comme une alerte

- c: Seuil pour lequel le résultat est considéré comme critique

- l : Paramètres supplémentaires (nécessaire ou non en fonction du paramètre "v")

Pour notre projet, nous utiliserons ce plugin pour superviser tous les postes

Windows (client XP/VISTA/7/8/8.1 + Windows server 2003/2008 ) sauf pour contrôler

l'espace des dossiers des profils des utilisateurs. En effet, ce plugin ne permet pas d'effectuer

cette vérification. Nous utiliserons un autre plugin pour cela.



2. Check_nrpe

Le plugin Check_nrpe est un plugin qui permet de superviser des PC dont le système

d'exploitation est Windows ou Linux.

Check_nrpe utilise une connexion SSL (Secure Socket Layout) pour aller chercher les

informations sur les postes. Ceci permet de crypter les trames d'échanges.

Mise en place de check_nrpe (sur Windows) :

i. le plugin check_nrpe est à installer sur la machine NAGIOS. Dans notre cas,

check_nrpe a été installé automatiquement (dans le dossier

/etc/usr/local/nagios/libexec) lors de l’installation de Nagios

ii. Sur les machines à superviser, on doit installer un logiciel permettant de dialoguer

avec check_nrpe. Le programme le plus couramment utilisé est "nrpe pluging".

Seulement, le logiciel NsClient++ permet aussi de faire des échanges avec le plugin

check_nrpe. Comme nous utilisons déjà ce programme pour check_nt, nous le

conservons aussi pour check_nrpe.

iii. Sur les machine à superviser, on doit configurer le fichier « NSC.ini ».c’est dans ce

fichier que l’on doit définir :

- Le port sur lequel NSCLIENT++ doit écouter les requêtes de check_nrpe

(différent de celui check_nt)

- Les adresses des machines qui ont le droit de dialoguer avec NSCLIENT++(les

machines qui ont le droit de récupérer les informations sur ce poste)

Le fichier de configuration NSC.ini est fourni en annexe

Fonctionnement de check_nrpe :

Figure 16 : Fonctionnement du plugin check_nrpe



Lorsque Nagios veut connaître une information sur un PC, il exécute le plugin check_nrpe.

Celui envoie une requête au PC. Sur le PC, le programme NsClient++ (ou nrpe si linux) reçoit

la requête, va chercher les informations dans les ressources du PC et renvoie le résultat au

serveur Nagios.

Usage :

Pour aller chercher les informations sur un PC grâce à check_nrpe, Nagios exécute une

commande ayant la syntaxe suivante :

Check_nrpe -H <adresse de l’hôte à superviser> -c <nom de la commande à exécuter sue

le serveur>

Puis sur les postes à superviser, dans le fichier de configuration (NSC.ini pour Windows,

nrpe.conf pour Linux), on doit définir la commande à exécuter pour chaque nom de

commande.

Exemple pour Windows :

Commande [check_cpu] = inject checkCPU warn=80 crit=90 5 10 15

Exemple pour Linux :

Command [check_cpu]=/usr/local/nagios/libexec/check_load -w 15,10,5

–c 30,25,20

Ces deux commandes vérifient la charge du processeur.

On remarque alors que la mise en place de nrpe dans une grande entreprise est très complexe

car il faut configurer toutes les commandes sur chaque hôte à superviser (contrairement à

check_nt qui ne nécessite pas de configuration). En revanche, nrpe offre une meilleure

sécurité puisque les échanges client – serveur sont sécurisés (grâce à SSL).

Pour notre projet, nous utilisons chec_nrpe pour :

- Superviser les clients Linux

- Recuperer la taille des dossiers de profils sous Windows



3. Check_ping

Le plugin Check_ping est un plugin qui permet de vérifier qu'un hôte est bien joignable.

Usage :

Pour vérifier qu'un hôte est joignable, Nagios exécute une commande ayant la syntaxe

suivante :

check_ping -H <adresse de l'hote> -w <temps maxi de réponse>, <Pourcentage de

réussite des pings> -c <temps maxi de réponse>, <Pourcentage de réussite des pings>

Avec :

- w : Seuil pour lequel le résultat est considéré comme une alerte

- c : Seuil pour lequel le résultat est considéré comme critique

4.13 Configuration de Nagios :

Les commandes permettant de démarrer, d'arrêter, de recharger Nagios sont les suivantes:

- Démarrer Nagios : /etc/rc.d/init.d/nagios start

- Arrêter Nagios : /etc/rc.d/init.d/nagios stop

- Recharger Nagios: /etc/rc.d/init.d/nagios reload

Après avoir modifié les fichiers de configuration de Nagios, il est très important de recharger

Nagios pour que les modifications soient prises en compte.

Il est possible de réaliser ces mêmes commandes, en mode graphique, sur l'interface de

Nagios :

Figure 17 : redémarrer ou arrêter Nagios par sa interface graphique



Pour respecter notre cahier des charges, nous devons configurer dans Nagios :

- les hôtes à superviser

- les groupes d'hôtes

- les commandes de supervision

- les services de supervision

- les contacts (les personnes qui reçoivent les alertes)

L'interface graphique de Nagios ne permet pas de configurer celui-ci. La seule manière de le

configurer, (sans utiliser d'autres outils) est de remplir les fichiers de configurations

manuellement (dans le dossier /etc/usr/local/nagios/etc/) :

Pour commencer nous allons définir le contact à notifier en cas d'alarme. Pour cela, il faut

aller dans le fichier contacts.cfg

Voici un exemple de commande que j'ai utilisé pour mon envoyer de notification des services

par e-mail. Comme on peut le voir le nom de la commande utilisée dans la définition du

contact est vient en fait du nom défini au-dessus. J'utilise mail avec les options de Nagios

pour le contact et le service qui a provoqué l'alarme.

Pour pouvoir utiliser correctement les notifications, il faiy s’assurer d’avoir installé au

préalable les applications tierces permettant d’envoyer soit des e-mail, soit des sms, puis de

modifier le fichier commands.cfg et de mettre les bonnes commandes.

Une fois nos contacts créés, il faut à présent les affecter à des groupes. La définition des

groupes se trouve dans le fichier contactgroups.cfg

Nous avons fini de configurer la première partie de Nagios. Il nous reste à présent la

configurer des différents équipements appartenant à notre réseau ainsi qur les services à

surveiller pour chaque.



Commençons tout d'abord par éditer la liste des équipements dans le fichier hosts.cfg :

On peut également définir des groupes de machines. Cela permet d’avoir une meilleure

visibilité surtout au niveau de l’interface web de Nagios.

Il ne reste plus qu’à definir les services que l’on désire surveiller.



On remarque alors que la configuration de Nagios est très complexe pour une grande

entreprise. En effet, si le parc informatique à superviser est grand, il faudra du temps pour

remplir l'intégralité des fichiers de configuration.

De plus, plus ces fichiers sont grands, plus il sera difficile pour l'administrateur réseau de s'y

retrouver.

Comme dans la plupart des cas, on supervise un réseau lorsque celui a une taille assez

importante, , la configuration de Nagios telle qu'elle sera rarement facile.

4.14 Combinaison de Nagios et Centreon

4.14.1 Pourquoi Centreon ?

Centreon est un logiciel qui s'installe par-dessus Nagios et qui permet d'améliorer l'interface

graphique, mais surtout le très gros avantage de Centreon est de pouvoir configurer Nagios

par l'interface graphique. En effet la configuration de Nagios, qui s'effectue par modification

de fichiers de configuration, devient très vite trop complexe lorsque le parc informatique à

superviser prend de l’importance.

Le principe de fonctionnement de centreon est simple. L’administrateur configure les options

de supervisions, hôtes, services, plugins, etc grâce à l’interface de centreon.

Ensuite toutes les configurations effectuées par l'administrateur sont stockées dans une base

de données, mais elles ne sont pas immédiatement appliquées au moteur Nagios.

Lorsqu'il veut appliquer ces modifications, il doit relancer Centreon, qui va alors modifier

automatiquement les fichiers de configuration de Nagios, grâce aux informations stockées

dans la base de données.

De plus, si l'administrateur réseau configure Nagios depuis les fichiers et que celui-ci fait une

faute de frappe, Nagios ne pourra pas fonctionner; dans certains cas, l'administrateur peut

mettre du temps avant de retrouver son erreur. Centreon évite ce problème car il contrôle les

données entrées par l'administrateur avant de les valider.

Cela permet de configurer Nagios avec une interface intuitive, plaisante, et moins complexe

que les fichiers de configuration que l'administrateur devait modifier lui-même, et en même



temps pouvoir visualiser l'état complet du parc informatique. C'est donc un outil complet et

indispensable lorsque le parc informatique à gérer devient complexe, comme cela est très

souvent le cas dans les entreprises.

4.14.2 Installation de Centreon :

Nous avons installé Centreon en suivant les étapes de l'installation qui sont fournies en

annexe.

Lors, de l'installeur va poser un certain nombre de questions concernant les emplacements des

différents fichiers, quelques avertissements sur certains fichiers qui risquent d'être effacés.

Pour la plupart des questions, il faut conserver la réponse par défaut.

Nous avons configuré l'interface web de Centreon de la même manière que celle de nagios :

Ensuite Centreon va installer ses plugins, puis pour finaliser l'installation, il faut se rendre sur

l’interface graphique, à l'adresse http://192.168.2.2/Centreon depuis le réseau local.

Une fois sur l'interface, il faut vérifier que tous les composants soient bien installés, puis

attribuer les mots de passes et les login pour accéder à l'interface et à la base de données..

4.14.3 Configuration de Centreon :

la page d’accueil de centreon après l’authentification

Figure 18 : La page d’accueil du Centreon



Nous avons ensuite crée les services.

Les services doivent avoir une commande (dans notre exemple ci-dessous : Ping) et doivent

être associés à des hôtes (les hôtes dont lesquels on supervisera avec ce service).Il faut ensuite

donner les valeurs des variables de la commande.

Enfin, une fois que la configuration est faite, il faut régénérer les fichiers de configuration de

Nagios.

En effet, toute la configuration crée jusqu'à présent a été stockée dans une base de données

mais n'était pas effective dans Nagios. Il faut donc transférer cette configuration dans les

fichiers de configuration Nagios.



Grace à cet outil, Centreon crée lui-même, à notre place, les fichiers de configuration cités

dans le paragraphe "Installation et configuration de Nagios".

Après avoir comparé entre la configuration de Nagios faite en remplissant manuellement les

fichiers de configuration puis entre la configuration de Nagios faite par l'interface de Centreon

nous confirmons que la deuxième méthode est beaucoup plus facile. Elle permet à

l'administrateur de mieux se repérer, de gagner du temps et d'éviter des erreurs.



4.15 NSClient++

4.15.1 Présentation de NSClient :

NSClient est un service pour toutes versions de Windows (NT, 2000, 2003, XP et Vista) qui

combine les fonctionnalités d’un agent de supervision dédié à l’environnement Windows ainsi

que les fonctions de transport NRPE et NSCA pour cet environnement. Il est disponible en

version 32 et 64 bits. Du fait de ces triples fonctions, le fichier de configuration de

NSClient++ est assez long mais également assez simple. Il est aujourd’hui considéré comme

l’agent de supervision standard Nagios pour plateformes Windows.

Figure 19 : Logo du NSClient ++

L’installation de NSClient++ ne pose pas de problème grâce au format d’installation .msi

fourni Il suffit de valider par le bouton next chacun des écrans présentés. Le logiciel est

installé par défaut dans le répertoire C:\Program Files\NSClient++. 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



Ensuite il faut ouvrir la mmc services.msc et configurer le démarrage automatique du service

et l’autoriser à interagir avec le bureau.

Ensuite on va éditer le fichier NSC.ini pour configurer la connexion entre le serveur à

monitorer et Nagios. Dans ce fichier il faut décommenter tous les modules de la section

[modules] à l’exception de checkWMI.dll et RemoteConfiguration.dll

Figure 20 : le fichier NSC.ini

Ce premier bloc de configuration permet d’activer et de désactiver les modules/extensions de

NSClient++. Il faut bien sûr en activer au minimum quelques-uns pour pouvoir interroger la

machine.



FileLogger permet de journaliser les événements NSClient++ ; il est conseillé de

l’activer,

CheckSystem permet les contrôles de CPU, RAM et charge,

CheckDisk permet les contrôles d’espace libre sur les disques durs,

NSClientListener permet le mode de fonctionnement nsclient,

NRPEListener permet le mode de fonctionnement NRPE,

SysTray est un extension à la barre des tâches Windows qui permet de stopper,

démarrer le service directement depuis celle-ci,

CheckEventLog permet l’interrogation des fichiers journaux Windows,

CheckHelpers ne produit aucun contrôle par lui-même mais permet de manipuler

les sorties des autres de plusieurs façons,

CheckWMI permet les interrogations de type WMI, NSCAAgent permet le mode

fonctionnement NSCA,

LUAScript permet d’exécuter des scripts en langage Lua

CheckExternalScripts permet d’exécuter toutes sortes de scripts externes,

NRPEClient permet un mode de fonctionnement proxy NRPE.

Ensuite il faut changer le password dans la section [Settings] pour que le client communique

avec Nagios. On a entré le password pour nagios un peu plus haut, bien entendu il faut que ce

soit le même.

Conclusion ONEE -Branche Eau

55 Conclusion | ONEE Branche Eau

Conclusion

Nous avons appris bien des choses durant ce mois passé très vite. Cependant, nous avons

l’impression en sortant du stage que tout reste à faire ! La solution livrée est fonctionnelle,

elle permet de visualiser en temps réel l’état des stations et des quelques services mis en place

sur certaines machines.

Il y a cependant un problème qui n’a pas encore été réglé. Certaines machines n’ont pas

d’adresse IP définies lors de la génération des fichiers de configurations, il s’agit des

machines dont l’adresse est affectée dynamiquement. Les outils standard comme le Ping

fournis avec Nagios, à la base créée pour la supervision de serveurs ayant donc des adresses

fixes, ne fonctionnent pas sans adresse IP. Nous avons alors utilisée une astuce qui fonctionne

sur quelques machines : utiliser le nom NetBIOS. Pour toutes les machines référencées, la

résolution d’adresse se fait bien, le Ping est alors fonctionnel.

En revanche, l’état actuel de la solution est incapable de superviser les machines non

référencées et sans adresse IP, Nagios les considère logiquement comme en état critique

puisqu’elles ne répondent pas au Ping. Une solution serait alors d’écrire (ou de trouver) un

plugin qui détermine dynamiquement l’adresse IP d’une machine donnée à partir de son nom

ou de son adresse mac en utilisant rarp par exemple. Une autre fonctionnalité intéressante

serait d’utiliser nagios graph et des plugins comme check_traffic ou autre afin de récupérer

des informations sur les débits circulants sur les différents ports des commutateurs ; il serait

alors possible d’avoir en temps réel des courbes indiquant des données sur le trafic du réseau.

Ce sont principalement les deux points que nous aurions développés sur un stage plus long.

Pour conclure, un projet comme celui-ci se révèle être une solution très intéressante au sein

d’une entreprise, mais il ne doit pas être réalisée par n'importe qui, et ne constitue qu'un outil

de travail pour un administrateur réseau. Il ne remplace en aucun cas celui-ci…

Bibliographie & Webographie ONEE - Branche Eau

56 Bibliographie & Webographie | ONEE Branche Eau

Bibliographie & Webographie

Bibliographie

Olivier Jan « Nagios au coeur de la supervision Open

Source: » ENI éditions.

Jan Gabes « Nagios 3 pour la supervision et la métrologie »

EYROLLES éditions.

”Nagios, un outil GPL de surveillance pour petits et grands

réseaux hétérogène”, Pierre-Antoine Angelini, JRES 2003

Webographie

http://www.nagios.org

http://www.centreon.com

http://www.nagiosexchange.org

http://doc.fedora-fr.org/centreon

http://wiki.monitoring-fr/centreon/

http://www.nsclient.org/nscp/

http://djibril.developpez.com/tutoriels/linux/na

gios-pour-debutant/

http ://www.snmplink.org

http ://wwwsnmp.cs.utwente.nl/

http://doc.ubuntu-fr.org/nagios

http://www.nagios.org/

http://www.centreon.com/

http://www.nagiosexchange.org/

http://doc.fedora-fr.org/centreon

http://wiki.monitoring-fr/centreon/

http://www.nsclient.org/nscp/

http://djibril.developpez.com/tutoriels/linux/nagios-pour-debutant/

http://djibril.developpez.com/tutoriels/linux/nagios-pour-debutant/

http://doc.ubuntu-fr.org/nagios

Annexes ONEE -Branche Eau

57 Annexes | ONEE Branche Eau

Annexes

Installation de Nagios

Avant de commencer l'installation de Nagios, il faut s'assurer de posséder les droits de « root

» sur la machine qui va accueillir Nagios.

Voici les étapes à suivre pour installer correctement Nagios :

# apt-get install nagios

# apt-get install nagios-plugins

# apt-get install nagios-plugins-ping nagios-plugins-tcp nagios-plugins-udp nagios-

plugins-http

nagios-plugins-dns nagios-plugins-smtp nagios-plugins-ldap nagios-plugins-pgsql

nagios-pluginsmysql

Remarque :

On peut Télécharger les package de Nagios et ses différents plugins de site de nagios si

on n’a pas d’internet sur notre machine serveur.

- Tout d'abord on télécharge la distribution Nagios sur son site officiel : www.nagios.org

- Ensuite, on extrait la distribution grâce à la commande suivante:

tar xzf nagios-version.tar.gz

Lorsque la commande aura été exécutée, un dossier nagios-version sera créé dans le

répertoire courant. A l'intérieur de celui-ci, il y aura tous les fichiers qui constituent le

noyau de la distribution Nagios

. Vient ensuite la configuration du serveur web (Apache dans notre exemple, mais

on peut en utiliser un autre). On doit pour cela modifier le fichier nagios.conf dans

/etc/httpd/conf.d/ pour autoriser l'accès depuis toutes les sources.

# vi /etc/httpd/conf.d/nagios.conf

> Remplacer les lignes deny from all par allow from all

On doit également générer un couple login/password pour accèder à l'interface Web

d'administration. Pour cela, il faut :

# htpasswd -c /etc/nagios/passwd AdminNagios



Dans ma configuration il a aussi fallu que je passe ma Fedora en mode SELINUX permissive,

sinon les scripts CGI de Nagios ne s'exécutaient pas.

# vi /etc/selinux/config

> SELINUX=disabled

# reboot

Interface de Nagios(Mode Passif)

Topologie de réseaux qu’on va superviser sous Nagios

On voir dans le schéma qu’on le noyau de serveur Nagios en centre ou toutes les machine a

surveille sont connecter.

Deux machines sont up (winXp et localhost), win7 et winVista sont Down car sont pas

connecter à notre serveur Nagios.

Les Hôtes qu’on va superviser sous Nagios

Dans cette imprime on visualise les détails sur les hosts qui sont connecter et la duré de leur

connexion au serveur Nagios plus la dernier mise a jour pour la fonctionnalité de service

supervisé et aussi l’état de la connectivité entre les machine superviser et le serveur (PING

OK).



Les Hôtes avec les services qu’on va superviser

Toute les services que ca marche bien ou on n’a pas de probleme on le voie avec un status

« ok » en vert et les autres qu’on des probleme à démarrer avec un status « critical et warning

» en rouge et orange.



Installation de Centreon

Pré-requis :

Dépendances requises LAMP

httpd

httpd-manual

mysql

mysql-server

mysql-devel

php

gd

gd-devel

rrdtool

net-snmp

Normalement, on a juste ca à faire par rapport à ce qui est déjà installé.



Apt-get install rrdtool

Bibliothèques nécessaires

php-mysql

php-pear

php-snmp

php-posix

libgd2

gd-devel

libpng

libpng-devel

perl-config-IniFiles

perl-Crypt-DES

perl-Digest-HMAC

perl-Digest-SHA1

perl-GD

perl-IO-Socket-INET6

perl-Net-SNMP

perl-rrdtool

perl-Socket6

La commande pour installer cette liste.

apt-get install php-mysql php-pear php-snmp php-posix php-ldap gd-devel libpng libpng-

devel perl-Config-IniFiles perlCrypt-DES perl-Digest-HMAC perl-Digest-SHA1 perl-GD

perl-IO-Socket-INET6 perl-Net-SNMP perl-rrdtool perlSocket6

Dépendances système requises

Sudo

Make

Gcc

La commande pour installer cette liste.

Apt-get install sudo make gcc

Installer les modules PHP pear suivants :

php-pear-DB

php-pear-DB-DataObject

php-pear-DB-DataObject-FormBuilder

php-pear-MDB2

php-pear-Date

php-pear-Numbers-Roman

php-pear-Numbers-Words

php-pear-HTML-Common

php-pear-HTML-QuickForm



php-pear-HTML-QuickForm-advmultiselect

php-pear-HTML-Table

php-pear-Archive_Tar

php-pear-Auth-SASL

php-pear-Console_Getopt

php-pear-HTTP

php-pear-Image-Canvas

php-pear-Image-Color

php-pear-Image-Graph

php-pear-Image-GraphViz

php-pear-Mail

php-pear-Mail-Mime

php-pear-Net-SMTP

php-pear-Net-Socket

php-pear-Net-Traceroute

php-pear-Net-Ping

php-pear-Validate

php-pear-XML_RPC

php-pear-SOAP

La commande pour installer cette liste

Apt-get install php-mysql php-pear php-snmp php-gd gd gd-devel libpng libpng-devel perl-

Config-IniFiles perl-Crypt-DES perl-Digest-HMAC perl-Digest-SHA1 perl-GD perl-IO-

Socket-INET6 perl-Net-SNMP perl-rrdtool perl-Socket6 php-pearDB php-pear-DB-

DataObject php-pear-DB-DataObject-FormBuilder php-pear-MDB2 php-pear-Date php-pear-

NumbersRoman php-pear-Numbers-Words php-pear-HTML-Common php-pear-HTML-

QuickForm php-pear-HTML-QuickFormadvmultiselect php-pear-HTML-Table php-pear-

Archive-Tar php-pear-Auth-SASL php-pear-Console-Getopt php-pearHTTP php-pear-Image-

Canvas php-pear-Image-Color php-pear-Image-Graph php-pear-Image-GraphViz php-pear-

Mail php-pear-Mail-Mime php-pear-Net-SMTP php-pear-Net-Socket php-pear-Net-

Traceroute php-pear-Net-Ping php-pearValidate php-pear-XML-RPC php-pear-SOAP

Après recherche, je me suis rendu compte que les classes sont toutes positionnées dans /usr

/share/pear et que les classes relatives à ces trois paquets sont en faite installées et fournit

par lepaquet php-pear.

Après un premier test de l’installation de centreon, 2.0.2, j’ai remarqué qu’il manquait un

paquet paquet et qu’un autre n’était pas en version suffisante. Un check est de toute façon

réalisé en fin d’installation. Il a fallu dans mon cas, mettre à jour la version de php-pear à une

version supérieure à la1.5.0 or le dépôt epel fournit la 1.4.9! Récupérer le rpm et mettre à jour

avec la commande suivante.

rpm –Uvh php-pear-1.8.1.61.el5.remi.noarch.epm



La même chose a été réalisée pour le paquet php-pear-Log préalablement récupéré en rpm.

apt-get install install php-pear-Log-1.11.3-1.el5.noarch.rpm

Localiser les librairies nécessaires à Centreon.

updatedb

locate RRDs.pm

/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/RRDs.pm

locate PEAR.php

/usr/share/pear/PEAR.php

Conserver dans un coin ces deux chemins, ils seront demandés à l’installation.

Ensuite nous pouvons commencer l'installation de Centreon :

Après l’installation de tous les packages nécessaire pour l’installation de Centreon on lance

l’installation de centreon on suivre les tapons entre et Yes.

Lancer l’interface web http://192.168.2.2/centreon/ afin de finaliser l’installation.

En cliquant sur Start pour commencer l’installation de Centreon.



Finir l’installation par la création de la base de données ndo à l’aide du script prévu à cet effet

dans centreon.

# mysql -u root -p

mysql> CREATE DATABASE `ndo` DEFAULT CHARACTER SET utf8 COLLATE

utf8_general_ci;

mysql> exit

# mysql -u root -p ndo < /root/centreon-2.0.2/www/install/createNDODB.sql

# mysql -u root -p

mysql> GRANT SELECT , INSERT , UPDATE ,DELETE ON ‘ndo’ .TO’centreon

@'localhost';

mysql> exit

La procédure d’installation est terminée. Il faut maintenant configurer les différents éléments

afin de les faire interagir ensemble.

Après on lance l’interface web http://192.168.2.2/centreon/

http://192.168.2.2/centreon/

rapport stage onee-be_2

Technology