etude et mise en œuvre d`un outil de supervision des serveurs

Transcription

Ministère de L’Enseignement
République de Côte d’Ivoire
Supérieur et de la Recherche Scientifique
Union – Discipline - Travail
Ecole Supérieure d’Industrie
N° d’ordre : 1 / 10 / ESI / ING TLC / 2011
G
2
E
Génie Electrique & Electronique
MEMOIRE DE FIN DE CYCLE
THEME
ETUDE ET MISE EN ŒUVRE D’UN OUTIL DE
SUPERVISION DES SERVEURS
04 Juillet 2011– 05 Décembre 2012
Présenté par ABBE SERGE ALAIN
En vue de l’obtention du diplôme d’Ingénieur en Télécommunications
Directeur de mémoire
Maître de Stage
M. GBEGBE Raymond
M. Konan Koffi Roger
Ministère de L’Enseignement
République de Côte d’Ivoire
Supérieur et de la Recherche Scientifique
Union – Discipline - Travail
Ecole Supérieure d’Industrie
N° d’ordre : 1 / 10 / ESI / ING TLC / 2011
G
2
E
Génie Electrique & Electronique
MEMOIRE DE FIN DE CYCLE
THEME
ETUDE ET MISE EN ŒUVRE D’UN OUTIL DE
SUPERVISION DES SERVEURS
04 Juillet 2011– 05 Décembre 2012
Présenté par ABBE SERGE ALAIN
En vue de l’obtention du diplôme d’Ingénieur en Télécommunications
Directeur de mémoire
Maître de Stage
M. GBEGBE Raymond
M. Konan Koffi Roger
Mémoire de Fin de Cycle
Etude et Mise en œuvre d’un Outil
de Supervision des Serveurs
DEDICACE
A mes parents,
Pour leur soutien indéfectible.
ABBE Serge Alain, élève Ingénieur en Télécommunications
I
REMERCIEMENTS
Nous tenons à manifester notre gratitude à des personnes particulières qui ont permis la
réalisation de ce travail et grâce à qui nous sommes parvenus à la fin de notre formation. Sans
être exhaustifs, nous aimerions citer :

Mlle NGONIAN YAO Larissa, Chef du Département Système, Maintenance et
DBA pour l’intérêt accordé à notre travail.

M. KONAN KOFFI ROGER, Administrateur Système, notre maître de stage
pour le temps qu’il nous a sans cesse consacré durant la réalisation de ce
mémoire ; pour la bonne humeur, les conseils avisés, le soutien,

M. KOUAO Aketchi, M. ALLE MONNE Yann, M. NGOUAN Guy Serge et tout le
personnel du Département Système, Maintenance et DBA et du
Département Réseau et Télécoms,

M. GBEGBE Raymond, enseignant-chercheur au DFR-GEE de l’INP-HB, notre
directeur de mémoire, pour sa disponibilité et tous les efforts consentis,

Tout le corps professoral et administratif de l’INP-HB,

Ceux qui nous ont soutenu et continuent de nous soutenir par leurs prières
et leurs pensées.
II
SOMMAIRE
DEDICACE ............................................................................................................................................................... I
REMERCIEMENTS ................................................................................................................................................... II
SOMMAIRE ........................................................................................................................................................... III
LISTE DES FIGURES ................................................................................................................................................. V
LISTE DES TABLEAUX ............................................................................................................................................. VI
AVANT-PROPOS ................................................................................................................................................... VII
RESUME ................................................................................................................................................................ IX
INTRODUCTION ..................................................................................................................................................... 1
PARTIE A : CADRE ET CONTEXTE DU STAGE............................................................................................................ 2
CHAPITRE 1 : PRESENTATION DE LA STRUCTURE D’ACCUEIL .............................................................................. 3
1.1 Création et missions de la SNDI .................................................................................................. 3
1.1.1 Création de la SNDI ............................................................................................................. 3
1.1.2 Missions de la SNDI ............................................................................................................. 4
1.2 Organisation de la SNDI ............................................................................................................. 4
CHAPITRE 2 : CONTEXTE DU STAGE ....................................................................................................... 6
2.1 Département d’accueil ............................................................................................................... 6
2.2 Positionnement du thème .......................................................................................................... 6
2.3 Cahier des charges ..................................................................................................................... 6
2.3.1 Contraintes ......................................................................................................................... 7
2.3.2 Méthodologie ..................................................................................................................... 7
2.4 Etude de l’existant ..................................................................................................................... 8
2.4.1 Présentation de l’environnement ....................................................................................... 8
CHAPITRE 3 : LA SUPERVISION DES RESEAUX ...................................................................................... 10
3.1 Le concept de supervision des réseaux ..................................................................................... 10
3.2 La norme ISO ............................................................................................................................ 10
3.2.1 Gestion des performances ................................................................................................ 10
3.2.2 Gestion des configurations (Management Configuration) ............................................... 11
3.2.3 Gestion de la comptabilité (Accounting Management) ..................................................... 11
3.2.4 Gestion des anomalies (Fault Management) ..................................................................... 11
3.2.5 Gestion de la sécurité (Security Management) .................................................................. 12
3.2.6 Structure de gestion des réseaux (Network Management System) ................................... 12
3.3 Le protocole SNMP ................................................................................................................... 13
3.4 Déploiement des logiciels de supervision ................................................................................. 14
PARTIE B : ETUDE ET CHOIX DE LA SOLUTION
DE SUPERVISION ..................................................................... 16
CHAPITRE 4 : CRITERES DE CHOIX DE LA SOLUTION .......................................................................................... 17
4.1 Les coûts élevés des licences propriétaires .............................................................................. 17
4.2 Le besoin d’adaptabilité et de modularité ................................................................................ 18
4.3 La Transparence du mécanisme de remontée d’alerte ............................................................. 18
4.4 Les performances ..................................................................................................................... 18
4.5 Mise en commun des expériences ............................................................................................ 18
CHAPITRE 5 : LES OUTILS DE SUPERVISIONS ................................................................................................ 19
5.1 ZABBIX ..................................................................................................................................... 19
III
5.1.1 Qu'est-ce que Zabbix? ....................................................................................................... 19
5.1.2 Qu'offre Zabbix? ............................................................................................................... 19
5.1.3 Les atouts de zabbix .......................................................................................................... 20
5.1.4 Le public visé par Zabbix ................................................................................................... 20
5.2 Zenoss ...................................................................................................................................... 20
5.2.1 Généralités et fonctionnalités de Zenoss .......................................................................... 20
5.3 OpenNMS ................................................................................................................................. 21
5.3.1 Description de OpenNMS .................................................................................................. 21
5.3.2 Les fonctionnalités ............................................................................................................ 22
5.4 FAN (FULLY AUTOMATED NAGIOS) .......................................................................................... 23
5.4.1 Présentation de FAN ......................................................................................................... 23
5.4.2 Nagios ............................................................................................................................... 23
5.4.3 Centreon ........................................................................................................................... 24
5.4.4 Nagvis ............................................................................................................................... 25
CHAPITRE 6 : CHOIX DE LA SOLUTION ................................................................................................. 27
6.1 Atouts de Nagios par rapport aux autres outils open source .................................................... 27
6.1.1 Zabbix : la supervision simplement ................................................................................... 27
6.1.2 Zenoss : très bonne supervision, mais pas complètement libre ......................................... 27
6.1.3 La supervision très SNMP .................................................................................................. 28
6.1.4 Nagios, logiciel open source de supervision le plus utilisé ................................................. 28
CHAPITRE 7 : ETUDE DE NAGIOS ......................................................................................................... 29
7.1 Architecture de Nagios ............................................................................................................. 29
7.1.1 Les Plugins ........................................................................................................................ 29
7.1.2 Les agents ......................................................................................................................... 30
7.2 Fonctionnement ....................................................................................................................... 31
7.2.1 Méthode d’obtention des informations ............................................................................ 31
7.2.2 Données à définir dans Nagios .......................................................................................... 32
PARTIE C : MISE EN ŒUVRE ................................................................................................................................. 41
CHAPITRE 8 : IMPLEMENTATION DE LA SOLUTION ........................................................................................... 42
8.1 Conception de l’architecture de supervision ............................................................................. 42
8.1.1 Le mode de déploiement .................................................................................................. 42
8.1.2 Regroupement par type .................................................................................................... 42
8.2 Installation ............................................................................................................................... 42
8.3 Configuration ........................................................................................................................... 43
8.3.1 Première configuration ..................................................................................................... 43
8.3.2 Configuration des groupes de contacts ............................................................................. 46
8.3.3 Configuration des contacts................................................................................................ 46
8.3.4 Configuration des moyens de notification......................................................................... 47
8.3.5 Configuration des hôtes .................................................................................................... 50
8.3.6 Configuration des services ................................................................................................ 51
8.4 Test .......................................................................................................................................... 59
CONCLUSION ....................................................................................................................................................... 60
BIBLIOGRAPHIE..................................................................................................................................................... IX
GLOSSAIRE ............................................................................................................................................................ XI
ANNEXES .............................................................................................................................................................XV
IV
LISTE DES FIGURES
FIGURE 1. ORGANIGRAMME DE LA SNDI ............................................................................................................... 5
FIGURE 2. ARCHITECTURE SIMPLIFIEE DU RESEAU INTERNE DE LA SNDI ................................................................ 8
FIGURE 3. NETWORK MANAGEMENT SYSTEM (MNS) .......................................................................................... 12
FIGURE 4. ARCHITECTURE DE NAGIOS ................................................................................................................. 29
FIGURE 5. FONCTIONNEMENT DE NRPE ............................................................................................................... 30
FIGURE 6. FONCTIONNEMENT DE NSCA ............................................................................................................... 31
FIGURE 8. INTERFACE D’ACCUEIL DE CENTOS....................................................................................................... 44
FIGURE 9. PAGE D’ACCUEIL DE FAN ..................................................................................................................... 45
FIGURE 10. INTERFACE D’ACCUEIL DE CENTREON ................................................................................................ 45
FIGURE 11. CREATION D’UN GROUPE DE CONTACTS ........................................................................................... 46
FIGURE 12. AJOUT D’UN CONTACT ...................................................................................................................... 47
FIGURE 13. INFORMATIONS GENERALES DE NOTIFICATION DES HOTES POUR LES CONTACTS ............................ 47
FIGURE 14. MOYENS DE NOTIFICATIONS PRECONFIGURES .................................................................................. 48
FIGURE 15.DEFINITION DE LA COMMANDE D’ENVOI D’EMAIL ............................................................................. 48
FIGURE 16. CONFIGURATION DE L’ENVOI PAR SMS POUR LES SERVICES DANS CENTREON.................................. 50
FIGURE 17. INFORMATIONS GENERALES DANS L’AJOUT D’UN HOTE ................................................................... 51
FIGURE 18. CONFIGURATION D’UN GROUPE D’HOTES ......................................................................................... 51
FIGURE 19. AJOUT D’UNE COMMANDE ............................................................................................................... 52
FIGURE 20. MISE EN RELATION DES SERVICES ET HOTES SUPERVISES .................................................................. 53
V
LISTE DES TABLEAUX
TABLEAU 1. COMPARAISON DES COUTS ENTRE LES LICENCES OPEN SOURCE ET LES LICENCES PROPRIETAIRES .. 17
TABLEAU 2. COMPARAISON DES DIFFERENTS LOGICIELS LIBRE PRESENTES ......................................................... 27
TABLEAU 3. COMPARAISON DE L’UTILISATION DES LOGICIELS OPEN SOURCE DE SUPERVISION .......................... 28
TABLEAU 4. PARAMETRES DE CONFIGURATION DES DIFFERENTS SERVICES ........................................................ 54
TABLEAU 5. SUPERVISION DES RESSOURCES PHYSIQUES LOCALES SUR LE SERVEUR LOCAL ................................ 55
TABLEAU 6. SUPERVISION DES RESSOURCES PHYSIQUES SUR LES MACHINES LINUX DISTANTES......................... 56
TABLEAU 7. SUPERVISION DES MACHINES WINDOWS ......................................................................................... 56
TABLEAU 8. SUPERVISION DE MYSQL ET POSTGRESQL ........................................................................................ 57
TABLEAU 9. SUPERVISION DES BASES DE DONNEES ORACLE ............................................................................... 58
VI
AVANT-PROPOS
Actes de création de l’ INP-HB
L'Institut National Polytechnique Félix HOUPHOUËT-BOIGNY, en abrégé INP–HB, est
né, par Décret 96–678 du 04/09/96, de la fusion de l'École Nationale Supérieure d'Agronomie
(ENSA), l'École Nationale Supérieure des Travaux Publics (ENSTP), l'Institut Agricole de Bouaké
(IAB) et de l'Institut National Supérieur de l'Enseignement Technique (INSET), quatre
établissements que l'on désignait communément sous le vocable Grandes Écoles de
Yamoussoukro.
Missions de l’INP-HB
Définies par le décret 96-678 du 04/09/96, les missions de l’INP-HB sont :
-
La formation initiale et la formation continue : formations diplômantes et qualifiantes
de techniciens supérieurs, d’ingénieurs (des techniques et de conception) dans les
domaines de l’industrie, du commerce, de l’administration, du génie civil, des mines et
de l'agronomie;
-
La recherche appliquée dans les domaines précédemment cités ;
-
L’assistance et la production au profit des entreprises et administrations.
Ambitions de l’INP-HB
Ses ambitions sont à la mesure des espoirs que la nation ivoirienne place en lui pour la
formation des élites qui lui assureront une présence digne dans le concert des nations du
troisième millénaire. Il ambitionne aussi de développer son leadership tant au plan national
qu’à l’échelle sous régionale dans le domaine de la formation et de la recherche technique et
technologique.
VII
L’Ecole Supérieure d'Industrie
L’INP-HB est constitué à ce jour de 7 Ecoles dont une école préparatoire. Celle à laquelle
nous appartenons est l’Ecole Supérieure d’Industrie (ESI), chargée de former des cadres de
haut niveau capables de promouvoir et d'accompagner les évolutions techniques et
technologiques au sein des entreprises industrielles et d'accroître leur compétitivité. Elle est
organisée aujourd’hui en plusieurs filières dont le Cycle Ingénieur de Conception en
Télécommunications.
Le Cycle Ingénieur de Conception en Télécommunications
Conscient des besoins du marché et constatant la volonté du gouvernement de faire de
la Côte d’Ivoire un point de référence en matière de télécoms, l'INP-HB, a eu la lourde mission
d’ouvrir depuis 2002 au sein de l’ESI la filière Ingénieur Télécoms et Réseaux en partenariat
avec les opérateurs du monde des nouvelles technologies, de l’industrie et de la recherche.
L’ingénieur Télécoms et Réseaux INP-HB est appelé à répondre aux besoins du marché des
télécoms en pleine croissance. Son intégration sera donc possible chez un constructeur, un
opérateur du secteur des Télécoms ou dans une société qui offre des services de télécoms.
La formation intègre le développement d'un esprit d'initiative et s'appuie sur un
partenariat très actif avec les milieux socioprofessionnels. Cette étroite collaboration avec les
entreprises se matérialise au niveau des étudiants par des stages qu’ils doivent effectuer durant
leur cycle. De plus, la validation de cette formation nécessite d’effectuer un stage qui revêt un
caractère assez particulier. En effet, au cours de ce stage (qui est le dernier du cycle), l’étudiant
aura à mener des études dans le cadre de son mémoire de fin de cycle.
C’est dans ce cadre que nous avons intégré le Département Système et Maintenance de
la Société Nationale de Développement Informatique (SNDI), où nous allons travailler sur
« L’ETUDE ET LA MISE EN ŒUVRE D’UNE SOLUTION DE SUPERVISION DES
SERVEURS ».
VIII
RESUME
La taille des réseaux ne cessant de grandir de jour en jour et l’importance de ceux-ci
dans le monde de l’entreprise prenant une place prépondérante, le besoin de contrôler en
temps réel leur qualité et leur état est rapidement devenu une priorité. C’est dans ce but qu’est
apparu, il y a maintenant une vingtaine d’années, le concept de supervision de réseaux. Nous
présenterons dans ce document ce qu’est la supervision de réseaux ainsi que l’implémentation
qui en a été faite au sein de la SNDI.
Pour ce faire nous allons définir en premier lieu le concept et la notion de la supervision
de réseaux. Ensuite nous allons faire une étude comparative sur les différentes solutions de
supervision des réseaux, puis nous allons procéder à une étude approfondie de la solution
retenue. Enfin nous allons procéder à sa mise en œuvre en tenant compte des spécifications du
cahier des charges.
IX
INTRODUCTION
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. 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.
Les administrateurs ont un objectif clair : le maintien en production du système
d’information. Cependant, tous les éléments ne sont pas logés à la même enseigne en ce qui
concerne la criticité. Certaines parties sont vitales pour l’entreprise, comme les serveurs.
Sans outil de supervision, il est quasi impossible pour un administrateur de garder en tête
ces différents niveaux de criticité. L’outil de supervision peut ainsi aider à mettre des
priorités sur les interventions des administrateurs et leur permettre de se concentrer sur
l’essentiel.
C'est pourquoi les administrateurs réseaux et systèmes font appel à des logiciels de
surveillance et de supervision de réseaux. Ces logiciels vérifient l'état du réseau ainsi que des
machines connectées et permettent à l'administrateur d'avoir une vue d'ensemble en temps
réel de l'ensemble du parc informatique sous sa responsabilité. Il peut être aussi informé
(par email, par SMS) en cas de problème. Un tel système assure une gestion proactive du
système et améliore la disponibilité effective des applications et des services opérant sur les
serveurs. Mieux elle permet d’anticiper et de prévoir les éventuels besoins en termes
d’équipements pour une gestion optimale du système d’information.
Conscient de cela, la SNDI (SOCIETE NATIONALE DE DEVELOPPEMENT
INFORMATIQUE) dans sa volonté d’améliorer le fonctionnement de ses serveurs, s’est doté
de la solution de supervision Open Source NAGIOS qui surveille actuellement le taux
d’occupation des disques, l’utilisation de la RAM et du SWAP, la charge des processeurs, les
services web et de messagerie. Cependant, vu le nombre important d’équipements et
services à surveiller, et considérant que l’écosystème de la supervision regorge de nombreux
outils, la SNDI veut s’assurer que l’outil actuel est celui qui répond au mieux à son
infrastructure informatique.
C’est ainsi que nous avons été sollicité pour l’étude et la mise en œuvre d’un outil de
supervision des serveurs.
Le présent mémoire résume l’ensemble des actions que nous avons entreprises pour
la réalisation de ce projet. Il est structuré en trois parties. La première partie présente le
cadre et le contexte du stage, dans la deuxième partie il s’agira d’une étude des différents
outils de supervision et du choix de la solution retenue et la troisième partie présente la
mise en œuvre de la méthode retenue.
1
PARTIE A : CADRE ET CONTEXTE DU
STAGE
Nous allons d’abord décrire l’environnement de travail dans lequel nous allons évoluer,
ensuite nous présenterons le thème étudié, et la méthode de travail adoptée, enfin nous
présenterons, le concept de la supervision.
2
CHAPITRE 1 : Présentation de la structure d’accueil
1.1 Création et missions de la SNDI
1.1.1 Création de la SNDI
Afin de faire face au problème de la mécanisation du traitement de données, l’Etat
Ivoirien, dès son accession à l’indépendance décida de la mise en place de la Centrale
Mécanographique (CM). Celle-ci eut pour but l’automatisation de certaines tâches qui à
cette époque étaient manuelles.
Le décret N° 67-528 du 28 novembre 1967 fit de la Centrale Mécanographique un
Etablissement Public à Caractère Industriel et Commercial (EPIC), qui devint après l’Office
Centrale de Mécanographie (OCM). Cette structure eut pour missions essentielles le
traitement automatique de l’information en particulier pour le Ministère de l’Economie et
des Finances, et en général pour l’administration ivoirienne, ainsi que la formation de son
personnel.
Le décret N° 80-1251 du 28 novembre 1980 fait de l’OCM un Etablissement Public à
caractère Administratif (EPA) avec le retrait de la mission de formation des informaticiens
confiée désormais à une nouvelle structure à savoir la Commission Nationale Informatique
(CNI).
L’OCM est restructurée par le décret N° 9222 du 8 janvier 1992 qui fixe ses nouvelles
attributions notamment la gestion des applications informatiques et le rôle de maître
d’œuvre total ou partiel pour les projets informatiques des services publics ou parapublics.
Le 19 mars 1999, par le décret N°99-220, l’OCM devient la Société Nationale de
Développement Informatique (SNDI). La SNDI est une société anonyme au capital de deux
cents millions de francs CFA (200.000.000). Elle est répartie sur quatre sites à savoir :




Immeuble AZUR (immeuble Union Européenne) - 4ème et 5ème étage, abrite la
Direction Générale.
Centre I : Immeuble THOMASSET, face à l’ATCI (en réhabilitation).
Centre II : Cité financière rez-de-chaussée, 4ème et 5ème étage de la tour B,
abrite la plupart des directions opérationnelles.
Centre III : La Direction des Etudes, du Développement, de la Formation et de
l’Organisation sise à Cocody Danga.
3
1.1.2 Missions de la SNDI
La SNDI se charge de répondre aux besoins de l’Etat et travaille dans l’optique de
satisfaire entièrement les demandes de celui-ci. Ainsi, la SNDI a des contrats d’assistance
avec certains services publics de l’état notamment le Trésor, le Budget, les ministères, les
centres hospitaliers, les communes, les entreprises publiques, etc. Elle apporte sa
contribution dans la prise en charge des besoins de ces services. Son rôle consiste à :

Faire l’audit informatique ;

Réaliser les études de projets et de schémas directeurs, des études de marchés
informatiques et de budgétisation des dépenses informatiques ;

Mettre en œuvre et contrôler l’exécution de projets informatiques en qualité de
maître d’œuvre ;

Concevoir les applications informatiques ;

Réaliser la mise à niveau du personnel à travers la formation ;

Concevoir, Paramétrer et Sécuriser le réseau ;

Assister les utilisateurs de SIGFIP par une gestion rigoureuse des appareils sur
lesquels ils travaillent et la maintenance de ceux-ci ;

Veiller au bon fonctionnement du réseau SIGFIP ;

Administrer des systèmes de gestion de base de données ;

Offrir aux entreprises une plate-forme pour la gestion de leur
communication à
travers le serveur de Messagerie Worknet SNDI Version 3 ;

Concevoir, Développer des sites Internet (statique et dynamique) ;

Hébergements des noms de domaines (.ci, .com, .net, .org) et de site Internet.
1.2 Organisation de la SNDI
Pour mener à bien sa mission, la SNDI a effectué une restructuration de ses services
en 2004 qui a donné l’organigramme ci-après :
4
Conseil d’Administration
Direction Générale
Direction Générale
Adjointe
DAL
DEDFO
DERT
DRT
DFC
DCM
DSM-DBA
Figure 1. Organigramme de la SNDI
Nous voyons sur la figure 1, en carreau plein le Département Système, Maintenance
et DBA (Data Base Administration) qui nous a accueillis. Par ordre d’apparition sur
l’organigramme nous avons :
DAL : Direction de l’Administration et de la Logistique
DEDFO : Direction des Etudes, du Développement, de la Formation
l’Organisation
et de
DERT : Direction de l’Exploitation du Réseau et des Télécoms
DFC : Direction Financière et Comptable
DCM : Direction Commerciale et Marketing
DRT : Département Réseaux et Télécoms
DSM-DBA : Département Système et Maintenance-Data Base Administrator
5
CHAPITRE 2 : CONTEXTE DU STAGE
2.1 Département d’accueil
Nous avons été accueillis au Département Système et Maintenance (DSM). Ce
département a pour rôle de :






Gérer le parc informatique (avec le logiciel GLPI)
Gérer la messagerie WORKNET
Configurer les machines utilisant les applications SIGFiP, SIGMaP, RICI-EPN …
Mettre à jour l’antivirus pour les postes utilisant les applications SIGFiP,
SIGMAP, RICI-EPN …
Administrer les systèmes
 Installer les systèmes d’exploitation
 Gérer les disques
 Configurer et administrer les services réseaux
 Gérer le service d’annuaire
Maintenir les équipements (les serveurs, postes de travail, imprimantes,
onduleurs)
2.2 Positionnement du thème
La SNDI gère un parc informatique important. La tâche des administrateurs systèmes
devenant de plus en plus complexe, il est impérieux pour l’équipe de gagner en temps et en
efficacité grâce à un bon outil de supervision. L’enjeu du déploiement, de la configuration et
de l’optimisation d’une solution de surveillance des équipements est de permettre aux
administrateurs :

D’être alertés en temps réel des dysfonctionnements des équipements et des
services
 De pouvoir remonter facilement les alertes
 D’être proactifs aux problèmes
 D’améliorer la disponibilité effective des applications
Le moniteur de supervision Nagios a été installé et configuré. Cependant, vu le
nombre important de logiciels de supervision, il paraît nécessaire de confronter Nagios avec
les autres outils de supervision et mettre en œuvre la solution retenue. Ce qui justifie le
thème :
« ETUDE ET MISE EN ŒUVRE D’UN OUTIL DE SUPERVISION DES
SERVEURS »
2.3 Cahier des charges
L’objectif de la solution de supervision devra permettre de surveiller les équipements
et services de la SNDI.
6
Concernant les équipements ce sont :

Les serveurs
 L’état du serveur
 Le taux d’occupation des disques durs et des partitions
 L’état du swap
 Le taux d’utilisation des processeurs
 L’utilisation de la RAM
Concernant les services ce sont :

Les services de base de données oracle
 Le service oracle
 La connexion au listner
 L’état des caches
 Le remplissage des Tablespaces
 L’utilisation des processus
 Le remplissage des mémoires (SGA, PGA)







Le service DHCP
Le service Bind
Le service d’annuaire LDAP
Les services de messagerie (POSTFIX, SMTP)
Le service OPENSSH
Le service Vsftpd
Le service Samba
2.3.1 Contraintes
La solution retenue devra être une licence Open Source, et les équipements réseaux
tels que les routeurs, les switchs et les câbles ne devront pas être supervisés.
2.3.2 Méthodologie
Pour remplir cette mission nous allons procéder comme suit :
-
-
Nous allons d’abord procéder par l’étude de l’existant, en vue de connaître le
nombre de serveurs à surveiller, les services utilisés et les systèmes d’exploitation
utilisés sur ces serveurs.
Ensuite nous allons procéder à une étude des forces et des faiblesses des différents
outils de supervision Open Source après les avoir recensés, puis nous allons choisir la
solution la plus optimale en tenant compte de l’évolution du réseau.
Enfin nous allons mettre en œuvre cette solution, par son installation, sa
configuration et son optimisation.
7
2.4 Etude de l’existant
2.4.1 Présentation de l’environnement
L’architecture simplifiée du réseau interne de la SNDI se présente comme suit :
Figure 2. Architecture simplifiée du réseau interne de la SNDI
Les serveurs à superviser se trouvent dans une zone démilitarisée (DMZ) et se trouvent
dans une salle appelée Salle Serveurs.
2.4.1.1 L’environnement Système
Le parc à superviser est composé de 40 serveurs. Les systèmes d’exploitation sur ces
serveurs sont :
 Les Systèmes Linux
 Debian de la version 3 à la version 6
 RHEL (Red Hat Enterprise Linux) version 4 et 5
 Les systèmes Windows
 Windows server 2003
 Windows NT
8
2.4.1.2 L’environnement des services
Nous avons 6 groupes de services :
 Les services de gestion de base de données
 Les services oracle (Oracle 10g, 11g, 9i)
 Les services PostgreSQL
 Les services MySQL
 Les services d’applications
Dans le cadre de l’architecture trois tiers composées des applications clientes, des
bases de données et d’applications devant servir d’interfaces entre ces applications.
 Les serveurs de fichiers
 Samba pour le partage de fichiers
 Subversion pour la gestion des versions
 Le service web (http)
 Le service d’authentification (ldap)
 Le service de messagerie (postfix, imap)
2.4.1.3 Groupes d’administrateurs et de contacts
Un groupe de diffusion existe pour les administrateurs systèmes et un autre les
administrateurs de base de données. Ces groupes seront utilisés pour la notification des
alertes selon les services supervisés.
9
CHAPITRE 3 : LA SUPERVISION DES RESEAUX
Avant de présenter le principal protocole ainsi que les outils actuels permettant de
superviser un réseau, il paraît bon de définir précisément le concept de supervision et la
manière dont il a été normalisé par l’ISO.
3.1 Le concept de supervision des réseaux
La supervision des équipements a pour but de surveiller le bon fonctionnement des
équipements.
Ce concept est né au début des années 1980, lors de l’explosion de la mise en place
des réseaux informatiques dans les entreprises. La taille grandissante de ceux-ci ainsi que
leur hétérogénéité posaient un réel problème de gestion et d’administration, multipliant les
besoins en main d’œuvre d’experts administrateurs. C’est donc à cette époque qu’ont été
menées les premières réflexions sur un nouveau concept, celui de la supervision.
La supervision devait être capable de s’adapter à des milieux hétérogènes,
d’automatiser le contrôle des réseaux et de générer un ensemble de statistiques donnant
une meilleure vision du réseau, permettant d’anticiper les besoins de celui-ci.
La supervision peut ainsi se définir comme étant l’utilisation de ressources réseaux
adaptées (matérielles ou logiciels) afin d’obtenir des informations sur l’utilisation et sur
l’état des réseaux et de leurs composants (logiciels, matériels). Ces informations peuvent
alors servir d’outils pour gérer de manière optimale (automatique si possible) le traitement
des pannes ainsi que la qualité des réseaux (problèmes de surcharge). Elles permettent
également de prévoir toute future évolution nécessaire.
La supervision est capable de diagnostiquer et bien souvent de réparer seule les
pannes. Si ce n’est pas le cas, elle se charge d’alerter immédiatement les personnes
concernées par l’incident. Elle est donc extrêmement réactive et représente un gain
important en temps. De plus, par sa vision continue du réseau, elle anticipe souvent sur des
problèmes ultérieurs. On parle alors de pro-activité [1].
Ainsi, la supervision est à la fois réactive et proactive. C’est pourquoi, petit à petit, la
supervision s’impose dans la plupart des entreprises possédant un parc informatique
conséquent, ce qui est le cas de la SNDI.
3.2 La norme ISO
L’ISO s’intéresse de près à la supervision. Et, dès 1988, l’organisme publie la norme
ISO7498/41 définissant les principales fonctions que doivent implémenter les systèmes de
supervision et d’administration. Ces fonctions sont les suivantes :
3.2.1 Gestion des performances
La gestion des performances analyse de manière continue les performances du
réseau afin de le maintenir dans un état de performance acceptable. Cette gestion s’opère
1
Aussi connue sous le nom de OSI management Framework
10
en trois étapes. Tout d’abord, des variables contenant des informations significatives quant
aux performances du réseau sont récupérées. Parmi celles-ci on peut citer le temps de
réponse d’une station utilisateur ou encore le taux d’occupation d’un segment réseau. Une
fois ces variables obtenues, elles sont analysées. Si elles dépassent un seuil de performance
fixé préalablement, une alarme est tout de suite envoyée à l’administrateur du réseau, pour
régler le problème au plus vite.
Ces variables de gestion de performances sont réactualisées à court intervalle de
temps dans le but d’être le plus réactif possible au moindre embryon de baisse de
performance.
La gestion des performances permet donc une évaluation du comportement des
ressources et un contrôle de l’efficacité des activités de communication.
3.2.2 Gestion des configurations (Management Configuration)
La gestion des configurations effectue un suivi des différentes configurations des
éléments présents sur le réseau. Elle stocke dans une base de données les versions des
systèmes d’exploitation et des logiciels installés sur chaque machine du parc réseau. Par
exemple pour un ordinateur du réseau, la base contiendra la version de son système
d’exploitation, du protocole TCP/IP, etc…
La gestion des configurations permet donc une identification et un contrôle, des
systèmes ouverts. Elle collecte et fournit des informations sur les différents systèmes du
réseau.
3.2.3 Gestion de la comptabilité (Accounting Management)
La gestion de la comptabilité a pour but de mesurer l’utilisation des ressources afin
de réguler les accès et d’instaurer une certaine équité entre les utilisateurs du réseau. Ainsi
des quotas d’utilisation peuvent être fixés temporairement ou non sur chacune des
ressources réseaux. De plus, la gestion de la comptabilité autorise la mise en place de
systèmes de facturation en fonction de l’utilisation pour chaque utilisateur.
La gestion de la comptabilité permet donc un établissement des coûts d’utilisation
ainsi qu’une facturation de l’utilisation des ressources.
3.2.4 Gestion des anomalies (Fault Management)
La gestion des anomalies détecte les problèmes réseaux (logiciels ou matériels). Elle
essaie d’isoler le plus précisément le problème en effectuant divers tests. Quand cela est
possible, elle règle elle-même automatiquement l’anomalie. Sinon, elle alerte les personnes
concernées par le type du problème afin de solliciter leur intervention. La gestion des
anomalies garde dans une base de données l’ensemble des problèmes survenus ainsi que
leur solution, de manière à être encore plus efficace face à un incident récurrent. Cette
fonction de la norme ISO7498/4 demeure de loin la fonction la plus implémentée à ce jour.
La gestion des anomalies détecte donc et corrige les fonctionnements anormaux des
éléments du réseau.
11
3.2.5 Gestion de la sécurité (Security Management)
La gestion de la sécurité contrôle l’accès aux ressources en fonction des politiques de
droits d’utilisation établies. Elle veille à ce que les utilisateurs non autorisés ne puissent
accéder à certaines ressources protégées. La gestion de la sécurité met donc en application
les politiques de sécurité.
3.2.6 Structure de gestion des réseaux (Network Management System)
Après avoir défini les fonctionnalités de la supervision réseau, l’ISO s’est attaché à
décrire la structure de la gestion des réseaux (Network Management System). L’ISO propose
d’installer un agent de gestion sur chaque machine supervisée, comme le montre la figure
suivante :
Figure 3. Network Management System (MNS)
Cet agent récupère périodiquement et stocke localement des informations sur la
machine sur laquelle il tourne. Quand il détecte un problème, il le signale au service de
gestion centralisée (installé sur le serveur de supervision). Le service de supervision, en
fonction de la nature de l’anomalie, prend un ensemble de décisions (actions) dont une
bonne partie est transmise à l’agent de gestion présent sur la machine en difficulté. L’agent
exécute alors l’ensemble des actions réparatrices demandées par le superviseur afin de
remettre la machine en état.
Toutefois, le service central de supervision ne reste pas inactif en attendant que ses
agents lui rapportent des problèmes. Il peut en effet questionner régulièrement ses agents,
12
par le biais de requêtes, pour connaître l’état complet d’une machine, et par addition, l’état
de l’ensemble du réseau.
Les objets stockés dans les bases de données des agents sont normalisés au format
ASN.1. Ces bases de données ont aussi été normalisées par l’ISO. Elles sont appelées bases
de données MIB. Pour transmettre les différents messages échangés entre l’agent de
supervision et le superviseur, un protocole réseau de couche OSI 7 a été défini par l’ISO : le
protocole CMIP.
3.3 Le protocole SNMP
Jugeant les spécifications du protocole de transport CMIP proposé par l’ISO trop
lourdes à mettre en œuvre, l’IETF a défini son propre protocole de gestion des réseaux :
SGMP (Simple Gateway Monitoring Protocol). Celui-ci ne fut jamais réellement déployé
mais donna naissance en 1988 au protocole SNMP (Simple Network Management
Protocol).
Comme son nom l’indique, SNMP se veut être le plus simple possible. L’IETF estime
en effet que le transport des données de supervision ne doit pas nuire aux performances du
réseau. SNMP ne permet de superviser que les réseaux TCP/IP.
Il est donc totalement adapté aux réseaux informatiques utilisant majoritairement
cette technologie. D’ailleurs, SNMP s’est imposé, ces dernières années, comme étant le
standard incontournable de la supervision pour l’ensemble des réseaux non téléphoniques.
Depuis 1988, SNMP a beaucoup évolué en passant de sa première version,
complétement dépourvue de sécurité, à sa version numéro trois combinant une sécurité
basée sur les usagers et sur le type des opérations. Toutefois, actuellement, SNMPv1 reste la
version la plus employée, SNMPv3 n’étant en cours de déploiement que depuis 1999.
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 (voir structure NMS FIG.2). L’agent
reçoit les requêtes sur le port 161 et le superviseur reçoit les alarmes sur le port 162. Le
modèle d’échange entre le serveur et l’agent est basé sur deux types d’opérations, les
requêtes et les alarmes :
– Lorsque le serveur veut demander quelque chose à l’agent ou lui imposer un ordre, il émet
une requête en direction de l’agent. Celui-ci la traite et lui retourne une réponse.
– Lorsqu’un évènement survient sur l’élément du réseau surveillé par l’agent, ce dernier en
informe immédiatement le superviseur par le biais d’une alarme de type trap ou inform.
Dans le cas d’un inform, le serveur retourne une réponse à l’agent émetteur.
Ainsi, il existe trois messages SNMP différents : les requêtes, les réponses et les
alarmes. Les requêtes SNMP sont présentées dans l’Annexe I.
Le paquet SNMP, tel qu’il est définit dans la RFC 1157 (SNMPv1), est encodé au format
ASN.1. Il possède les champs suivants :
 Version SNMP
 Communauté
 PDU
La communauté définit le domaine de gestion. Agents et superviseurs doivent être
dans la même communauté pour pouvoir échanger. Le PDU contient les données du
13
protocole de supervision. Il est construit de manière identique pour les requêtes et les
réponses. Il diffère légèrement pour les alarmes (voir annexe 1). Comme nous l’avons vu, le
protocole SNMP permet l’échange de données de gestion entre un agent et un superviseur
dans un réseau TCP/IP. Toutefois, il n’est pas possible de surveiller des équipements
n’utilisant pas TCP/IP ou n’ayant pas d’agent SNMP. Pour cela, un proxy SNMP doit être
installé sur une machine TCP/IP. Ce proxy se charge de faire la translation entre les données
d’un agent de supervision privée et SNMP. Il est ensuite capable de transmettre ces données
à un superviseur SNMP. L’utilisation de ces proxys permet ainsi à SNMP de s’adapter
facilement à des réseaux très hétérogènes et prouve la grande flexibilité de ce protocole.
En plus des proxys SNMP, l’IETF a aussi défini des sondes capables de collecter des
informations de gestion sur un segment de réseau. Ces sondes font tampon entre les agents
d’un segment et un superviseur en centralisant les données relatives à un segment réseau
dans une base de données MIB. Les superviseurs ne dialoguent alors plus qu’avec les sondes.
Celles-ci ajoutent donc un niveau hiérarchique à la supervision. Chaque sonde dite RMON
peut écouter des segments réseaux de type Ethernet, TokenRing, ATM ou encore FDDI.
3.4 Déploiement des logiciels de supervision
Les logiciels de supervision peuvent être déployés de trois manières différentes :
- centralisée
- hiérarchique
- distribuée
 Déploiement centralisé : La supervision n’est assurée que par un seul ordinateur,
avec éventuellement une ou plusieurs machines miroir synchronisées. La
visualisation des éléments du réseau (alarmes, état des nœuds, etc...) est alors
centralisée en un point unique. Ce type de supervision reste tout de même sensible,
car toute la gestion repose sur une seule station. Si celle-ci vient à tomber en panne,
tout le processus de supervision est alors compromis. De plus la machine étant seule,
elle doit être suffisamment robuste pour pouvoir traiter l’ensemble des données de
supervision du réseau. Enfin, la machine effectue la totalité des requêtes de
supervision, ce qui a pour conséquence d’augmenter fortement le trafic réseau en
provenance de cette machine.
 Déploiement hiérarchique : La supervision est assurée ici de manière hiérarchique.
Un serveur de supervision central dialogue avec d’autres serveurs de supervision ne
s’occupant chacun que d’un segment de réseau. Ces mêmes serveurs peuvent aussi
avoir d’autres serveurs sous leur responsabilité. Ils sont à la fois clients et serveurs de
supervision. Ce type de déploiement est bien plus délicat à mettre en œuvre qu’un
simple déploiement centralisé mais offre une tolérance aux pannes bien plus élevée.
En effet, si un serveur supervisant un segment tombe en panne, seul le segment
concerné ne sera plus supervisé. De plus un tel déploiement permet d’avoir plusieurs
visions du réseau : une vision globale, depuis le serveur central, une vision d’un
segment depuis un serveur supervisant un segment, etc... Toutefois, il ne faut pas
occulter le fait qu’un déploiement hiérarchique reste plus coûteux en temps de
14
réponse qu’un déploiement centralisé, les différents serveurs devant se synchroniser
pour faire remonter les informations au niveau hiérarchique le plus haut.
 Déploiement distribué : Ce déploiement combine l’approche centralisée et
l’approche hiérarchique. Chaque station de supervision tient à jour une base de
données complète. Toutes les stations échangent donc entre elles les données de
supervision, sans restriction. Cela permet même de spécialiser certaines machines
sur un traitement de supervision précis (alarme, sécurité, performances, etc...).
Toutefois, il convient de bien définir le degré de responsabilité et de coopération
entre les machines.
15
PARTIE B : ETUDE ET CHOIX DE LA
SOLUTION
DE SUPERVISION
Dans cette partie, nous présentons de prime abord les différents critères de
choix d’une solution de supervision des serveurs, ensuite nous procédons à une
étude comparative des logiciels de supervision, pour terminer sur l’étude
approfondie de la solution choisie.
16
Chapitre 4 : Critères de choix de la solution
4.1 Les coûts élevés des licences propriétaires
En ces périodes où les budgets des services informatiques fondent comme la 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. Il y a quatre grosses sociétés qui se partagent le marché de la supervision
informatique ; elles sont appelées le « Big4 » et les tarifs pratiqués par l’ensemble de cellesci ont de quoi arrêter net tout projet de supervision. Ce sont :
 BMC SOFTWARE avec ses logiciels BMC Patrol, BMC Performance
Manager, BMC ProActiveNet
 Computer Associates Technologies avec UNICENTER
 HP avec hp Openview
 IBM avec Tivoli
Les logiciels propriétaires sont souvent incompatibles entre eux et imposent le choix d’un
fournisseur unique. L’utilisation d’un outil open source est tout indiquée dans ce genre de
situation.
Aussi les solutions open source ne sont-elles pas basées sur des licences dont le prix
est calculé au nombre de machines à superviser, elles permettent d’envisager
l’augmentation du périmètre supervisé sans coût supplémentaire du logiciel. Le tableau 1
représente une simple comparaison par rapport au coût entre une solution « Big4 » et une
solution « FOSS2 » pour la supervision de 1000 périphériques [2].
Tableau 1. Comparaison des coûts entre les licences Open Source et les licences
propriétaires
Coût de la licence
Coût de la Souscription
Coût de la maintenance
Coût de l’implémentation
Total
FOSS(€)
0
0
0
0
0
BIG 4(€)
443,34
0
157,031
266,375
866.375
* Pour les « Big4 » les frais de mise en œuvre sont >= 30% de la redevance en 2 ans
* Pour les « Big4 » les frais d'entretien sont > = 24% des coûts de la licence.
Par la suite nous allons voir un peu plus en détail les quelques outils FOSS utilisés sur
la marché de la supervision.
2
Free and open-source software (Un logiciel libre et gratuit)
17
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é. Les environnements informatiques étant tous 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 étant é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 [3].
4.3 La 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.
4.4 Les performances
Les systèmes d’information varient en architecture mais aussi en taille. La solution de
supervision choisie doit être performante afin d’être en mesure de gérer un nombre
important d’éléments. Il serait dommage de se restreindre à cause des piètres performances
de l’outil.
Bien évidemment, toute solution a ses limites, ne serait-ce qu’en raison des
limitations des serveurs. L’outil doit dans l’idéal proposer des méthodes de répartition de
charge sur plusieurs serveurs.
4.5 Mise en commun des expériences
Le phénomène de communauté3 est également important. Si chaque système
d’information se distingue des autres, les différences ne sont généralement cantonnées qu’à
une partie restreinte. Les systèmes ont, en général, de nombreux points communs et
doivent être supervisés de la même manière. Au sein d’une communauté d’utilisateurs, il est
possible de partager et de rassembler les meilleures pratiques de supervision.
Ce phénomène de communauté est extrêmement marqué lorsqu’il s’agit d’outils
open source car tout le monde peut participer à la conception de l’application, et chacun
peut apporter son expérience dans la supervision d’un élément particulier et en faire
profiter l’ensemble de la communauté.
3
Ensemble des utilisateurs d’une application
18
CHAPITRE 5 : Les outils de supervisions
5.1 ZABBIX
5.1.1 Qu'est-ce que Zabbix?
Zabbix a été créé par Alexei Vladishev en 2000, et est actuellement développé et
soutenu par ZABBIX SIA. Zabbix est une solution de supervision distribuée et open source de
classe Entreprise.
Zabbix est un logiciel qui supervise de nombreux paramètres réseaux ainsi que la
santé et l'intégrité des serveurs. Zabbix utilise un mécanisme de notification flexible qui
permet aux utilisateurs de configurer une base d'alerte e-mail pour pratiquement tous les
événements. Cela permet une réponse rapide aux problèmes serveurs. Zabbix offre un
excellent reporting et des fonctionnalités de visualisation de données basées sur les
données stockées.
Zabbix supporte à la fois polling et trapping4. Tous les rapports et statistiques,
comme la configuration de paramètres, sont accessibles par l'interface web. L'interface web
veille à ce que le statut du réseau et des serveurs puisse être évalué depuis n'importe quel
endroit. Correctement configuré, Zabbix peut jouer un rôle important dans la supervision de
l'infrastructure informatique. Ceci est également vrai pour les petites organisations avec peu
de serveurs ainsi que pour les grandes entreprises avec une multitude de serveurs [4].
5.1.2 Qu'offre Zabbix?
Zabbix nous offre les possibilités suivantes:











Découverte automatique des serveurs et périphériques réseaux
Supervision répartie sur une administration web centralisée
Support des mécanismes “polling and trapping”
Logiciels serveurs pour Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X
Agent haute performance en natif (Logiciel client pour Linux, Solaris, HP-UX, AIX,
Free BSD, Open BSD, OS X, Tru64/OSF1, Windows NT4.0, Windows 2000, Windows
2003, Windows XP, Windows Vista)
Supervision sans agent
Authentification d'agent sécurisée
Permissions utilisateurs flexibles.
Interface web
Notification d'événements prédéfinis par e-mail ou par sms
Haut niveau de visualisation des ressources supervisées
4
Envoi des requêtes de supervision (polling) et réception des alertes (trapping)
19
5.1.3 Les atouts de zabbix
Zabbix offre aux ingénieurs systèmes les avantages suivants :










Solution Open Source
Grande efficacité des agents pour les plateformes UNIX et WIN32
Faible coût de “possession”
Configuration très simple
Système de supervision centralisé. Toute l'information (configuration, performance,
données) est stockée dans une base de données relationnelle.
Installation très facile
Support du SNMP (v1, V2).
Visualisation des capacités
Procédure de nettoyage intégrée
Gestion de l’architecture distribuée
5.1.4 Le public visé par Zabbix
Le public est assez large, allant de simples individus à des entreprises multinationales.
Il y a des gens qui utilisent Zabbix pour superviser juste quelques machines et il y a aussi de
grandes entreprises qui utilisent Zabbix pour la supervision d’infrastructures mondiales de
dizaines et de centaines de milliers de serveurs collectant des téraoctets de données
d’historique par an.
Fait intéressant, Zabbix est très bien conçu comme plate-forme de supervision pour
des entreprises du secteur financier. Il y a de nombreuses grandes institutions financières et
de banques en Europe utilisant Zabbix pour la surveillance de leur infrastructure IT. En
Lettonie, pays d’origine de Zabbix, il est activement utilisé par la plupart des banques du Top
10 [5].
Le large public rend toutes les décisions architecturales beaucoup plus difficiles. Il y a
cinq ans notre client type était une société ayant quelques centaines d’équipements, de nos
jours nous communiquons plus fréquemment avec de grandes entreprises ayant des
environnements distribués et des dizaines de milliers d’appareils à superviser.
5.2 Zenoss
5.2.1 Généralités et fonctionnalités de Zenoss
Le développement de Zenoss a été lancé en 2002 par Erik Dahl. La société Zenoss a
été fondée en 2005 pour accompagner le développement de Zenoss. Zenoss est déployé en
production dans de nombreuses entreprises et administrations de taille moyenne. C’est une
application open source, le serveur et la plate-forme de gestion de réseau sont basées sur le
serveur d'application Zope. Publié sous la licence publique générale GNU (GPL) version 2,
Zenoss Core fournit une interface Web qui permet aux administrateurs systèmes de
20
contrôler la disponibilité, l'inventaire et la configuration, les performances et les
événements.
Zenoss, Inc. parraine le développement de Zenoss Core et vend une version
d'entreprise basée sur la version de base [6].
Zenoss Core combine une programmation originale et plusieurs projets open source
d'intégration de stockage de données et les processus de collecte de données avec une
interface utilisateur Web. Selon le site web du projet www.zenoss.org, Zenoss Core est bâti
sur les sources suivantes des technologies open source ouvertes:
 Serveur d'applications Zope: Un serveur web orienté objet écrit en Python.
 Python: langage de programmation.
 Net-SNMP: protocole de surveillance qui recueille des informations sur l'état
des systèmes.
 Les données rrdtool: Graphique et log des séries chronologiques.
 MySQL: Une base de données open source.
 Twisted: Un moteur réseau événementiel écrit en Python.
Zenoss Core fournit les fonctionnalités suivantes:
 Suivi des disponibilités des périphériques réseau utilisant SNMP, SSH
 Surveillance des services réseau (HTTP, POP3, NNTP, SNMP, FTP)
 Contrôle des ressources hôte (processeur, l'utilisation du disque) sur la
plupart des systèmes d'exploitation réseau.
 Suivi de la performance des séries chronologiques de dispositifs
 Outils de gestion de l'événement pour annoter des alertes du système
 Découverte automatique des ressources réseaux et les changements de
configuration réseau
 Système d'alerte
 Fournit des notifications basées sur des ensembles de règles et calendriers
sur appel
5.3 OpenNMS
5.3.1 Description de OpenNMS
Le projet OpenNMS a débuté en Juillet 1999 et a été enregistré sur SourceForge5 en
Mars 2000. OpenNMS est une plate-forme de qualité réseau et de surveillance mis au point
dans le cadre du modèle FOSS. OpenNMS est soutenue par la communauté Open Source,
ainsi que par Sortova Consulting qui offre des services commerciaux, de formation et de
soutien. L'objectif est qu’OpenNMS soit réellement distribué en tant que plate-forme
évolutive pour tous les aspects de la gestion et de monitoring6 de réseau. Tout le code
associé au projet est disponible sous la GNU General Public License. OpenNMS est
actuellement maintenu par Tarus Balog, le Groupe OpenNMS et l'ordre du polo vert [7].
Trois ans de développement ont suffi pour placer l'application comme une référence
dans son domaine, au même titre que des logiciels commerciaux beaucoup plus anciens (et
onéreux) comme HP OpenView.
5
6
Plate-forme d'hébergement de projets
Surveillance
21
Les raisons de ce succès rapide, mis à part son mode de développement, sont à
attribuer à une conception claire et rigoureuse, par des spécialistes réseaux, autour de
technologies modernes et standardisées comme Java (langage de programmation orienté
objet multiplateformes), XML (qui structure les données et les échanges de manière
homogène) et SNMP (protocole de gestion de réseaux).
OpenNMS est une application Web (tournant sous Apache) accessible depuis
n'importe quel poste du réseau disposant d'un simple navigateur internet. Elle est construite
sur d'autres logiciels libres phares, comme Tomcat (serveur d'application développé par la
fondation Apache), PostgreSQL (moteur de bases de données relationnelles robustes et
conformes aux dernières normes en la matière), qui sont des gages d'évolutivité, de stabilité
et de pérennité.
5.3.2 Les fonctionnalités
OpenNMS offre entre autre les fonctionnalités suivantes :










Découverte des équipements réseaux à superviser (ping) ;
Découverte des services présents sur un équipement et en mesurer la disponibilité ;
Identification et énumération des interruptions de services réseaux ;
Collecte des informations et réception des alarmes provenant des équipements
supervisés via le protocole SNMP ;
Enrichissement des informations d’un évènement par des données stockées dans la
base de données ;
Corrélation entre les alarmes afin de présenter un affichage clair des problèmes en
cours ;
Corrélation, notification et escalade des évènements sous forme d’alarmes ;
Disposition d’une interface Web permettant d’administrer et de superviser en tout
lieu;
Réalisation des graphiques à partir de polling SNMP ;
Représentation graphique des équipements supervisés.
Bien que prêt à l'emploi avec sa configuration par défaut, OpenNMS se doit d'être
paramétré :
-
pour s'adapter au mieux à la topologie du réseau et à la nature des services qu'il
surveille
pour affecter des niveaux de gravité adéquats aux évènements qui peuvent
survenir
pour cibler les alertes de manière pertinente, et s'adapter à la structure du
service informatique.
OpenNMS a été conçu dès le départ pour gérer des dizaines de milliers d’équipements avec
une seule instance. Il apporte la puissance, l’évolutivité et la flexibilité que demandent les
entreprises et les opérateurs.
22
5.4 FAN (FULLY AUTOMATED NAGIOS)
5.4.1 Présentation de FAN
Initié par Cédric Temple début 2008 pour répondre à des besoins quotidiens
d’administration, le projet FAN, Fully Automated Nagios, est une distribution GNU/Linux
dédiée à la supervision basée sur Nagios et son formidable écosystème. Les auteurs ont
écouté les demandes de nombreux utilisateurs pour bâtir une solution complète qui
comprend les principaux plug-ins de Nagios, l’interface de configuration Centreon pour la
configuration, NagVis pour la visualisation du réseau. Son objectif principal est de fournir
tout cela en moins de 20 minutes avec la même simplicité d’installation que pour n’importe
quelle autre distribution. FAN est basé sur la distribution CentOS et propose la solution la
plus simple et efficace pour mettre en place Nagios, Centreon et NagVis en une seule
installation. Elle a de plus l’avantage de proposer un environnement déjà configuré. Les
administrateurs n’ont plus qu’à rajouter leurs éléments à superviser. Etudions chacun des
éléments constituant FAN, c’est à dire Nagios, Centreon et Nagvis [8].
5.4.2 Nagios
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 3.2.3, il a plus de neuf ans d’existence.
Comme nous le verrons par la suite, il se bonifie avec l’âge.
5.4.2.1 Présentation
Nagios récupère les informations fournit par les services de surveillance et les
analyse. Si le résultat de cette analyse fait remonter un problème, les services de
surveillance peuvent envoyer des avertissements à l’administrateur du réseau de différentes
manières : courriers électroniques, messages instantanés, SMS, flux RSS etc...
5.4.2.2 Fonctionnalités
Nagios possède de nombreuses fonctionnalités, voici les principales :
 Surveillance des services réseaux (SMTP, POP3, http, NNTP, PING, etc.)
 Surveillance des ressources des stations (serveur, routeur ...) comme la
charge du processeur, des informations sur l’utilisation des disques durs,
les
processus en cours, les fichiers de log, . . .
 Surveillance des données environnementales comme par exemple la température.
 Une conception simple de greffons permettant aux administrateurs de
développer facilement leurs propres fonctionnalités de surveillance.
 Possibilité de définir des groupes de contacts à joindre en cas d’apparition de
problème via différentes méthodes (le courrier électronique, les messages
instantanés).
23
 Sectorisation des groupes de contacts par rapport aux problèmes rencontrés et
définition de procédures.
 Définition de gestionnaires évènements qui peuvent être exécutés afin
d’automatiser la résolution de problèmes rencontrés.
 Surveillance des architectures des systèmes repartis ou redondants.
 L’interface de commandes externes permet des modifications à la volée du
comportement de la surveillance et du retour d’informations à travers l’utilisation
de gestionnaires évènements, d’une interface web et d’applications tierces.
 L’historique de l’état du réseau est conservé même après un redémarrage
 Possibilité de planifier des périodes d’inactivités des contrôles pour correspondre à
une période d’inactivité physique d’un serveur.
 Retour d’informations disponible à travers n’importe quel navigateur, permettant
de consulter l’état courant du réseau, l’historique des avertissements et les fichiers
de log.
 Un schéma simple de gestion des autorisations permet de gérer facilement les
droits de consultation des informations par les utilisateurs à travers un navigateur.
Nagios possède également une fonctionnalité importante : l’héritage. Cela permet de
hiérarchiser l’ensemble des hôtes supervisés. Concrètement, si un hôte faisant la jonction
entre la machine Nagios et le reste d’une branche ne fonctionne plus, Nagios ne générera
pas d’alertes concernant les éléments de cette branche [9].
Nagios est un logiciel très performant, mais difficile à administrer car sa configuration est
longue et fastidieuse. Heureusement, il est possible de puiser dans un écosystème applicatif
très vaste pour trouver d’excellents outils d’aide à la configuration, parmi lesquels figure en
première place Centreon.
5.4.3 Centreon
5.4.3.1 Présentation
Le développement de Centreon commence en 2003 sous le nom d’Oreon, sous
licence GPL v2. Centreon est le dérivé français de Nagios de référence développé par la
société Merethis. Il s’agit d’une couche applicative Web venant se greffer à Nagios pour
offrir une administration moins rudimentaire (évite les fichiers de configuration et les lignes
de commandes brutes). Voyons les fonctionnalités de Centreon [10].
5.4.3.2 Fonctionnalités
Centreon offre entre autre les fonctionnalités suivantes :

administration du système de supervision :
- configuration de Nagios (v2 ou v3),
- configuration simplifiée des alertes SNMP,
- gestion des droits d'accès de manière très fine et très simple,
- installation de modules supplémentaires en fonction du besoin,
- aide à la lecture et à l'interprétation des journaux d'événements de Nagios,
24
-
augmentation des performances et agrégation des données issues de
plusieurs serveurs Nagios répartis sur le système d'information.

supervision du Système Informatique :
7
- permet de suivre l'historique du fonctionnement du SI (graphes, échelles de
temps),
- permet d'effectuer des rapports de fonctionnement de services,
- permet aux managers d'estimer la qualité de service rendu par leur SI,
- permet aux administrateurs des systèmes du SI d'être prévenus et donc de
réagir très rapidement en cas de problème ce qui ne peut qu'augmenter la
qualité de service du SI de l'entreprise.

permet de choisir une architecture de supervision adaptée :
- supervision centralisée pour les petits et moyens systèmes informatiques
- supervision distribuée adapté aux grands systèmes informatiques
Centreon est un outil d’aide à la configuration de Nagios très utile, il induit un gain de temps
à ne pas négliger. Il s’occupe de nombreux aspects de la solution comme la supervision, la
configuration, la gestion des alertes SNMP ou encore la métrologie. Il facilite grandement la
mise en place d’environnements distribués.
Une fois les informations de supervision recueillies, il est important de les présenter
sous différentes formes, afin que les données soient utilisées immédiatement ou agrégées
pour être intégrées dans des indicateurs. D’où l’utilisation de Nagvis.
5.4.4 Nagvis
Parmi les outils permettant d’agréger les données de supervision de Nagios pour
obtenir des écrans de supervision, il en est un qui se détache nettement en termes de
fonctionnalités et de stabilité : NagVis. Écrit en PHP, il utilise beaucoup de JavaScript afin de
donner vie aux pages. La création des cartes se fait directement depuis son interface web.
Cette étape est intuitive. Les fonctionnalités Javascript font que la définition d’un élément et
son placement sont faciles.
Nagvis permet entre autres de :
- Afficher de simples hôtes et des services
- Visualisez un hôte ou un service avec une icône
- Afficher l'état sommaire d'un hôte et de tous ses services
- Afficher uniquement les vrais problèmes
- Disposer de sous-cartes qui représentent une carte NagVis complète en un
seul icône (drill down)
- Visualiser complètement des processus IT en utilisant l'auto graphique
(Automap)
- Se documenter en ligne sur les environnements informatiques actuels, y
compris les États
7
Système Informatique
25
-
Visualiser du trafic réseau en utilisant les lignes weathermap
Avoir des capacités multilingues
Avoir une interface web de configuration
Les administrateurs ont souvent besoin d’observer l’état des indicateurs les plus importants
de leurs systèmes. NagVis permet de récupérer les informations de Nagios et de les
présenter de manière agréable [11].
Le but de FAN est de fournir un CD d'installation qui comprend les outils les plus utilisés dans
la communauté Nagios. Le FAN CD-ROM est certifiée ISO. Il est donc très facile à installer. Un
grand nombre d'outils sont également distribués, ce qui rend la mise en œuvre d'une
plateforme de suivi efficace beaucoup plus facile.
Nous avons présenté quelques outils de supervision libres, les plus connus. Il convient de
choisir la solution à mettre en œuvre et de justifier ce choix.
26
CHAPITRE 6 : CHOIX DE LA SOLUTION
Le Tableau suivant récapitule la comparaison des différents logiciels présentés.
Logiciel
Zabbix
Zenoss
OpenNMS
Nagios (FAN)
Tableau 2. Comparaison des différents logiciels libre présentés
Modularité
Performances
Communauté
Moyenne
Bonnes
Grande
Bonne
Bonnes
Grande
Moyenne
Moyennes
Grande
Très bonne
Très bonnes
Très grande
>250000 membres
Age
11 ans
9 ans
12 ans
12 ans
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. Voyons ses
atouts par rapport aux différents logiciels présentés.
6.1 Atouts de Nagios par rapport aux autres outils open source
6.1.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 [12].
6.1.2 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 GPL8, 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 virtualité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
8
Licence de logiciel libre
27
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 .
6.1.3 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 ne possè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.
6.1.4 Nagios, logiciel open source de supervision le plus utilisé
Grâce à Google trends nous pouvons comparer les différentes plateformes de supervision
open source (Zabbix, Zenoss, OpenNMS, Nagios) le tableau suivant représente l’évolution
générée par le trafic d’utilisation de ses solutions au cours des sept dernières années dans le
monde entier. Les captures d’écran illustrant ce tableau sont contenues dans l’annexe IV.
Tableau 3. Comparaison de l’utilisation des logiciels open source de supervision
Logiciel de
Dans le
Allemagne
France
USA
supervision
Monde
Nagios
73%
90%
90%
70%
Zabbix
10%
3%
3%
10%
OpenNMS
5%
3%
3%
7%
Zenoss
5%
3%
3%
4%
Autres
17%
1%
1%
9%
On remarque que l’utilisation de Nagios reste la pierre angulaire lors du choix des solutions
open source pour la supervision et est le logiciel Open Source le plus documenté.
Nagios est la référence en matière de logiciel de supervision open source. Développé
depuis plus de 10 ans, il possède une communauté sans égale et des possibilités très
étoffées. Il a cependant une réputation, méritée, d’être relativement complexe à prendre en
main, notamment la partie configuration. C’est pourquoi le logiciel FAN vient à point nommé
pour faciliter sa configuration et sa prise en main. Nous allons l’étudier en profondeur pour
faciliter sa mise en œuvre.
28
CHAPITRE 7 : ETUDE DE NAGIOS
7.1 Architecture de Nagios
Nagios repose sur un serveur web et des CGI. Il peut intégrer une base de données de
type MySQL ou PostgreSQL pour y stocker des informations de supervision. Bien que
conseillée, la base de donnée n'est pas essentielle dans le fonctionnement de Nagios et peut
être remplacée par de simples fichiers tournants, mais cette architecture doit être limitée à
de petites installations avec un nombre de machines supervisées restreint. L'architecture
standard de Nagios peut donc être représentée de la manière suivante :
Figure 4. Architecture de Nagios
7.1.1 Les Plugins
Les plugins sont des programmes exécutables ou des scripts (perl, Shell, etc..) qui peuvent
être lancés depuis une ligne de commande pour tester un hôte ou un service.
Le résultat de l'exécution d'un plugin est utilisé par Nagios pour déterminer le statut des
hôtes ou des services sur le réseau. Le développement des plugins pour Nagios est fait sur
SourceForge. La page du projet de développement de plugins pour Nagios (où vous
trouverez
toujours
la
dernière
version
des
plugins)
se
trouve
à
http://sourceforge.net/projects/nagiosplug/.
Les plugins développés pour Nagios doivent respecter un certain format d'affichage
de retour afin de garantir leur intégration. Tous les plugins qui respectent les consignes
minimales de développement pour ce projet contiennent une documentation interne. Cette
documentation peut être affichée en exécutant le plugin avec le paramètre "-h" ("--help" si
les paramètres longs sont activés) [13].
29
Par exemple, si nous voulons savoir comment fonctionne le plugin check_http
(vérification de l’état du serveur web) ou quels paramètres il accepte, vous devez saisir dans
la ligne de commande:
#. /check_httpd --help
7.1.2 Les agents
Il est possible d'utiliser des agents de supervision permettant de récupérer des
informations à distance. Ils offrent la possibilité de profiter de la puissance offerte par les
plugins. Il existe 2 types d'agents :


Les agents NRPE
Les agents NCSA
Le principe de fonctionnement des agents nrpe (pour Nagios Remote Plugin Executor)
est simple : les plugins sont installés sur l'équipement à superviser, compilés en fonction de
son architecture car c'est elle qui va les exécuter, ainsi que le démon nrpe faisant office de
serveur. Sur la plateforme de supervision Nagios, le plugin check_nrpe fera alors office de
client nrpe, récupérant les informations en interrogeant le démon nrpe sur l'équipement
concerné.
Le plugin check_nrpe sur le serveur Nagios initiera une connexion vers l'agent nrpe de la
machine cible et lui demandera alors l'exécution d'une vérification. L'agent nrpe lancera
alors le plugin configuré en local pour obtenir l'information et retournera le code retour de
l'exécution ainsi que sa sortie standard [14].
Figure 5. Fonctionnement de nrpe
30
Les agents ncsa (pour Nagios Service Check Acceptor) diffèrent des agents nrpe car la
vérification est plannifiée en local sur l'équipement supervisé, exécutée, puis le résultat est
envoyé au serveur Nagios. De même que pour nrpe, l'architecture ncsa demande la
présence du plugin check_ncsa sur la plateforme Nagios.
Figure 6. Fonctionnement de nsca
7.2 Fonctionnement
7.2.1 Méthode d’obtention des informations
Nous pouvons distinguer deux modes de fonctionnement complémentaires de
Nagios : le mode actif, ou de polling et le mode passif ou de traps [15].
Figure 7. Les deux modes de fonctionnement de Nagios
 En mode polling, Nagios exécute un plugin pour réaliser un test à des intervalles
de temps réguliers. Il analyse ensuite la réponse et adopte un comportement en
fonction de celle-ci. Ce mode de fonctionnement entraîne une génération du
trafic sur le réseau.
 En mode passif, Nagios reste à l’écoute de tout ce qu’on peut lui dire. Pour communiquer
avec lui, il suffit d’installer le programme client send_nsca sur les serveurs à superviser et
de faire tourner le démon nsca sur le serveur Nagios. Dans notre configuration, c’est le
31
démon9 snmptrapd de Net-SNMP qui utilise ce programme client via le script ‘traitementtrap’.
Quel que soit le mode de fonctionnement, Nagios remonte des alertes aux
administrateurs définis dans ses fichiers de configuration, que ce soit par mail, sms, flux
RSS… Nagios met aussi en permanence à jour sont interface web qui reflète donc en temps
réel l’état du réseau et des services.
7.2.2 Données à définir dans Nagios
Nous avons parlé des éléments distants à superviser, regardons maintenant les
informations dont a besoin Nagios afin d’accomplir sa tâche. Ces éléments devront être
définis dans les fichiers de configuration de Nagios [16]. Ces fichiers sont généralement
situés dans le répertoire etc de l’arborescence de Nagios, par défaut /usr/local/nagios. Ils
sont construits sur le modèle suivant :
define type {
parametre1=valeur1 ; commentaire
parametre2=valeur2
}
Ici nous voyons la déclaration d’un objet type qui a comme valeur valeur1 pour
parametre1. Certains paramètres sont indispensables, d’autres sont optionnels. Les
commentaires commencent par le signe ; .
7.2.2.1 Commandes de vérification
Nagios a besoin qu’on lui fournisse les commandes responsables des vérifications des
éléments distants. Ce sont ces commandes qui déterminent l’état des éléments distants et
donnent l’information à Nagios. Elles récupèrent également les données de performances.
Pour les définir, on doit instancier l’objet command. Ces instances figurent dans le fichier
commands.cfg. Ces objets sont simples et ne comportent que deux propriétés :
• command_name : c’est le nom de la commande tel qu’on va pouvoir l’utiliser dans le
reste de la configuration Nagios ;
• command_line : c’est la commande que doit lancer Nagios. On remarque dans l’exemple
ci-dessous une valeur un peu particulière, $HOSTADDRESS$. C’est en fait une macro qui est
positionnée lors du lancement de la commande par Nagios. Elle peut changer de valeur
suivant le contexte. Ici, elle est égale à l’adresse réseau de l’élément que l’on veut surveiller.
 Exemple de commande
define command {
command_name check_tcp
command_line /usr/local/nagios/libexec/check_tcp -H $HOSTADDRESS$ -p $ARG1$
}
9
programme informatique qui s'exécute comme un fond processus
32
- Arguments des commandes
Les commandes peuvent prendre des arguments, comme c’est le cas dans notre
exemple check_tcp ci-dessus. Les arguments sont de la forme $ARGn$, n pouvant aller de 1
à 32. Ils peuvent être donnés lors de l’appel de la commande, par un hôte ou par un service.
Ceci permet, entre autres, d’avoir une seule définition de commande pour vérifier un port
TCP et de spécifier, par exemple dans le service, le numéro de port que l’on souhaite
surveiller.
7.2.2.2 Commandes de notification
Les commandes de notification sont faites pour avertir les administrateurs. Elles
figurent dans le fichier commands.cfg aux côtés des commandes de vérifications. Par
exemple, pour envoyer un e-mail relatif à un événement sur un hôte, nous avons la
définition suivante :
define command{
command_name host-notify-by-email
command_line /bin/echo "Host $HOSTNAME$ is $HOSTSTATE$" | /bin/mail
$CONTACTEMAIL$
}
7.2.2.3 Périodes de temps
Nagios a besoin de savoir quand superviser les éléments et quand avertir les
administrateurs. Ces périodes de temps peuvent varier suivant les environnements. Il faut
que l’administrateur puisse les définir librement.
 Définition des périodes de temps
L’objet qui se charge de cela est timeperiod. Ses instances figurent dans le fichier
timeperiods.cfg. Cet objet a comme propriétés :
• timeperiod_name : c’est le nom qui sera utilisé dans le reste de la configuration ;
• alias : c’est un nom d’affichage dans les interfaces ;
• sunday, monday, etc. : pour chaque jour, on peut préciser un intervalle de temps qui sera
pris en considération.
Les périodes de temps peuvent être exprimées simplement. Ici, par exemple, les
33
horaires d’ouverture du service :
define timeperiod{
timeperiod_name workhours
alias Work Hours
monday 09:00,17:00 ; Lundi
tuesday 09:00,17:00 ; Mardi
wednesday 09:00,17:00 ; Mercredi
thursday 09:00,17:00 ; Jeudi
friday 09:00,17:00 ; Vendredi
}
7.2.2.4 Hôtes
Également nommés hosts, nœuds ou ressources, ce sont les éléments que Nagios
supervise. Dans le cadre de la supervision système, c’est le serveur à surveiller ; En cas de
problème, il alerte un ou plusieurs contacts.
Cet élément est la base de la supervision dans Nagios car il permet de renseigner
l’administrateur sur la disponibilité d’un serveur.
 États d’un nœud
Un hôte peut avoir trois états :
• UP : il est en état de répondre ;
• DOWN : il est indisponible ;
• UNREACHABLE : l’état n’est pas connu car il est situé, en termes de réseau, derrière un
élément qui est tombé (Switch, Routeur, Hub).
 Définition d’un hôte
Un nœud possède des propriétés particulières comme son adresse réseau ou bien les
personnes à contacter en cas de problème. C’est un objet host au sens de Nagios. Ces objets
figurent dans le fichier hosts.cfg. L’ensemble des propriétés indispensables sont les
suivantes :
• host_name : nom de l’hôte tel qu’il sera utilisé dans le reste de la configuration ;
• alias : nom qui est affiché aux utilisateurs ;
• address : adresse réseau de l’hôte ;
• max_check_attempts : nombre de vérifications que Nagios doit tenter avant de le déclarer
réellement DOWN ;
• check_period : période de temps pendant laquelle le nœud est supervisé ;
• contacts : contacts à prévenir en cas de souci ;
• contact_groups : groupes de contacts à prévenir en cas de souci ;
• notification_interval : intervalle de temps, en minutes, entre les notifications d’erreur ; si
cette valeur est à zéro, il ne sera envoyé qu’une seule notification ;
• notification_period : période de temps appliquée aux notifications des contacts.
34
Deux autres propriétés sont facultatives mais fortement conseillées :
• check_command : commande qui vérifie l’état de l’hôte. Elle est optionnelle car, dans
certains cas particuliers comme la supervision passive, elle n’est pas nécessaire.
• notification_options : ce sont les états des hôtes qui doivent faire l’objet d’une
notification. Si l’option n’est pas spécifiée, Nagios considère que tous les états doivent être
remontés. Les états possibles sont :
– d : lorsqu’un hôte passe en état DOWN ;
– u : lorsqu’un hôte passe en état UNREACHABLE ;
– r : lorsqu’un hôte revient en état UP ;
– n : est utilisé si un contact ne veut recevoir aucune notification.
 Exemple de définition
Définissons un hôte représentant un serveur nommé srv-web1. Il est vérifié avec la
commande check-host-alive qui envoie simplement un ping vers l’adresse du serveur. Ce
test est effectué toutes les 5 minutes. En cas de problème, ce test est réitéré deux autres
fois : la propriété max_check_attempts = 3 = 2 + 1 test déjà effectué. Si le problème
persiste, une notification est envoyée au groupe web-admins. Si le problème n’est pas
résolu 30 minutes après, une autre notification est envoyée, et ainsi de suite. Lorsque le
problème est résolu, le compteur repasse à zéro.
 Définition d’un hôte
define host {
host_name srv-web1
alias Serveur Web 1
address 192.168.0.1
check_command check-host-alive
check_interval 5
retry_interval 1
max_check_attempts 3
check_period 24x7
contact_groups web-admins
notification_interval 30
notification_period 24x7
notification_options d, u, r
}
 7.2.2.5 Services
Les services sont les points supervisés sur les hôtes. Dans le cas d’un serveur, il
s’agira, par exemple, de s’assurer du bon fonctionnement d’une application particulière, ou
bien de vérifier si la charge du serveur est acceptable. Les hôtes et les contacts à alerter sont
indispensables dans la définition des services.
35
 États des services
Un service peut avoir plusieurs états :
•. OK : tout va bien pour l’élément surveillé
• WARNING : quelque chose commence à aller mal comme, par exemple, un disque qui est
presque rempli.
• CRITICAL : la situation est très grave et demande une intervention immédiate. C’est le cas,
par exemple, d’un disque plein.
• UNKNOWN : la commande de vérification n’a pas pu obtenir les informations souhaitées.
Par exemple, les arguments fournis à la commande ne sont pas bons.
 Définition d’un service
Tout comme les autres objets, les services possèdent des propriétés indispensables :
• service_description : nom du service ;
• host_name : nom de l’hôte sur lequel se trouve le point à surveiller ;
• check_command : commande de vérification pour obtenir l’information souhaitée ; on
peut lui fournir des arguments en les séparant par le caractère ! ;
• max_check_attempts : nombre de tentatives au bout desquelles la
situation est
considérée comme sûre ;
• check_interval : période entre deux tests en temps normal ;
• retry_interval : période entre deux tests lorsqu’il y a un souci ;
• check_period : période de temps durant laquelle le service est supervisé ;
• notification_interval : intervalle de temps entre deux notifications. Tout comme pour
les nœuds, si cette valeur est à zéro, une seule notification est envoyée ;
• notification_period : période de temps durant laquelle les notifications sont envoyées
;
• contacts : contacts à prévenir ;
• contact_groups : groupes de contacts à prévenir.
Une autre propriété est importante mais facultative :
• notification_options : ce sont les états qui, pour un service, doivent faire l’objet d’une
notification. Comme pour les hôtes, si ce paramètre n’est pas positionné, tous les états
sont pris en compte. Ces états sont :
– w : lorsqu’un service passe en état WARNING ;
– u : lorsqu’un service passe en état UNKNOWN ;
– c : lorsqu’un service passe en état CRITICAL ;
 Exemple de définition
Définissons un service Http vérifiant que le port 80 (HTTP) est bien ouvert sur le
serveur srv-web1. Le numéro de port est ici passé en argument numéro 1 à la commande
check_tcp définie précédemment. Si la commande avait eu besoin d’un second argument,
on l’aurait ajouté à la suite, en mettant un autre ! entre les arguments. Par exemple
check_tcp!80!5, 80 étant $ARG1$ dans la commande et 5, $ARG2$. Il est à noter que ceci
vaut pour tous les appels de check_command et donc pour les hôtes également.
36
Les paramètres contacts et contact_groups n’ont pas besoin d’être présents tous les
deux. Si un seul est positionné, la définition est valide. Cette vérification est faite toutes les 5
minutes. En cas de problème, un test supplémentaire est effectué (max_check_attempts = 3
= 2 + 1 test déjà effectué) au bout de 3 minutes. Si le problème est toujours présent, une
notification est envoyée aux admins-web. Au bout de 30 minutes, si le problème n’est
toujours pas résolu, une autre notification est envoyée et ainsi de suite.
 Définition d’un service
define service {
host_name srv-web1
service_description Http
check_command check_tcp!80
max_check_attempts 2
check_interval 5
retry_interval 3
check_period 24x7
notification_interval 30
notification_period 24x7
notification_options w,c,r
contact_groups admins-web
}
7.2.2.6 Contacts : qui et comment ?
Les contacts sont les personnes qui reçoivent les notifications d’alertes de Nagios. Les
hôtes et les services se voient accrocher des contacts. Nous avons vu qu’il ne faut prévenir
les utilisateurs que pour des incidents qui les concernent. Nagios doit savoir qui prévenir
lorsqu’un problème surgit.
Nous allons avoir un contact par utilisateur de Nagios. Les contacts doivent avoir des
périodes de notification. Certains souhaitent recevoir les alertes uniquement sur certaines
plages horaires. Ceci est tout particulièrement vrai lorsqu’on évoque les envois de SMS. Il est
inutile que ces messages partent en pleine journée. Certains autres ne veulent recevoir que
les alertes critiques et pas les simples avertissements. Tout ceci est possible avec Nagios.
 Définition d’un contact
Les objets contenant les contacts sont tout simplement contact. Ils sont définis dans le
fichier contacts.cfg et possèdent les propriétés suivantes :
• contact_name : c’est le nom du contact tel qu’il sera utilisé dans le reste de la
configuration.
• host_notifications_enabled : accepte ou non les notifications concernant les hôtes.
• service_notifications_enabled : accepte ou non les notifications concernant les services.
• host_notification_period : période de temps où les notifications d’erreurs sur les hôtes
sont acceptées.
37
• service_notification_period : période de temps où les notifications d’erreurs sur les
services sont acceptées.
• host_notification_options : états qui, sur les hôtes, doivent faire l’objet d’une notification.
Les valeurs possibles sont les mêmes que pour le paramètre notification_options des hôtes.
Ces états sont :
– d : lorsqu’un hôte passe en état DOWN ;
– u : lorsqu’un hôte passe en état UNREACHABLE ;
– r : lorsqu’un hôte revient en état UP ;
– n : est utilisé si un contact ne veut recevoir aucune notification.
• service_notification_options : états qui, sur les services, doivent faire l’objet d’une
notification. Les valeurs possibles sont les mêmes que pour le paramètre
notification_options des services. Ces états sont :
– w : lorsqu’un service passe en état WARNING ;
– u : lorsqu’un service passe en état UNKNOWN ;
– c : lorsqu’un service passe en état CRITICAL ;
• host_notification_commands : commande de notification qui est utilisée pour avertir d’un
évènement sur un hôte.
• service_notification_commands : commande de notification qui est utilisée pour avertir
d’un évènement sur un service.
Les états des éléments seront étudiés un peu plus loin dans ce chapitre.
Un autre paramètre important, quoique facultatif, est :
 pager : numéro de téléphone du contact
• email : l’adresse e-mail du contact.
 Exemple de définition de contact
Voici une définition de contact. Il se nomme ABBE SERGE. Il souhaite être averti tout le
temps et ce, par e-mail.
define contact {
contact_name abserge
alias ABBE SERGE
host_notifications_enabled 1
service_notifications_enabled 1
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-by-email, notify-by-sms
host_notification_commands host-notify-by-email
email [email protected]
}
38
7.2.2.7 Groupes de contacts
Il est rare qu’un administrateur soit seul à recevoir une alerte. On peut créer un
groupe de contacts dans lequel sont placés plusieurs contacts devant recevoir les mêmes
alertes. Il est possible de définir ce groupe à notifier. L’information sera alors redirigée
automatiquement vers les membres du groupe. La définition est très simple. L’objet associé
est contactgroup et se trouve dans le fichier contacts.cfg aux côtés des contacts. Il ne
possède que quatre propriétés :
• contactgroup_name : nom du groupe tel qu’il sera utilisé dans le reste de la configuration ;
• alias : nom d’affichage pour ce groupe ;
• members : liste des contacts du groupe, séparés par des virgules ;
• contactgroup_members : liste des groupes de contacts faisant parti du groupe. Voici un
exemple de définition d’un groupe de contacts regroupant les administrateurs abserge et
abyves et incluant également les membres du groupe admins-linux.
 Définition d’un groupe de contacts
define contactgroup{
contactgroup_name admins-web
alias Administrateurs web
members abserge,abyves
contactgroup_members admins-linux
}
7.2.2.8 Les templates
Les templates sont des modèles utilisés pour simplifier la configuration. En effet,
lorsque les paramètres à entrer pour les hôtes sont les mêmes à quelques détails près
(adresse IP, nom, alias), on utilise un template qui comprend tous les paramètres qui se
ressemblent. Dans la définition d’un hôte on ne mentionnera que ses paramètres personnels
(adresse IP, nom, alias).
Ceci est valable pour les services comme nous le montre l’exemple suivant :
39
# Generic service definition template
define service {
name
register
0
active_checks_enabled
passive_checks_enabled
parallelize_check
1
obsess_over_service
check_freshness
notifications_enabled
event_handler_enabled
flap_detection_enabled
process_perf_data
retain_status_information
retain_nonstatus_information
check_period
max_check_attempts
normal_check_interval
retry_check_interval
contact_groups
notification_interval
notification_period
notification_options
}
define service {
host_name
use
service_description
check_command
}
define service {
host_name
use
service_description
check_command
}
generic-service
1
1
1
0
1
1
1
1
1
1
24x7
3
3
1
labo-admins
240
24x7
c,r
mailhost
generic-service
SMTP
check_smtp
ns
generic-service
DNS
check_dns
define service {
hostgroup_name
web-internet
use
generic-service
service_description
HTTP
check_command
check_http
}
Ici nous avons créé le template generic-service. La définition des services de Mail, DNS et
Web utilise ce template.
40
PARTIE C : MISE EN ŒUVRE
Dans cette partie nous procédons à l’implémentation de la solution et
nous terminons par sa prise en main.
41
Chapitre 8 : Implémentation de la solution
8.1 Conception de l’architecture de supervision
8.1.1 Le mode de déploiement
Nous allons mettre en œuvre un déploiement centralisé, c’est-à-dire un serveur
central Nagios qui supervise les autres équipements. Vu que le nombre d’équipements à
surveiller est très petit (40) la mise en œuvre d’une architecture distribuée n’est pas
nécessaire ou serait considéré comme de la su qualité.
8.1.2 Regroupement par type
Nous allons regrouper les différents éléments à superviser et les administrateurs
dans des groupes afin de faciliter la configuration. Les groupes constitués sont :
-
Pour les systèmes
 Le groupe wingroup pour les serveurs windows
 Le groupe lingroup pour les serveurs Linux
Oragroup pour les serveurs hébergeant des services oracle
Postgroup pour les serveurs hébergeant les services PostgreSQL
MySQLgroup pour les services hébergeant les services MySQL
Smbgroup pour les serveurs samba
Postfixgroup pour les serveurs postfix
Imapgroup pour les serveurs imap
Webgroup pour les serveurs web
Ldapgroup pour les serveurs d’authentification
DBgroup pour les administrateurs de base de données
Sysgroup pour les administrateurs systèmes
Hostsgroup pour tous les hôtes
8.2 Installation
FAN est un CD au format iso basé sur la distribution CentOS 5.4. La source se
récupère sur le site du projet à l’adresse:
http://lkco.gezen.fr/FAN/FAN-2.1.iso
Son installation est semblable à celle de toute distribution CentOS. La procédure
d’installation est ajoutée en annexe III. Rappelons que FAN est avec les outils suivants
préconfigurés :
Nagios : cœur de la supervision
Nagios plugins : plugins pour superviser différents équipements et
services
Centreon : interface web pour Nagios de configuration
42
NagVis : cartographie avancée
NDOUtils : stocke les données Nagios dans une base MySQL
NRPE : permet de superviser les serveurs Windows
8.3 Configuration
8.3.1 Première configuration
Afin de profiter de notre nouvelle plate-forme, il faut tout de même configurer un
minimum. Ce minimum est :
-
La configuration réseau (adresse IP, DNS)
L’environnement graphique
8.3.1.1 La configuration réseau
8.3.1.1.1 Configuration de l’interface réseau
Les commandes suivantes permettent de configurer l’interface réseau du serveur :
# system-config-network ou
# vi /etc/sysconfig/networking/devices/ifcfg-eth0
8.3.1.1.2 Configuration du DNS (Domain Name System)
Le Domain Name System (ou DNS, système de noms de domaine) est un service
permettant d'établir une correspondance entre une adresse IP et un nom de domaine et,
plus généralement, de trouver une information à partir d'un nom de domaine.
Sa configuration se fait dans le fichier /etc/resolv.conf comme suit :
# vi /etc/resolv.conf
nameserver monDNS
nameserver DNSpublic
search mondomaine
8.3.1.2 Configuration de l’interface graphique
L’installation se termine sans interface graphique. Pour mettre en place
l’environnement graphique nécessaire pour la configuration de Centreon nous devons entrer
de le shell cette commande :
# yum --exclude=nautilus-sendto groupinstall
Environment" "X Window System" (capture d’écran)
"GNOME
Desktop
43
Le système recherche les paquets sur internet et les installe les paquets. Et nous entrons ensuite la
commande pour afficher l’interface graphique:
# startx
Figure 8. Interface d’accueil de CentOS
Nous pouvons accéder à la page d’accueil du projet depuis un poste sur le réseau :
http://ip-serveur/ (Figure 9)
44
Figure 9. Page d’accueil de FAN
Cette page d’accueil regroupe les différents services proposés par FAN. Nous cliquons
sur Centreon pour accéder à l’interface de Centreon.
Figure 10. Interface d’accueil de Centreon
45
Les différentes interfaces de Centreon pour sa prise en main seront étudiées dans le
guide de procédures que nous avons rédigé à cet effet.
8.3.2 Configuration des groupes de contacts
Pour créer un groupe de contacts, il faut se rendre dans l’onglet Configuration →
Users → Contacts Groups → add. Il suffit ensuite de compléter la page, en spécifiant le nom
du groupe, son alias (« surnom ») et de sauvegarder. Ce qui a été fait pour les groupes
DBgroup et SYSgroup.
Figure 11. Création d’un groupe de contacts
Nous créons ensuite les contacts que nous intégrons dans les groupes de contacts
créés précédemment.
8.3.3 Configuration des contacts
Du fait des groupes de diffusion créés au niveau de la messagerie interne de
l’entreprise, pour les administrateurs systèmes et de base de données, deux contacts ont été
créés avec pour référence ces groupes de contacts. L’ajout d’un hôte se fait en allant dans :
Configuration → Users → Contacts/Users → add
Nous renseignons les champs suivants:
 Le nom
 L’alias
 L’adresse mail du contact
 Les groupes de contacts auxquels se rattache le contact
46
Figure 12. Ajout d’un contact
Ensuite nous ajoutons les paramètres concernant les hôtes:
 Les options de notifications (Down, Unreachable, …)
 Les moyens de notifications (email, sms …)
 Les périodes de notification des hôtes
Figure 13. Informations générales de notification des hôtes pour les contacts
Nous terminons par les paramètres concernant les notifications pour les services qui suivent
la même configuration que celles des hôtes.
8.3.4 Configuration des moyens de notification
8.3.4.1 Configuration des emails
La configuration des emails, comme moyen de notification des services et des hôtes
est déjà configuré dans Centreon. En allant dans
Configuration → Commands → Notifications
47
Figure 14. Moyens de Notifications préconfigurés
Nous voyons host-notify-by-email et notify-by-email qui gèrent respectivement la notification par
email des hôtes et des services. En cliquant sur notify-by-email dans le champ Command Line nous voyons la
commande d’envoi d’email :
Figure 15.Définition de la commande d’envoi d’email
Elle réalise l’envoi de l’e-mail en deux étapes. Tout d’abord, elle génère le texte du
message. Lors de l’appel à la commande pour l’envoi d’une notification, les macros sont
modifiées par les valeurs du contexte de l’erreur. Par exemple, dans le cas d’une erreur sur
le nœud srv-web1, la macro $HOSTNAME$ est modifiée en srv-web1.
Une fois ce texte généré, il est envoyé sur l’entrée standard de la commande
/bin/mail. Cette dernière sert tout simplement à envoyer un e-mail. Le paramètre -s sert à
paramétrer le titre, qui est également appelé avec des macros. Le dernier argument
correspond à l’adresse du destinataire du message. Un service d’envoi d’e-mail est
nécessaire sur le serveur de supervision. À ce propos, sur la distribution installée ici, c’est le
48
programme Sendmail qui est installé par défaut. Nous allons utiliser un programme plus
récent et de meilleure réputation : Postfix. Cette opération est fort simple :
#yum install postfix
#/etc/init.d/sendmail
stop
#chkconfig sendmail off
#chkconfig --add postfix
#/etc/init.d/postfix start
Nous configurons ensuite l’envoi par sms.
8.3.4.1 Configuration des sms
Le réseau GSM a un intérêt tout particulier : il est indépendant du réseau de
l’entreprise. Si le serveur de messagerie n’est tout simplement pas joignable, il y a peu de
chance que les administrateurs reçoivent leurs e-mails d’alerte. Dans ce cas, le SMS est l’un
des seuls moyens de les joindre.
Ces messages sont en règle générale très courts, 160 caractères. Pour les envoyer, un
modem GSM est nécessaire. Le plus simple appareil du genre est un simple téléphone
portable. Des boîtiers dédiés existent. Ils se connectent au serveur de supervision par port
série ou USB. Nous utilisons un simple téléphone portable (Nokia E63) branché par USB.
Le programme gnokii permet de contrôler ce « modem » et de demander un envoi de SMS.
Il s’installe simplement et se télécharge sur le site www.gnokii.org :
#yum install gnokii
Lorsqu’un téléphone est connecté, il est disponible à travers le fichier /dev/ttyACM0.
L’accès au fichier demande à l’utilisateur nagios d’être dans le groupe dialout. Le
programme gnokii est configuré dans le fichier /etc/gnokiirc.
port = /dev/ttyACM0
model = AT
connection = serial
Paramètres du fichier /etc/gnokiirc
Une simple commande permet de tester l’envoi d’un message vers un téléphone portable :
#echo 'Test avec Gnokii' | gnokii –-config /etc/gnokiirc –-sendsms
+22549564583
Test d’envoi d’un sms
49
Le numéro de téléphone doit être au format international, avec l’indicatif +225 pour la Côte
D’Ivoire. Dans Nagios, on définit les commandes d’envoi de SMS comme suit :
define command{
command_name notify-by-sms
command_line echo "$NOTIFICATIONTYPE$: $HOSTALIAS$ $SERVICEDESC$
is $SERVICESTATE$ - $OUTPUT$" | gnokii –config /etc/gnokiirc –sendsms
$CONTACTPAGER$
}
Commande d’envoi des sms pour les services
define command{
command_name host-notify-by-sms
command_line
echo
"$NOTIFICATIONTYPE$
:
$HOSTALIAS$
$HOSTSTATE$ $OUTPUT$" | gnokii –config /etc/gnokiirc –sendsms $CONTACTPAGER$
}
is
Commande d’envoi des sms pour les hôtes
Nous configurons ces commandes dans Centreon et nous sauvegardons.
Figure 16. Configuration de l’envoi par sms pour les services dans Centreon
8.3.5 Configuration des hôtes
Nous allons créer quarante hôtes. La procédure de création d’un hôte se fait comme
suit :
Configuration → Hosts → add
Nous précisons les paramètres essentiels pour configurer un hôte :
 Nom de l’hôte : C’est le nom qui va l’identifier pour Nagios et
Centreon
 Alias : Le « surnom » de l’hôte. On peut aussi mettre des informations
supplémentaires (localisation…)
50
 Adresse IP/DNS : l’adresse IP
 Surveillé depuis : Le collecteur qui va le superviser
 Modèle multiple de l’hôte : pour le template attaché pour cet hôte,
nous allons prendre « generic-host » par défaut. Generic-host utilise
le plugin check_host_alive (ping) pour vérifier la disponibilité de
l’hôte.
Figure 17. Informations générales dans l’ajout d’un hôte
8.3.6 Configuration des services
La configuration des services a été faite suivant les groupes d’hôtes définis dans le
2.4.1.2. La création d’un groupe d’hôtes se fait comme suit :
Configuration → Hosts → Hosts Group → add
Figure 18. Configuration d’un groupe d’hôtes
51
Nous renseignons le nom, l’alias du groupe, les hôtes faisant partie du groupe et nous
sauvegardons.
Nous devons ensuite spécifier pour chaque service à superviser, la commande
utilisée. Pour ajouter une commande nous devons aller dans :
Configuration → Commands → add
Figure 19. Ajout d’une commande
Les paramètres pour la définition d’une commande sont les suivantes :





Nom de la commande : c’est le nom qui va être utilisé, lors de la définition d’un
service.
Ligne de commande : c’est ici que l’on construit la commande qui va être lancée par
Nagios. Centreon propose des menus déroulants afin de faciliter cette construction.
Le premier menu donne accès aux macros utilisateurs (par défaut la macro
$USER1$10 contient le chemin des plugins).
Le deuxième menu permet de sélectionner le plugin qui doit être utilisé.
Le troisième menu permet de sélectionner les macros disponibles dans Nagios (ex
$HOSTADDRESS$).
Exemple d’arguments : Ces deux cases permettent de tester une commande et de définir les
valeurs par défaut lors de la définition d’un service.
Type de commande : On laisse la valeur par défaut « vérification ».
Modèle de graphique : On peut laisser ce champ vide ou utiliser un des modèles proposés.
10
$USER1$ correspond au répertoire /usr/lib/nagios/plugin
52
Une fois l’hôte et la commande renseignés, nous allons pouvoir définir un service
attaché au serveur supervisé. Pour ajouter ou modifier un service, il faut se rendre dans
l’onglet Configuration → Services. Sur la page s’affiche tous les services par hôte.
Pour ajouter un service, il suffit donc de sélectionner Services by Hosts Group → add
et de commencer la configuration. Comme pour les hôtes, il y a un grand nombre de
paramètres à définir. Il est donc aussi fortement conseillé d’utiliser les templates pour
faciliter la configuration du service. Par défaut nous utilisons le template generic-service.
Sur la page Configuration du service, nous allons renseigner les paramètres suivants :




Description : C’est le nom du service qui sera affiché dans la page de supervision
Modèle de service : Le template utilisé, par défaut nous prenons generic-service.
Commande de vérification : c’est ici que l’on précise la commande à utiliser.
Arguments : les arguments de la commande. Le format est !arg1 !arg2 !arg3 !….
Pour les options de notifications, si elles sont différentes de celle du template.
 Contacts liés : les contacts à notifier
 Groupe de contacts liés : les groupes de contacts à notifier
Sur la page Relations, nous allons faire le lien entre le service et le ou les hôtes.
Figure 20. Mise en relation des services et hôtes supervisés
53
Ceci est la configuration de base d’un service pour un groupe d’hôtes. Nous
présentons maintenant pour chaque service la commande utilisée pour sa supervision sur les
hôtes concernés.
Tableau 4. Paramètres de configuration des différents services
Nom du
service
Commande
Ligne de commande
Description de la commande
contacts
Nombre
d’hôte(s)
Ldap
Check_ldap
$USER1$/check_ldap H $HOSTADDRESS$ -b
$ARG1$
SYSgroup
1
DNS
Check_dns
$USER1$/check_dns -H
$ARG1$ -s
$HOSTADDRESS$
Elle prend comme argument
le serveur à interroger avec -H
et la requête à effectuer avec
-b
Elle prend en paramètre -H,
l’enregistrement à récupérer,
et -s, le serveur DNS
interrogé.
SYSgroup
4
DHCP
Check_dhcp
$USER1$/check_dhcp -s
$HOSTADDRESS$ -i
$ARG1$
Le paramètre -s permet de
spécifier à la commande
l’adresse du serveur dont
on veut une réponse. Enfin,
le paramètre -i permet de
choisir l’interface réseau
SYSgroup
Suite du tableau 4.
Nom du
service
HTTP
Commande
Ligne de commande
contacts
Check_http
$USER1$/check_http -H
$HOSTADDRESS$
SYSgroup
HTTPS
Check_https
$USER1$/check_http -H
$HOSTADDRESS$ -S
SYSgroup
5
FTP
Check_ftp
$USER1$/check_ftp -H
$HOSTADDRESS$
SYSgroup
5
SMTP
Check_smtp
$USER1$/check_smtp -H
$HOSTADDRESS$
SYSgroup
1
POP
Check_pop
$USER1$/check_pop -H
$HOSTADDRESS$
SYSgroup
1
IMAP
Check_imap
$USER1$/check_pop -H
$HOSTADDRESS$
SYSgroup
1
SAMBA
Check_smb
$USER1$/check_tcp -H
$HOSTADDRESS$ -p
445
l’adresse du service à tester
par le paramètre -H.
par le paramètre –H, -S est
utilisé pour renvoyer les
requêtes vers le canal SSL.
l’adresse du service à
superviser et le port
Nombre
d’hôte(s)
12
SYSgroup
11
54
Tableau 5. Supervision des ressources physiques locales sur le serveur local
Alias du
service
Charge
moyenne
Commande
Ligne de commande
contacts
load
check_load -w 1,1,1 -c 2,2,2
SYSgroup
RAM
mem
check_mem.pl -w 90 -c
95
Permet de vérifier « charge
moyenne » sur les unix. Un
warning est levé pour une
valeur de 1 et un critical pour
une valeur de 2
Lève un warning dès que la
mémoire est utilisée à 90% et
un critical à 95%
Nombre
d’hôte(s)
40
SYSgroup
40
SWAP
swap
check_swap -w 80% -c
50%
si le swap est utilisé à plus de
20%, un WARNING est levé.
S’il est supérieur à 50%, c’est
un CRITICAL, car les seuils de
check_swap sont exprimés en
pourcentage d’espace libre.
SYSgroup
40
Suite du Tableau 5
Alias du
service
DISQUE
Commande
Ligne de commande
Description de la
commande
Lève un warning dès que
la mémoire est utilisée à
80% et un critical à 90%
contacts
SYSgroup
Nombre
d’hôte(s)
40
disk
check_disk -w 80 -c 90
PROCESSEUR
cpu
check_cpu -w 90 -c 95
Lève un warning dès que
la mémoire est utilisée à
90% et un critical à 95%
SYSgroup
40
PROCESSUS
procs
$USER1$/check_procs
-C $ARG1$ -w $ARG2$
-c $ARG3$
Le paramètre –C indique
le nom du service, et les
paramètres –w et –c
indiquent le nombre de
processus requis pour
déclencher une alerte
warning et critical
SYSgroup
40
 Pour les serveurs distants, nous utilisons le plugin check_nrpe. Sa configuration
nécessite l’installation du serveur nrpe sur les serveurs distants, elle est présentée
dans le guide de procédure. Le téléchargement du plugin se fait sur le site suivant :
http://downloads.sourceforge.net/project/nagios/nrpe-2.x/nrpe-2.12/nrpe-2.12.tar.gz.
Ensuite nous devons modifier les options du fichier de configuration de nrpe (nrpe.cfg). Ces
options à modifier sont :
 dont_blame_nrpe : autorise ou non l’utilisation d’arguments envoyés par
le client au serveur NRPE. Il doit être à 1

allowed_hosts : nous renseignons l’adresse du serveur Nagios
Puis nous configurons dans Centreon suivant le Tableau 6 :
55
Tableau 6. Supervision des ressources physiques sur les machines Linux distantes
Nom du
service
Load_remote
Alias
Ligne de commande
Etat de la Charge
moyenne sur une
machine distante
check_nrpe -H
$HOSTADDRESS$ -c
load
RAM_remote
Etat de la RAM sur
une machine
distante
SWAP_remote
Etat du SWAP sur
une machine
distante
Etat du taux de
remplissage du
disque sur une
machine distante
Etat de la charge
du processeur sur
une machine
distante
Etat des processus
sur une machine
distante
Disk_remote
Cpu_remote
Procs_remote
contacts
check_nrpe -H
$HOSTADDRESS$ -c
mem
Description de la
commande
On donne en paramètre
l’adresse du serveur
distant et le nom de la
commande à lancer sur
l’hôte distant
Vérifie l’état de la
mémoire sur le serveur
distant
SYSgroup
Nombre
d’hôte(s)
40
SYSgroup
40
check_nrpe -H
$HOSTADDRESS$ -c
swap
check_nrpe -H
$HOSTADDRESS$ -c
disk
Vérifie l’état du swap la
mémoire sur le serveur
distant
Vérifie le taux de
remplissage du disque
sur le serveur distant
SYSgroup
40
SYSgroup
40
check_nrpe -H
$HOSTADDRESS$ -c
cpu
Vérifie la charge du
processeur sur une
machine distante
SYSgroup
40
check_nrpe -H
$HOSTADDRESS$ -c
procs
Vérifie le nombre de
processus utilisé par un
service sur une machine
distante
SYSgroup
40
 Superviser des attributs sur une machine Windows requiert l'installation d'un agent
sur celle-ci. Cet agent agit comme un proxy entre les plugins Nagios qui font la
supervision et l'attribut sur la machine Windows. Nous allons installer l'addon
NSClient++ (étudié dans l’annexe V) sur les machines Windows et utiliser le plugin
check_nt pour communiquer avec NSCLient++. La configuration se fait par la suite de
manière classique dans Centreon suivant le tableau suivant :
Tableau 7. Supervision des machines windows
Nom du
service
Win_cpu
Alias
Ligne de commande
Etat de la charge
du processeur sur
une machine
windows
check_nt -H serveur -v
CPULOAD –l 15, 90,
95
Win_mem
Etat de la mémoire
sur une machine
windows
check_nt -H serveur -v
MEMUSE -w 90 -c 95
Win_disk
Etat du taux
d’occupation des
disqes sur une
machine windows
check_nt -H
$HOSTADDRESS$ -v
USEDDISKSPACE -l C -w
90% -c 95%
Description de la
commande
Lève un warning si la
charge des 15
dernières minutes est
à 90% et un critical à
95%
Lève un warning dès
que la mémoire est
utilisée à 90% et un
critical à 95%
contacts
Lève un warning dès
que la mémoire est
utilisée à 90% et un
critical à 95%
SYSgroup
Nombre
d’hôte(s)
40
SYSgroup
40
SYSgroup
40
56
 Configuration des bases de données PostgreSQL et MySQL
MySQL et PostgreSQL sont des systèmes de gestion de base de données open-source très
répandus. Il existe donc deux plugins spécifiques check_mysql et check_pgsql disponible en standard
avec Nagios. Ces plugins présentent une faille dans le réseau. En effet, ils utilisent une
requête SQL nécessitant un login/password, or ce couple apparaîtra dans la liste des
processus lors de l'exécution du plugin par Nagios. Nous allons utiliser un plugin basé sur
Check_tcp, comme le montre le tableau suivant :
Tableau 8. Supervision de MySQL et PostgreSQL
Nom du
service
Mysql
Alias
Ligne de commande
Service MySQL
$HOSTADDRESS$ -p
3306
PgSQL
Service PostgreSQL
$HOSTADDRESS$ -p
5432
Description de la
commande
On donne en
paramètre l’adresse du
serveur distant et le
port du service MySQL
On donne en
paramètre l’adresse du
serveur distant et le
port du service
PostgreSQL
contacts
DBgroup
Nombre
d’hôte(s)
2
DBgroup
2
 Supervision des bases de données oracle
La supervision d’oracle se fait à l’aide plugin check_oracle_health. Ce plugin permet
de superviser de nombreuses métriques sur une base de données oracle comme :








La connexion au listner
La durée de connexion
Le nombre de processus maximum possible
Le nombre maximal de connexion possible
Les données SGA (hit ratio tampon, bibliothèque ratio de cache, dictionnaire
ratio de cache …)
Les tablespace
La PGA (Program Global Area)
Les redo log buffer
Le plugin nécessite la librairie perl DBD::oracle, les drivers oracle oracleinstantclient-basic, oracle-instantclient-sdk à obtenir sur le site d’oracle : www.oracle.com.
La configuration de check_oracle_health va utiliser l’agent nrpe. La configuration des
différentes métriques s’est faite comme suit :
57
Tableau 9. Supervision des bases de données oracle
Nom
de
métrique
tnsping
Ligne de commande
Commande dans nrpe
$USER1$/check_oracle_health
–mode tnsping
–mode connection-time
–mode connected-users
Check_nrpe!tnsping
sga-data-bufferhit-ratio
–mode sga-data-buffer-hitratio
Check_nrpe! sga-data-buffer-hitratio
Description
de
la
commande
Vérifie la connexion au
listener
Le temps de se
connecter au serveur
Nombre d’utilisateurs
actuellement
connectés
Taux d'accès au Buffer
de données
sga-library-cachehit-ratio
–mode sga-library-cache-hitratio
–mode sga-dictionnary-cachehit-ratio
–mode sga-shared-pool-free
–mode pga-in-memory-sortratio
Check_nrpe! sga-library-cachehit-ratio
Taux d'accès au library
cache
Check_nrpe! sga-dictionnarycache-hit-ratio
Taux d'accès au
dictionnary cache
Check_nrpe! sga-shared-poolfree
Check_nrpe!pga-in-memory-sortratio
–mode tablespace-usage –
tablespace
–mode tablespace-usage –
tablespace
–mode tablespace-io-balance
Check_nrpe! tablespace-usage
Mémoire partagée des
requêtes
Mémoire non partagée
utilisée par les
processus serveur ou
d’arrière-plan
Espace Utilisé des
tablespace
–mode redo-io-traffic
–mode roll-avgactivesize
Check_nrpe! redo-io-traffic
Connection-time
Connected-users
sga-dictionnary cache-hit-ratio
sga-shared-poolfree
pga-in-memorysort-ratio
tablespace-usage
tablespaceremaining-time
tablespace-iobalance
redo-io-traffic
roll-avgactivesize
la
Check_nrpe!connection-time
Check_nrpe!connected-users
Check_nrpe! tablespaceremaining-time
Check_nrpe! tablespace- iobalance
Check_nrpe! roll-avgactivesize
Temps restant
jusqu’au remplissage
d’un tablespace
Equilibre des fichiers
de données InputOutput
Redo log en octet par
seconde
Taille moyenne du
segment rollback
Cette configuration a été faite pour 10 serveurs Oracle et les alertes concernent les
administrateurs de base de données.
Une fois tous les éléments configurés, Centreon génère la configuration finale dans Nagios.
Ceci se passe dans la page
Configuration->Nagios. L’option Generate Configuration Files
demande à Centreon de créer les fichiers de Nagios à partir des informations contenues
dans sa base de données. Cette génération se fait dans le répertoire
/usr/local/centreon/filesGeneration/nagiosCFG. L’option Run Nagios Debug (-v) permet de
lancer Nagios en mode vérification de configuration, avec l’option –v. Si cette étape de
vérification s’est bien déroulée, l’administrateur peut demander, avec l’option Move Export
Files, de déplacer ces fichiers de configuration temporaires vers leur destination réelle
/usr/local/nagios/etc. nous redémarrons le service en choisissant cette option dans la partie
Method restart et nous cliquons sur Export.
58
Cette phase terminée nous allons configurer Nagvis pour la cartographie du réseau.
La prise en main de Nagvis sera étudiée dans le guide de procédures.
8.4 Test
Une fois ces configurations réalisées sur le serveur de supervision central, nous avons
effectué la surveillance de 2 serveurs de tests, l’un ayant les services PING, SSH et SAMBA
puis l’autre ayant les services PING, DNS et DHCP. Aussi avons-nous configuré un serveur
imaginaire pour si notre solution est capable détecter un hôte injoignable.
Le serveur FAN supervise bien les deux machines hôtes y compris les différents
services. Mais les notifications par e-mail et par sms sont en cours de configuration.
Pour les notifications par e-mail, le serveur Postfix configuré sur le serveur FAN doit
utiliser le serveur de messagerie interne de la SNDI comme relai pour transmettre les
messages aux administrateurs. Vu le nombre important de messages reçus par ce serveurs, il
a été demandé d’arrêter le service d’envoi d’e-mail pour une période déterminée.
Pour les notifications par sms, les tests en lignes de commandes marchent, mais le
serveur ne prend pas le contrôle de l’envoi des sms. A ce niveau, nous poursuivons les
configurations au niveau de l’utilisateur propriétaires des commandes d’envoi de SMS. Il faut
noter que ces configurations ont été arrêtées pour la même raison que celle de l’envoi
d’email.
Nous avons exprimé le désir de poursuivre les configurations à la direction en vue
d’un serveur de supervision complètement fonctionnelle, cette proposition est en cours
d’analyse par notre direction.
59
CONCLUSION
Le projet pour lequel nous avons été sollicités a porté sur l’étude et la mise en œuvre
d’un outil de supervision des serveurs. Il a consisté en une étude approfondie des différentes
solutions de supervision open source, d’en choisir la solution la mieux adaptée pour la SNDI.
Ensuite nous avons mis en œuvre cette solution en tenant comptes des spécifications du
cahier des charges. Enfin nous avons rédigé un guide de procédure pour faciliter son
administration.
Après réflexion, nous avons opté pour l'installation de FAN. C'est un logiciel qui
intègre à Nagios de nouveaux outils comme Centreon et Nagvis qui permettent, grâce à
l’interface graphique de Centreon, à la fois de visualiser l'état du réseau, mais également de
tout configurer en mode graphique. Centreon agit comme un intermédiaire entre
l'administrateur et les fichiers de configuration de Nagios. Il enregistre dans une base de
données les configurations effectuées par l'administrateur, puis il modifie les fichiers de
configuration de Nagios en fonction du contenu de la base de données. Cela permet de
simplifier grandement le travail de l'administrateur, contrairement à l'utilisation de Nagios
seul.
La solution mise en œuvre supervise bien les serveurs, en montrant les services
défaillants sur chaque serveur et les paramètres systèmes critiques sur les serveurs comme
le taux d’occupation de la mémoire ram, des processeurs et des disques. Cependant les
notifications par e-mail et par SMS ont été configurées, mais ont été arrêtées du fait du
nombre important de messages envoyés sur le serveur de messagerie de l’entreprise.
Vu le caractère important des notifications, nous suggérons de poursuivre la
configuration en rendant les alertes précises et concises. Ceci est possible par une bonne
définition du niveau de criticité des alertes, la diminution du nombre d’alertes par erreur et
en tirant avantages des périodes de supervision et de notification.
FAN est à un carrefour de son évolution. Les environnements informatiques
grandissent constamment, et les systèmes distribués vont prendre de plus en plus
d’importance. Référence dans le monde de la supervision open source, FAN gardera sa place
tant qu’il conservera les principes qui font sa force : sa simplicité et sa modularité. Gageons
que l’auteur et la communauté sauront continuer à suivre cette voie pour le plus grand
bonheur des administrateurs.
60
BIBLIOGRAPHIE
[1] Thierry Briche, Matthieu Voland, Les outils d’administration et de supervision du réseau :
L’exemple de Nagios. (Pages consultées le 7 Juillet 2011 à 9h33),
<http : // web.univ-pau.fr/~cpham/M2SIR/BIBLIO/DOC04-05/Nagios.pdf>
[2] Sabir Abidi, Centralisation SYSLOG Etude Cacti. (Pages consultées le 7 Juillet 2011 à 9h33), <
sabirino.free.fr/wp-content/uploads/2009/09/PFE_Supervision.pdf>
[3] Jean Gabès, Nagios 3 pour la supervision et la métrologie, EYROLLES, 2009, page 30, 482
pages.
[4] Présentation de Zabbix, (Page consultée le 10 Juillet 2011 à 14h 22),
<http://www.zabbix.com/documentation/fr/1.8/manual/about/overview_of_zabbix>
[5] Zabbix : Interview d’Alexei Vladishev, (Page consultée 10 Juillet 2011 à 15h 12),
<http://www.monitoring-fr.org/2011/06/zabbix-interview-dalexei-vladishev/>
[6] Zenoss Installation, (Page consultée 13 Juillet 2011 à 8h20),
<http://community.zenoss.org/thread/14051>
[7] About openNMS, (Page consultée 9 Juillet 2011 à 22h),
<http://www.opennms.org/about/>
[8] FAN Documentation, (Page consultée le 20 juillet 2011 à 4h),
<http://fannagioscd.sourceforge.net/wordpress/documentation/>
[9] Nagios Documentation, (Page consultée le 20 juillet 2011 à 7h),
<www.nagios.org/documentation>
[10] Centreon Overview, (Page consultée le 16 Juillet à 9h),
<http://www.centreon.com/>
[11]Nagvis Documentation, (Page consultée le 16 Juillet à 10h),
<http://docs.nagvis.org/1.5/en_US/index.html/>
[12] Jean Gabès, Nagios 3 pour la supervision et la métrologie, EYROLLES, 2009, page 63, 482
pages.
[13] Nagios, (Page consultée le 22 juillet à 7h),
<http://articles.mongueurs.net/magazines/linuxmag65-bis.html>
[14] NRPE Documentation, (Page consultée le 27 juillet à 7h),
< http://securinets.com/sites/default/files/tuto_pdf/nagios.pdf>
IX
[15] Nagios, (Page consultée le 22 juillet à 7h),
< http:// igm.univ-mlv.fr/.../Imanache-Joubert-Mayaud-SNMP-Nagios.pdf>
[16] ] Jean Gabès, Nagios 3 pour la supervision et la métrologie, EYROLLES, 2009, page 69, 482
pages.
X
GLOSSAIRE
A:
ASN.1 (Abstract Syntax Notation number One)
Notation formelle qui permet de spécifier très facilement et sans sacrifier à la généralité
les informations manipulées par les protocoles de télécommunications, indépendamment des
systèmes informatiques, des logiciels et des modes de transfert des données. Voir 3.2.6
ATM :
Asynchronous Transfer Mode est un protocole réseau de niveau 2 à commutation de cellules,
qui a pour objectif de multiplexer différents flots de données sur un même lien utilisant une
technique de type TDM ou MRT (multiplexage à répartition dans le temps). Voir 3.3
C:
CGI :
Common Gateway Interface (littéralement « Interface de passerelle commune »). Au lieu
d'envoyer le contenu d'un fichier (page HTML, image...), un serveur HTTP utilisant une interface
CGI exécute un programme puis retourne le contenu généré, comme s'il s'agissait d'un contenu
de fichier. CGI est le standard industriel qui indique comment transmettre la requête du
serveur HTTP au programme et comment récupérer la réponse générée. Voir 7.1
CMIP:
Common Management Information Protocol est norme de supervision de réseaux définie par
l’ISO qui permet de fournir les services liés au standard CMIS. Voir 3.2.6
CHARGE SERVEUR : load average représente le nombre moyen de processus dans la file
d'attente des processus ready for running pour, respectivement, la dernière minute, les 5
dernières minutes et les 15 dernières minutes. Voir 5.4.2.2
E:
ETHERNET : Ethernet est un protocole de réseau local à commutation de paquets. Voir 3.3
XI
F:
FDDI : Fiber Distributed Data Interface (FDDI) est un type de réseau informatique LAN
ou MAN permettant d'interconnecter plusieurs LAN à une vitesse de 100 Mbit/s sur de la fibre
optique (ce qui lui permet d'atteindre une distance maximale de 200 km). Voir 3.3
G:
GOOGLE TRENDS :
Google Trends est un outil issu de Google Labs permettant de connaître la fréquence à
laquelle un terme a été tapé dans le moteur de recherche Google, avec la possibilité de
visualiser ces données par région et par langue. Présenté sous forme d'un graphique, l'abscisse
indique l'échelle de temps année par année, démarrant en 2004, et l'ordonnée indique la
valeur de la fréquence de recherche du terme. Voir 6.1.4
I:
IETF:
Internet
Engineering
Task
Groupe de travail qui développe les nouveaux standards pour l’Internet. Voir 3.3
Force
ISO: International Organization for Standardization. Voir 3.2
L:
LICENCE : Une licence de logiciel est un contrat par lequel le titulaire des droits d'auteur
sur un programme informatique définit avec son cocontractant (exploitant ou utilisateur) les
conditions dans lesquelles ce programme peut être utilisé, diffusé ou modifié. Voir 4.3
M:
MIB:
Un MIB (Management Information Base, base d'information pour la gestion du réseau)
est un ensemble d'informations structuré sur une entité réseau, par exemple un routeur, un
commutateur ou un serveur. Ces informations peuvent être récupérées, ou parfois modifiées,
par un protocole comme SNMP. Voir 3.2.6
XII
O:
OSI:
Le modèle OSI (de l'anglais Open Systems Interconnection, « Interconnexion de
systèmes ouverts ») d'interconnexion en réseau des systèmes ouverts est un modèle de
communications entre ordinateurs proposé par l'ISO (Organisation internationale de
normalisation). Il décrit les fonctionnalités nécessaires à la communication et l'organisation de
ces fonctions. Voir 3.2.6
P:
PDU :
Protocol
Data
Unit
Le Protocol Data Unit ou Unité de données de protocole (PDU) est l'ensemble des informations
échangées entre niveaux dans le système de couches Modèle OSI. Voir 3.3
POLLING : un client obtient des informations en lançant une requête au serveur. Voir
5.1.1
R:
RFC : Les Requests For Comments, littéralement « demande de commentaires », sont
une série numérotée de documents officiels décrivant les aspects techniques d'Internet, ou de
différent matériel informatique (routeurs, serveur DHCP). Peu de RFC sont des standards, mais
tous les standards d'Internet publiés par l'IETF sont des RFC. Voir 3.3
RMON : (Remote Monitoring)
Le standard est basé sur l’utilisation du protocole de management SNMP et requiert
deux composants, un manager snmp et des agents snmp supportant RMON. L’association des
deux composants est équivalente à un système d’analyseurs réseaux distribués. Voir 3.3
REPORTING :
Il consiste à établir un rapport complet sur les différents éléments supervisés du réseau.
Voir 5.1.1
XIII
S:
SGMP: Simple Gateway Monitoring Protocol
Elle permet aux commandes devant être émises à des entités de protocole d'application
pour une utilisation dans le suivi des passerelles sur lesquels les entités de protocole
d'application résident. Voir 3.3
T:
TCP/IP: Transmission Control Protocol / Internet Protocol. Voir 3.2.2
Transmission Control Protocol (littéralement, « protocole de contrôle de transmissions »)
abrégé TCP, est un protocole de transport fiable, en mode connecté, documenté dans la RFC
793 de l' IETF. Voir 3.2.2
TRAPPING :
L’élément réseau envoie une information sous la forme d’une alerte à un démon
distant. Voir 5.1.1
U:
UDP: User Datagram Protocol
C’est un des principaux protocoles de télécommunication utilisés par Internet. Il fait
partie de la couche transport de la pile de protocole TCP/IP : dans l'adaptation approximative
de cette dernière au modèle OSI, il appartiendrait à la couche 4, comme TCP. Il est détaillé dans
la RFC 768.Le rôle de ce protocole est de permettre la transmission de données de manière très
simple entre deux entités, chacune étant définie par une adresse IP et un numéro de port.
Contrairement au protocole TCP, il fonctionne en mode non-connecté : il n'existe pas de
procédure de connexion préalable à l'envoi des données, et il n'y a pas de garantie de bonne
livraison d'un datagramme à sa destination, l'ordre d'arrivée des datagrammes peut différer de
l'ordre d'envoi. Voir 3.3
XIV
ANNEXES
XV
ANNEXE I : Les requêtes SNMP
Les requêtes SNMP sont les suivantes :
– GetRequest : recherche d’une variable sur un agent.
– GetNextRequest : recherche la variable suivante.
– GetBulk : recherche un ensemble de variables regroupées.
– SetRequest : change la valeur d’une variable sur un agent.
L’agent répond aux requêtes par un message GetResponse. En cas d’erreur, le message
sera accompagné d’un des codes d’erreurs suivants :
– NoAccess : accès non autorisé.
– WrongLength : erreur de longueur.
– WrongValue : erreur de valeur.
– WrongType : erreur de type.
– WrongEncoding : erreur d’encodage.
– NoCreation : objet inexistant.
– ReadOnly : seule la lecture est autorisée.
– NoWritable : interdiction d’écrire.
– AuthorisationError : erreur d’autorisation.
Les alarmes sont envoyées par l’agent lorsqu’un évènement survient sur la ressource
supervisée. Elles peuvent prendre les formes suivantes :
– ColdStart (0): redémarrage du système à froid.
– WarmStart (1): redémarrage du système à chaud.
– LinkDown (2) : le lien n’est plus opérationnel.
– LinkUp (3) : le lien est à nouveau opérationnel.
– AuthentificationFailure (4) : Tentative d’accès à l’agent avec un mauvais nom de
communauté.
– EgpNeighborLoss (5) : la passerelle adjacente ne répond plus.
– EntrepriseSpecific (6) : alarme spécifique aux entreprises.
XVI
ANNEXE II : Détails du Packet Data
Unit (PDU)
Il existe deux structures de PDU dans SNMP. La première est commune aux requêtes et
aux réponses. Elle est constituée des champs suivants :
Figure 1 – PDU SNMP (requêtes et réponses)
L’autre PDU est propre aux alarmes (trap). Il est construit de la manière suivante:
Figure 2 – PDU SNMP (alarmes)
II.1 PDU Type
Il identifie le message transporte par le PDU. Ses valeurs possibles sont les suivantes :
– 0 : GetRequest
– 1: GetNextRequest
– 2: SetRequest
– 3: GetResponse
– 4: Trap
II.2 Request ID
Il permet de faire correspondre une requête avec une réponse.
II.3 Error Status
Il est utilisé par les réponses et les requêtes pour indiquer une erreur du type suivant :
– 0: NoError
– 1: tooBig
– 2: noSuchName
– 3: badValue
– 4: readOnly
– 5: genError
II.4 Error Index
Il indique, dans le cas d’une erreur, quelle variable a causé l’erreur.
II.5 Variable Binding List
XVII
Ce champ liste les variables. Pour chaque variable, il est constitué de l’identificateur
unique de la variable dans la base MIB (ObjectName), associé à la valeur de la variable (Value).
II.6 Entreprise
Il est l’identifiant de l’agent ayant généré l’alarme.
II.7 Agent-addr
C’est l’adresse IP de l’agent ayant généré l’alarme.
II.8 Generic-Trap
Ce champ prend une des sept valeurs possibles de l’alarme :
– 0: ColdStart : redémarrage du système à froid.
– 1: WarmStart : redémarrage du système à chaud.
– 2 : LinkDown : le lien n’est plus opérationnel.
– 3 : LinkUp : le lien est à nouveau opérationnel.
– 4 : AuthentificationFailure : Tentative d’accès à l’agent avec un mauvais nom de
communauté.
– 5 : EgpNeighborLoss : la passerelle adjacente ne répond plus.
– 6 : EntrepriseSpecific : alarme spécifique aux entreprises.
II.9 Specific-Trap
Ce champ est un code déterminant la nature de l’alarme. Il est spécifique à chaque
agent propriétaire.
II.10 Time-Stamp
Ce champ donne le temps écoulé, en millisecondes, entre l’envoi de l’alarme et
l’initialisation de l’agent.
XVIII
ANNEXE III : CONFIGURATION DES
AGENTS
I.
Surveiller vos serveurs linux avec nagios et nrpe
Suite à l'introduction sur les plugins Nagios, voici une simple procédure pour
mettre en place le monitoring de serveurs sous Linux à partir de Nagios en utilisant
le plugin NRPE.
Figure 1. Fonctionnement de nrpe
I.1
Sur votre serveur Nagios
Il faut installer le plugin NRPE. Pour cela, le plus simple est de faire confiance à
votre gestionnaire de paquets. Sous CentOS, la commande suivante devrait suffire:
# sudo yum install nagios-plugins-nrpe
XIX
Il faut également vérifier que la définition du plugin est bien présente dans le fichier de
configuration des commandes (commands.cfg):
...
######
#NRPE
#######
#'check_nrpe' command definition
define command {
command_name check_nrpe
command_line $USER1$/check_nrpe -H
$HOSTADDRESS$ -c $ARG1$
}
...
I.2
Sur votre serveur Linux
La procédure est un peu plus longue. Il faut d'abord installer le daemon NRPE et
les plugins Nagios (qui vont être lancés localement par le daemon NRPE):
# sudo yum install nrpe
# sudo yum install nagios-plugins-all
Puis éditer le fichier /etc/nagios/nrpe.cfg pour modifier la ligne suivante:
...
allowed_hosts = Mettre ici l'adresse IP de votre serveur Nagios
...
On automatise le lancement du daemon au démarrage du serveur avec la commande:
# chkconfig --add nrpe
On ajoute une règle pour autoriser le Firewall IPtable à laisser passer les requêtes NRPE (à
adapter selon vos règles):
# Iptables -I RH-Firewall-1-INPUT 10 -p tcp --dport 5666 -j ACCEPT
Attention il faut mettre deux - (- -) avant l'option dport
XX
Il ne reste plus qu'à lancer le daemon:
# service nrpe start
Pour tester que la communication entre le serveur Nagios et le serveur à surveiller se
passe bien, il suffit de se rendre dans le répertoire des plugins (/usr/lib/nagios/plugins) de
Nagios et de tester le plugin NRPE:
#. /check_nrpe -H Adresse_IP_du_serveur_Linux
NRPE v2.7
Si tout est OK, cette commande devrait renvoyer la version du daemon NRPE. Vous
pouvez tester directement les plugins avec la commande suivante (exemple donnée pour un
check de la charge):
#. /check_nrpe -H Adresse_IP_du_serveur_Linux -c check_load
I.3 Configuration de nagios
La dernière étape consiste à modifier les fichiers de configuration de Nagios pour
intégrer le monitoring des serveurs Linux. Il faut dans un premier temps éditer votre fichier de
configuration des hosts (hosts.cfg par défaut) et y ajouter votre machine Linux:
define host {
use generic-host
host_name linux
alias Ma machine Linux
address 192.168.0.7
}
XXI
Puis ajouter les services offerts par NRPE (dans le fichier services.cfg), quelques
exemples:
# Charge CPU
define service {
use generic-service
host_name remotehost
service_description CPU Load
check_command
check_nrpe!check_load
}
# Memoire
define service {
use generic-service
host_name remotehost
service_description Memory
check_command
check_nrpe!check_mem
}
Pour ajouter des nouveaux plugins exécutables par NRPE, il faut éditer le fichier
/etc/nagios/nrpe.cfg et ajouter une ligne par service:
...
command [check_disk] =/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/hda
...
Ne pas oublier de relancer le daemon quand on change le fichier de configuration
(nrpe.cfg):
# service nrpe restart
Il est bien entendu possible d'écrire son propre plugin Nagios et de le faire exécuter par
NRPE.
XXII
II.
Surveiller vos serveurs Windows avec Nsclient++
Comme les plugins NRPE et NSCA (disponible seulement sous Linux et Mac
OS X), NSClient se base sur une architecture client/serveur. La partie cliente
(nommée check_nt), doit être disponible sur le serveur Nagios. La partie serveur
(NSClient++) est à installer sur chacune des machines Windows à surveiller.
Figure 2. Surveillance d’un serveur Linux
II.1
Installation de check_nt
# cd /usr/lib/nagios/plugins
# ls check_nt
check_nt
Si ce n'est pas le cas, il suffit de l'installer grâce aux commandes suivantes:
Fedora:
# sudo yum install nagios-plugins-nt
Ubuntu:
# sudo apt-get install nagios-plugins-nt
II.2 Installation de Nsclient++
Remarque: cette opération est à faire sur l'ensemble des PC Windows à surveiller.
La première chose à faire est de télécharger la dernière version (0.2.5e ou supérieure) à
l'adresse suivante: Sourceforge de NSClient++.
Ensuite il faut:
XXIII




"dézipper" le client dans le répertoire C:\nsclient
ouvrir une commande DOS (cmd.exe)
puis entrer les commandes suivantes:
o cd nsclient
o nsclient++ /install
Ouvrir le gestionnaire des services et vérifier que le service est autorisé à "Interagir avec
le bureau"
Figure 3. Configuration de l’interaction de nsclient++ avec le bureau


Editer le fichier c:nsclientNSC.INI en:
o décommentant tous les modules listés dans la section [modules] sauf
CheckWMI.dll et RemoteConfiguration.dll
o décommentant la ligne allowed_hosts dans la section [Settings] et en y ajoutant
l'adresse du serveur Nagios.
puis entrer les commandes suivantes dans votre fenêtres DOS:
o cd nsclient
o nsclient++ /start
Pour tester que l'installation a bien marchée, le plus simple est de faire un test depuis le
serveur Nagios. Pour cela, il faut:
# cd /usr/lib/nagios/plugins
#. /check_nt -H IPMACHINEWINDOWS -v CLIENTVERSION -p 12489
Si tout se passe bien, le client doit envoyer la version de NSClient (0.2.5e)
XXIV
Si cela ne fonctionne pas, il faut peut-être vérifier que la requête (TCP sur port 12489)
n'est pas bloquée par un Firewall.
II.3 Configuration de nagios
Une fois le client et le serveur installé, il faut configurer Nagios de la manière suivantes.
Il faut dans un premier temps éditer votre fichier de configuration des hosts (hosts.cfg par
défaut) et y ajouter votre machine Windows:
define host {
use generic-host
host_name abserge
alias Ma machine Win
address 192.168.6.66
}
XXV
Puis ajouter les services offerts par NSClient++ (dans le fichier services.cfg):
# Affiche la version du NSClient
define service {
use generic-service
host_name abserge
service_description VERSION
check_command check_nt!CLIENTVERSION
}
# Temps écoulé depuis le dernier reboot (uptime)
define service {
use generic-service
host_name abserge
service_description UPTIME
check_command check_nt!UPTIME
}
# Charge CPU
# WARNING si charge > 80% pendant plus de 5 minutes
# CRITICAL si charge > 90% pendant plus de 5 minutes
define service {
use generic-service
host_name abserge
service_description CPU
check_command check_nt!CPULOAD!-l 5, 80, 90
}
# Etat de la mémoire vive libre
# WARNING si mémoire > 80%
# CRITICAL si mémoire > 90%
define service {
use generic-service
host_name abserge
service_description MEM
check_command check_nt!MEMUSE!-w 80 -c 90
}
Il est également possible de surveiller l'état d'un service (SERVICESTATE) ou d'un
processus (PROCSTATE).
XXVI
ANNEXE
IV :
COMPARAISON
DE
L’UTILISATION DES LOGICIELS DE SUPERVISION
Cette comparaison se base sur l’utilitaire Google Trends.
 Dans le monde
Figure 1. Etude comparée des logiciels open source de supervision dans le monde
XXVII
 En Allemagne
Figure 2. Etude comparée des logiciels open source de supervision en Allemagne
XXVIII
 En France
Figure 3. Etude comparée des logiciels open source de supervision en France
XXIX
 Aux Etats Unis
Figure 4. Etude comparée des logiciels open source de supervision aux Etats-Unis
XXX

etude et mise en œuvre d`un outil de supervision des serveurs

Transcription

Documents pareils

Formation Expériences Professionnelles Expériences

Supervision de serveurs à distance

Offre d`emploi Direction générale

technicien informatique administration et supervision

TP logiciels de supervision

Courte Introduction « Nagios Business Process View » et « Nagios

Pierre TERRIER Site internet : wiki.tuxunix.com 2 Quater rue Barbes

Cédric MOREAU - Dauphine Alumni

De la Surveillance à l`Hypervision Une Solution qui fédère vos