Ministère de l’Éducation Nationale

Université de Montpellier II
- Faculté des Sciences -

Mise en oeuvre d’un système de supervision au

sein du service SI2 du LIRMM
Hakima Manseri

Rapport de stage
effectué au Lirmm
du 16 avril au 30 septembre 2009

Directeur du stage de l’entreprise : Michel Jacquot

Directeur du stage de l’Université : Jacques Chauché
Remerciements

Je tiens à remercier la direction du LIRMM de m’avoir permis d’effectuer mon stage dans
ce laboratoire.

Je remercie le groupe SI2 de m’avoir accueillie durant ces six mois très enrichissants.

Je remercie enfin Michel Jacquot et Cathy Tuchming pour l’aide et les conseils concernant
les missions évoquées dans ce rapport, qu’ils m’ont apportés durant ce stage.

2
Résumé

La complexité des systèmes informatiques croît de jour en jour et il devient de plus

en plus difficile pour un administrateur de surveiller manuellement de tels systèmes. Il
faut automatiser la surveillance du matériel et des applications. De multiples logiciels de
supervision existants répondent à ce besoin.
Dans les pages suivantes, nous étudierons les besoins du service SI2 du LIRMM et
les différentes solutions envisageables pour la supervision de leur système. Suite à leur
comparaison de deux d’entre elles, Zabbix et Centreon, nous proposerons un plan de
déploiement de la solution choisie.

Mots-clé : supervision, système, Linux, Solaris, Nagios, Centreon, Zabbix.

3
Chapitre 1

Présentation

1.1 Le LIRMM
Le Laboratoire d’Informatique, de Robotique et de Microélectronique de Montpellier
(LIRMM) est une unité mixte de recherche CNRS 1 et UM2 2 regroupant 360 personnes
dont environ 140 chercheurs et enseignant-chercheurs et autant de doctorants auquels
s’ajoutent une trentaine de contractuels de recherche (dont des postdocs). Ils se répartissent
dans trois départements scientifiques de recherche :
• Informatique : Étude en algorithmique, en base de données et système d’information,
en génie logiciel, intelligence artificielle et sur les interactions homme-machine.
• Microélectronique : Conception et vérification de systèmes intégrés et microsystèmes,
avec un accent sur les aspects de modélisation et méthodologie.
• Robotique : Recherches en automatique, traitement du signal et de l’image, produc-
tique et informatique industrielle (modélisation, conception et commande).
Ses activités de recherche positionnent pleinement le LIRMM au coeur des sciences et
technologies de l’information, de la communication et des systèmes. Elles font l’objet de
transferts technologiques vers les entreprises via des partenariats ou encore à travers l’aide
à la création d’entreprises (incubateurs 3 ).
Le LIRMM n’oublie pas sa mission d’enseignement et de diffusion de la recherche : il
pilote ainsi deux formations doctorales, l’une en Informatique, l’autre en Systèmes auto-
matiques et microélectroniques.
Aux financements du CNRS et de l’Université Montpellier 2, s’ajoutent ceux de nom-
breux programmes de recherche nationaux et européens auxquels le LIRMM participe.

Toute cette activité de recherche est soutenue par les services généraux :
– service administratif et financier ;
– service logistique ;
– services techniques et informatiques : RéseauX, SI2, Appui à la recherche ;
– communication, documentation, incubation.

1.2 Le service SI2

Mon stage s’est déroulé au sein du service « Système d’Information et Systèmes In-
formatiques », sous la direction de Michel Jacquot, responsable du groupe. Ce service est
1. Centre National de la Recherche Scientifique http://www.cnrs.fr/
2. Université Montpellier 2 http://www.univ-montp2.fr/
3. Le LIRMM est partenaire de Langudoc-Roussillon Incubation www.lr-incubation.com

4
composé de cinq permanents dont les compétences diverses permettent de répondre aux
besoins très variés des utilisateurs.
Comme son nom l’indique, le service SI2 assure principalement deux missions au sein
du laboratoire décrites ci-après.

1.2.1 Axe « Système d’Information »

Essentiellement le fait de Christine Carvalho de Matos et Thibaud Brunel, il prend en
charge le développement et la gestion de projets, dont voici quelques exemples :

• le Système d’Information (SI) : Ce Système d’information regroupe toutes les don-

nées de gestion du Personnel, des contrats de recherche, des publications et des
données de valorisation du laboratoire.
Conçu par le service, il est réalisé sous technologie Oracle, XML, PHP, PL-SQL.
Sa maintenance et son évolution sont une priorité pour le service, qui en tire son
nom.
• le site Web institutionnel : Le site Web institutionnel du laboratoire est également
sous la responsabilité du SI2, qui l’a conçu en XML/XSL sous cocoon/tomcat.
• le portail HAL-LIRMM : Les publications du LIRMM sont gérées sur le portail
HAL-LIRMM conçu par le CCSD 4 en collaboration avec le SI2, le fonds documen-
taire s’appuyant sur le progiciel Alexandrie 5 .

De plus, le SI2 réalise des projets à la demande des services du LIRMM : application de
gestion d’absence, migration du fond documentaire sous le logiciel PMB 6 .

1.2.2 Axe « Systèmes informatiques »

Sous la houlette de Michel Jacquot, de Cathy Tuchming et de Pierre Amadou, le service
met en œuvre et gère les serveurs du laboratoire (Fig. 1.1), notamment la messagerie (qui
inclut un système anti-spam, et des listes de diffusion institutionnelles reliées au Système
d’Information), le Web et les bases de données (Oracle, MySQL et PostGresql). On notera
qu’afin d’assurer la continuité de service, certains serveurs disposent d’un secondaire. Par
exemple, le service LDAP est disponible sur ldap et en cas de panne de ce dernier, sur
octopus.
La gestion des comptes utilisateurs est réalisée de façon automatisée, en relation avec
le Système d’Information.
Le service fournit une aide aux utilisateurs et une étude des besoins à la demande
des chercheurs ou du personnel administratif : par exemple, une plateforme de travail
collaboratif GForge a été mise en place.

1.2.3 Évolution du service

Le service SI2 gère un ensemble matériel et services de plus en plus complexe avec une
demande toujours plus forte des utilisateurs pour une haute disponibilité des services.
La volonté de prévenir et de détecter les problèmes avant que cela n’impacte les utili-
sateurs pousse le SI2 à mettre en place un système de surveillance.

4. Centre pour la Communication Scientifique Directe www.ccsd.cnrs.fr/

5. http://www.gbconcept.com/pro_alexandrie.html
6. Système intégré de gestion de bibliothèque http://www.sigb.net/

5
Figure 1.1 – Services et serveurs gérés par le SI2. Certains serveurs abritant plusieurs
services, ils apparaissent plusieurs fois sur ce schéma.

1.3 Cahier des charges initial

Le service SI2 désire trouver une solution de surveillance permettant de superviser
l’ensemble des composants du service, afin d’être prévenu en cas d’incident.
L’étude à réaliser pourra comporter :
– une comparaison de différentes solutions open source
– la mise en place d’un tel système
– éventuellement, l’adaptation ou la modification de la solution afin d’intégrer les
composants du système non supporte par la solution choisie.
Dans la suite, nous commencerons par développer certains points de ce cahier des
charges. En particulier, nous expliquerons ce qu’est l’open source afin de réaliser les
contraintes que ce choix peut entraîner. Nous décrirons ce qu’est la supervision de système
et préciserons avec le SI2 quelles caractéristiques les intéressent, adaptant ainsi la solution
choisie aux besoins réels, aux compétences et aux goûts des membres du SI2. Ceci aboutira
à la réécriture du cahier des charges et à la réalisation de l’étude comparative demandée.

6
Chapitre 2

La supervision ou surveillance
systèmes et réseaux

2.1 Nécessité d’une surveillance des systèmes informatiques

Les systèmes informatiques étant de plus en plus complexes, leur surveillance et la
localisation des problèmes deviennent de plus en plus ardus pour l’administrateur réseaux
et systèmes. La pression est d’autant plus forte que les entreprises ou organismes s’appuient
sur le système d’information pour leur activité, demandant ainsi une très grande réactivité
de la part de l’administrateur. Il lui faut donc automatiser la surveillance de son système.

2.1.1 Définition
La supervision désigne un ensemble de concepts recouvrant la surveillance du bon
fonctionnement d’un système informatique (matériel, services, applicatifs) en production.
On distingue trois types :
Supervision système. La supervision système porte principalement sur les trois types
principaux de ressources système : processeur, mémoire et stockage.
Supervision réseau. La supervision réseau porte sur la surveillance de manière continue
de la disponibilité des services en ligne - du fonctionnement, des débits, de la sécurité
mais également du contrôle des flux.
Supervision des applications. La supervision des applications (ou supervision appli-
cative) permet de connaître la disponibilité des machines en terme de services rendus
en testant les applications hébergées par les serveurs.
À titre d’exemple, un serveur Web peut avoir une supervision système et réseau avec
des signaux au vert, et la machine ne sera pourtant pas disponible au sens du service Web
si apache n’est pas présent ou n’est pas en mesure de servir des pages Web.

2.1.2 Mode opératoire

Face à l’hétérogénéité des systèmes tant matériel que logicielle, on recherchera une so-
lution de supervision s’appuyant sur des protocoles réseaux courants ou un environnement
normalisé (modèle client/serveur) afin d’en faire l’unique point d’entrée pour la collecte
d’information.
On peut ainsi installer sur les machines à surveiller un agent qui se charge de collecter
les informations requises et les transmet à un serveur de supervision qui les stockent et
leur fait subir les traitements adéquats : par exemple, l’agent peut analyser les journaux,
vérifier les caractéristiques du système (utilisation processeur et mémoire).

7
 Certaines solutions n’utilisent pas ce modèle de fonctionnement et préfère se baser sur le
protocole SNMP (Simple Network Management Protocol) qui permet de gérer le matériel
informatique à distance (voir annexe A). Pour les services publics (Web, messagerie), le
serveur de supervision peut se contenter de simuler le comportement de l’application en
faisant par exemple une requête HTTP sur le serveur Web pour vérifier son activité. On
peut donc faire de la supervision sans installer d’agent au préalable.
En cas de dysfonctionnement, le système de supervision permet d’envoyer des mes-
sages sur la console de supervision, ou bien d’envoyer un courriel, un SMS voire un appel
téléphonique à l’opérateur d’astreinte.

2.1.3 Sécurité
Le serveur de supervision ayant accès à énormément d’informations, il doit être consi-
déré comme un point potentiellement dangereux et doit être sécurisé au maximum.

2.1.4 Besoins
Les besoins en matière de supervision de systèmes et de réseaux sont assez variés.
Certaines entreprises souhaitent simplement une visibilité en temps réel de leur fonction-
nement, d’autres veulent également des alarmes ou des actions automatiques en cas de
problème, des mesures de performances ou un historique pour l’aide à la décision, voire
l’ensemble.

2.2 Panorama
2.2.1 Un détour par le « libre »
Un logiciel libre est un logiciel dont la licence dite libre donne à chacun (et sans
contrepartie) le droit d’utiliser, d’étudier, de modifier, de dupliquer et de diffuser (donner
et vendre) le dit logiciel. Richard Stallman a formalisé la notion de logiciel libre dans la
première moitié des années 1980 puis l’a popularisée avec le projet GNU et la Free Software
Foundation (FSF). Les logiciels libres constituent une alternative à ceux qui ne le sont pas,
qualifiés de « propriétaires » ou de « privateurs ».
Comme souvent répété, les logiciels libres ne sont pas forcément gratuits. De plus, il
existe plusieurs types de licences, sous lesquelles les logiciels peuvent être distribués, qui
donnent plus ou moins de droits aux utilisateurs. La plus connue d’entre elles est la licence
GPL (GNU Public Licence) qui garantie les libertés suivantes :
1. La liberté d’exécuter le programme ;
2. La liberté d’étudier le fonctionnement du programme ce qui suppose l’accès au code
source ;
3. La liberté de redistribuer des copies ce qui comprend la liberté de vendre des copies ;
4. La liberté d’améliorer le programme et de publier ses améliorations ce qui suppose,
là encore, l’accès au code source.
On parle souvent de logiciel Open Source.

La possibilité d’avoir accès au code source permet un développement partagé par une
communauté de programmeurs et d’utilisateurs. Le grand nombre des premiers est un gage
de qualité et de réactivité. Le soutien par un éditeur garantit une certaine pérennité de la
solution.
Quant aux utilisateurs, ils ont une grande influence car ce sont eux qui font remon-
ter les dysfonctionnements et qui proposent des améliorations tant du logiciel que de la

8
documentation. De plus, l’accès au code source permet d’adapter le logiciel à son pro-
blème et de le faire évoluer selon ses besoins, tout en faisant bénéficier la communauté de
ces améliorations. Cette souplesse d’utilisation est souvent ce qui fait défaut aux logiciels
propriétaires.
Cependant, il faut garder à l’esprit que le déployement et le maintien d’un logiciel n’est
pas une tâche aisée. Contrairement aux solutions propriétaires, le support n’est en effet
pas garanti : si un problème se fait jour ou qu’un développement est nécessaire, il n’est
pas sûr d’obtenir une réponse ou un soutien de la part de la communauté.
Les entreprises qui désirent passer aux logiciels libres s’adressent d’ailleurs de plus en
plus souvent à des sociétés de services pour leur déployement et leur maintien. Ou bien
elles souscrivent à des contrats de maintenance auprès d’éditeurs de logiciels libres : le
logiciel lui-même est gratuit mais le support, payant, garantit une réponse rapide en cas
de problème. L’éditeur peut aussi réaliser des développements à la demande du client.

2.2.2 Les solutions de surveillance offertes

Le panorama décrit ci-après est tiré en partie de la lecture des journaux spécialisés
dont [1, 2], les documentations officielles des logiciels ainsi que les notices techniques de
Wikipédia [3] et de blogs dédiés, par exemple [4].
Les produits de supervision libres sont généralement constitués d’un noyau, auquel se
greffent des modules personnalisables : administration, reporting, gestion des métriques,
interface utilisateur, etc. Les produits issus du monde libre sont facilement adaptables et
modulables.
Nous recherchons une solution qui gère des serveurs et des services. Nous distinguerons
deux grandes familles de logiciels de supervision : ceux basés sur Nagios et les autres qui se
présentent comme des solutions « complètes » ou « tout en un », généralement développés
par un éditeur. Ces dernières se veulent des concurrents directes des solutions propriétaires.
La tableau 2.1 montre une sélection de logiciels pouvant nous intéresser. On voit qu’elles
ont des caractéristiques assez comparables.
Nagios est un ordonnanceur de scripts (plugins ou greffons) de supervision. Il est géné-
ralement complété d’une ou plusieurs surcouches qui facilitent son utilisation (Centreon,
pour une interface Web plus conviviale), exploitent les données accumulées (NaReTo, pour
le reporting) ou bien ajoutent des fonctionnalités (NagVis, pour la cartographie). Cette
très grande flexibilité qui laisse le choix quant aux composants utilisés peut aussi être un
repoussoir pour qui n’est pas habitué à la philosophie Lego de cette solution.
Nous voudrons alors nous tourner vers des solutions « tout en un », qui sont généra-
lement très faciles à installer. Cependant, elles peuvent paraître lourde pour un système
aussi simple que celui du SI2. Le principal avantage de ces solutions est qu’elles sont dis-
tribuées par des structures commerciales qui possèdent donc un service de support aux
utilisateurs : hotline, messagerie, mise à jour automatique du logiciel. Étant encore peu
présentes en France, il faut s’adresser à une société de services.
Du côté des grands éditeurs, des solutions libres sont en préparation tel Cosmos
d’IBM 1 .

2.3 Un cahier des charges revisité

L’équipe du SI2 désire l’installation d’un logiciel de surveillance système et applicative
suffisamment souple pour prendre en compte la diversité du matériel informatique et des
applications dont elle a la charge (Fig. 1.1). Son extension doit être facilement réalisable,

1. http://www.eclipse.org/cosmos/

9
 Nom Licence Langage Graphes Greffons (Création) Interface Web Droits utilisateur
Nagios [5] GPL C Oui Oui (Facile) Oui Oui
OpenNMS [6] GPL Java Oui Oui (Assez facile) Oui Oui
Hyperic [7] GPL Java/JBOSS Oui Oui (Facile) Oui Oui
& commerciale

10
Zabbix [8] GPL C/Php Oui Oui (Facile) Oui Oui
Zenoss [9] GPL Python/Zope Oui Oui (Facile) Oui Oui
& commerciale
Table 2.1 – Quelques solutions libres et leurs caractéristiques (adapté du tableau http://en.wikipedia.org/wiki/Comparison_of_network_
monitoring_systems)
c’est-à-dire pour accomoder l’ajout de matériel ou d’applications non supportés en stan-
dard par la solution de surveillance. Il doit permettre l’envoi de notifications en cas de
problème par email, SMS ou appel téléphonique.
Ce logiciel doit être « libre », pour limiter les coûts (pas d’acquisition de licence), tout
en étant soutenu par une large communauté de développeurs et d’utilisateurs, voire par
un éditeur, pour assurer sa pérennité et un soutien si un quelconque problème se présente.
Il est installable sous CentOS de préférence.
Idéalement, cette solution est déjà deployée dans d’autres entreprises ou organismes
avec un retour positif.
Les tests porteront sur les services dits publics (serveurs Web, messagerie, base de
donnees MySQL, annuaire LDAP) qui sont ceux que le SI2 désire surveiller en priorité.
Enfin, la solution choisie doit être bien documentée, tant au niveau de l’installation que
de l’utilisation. Le logiciel doit, de préférence, comporter une interface graphique agréable
et simple d’utilisation. Il doit être aisé de le maintenir, en particulier pour les mises à jour.
Le stagiaire devra former ses collègues et rédiger une documentation administrateur
et utilisateur sous forme de notices qui seront conservées sur le site technique du SI2.

2.4 Choix et méthode de test

2.4.1 Solutions candidates
Nagios étant une des solutions les plus anciennes et les plus répandus, nous consi-
dèrerons une solution basée dessus. Notre préférence se porte sur Centreon qui est une
sur-couche Web de gestion en vogue auprès des utilisateurs de Nagios et soutenue par un
éditeur, Merethis.
Nous voulons comparer Nagios à une des solutions complètes du tableau 2.1. Le groupe
SI2 ayant fait part de son appréhension face à Java, nous éviterons donc les solutions
comme Hypéric ou OpenNMS. Zenoss est une solution très jeune et dont l’éditeur améri-
cain n’est pas présent en France. Nous testerons donc Zabbix dont les échos dans la presse
spécialisée sont très favorables.

2.4.2 Le système de tests

La mise en place et la comparaison de ces solutions recquièrent deux machines indé-
pendantes fonctionnant si possible en même temps. Or nous ne les possédons pas. De plus,
nous voulons tester le comportement de ces logiciels en cas de pannes et il est hors de
question de provoquer de tels dysfonctionnements dans le système en production.
Nous allons donc profiter du serveur de virtualisation 2 virtuose présent au LIRMM
pour construire un système de tests à base de machines virtuelles. Ainsi, l’arrêt des services
ou des machines n’aura aucun impact sur le service SI2 et ses utilisateurs mais permettra
la simulation des conditions réelles de supervision.
Le logiciel de virtualisation KVM 3 permet de créer des machines virtuelles ayant cha-
cune leurs propres adresses MAC et IP. Nous obtenons donc la configuration de tests
présentée sur la figure 2.1.
Nous nous limitons à deux machines virtuelles, l’une sous CentOS et l’autre sous Open-
Solaris : ce seront les hôtes à surveiller. Pour chacun d’eux, nous voulons savoir s’il est
actif et connaître le taux d’occupation des disques et d’utilisation des processeurs et de la
mémoire.
2. Une machine virtuelle ressemble en tout point à une machine normale (système d’exploitation, appli-
cations, etc.) si ce n’est qu’elle fonctionne en même temps que d’autres machines sur un serveur physique
unique. Un logiciel de virtualisation permet cette cohabitation en faisant l’interface entre le matériel du
serveur et les différents systèmes d’exploitation.
3. http://www.linux-kvm.org/

11
Figure 2.1 – Configuration de tests : à gauche, les machines de supervision ; à droite, les
machines surveillées.

Les services installés sur ces hôtes sont une sélection de services effectivement utilises
par le SI2. Nous avons donc un serveur de messagerie, un serveur Web, une base de données
mysql et un annuaire ldap.
Nous utiliserons 3 recipiendaires pour les emails d’alerte :
– un responsable pour le système entier qui recevra toutes les alertes 24h sur 24h, 7
jours sur 7 ;
– deux gestionnaires restreints à un sous-groupe (serveur Web/base de donnees) qui
ne recevront les alertes qu’entre 14h et 17h du lundi au jeudi.

2.4.3 Marche à suivre

1. Lecture de la documentation d’installation et de configuration de chaque solution.
2. Installation des logiciels de supervision sur des machines virtuelles dédiées.
3. Installation et configuration des hôtes à surveiller.
4. Déclaration de trois gestionnaires qui recevront les alertes.
5. Déclaration de chaque machine et des services associés auprès des outils de supervi-
sion.
6. Ajout des alertes.
7. Arrêt intempestif de services et/ou d’hôtes avec réception d’alertes.
8. Arrêt programmé de services (pour maintenance). Nous ne devons pas recevoir
d’email d’alerte.
9. Production de graphiques sur une période de plusieurs jours d’activité d’hôtes ou de
services surveillés.
À chaque étape, la facilité d’utilisation et l’existence d’une documentation appropriée
seront indiquées.

12
Chapitre 3

Nagios/Centreon

3.1 Présentation
Un des prérequis pour utiliser Centreon est d’installer Nagios et comprendre son fonc-
tionnement.

3.1.1 Nagios [5]

Nagios 1 est une application écrite en C permettant la surveillance des systèmes. Créée
en 1999 sous le nom de NetSaint et toujours maintenue par Ethan Galstad, elle surveille
des hôtes et les services associés, alertant le personnel d’astreinte lorsqu’un problème se
présente. C’est un logiciel libre sous licence GPL version 2 qui fonctionne sous Linux et
d’autres variantes Unix.
Nagios est un programme modulaire qui se décompose en trois parties :
1. le moteur de l’application qui vient ordonnancer les tâches de supervision ;
2. l’interface web, qui permet d’avoir une vue d’ensemble du système d’information et
des possibles anomalies ;
3. les plugins ou greffons, une centaine de mini programmes que l’on peut compléter en
fonction des besoins de chacun pour superviser chaque service ou ressource disponible
sur l’ensemble des ordinateurs ou éléments réseaux du SI.
La déclaration et la gestion des hôtes et services se fait par l’édition de fichiers texte,
ce qui peut devenir rapidement fastidieux et requiert rigueur et organisation. La figure 3.1
montre la complexité des relations entre les différents fichiers de configuration dont le
logiciel Nagios se sert pour effectuer sa surveillance.
Nagios permet la surveillance des hôtes à l’aide de SNMP et des services publics comme
expliqué page 8. Cependant, certains services ou caractéristiques de l’hôte nécessite d’avoir
une autorisation pour y avoir accès. Nagios propose deux solutions :
• avec ssh : après avoir installer et échanger des clés ssh entre le serveur Nagios et l’hôte
distant, les connexions se font sans requérir de mot de passe. Un greffon, check_ssh,
permet alors d’exécuter une commande, un script ou un autre greffon sur la machine
distante.
• avec NRPE : de trop nombreuses connexions ssh peuvent devenir trop lourdes à gérer
pour le serveur Nagios et il peut être plus intéressant d’installer un agent sur l’hôte
distant. Le démon NRPE (Nagios Remote Plugin Executor) est installé sur la ma-
chine ainsi que les greffons nécessaires pour la surveillance. Il les exécute et répond
au requête du serveur Nagios (Fig. 3.2).
1. Acronyme récursif : "Nagios Ain’t Gonna Insist On Sainthood", en référence au nom originel de ce
programme qui a dû être changé en 2001 pour des raisons légales. http://www.nagios.org

13
Figure 3.1 – Fonctionnement de Nagios.

14
Cette surveillance est dite active car elle se fait à la demande du serveur Nagios.

Figure 3.2 – Fonctionnement de NRPE.

Tous les services ne peuvent être testés à intervalles fixes : par exemple, les sauvegardes
effectués par le SI2 tous les jours peuvent prendre plus ou moins de temps. Il faut donc un
agent qui surveille ces activités et acquittent leur bon fonctionnement auprès de Nagios :
NSCA (Nagios Service Connection Acceptor) est ce démon qui permet de remonter les
alertes asynchrones vers le serveur Nagios (Fig. 3.3). Dans ce cas, on parle de surveillance
passive car Nagios est à l’écoute.

Figure 3.3 – Fonctionnement de NSCA.

Nagios n’est qu’un ordonnanceur de scripts qui acquitte les réponses des différents
hôtes interrogés. Il est donc nécessaire d’ajouter un module pour conserver les données
recueillies et ainsi pouvoir générer des graphes de suivi. Ce module NDO utilise une base
de données MySQL pour le stockage des données (Fig. 3.4). Le contenu de cette base peut
ensuite être exploité par n’importe quel logiciel tier.

Figure 3.4 – Fonctionnement de NDO.

Outre la configuration par l’édition de fichier texte, l’autre point faible de Nagios est
la non-convivialité de son interface Web. Mais sa grande force est qu’il s’agit simplement
d’un ordonnanceur qui se charge d’excécuter des commandes (greffons), ce que ces greffons
testent ne le concerne pas. De même, ce que nous faisons des résultats obtenus lui importe
peu. On peut donc définir facilement de nouveaux greffons et on peut développer de

15
nouvelles interfaces pour Nagios. Nous nous proposons d’utiliser l’une d’elles, Centreon.

3.1.2 Centreon [10]

Centreon est un logiciel de surveillance et de supervision systèmes,sous licence GPL,
basé sur le moteur de récupération d’information libre Nagios. Il est édité par la société
Merethis depuis 2003 sous le nom d’Oreon. En 2007, il devient Centreon.
Au départ utilisé par une communauté francophone, il s’est depuis internationalisé
(traduction du logiciel en anglais, en portugais et en allemand). En tant qu’éditeur, Me-
rethis propose un support et des extensions payants mais laisse le coeur de Centreon sous
licence GPL et donc en libre accès.
Centreon fournit une interface simplifiée en apparence pour rendre la consultation de
l’état du système (Fig. 3.6) accessible à un plus grand nombre d’utilisateurs, y compris
des non-techniciens, notamment à l’aide de graphiques (Fig. 3.5). Les techniciens ont
cependant toujours accès aux informations techniques de Nagios.

Figure 3.5 – Exemple de graphique produit par Centreon :il s’agit du temps de réponse
à une requête ICMP Echo afin de s’assurer de l’activité du serveur.

3.2 Mise en oeuvre de Nagios/Centreon

3.2.1 Installation
L’installation, détaillée dans l’annexe B, est longue mais relativement simple car très
bien documentée. Les quelques problèmes rencontrés ont rapidement trouvé une solution
sur les différents blogs et forums consacrés à cette solution.

3.2.2 Déclaration de gestionnaires

La déclaration des gestionnaires ou utilisateurs se fait à travers l’interface Web. On peut
aussi définir des groupes, sachant qu’un utilisateur peut appartenir à plusieurs groupes.
Les autorisations d’accès à l’interface Centreon peuvent être réglée très finement :
l’utilisateur peut accéder à tout ou juste une partie du site suivant le groupe auquel il
appartient. Pour cela, Centreon nous permet de définir des règles ACL (Access Control
List) pour chaque partie et sous-partie du site et d’autoriser ou non l’accès à un ou plusieurs
groupes.
Nous définissons donc un superutilisateur (le responsable) et deux gestionnaires en
charge des bases de données et du serveur Web comme décrit § 2.4.2 qui auront accès aux

16
Figure 3.6 – Interface Web sous Centreon : état des services surveillés (ils sont tous OK).

17
graphiques sur Centreon mais ne pourront pas le configurer (groupe de simples utilisa-
teurs).

3.2.3 Déclaration d’hôtes et de services

L’utilisation des paramètres par défaut fourni dans le formulaire est généralement
suffisante : les hôtes sont défini a minima et on ajoute les services qui nous intéressent
pour chacun d’eux. C’est ici qu’on associe des utilisateurs ou groupes d’utilisateurs pour
la réception des alertes.

3.2.4 Définitions d’alerte

La définition des alertes se fait sur le formulaire de déclaration du service ou de l’hôte
concerné. On y indique la fréquence de ses alertes ainsi que les récipiendaires (individuel-
lement ou par groupe).

3.2.5 Arrêts de service ou d’hôte

Nous avons effectué plusieurs arrêts : machines virtuelles éteintes (voir Fig. 3.7), arrêts
de services intempestifs, fermeture de ports et vérifier que les emails de notification étaient
bien reçus.
Par exemple, on stoppe le service httpd sur la machine virtuelle virt6 (sur Opensolaris) :
seul le responsable reçoit bien un email tous les 1/4h comme demandé. On relance le service
et on constate un retour à la normale sous Centreon quelques minutes plus tard.

3.2.6 Arrêt programmé

Ici encore, nous avons fait plusieurs tests, programmant l’arrêt des machines et des
services à plusieurs reprises au cours du stage.
Par exemple, on déclare l’arrêt du service mysqld toujours sur virt6 de 15h45 à 16h
le 10/7/2009 (Downtime schedule). On stoppe le service sur la machine dans le laps de
temps indiqué. Le service est bien vu comme “critique” mais aucun des gestionnaire ne
reçoit pas de notification pendant cette période. On ne relance pas le service : tous les
gestionnaires reçoivent un email à 16h03 (il y a une interrogation du serveur mysql toutes
les 5 minutes). On relance le service et tout repasse à la normale à 16h08.

3.2.7 Production de graphiques

Les figures 3.5 et 3.8 montrent respectivement l’activité du serveur Webmail sur quelques
heures et la charge processeur sur un mois. On peut y voir une interruption de service de
quelques jours due à une maintenance. Ces graphiques sont accessibles à tous les utilisa-
teurs définis.

18
Figure 3.7 – Centreon en état d’alerte : les deux serveurs ont été éteints (encadrés sur la
figure). On voit les services passés au rouge.

Figure 3.8 – Charge processeur du serveur Webmail installé sur la machine virtuelle virt2
(Webmail sous CentOS).

19
Chapitre 4

Zabbix

4.1 Présentation
Zabbix [8] est une solution de supervision système développée par Alexei Vladishev
depuis 2001. Il est aussi le directeur de ZABBIX SIA, basé à Riga, en Lettonie. Zabbix est
conçu pour surveiller les services, serveurs et tourtes sortes de matériel réseau. Il utilise
une base de données pour stocker les informations et se configure à travers une interface
Web très riche (Fig. 4.1).

Figure 4.1 – Aperçu de l’interface de configuration Zabbix.

20
 Il se base sur les protocoles de communication connus (SNMP, HTTP, etc.), ce qui
permet une surveillance avec ou sans agent comme expliquer 8. Il permet de produire des
graphiques et des alertes avec envoi de notifications (email, SMS).
Le coeur de Zabbix est codé en C et son interface en PHP. Il est livré sous la licence
GPL v2.

4.2 Mise en oeuvre de Zabbix

Globalement, Zabbix reprend les idées mises en oeuvre dans Nagios/Centreon : instal-
lation, configuration et visualisation se font à travers une interface Web 4.1.

4.2.1 Installation
L’installation, détaillée dans l’annexe C, est assez simple et est très bien documentée.
Nous choisissons de travailler en mode client/serveur, qui nécessite l’installation d’agents
sur les hôtes, car c’est le mode conseillé par la documentation.

4.2.2 Déclaration de gestionnaires

Contrairement à Centreon, Zabbix propose déjà des groupes et des types d’utilisateurs.
Trouver comment en définir de nouveau n’est pas évident. Nous parvenons tout de même
à créer les utilisateurs requis à l’aide des groupes prédéfinis.

4.2.3 Déclaration d’hôtes et de services

Ici encore, des modèles existent : nous utiliserons les modèles Linux et Solaris pour les
hôtes qui incluent les services à surveiller. Mais nous devons les modifier car ils comportent
des services dont nous n’avons pas l’usage (news, ftp par exemple).

4.2.4 Définitions d’alerte

Il faut définir ce que Zabbix nomme une action : à un déclencheur, c’est-à-dire une
condition d’alerte, on associe un groupe d’utilisateurs qui recevra une notification ou alors
une commande qui sera exécutée.

4.2.5 Arrêts de service ou d’hôte (intempestifs ou programmés)

Les arrêts sont les mêmes que ceux provoqués pour tester Centreon puisque les deux
logiciels fonctionnent en même temps et surveillent les mêmes machines (voir Fig. 4.2).
Nous récupérons bien les emails comme indiqués pour Centreon § 3.2.

4.2.6 Production de graphiques

La figure 4.3 montre la charge processeur sur quelques heures. Ces graphiques sont
accessibles à tous les utilisateurs définis.

21
Figure 4.2 – Zabbix en état d’alerte : les deux serveurs ont été éteints (encadrés sur la
figure).

Figure 4.3 – Graphique sous Zabbix. Charge processeur du serveur Webmail installé sur
la machine virtuelle virt2 (sous CentOS).

22
Chapitre 5

Choix et mise en oeuvre

5.1 Résumé comparatif des deux solutions

Comme le montre les tableaux 5.1, 5.2 et 5.3, les deux solutions sont comparables en
terme de capacité : elles couvrent toutes les applications et le matériel que nous souhaitons
surveillés et permettent d’utiliser divers systèmes de notification (email, SMS).
Les grandes différences proviennent de la documentation, et de la communauté propre
à chaque solution, ainsi que de l’ergonomie de l’interface Web.
Zabbix est une solution complète très simple d’installation. Cependant elle est encore
jeune et les retours de déployement sur de gros systèmes commencent seulement à paraitre.
De plus, son interface Web me semble un peu trop touffu : Zabbix est très modulaire
et flexible, ce qui rend sa configuration et donc l’interface qui y donne accès un peu
compliquées. C’est une solution à surveiller car elle évolue très vite et peut être plus
adaptée si le service SI2 venait à grossir.
Pour un système aussi simple que celui du SI2, le couple Nagios/Centreon nous semble
plus approprié : les exemples concrets d’installation, d’application et les greffons abondent
sur Internet. En particulier, la documentation de Nagios, très didactique, permet de com-
prendre les dessous de la supervision et de prendre en main le logiciel (Nagios et Centreon)
très rapidement.

Critère Zabbix Nagios/Centreon

Installation Facile Facile
Documentation Pas assez orientée utilisateur Excellent, différentes sources,
plusieurs niveaux, beaucoup d’exemples
Communauté Assez active Très active
Configuration Un peu complexe Facile
Adaptabilité Oui Oui
Extension Facile Facile
Maintien Non testé Non testé
Maturité/Pérennité Jeune mais en progression Très utilisé
Éditeur Oui Oui
Graphes Oui Oui
Interface web Un peu confuse Très claire et agréable

Table 5.1 – Caractéristiques des solutions de supervision.

23
 Services Zabbix Centreon
LDAP OK OK
Messagerie OK OK
MySQL OK OK
Postgresql OK OK
Oracle OK OK
Apache OK OK
Tomcat OK OK
Acquittement sauvegardes OK OK

Table 5.2 – Support des services. On constate que les deux solutions couvrent toutes les
applications que nous désirons surveillées.

Matériel/OS Zabbix Centreon

Sun SPARC/Solaris 10 OK OK
Sun X86/Linux 2.6 OK OK

Table 5.3 – Supervision des caractéristiques des serveurs (processeurs, mémoire, occupa-
tion des disques, montage NFS).

5.2 Proposition de déployement de la solution choisie

Nous proposons de déployer Centreon en plusieurs phases : sans agent NRPE/NSCA
puis avec.

5.2.1 À court terme : pas d’agent

Le serveur Centreon

Le serveur sera hébergé sur une machine virtuelle dédiée (sous CentOS 5.3). Nous
pouvons utiliser la version qui a servi pour les tests. Nous pensons tout de même qu’il
serait formateur pour les membres du SI2 intéressés, de procéder à l’installation eux-
mêmes, cette installation n’étant pas très difficile.

Creation des utilisateurs

Un groupe si2 qui comprend tous les membres du SI2 interessés est créé. Ils reçoivent
les alertes par email.

Surveillance des hôtes

Nous installons le démon SNMP sur les hôtes et les déclarons auprès de Centreon en
indiquant le groupe si2 comme récipiendaire des alertes (voir la figure 1.1 pour la liste des
serveurs).

Surveillance des services publics

Nous déclarons ensuite les services à surveiller et ici encore, associons le groupe si2
aux alertes (voir la figure 1.1 pour la liste des services).

24
5.2.2 Évolution de la surveillance : avec agent
Agents NRPE/NSCA
Lorsque le groupe SI2 est à l’aise avec la manipulation de Centreon, nous pouvons
installer les agents NRPE/NSCA sur les hôtes le nécessitant. Par exemple, le service SI2
a mis en place des tâches cron qui permettent de faire une sauvegarde automatique des
serveurs. Lorsque celle-ci est achevée, le démon NSCA peut prévenir le serveur Centreon.

Groupes de services
Certains services sont dédoublés : en cas de panne du serveur ldap abritant l’annuaire
LDAP, par exemple, le serveur ocotopus prend le relais puisqu’un annuaire LDAP secon-
daire y est installé.
Nous pouvons définir un tel groupe de services : dans ce cas, le service LDAP est
marqué comme en fonctionnement mais l’hôte ldap est signalé aux gestionnaires comme
ayant un problème.

À terme, il s’agit de remplacer toutes les alertes individuelles mises en place manuel-
lement par le service SI2 par les services de Nagios/Centreon.

5.3 Déployement effectif

Au cours de mon stage, le SI2 s’est adressé à une SSII 1 pour un contrat de service.
Afin d’assurer cette mission, les ingénieurs de cette entreprise ont dû mettre en place un
serveur de supervision (serveur rhapsodie sur la figure 1.1) : leur choix s’est aussi porté sur
Centreon. Pour ne pas interférer avec leur travail d’audit, je n’ai finalement pas déployé
la solution comme prévu sur le système en production, je l’ai donc déployé et testé sur un
système de tests à base de machines virtuelles.

1. Société de Services en Ingénierie Informatique

25
Chapitre 6

Conclusions

Le domaine de la supervision est un domaine important de l’administration systèmes et

réseaux. En constante évolution, les solutions libres ont prouvée qu’elles avaient leur place
dans la sphère professionnelle. Bien que n’ayant pas déployé Centreon pour le système
en production, ce stage m’a permis de comprendre les méandres de la supervision. Il m’a
aussi permis d’interagir avec une équipe pour la rédaction d’un cahier des charges et sa
réalisation.
Le but du stage a été pleinement réalisé et a été très enrichissant tant du point de vue
professionnel qu’humain.

26
Annexes

27
Annexe A

Le protocole SNMP

Simple Network Management Protocol (SNMP) est un protocole de communication 1

qui permet aux administrateurs réseaux de gérer, superviser et diagnostiquer le matériel
informatique à distance.
Un agent, ou démon, est installé sur le matériel à surveiller et l’administrateur peut,
depuis une console que l’on nomme « manager » ou « superviseur », faire des requêtes
respectant le protocole SNMP pour récupérer des informations depuis cet agent.
Un grand nombre de logiciels libres et propriétaires utilisent SNMP pour interroger
régulièrement les équipements et produire des graphes rendant compte de l’évolution des
réseaux ou des systèmes informatiques (NetCrunch 5, MRTG, Cacti, Nagios, Zabbix, The
Dude...).
SNMP existe au moins quatre versions (1, 2c, 2 et 3), la version 1 étant la plus ancienne
et la plus répandue.

A.1 Le protocole
Une requête SNMP est un datagramme UDP habituellement à destination du port
161 de la machine surveillée. La réponse, quant à elle, est envoyée vers le port 162 du
superviseur.
Les commandes utilisées dans les requêtes et réponses sont indiquées dans le ta-
bleau A.1. Il est possible de lire et de modifier les données sur la machine distante.

Commande Action
get-request Le Superviseur SNMP demande une information à un agent SNMP
get-next-request Le Superviseur SNMP demande l’information suivante à l’agent SNMP
set-request Le Superviseur SNMP met à jour une information sur un agent SNMP
get-reponse L’agent SNMP répond à un get-request ou a un set-request
trap L’agent SNMP envoie une alarme au Superviseur

Table A.1 – Liste des commandes acceptées dans la version 1 de SNMP.

Le fonctionnement, relativement simple, est résumé sur la figure A.1 : l’agent n’envoie ou
ne modifie les informations qu’à la demande du superviseur. En cas de problème, il est
possible pour l’agent d’envoyer une alerte ou « trap » au superviseur mais il n’attend pas
d’acquittement.

[ !ht]

1. Plusieurs RFC (Requests For Comments) concernent ce protocole. Voir www.rfc-editor.org/.

28
 Figure A.1 –

A.2 La MIB

Pour que SNMP fonctionne, il faut une standardisation des informations que ce pro-
tocole peut transporter : ces informations sont stockées dans une MIB (Management In-
formation Base).
La MIB se présente comme une base de données normalisée, qui permet de lire et
d’écrire sur les équipements distants, de façon également normalisée. Ce sera à l’agent lui-
même de faire la traduction entre les informations transmises par SNMP et la plate-forme.
Elle est organisée hiérarchiquement, comme montré sur la figure A.2. Chaque noeud ou
feuille de l’arbre est situé par un index, cette numérotation étant normalisée. Pour rendre
cet arbre plus lisible, les noeuds possède un nom, cette nomenclature étant elle-même
normalisée.
Elle contient une partie commune à tous les agents SNMP en général, une partie
commune à tous les agents SNMP d’un même type de matériel et une partie spécifique à
chaque constructeur.
On peut lire la MIB en faisant référence aux index ou aux noms : interroger .1.3.6.1.2.1.1.3.0
ou .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0 désigne la même feuille, sysUp-
TimeInstance.

A.3 La sécurité avec SNMP

Un agent SNMP est plus ou moins finement paramétrable, suivant le système. Il est
possible, par exemple de créer des groupes de sécurité qui auront accès en lecture seule,
d’autres en lecture/écriture, d’autres encore en lecture seule, mais sur certaines branches
seulement.
Chaque groupe devra disposer d’une sorte de mot de passe, appelé "community". En
général, la communauté "public" est celle qui a le droit de lecture sur les informations non
sensibles.
L’inconvénient majeur est qu’avec SNMP v1, qui est actuellement la seule version
vraiment stabilisée et reconnue par tous, ce mot de passe circule en clair sur le réseau, ce
qui rend dans ce cas SNMP plus que dangereux.
Les versions suivantes de SNMP corrigent ce problème majeur.

29
+--system(1)
|
+-- -R-- String sysDescr(1)
| Textual Convention: DisplayString
| Size: 0..255
+-- -R-- ObjID sysObjectID(2)
+-- -R-- TimeTicks sysUpTime(3)
| |
| +--sysUpTimeInstance(0)
|
+-- -RW- String sysContact(4)
| Textual Convention: DisplayString
| Size: 0..255
+-- -RW- String sysName(5)
| Textual Convention: DisplayString
| Size: 0..255
+-- -RW- String sysLocation(6)
| Textual Convention: DisplayString
| Size: 0..255
+-- -R-- INTEGER sysServices(7)
| Range: 0..127
+-- -R-- TimeTicks sysORLastChange(8)
| Textual Convention: TimeStamp
|
+--sysORTable(9)
|
+--sysOREntry(1)
| Index: sysORIndex
|
+-- ---- INTEGER sysORIndex(1)
| Range: 1..2147483647
+-- -R-- ObjID sysORID(2)
+-- -R-- String sysORDescr(3)
| Textual Convention: DisplayString
| Size: 0..255
+-- -R-- TimeTicks sysORUpTime(4)
Textual Convention: TimeStamp

Figure A.2 – Extrait de la MIB, sous-arbre « System ».

A.4 Interrogation d’un agent

Le superviseur a généralement accès à une série de commandes en ligne permettant

d’interroger les agents, dont le nom commence par snmp :
– récupérer les informations provenant d’un agent par l’utilisation de requêtes simples
(snmpget, snmpgetnext) ou multiples (snmpwalk, snmptable, snmpdelta) ;
– manipuler la configuration du matériel (snmpset) ;
– récupérer un groupe d’informations donné (snmpdf, snmpnetstat, snmpstatus) ;
– convertir les identifiants de la MIB de la forme numérique vers la forme textuelle et
inversement, afficher le contenu de la MIB et sa structure (snmptranslate).

30
 Par exemple, si on veut connaître depuis combien de temps le serveur fonctionne (ou
uptime), on fait la requête suivante :

[root@virt7 usr]# snmpget -v 1 -c public localhost \

.1.3.6.1.2.1.1.3.0
DISMAN-EVENT-MIB::sysUpTimeInstance =
Timeticks: (113531256) 13 days, 3:21:52.56
[root@virt7 usr]# snmpget -v 1 -c public localhost \
.iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0
DISMAN-EVENT-MIB::sysUpTimeInstance =
Timeticks: (113539659) 13 days, 3:23:16.59

On voit que les deux formes (numérique et textuelle) sont équivalentes.

A.5 Installation et utilisation de SNMP

A.5.1 Sous CentOS 5.3
Il suffit d’installer les paquets net-snmp et net-snmp-utils à l’aide la commande yum
puis de déclarer les serveurs et communautés autorisés à faire des requêtes dans le fichier
/etc/snmp/snmpd.conf.
Il faut enfin démarrer le service et l’enregistrer comme un service à lancer à chaque
reinitialisation de la machine.

# service snmpd start

# chkconfig --level 345 snmpd on

A.5.2 Sous OpenSolaris 2009.06

Il faut installer les paquets SUNWsmagt, SUNWsmcmd et SUNWsmmgr à l’aide de la
commande pkg puis éditer comme précédemment le fichier de configuration
/etc/sma/snmp/snmpd.conf. On démarre le service :

#svcadm enable sma

31
Annexe B

Installation de Centreon

Centreon nécessite l’installation de Nagios en premier lieu. Ensuite, une fois Centreon
installé, la déclaration des machines peut se faire à travers l’interface Web.
Nous avons suivi les instructions données dans la documentation fournie avec Nagios
v3.0.6 [11] et Centreon v2.0.2 [12] et sur le site de Nicolargo [13]. Nous n’indiquons ici que
les grandes lignes pour donner une idée de la complexité de l’installation.

B.1 Installation de Nagios

Bien que disponible sous forme de paquet pour la distribution CentOS, nous avons
décidé de compiler le code source directement pour utiliser la version stable la plus à jour
de Nagios au début de ce stage. Après installation des dépendances (serveurs Apache,
MySQL et SNMP), le code source a été téléchargé 1 et compilé sans problème notable.
L’utilisation de Nagios requiert la création d’un utilisateur (nagios) et d’un groupe
(nagcmd) qui seront utilisés pour exécuter le logiciel. En effet, pour des raisons de sécurité,
nous ne voulons pas que Nagios soit exécuté par le superutilisateur root.
De même, nous téléchargeons, compilons et installons les greffons disponibles librement
sur le site de Nagios.
Afin de vérifier que tout fonctionne, on peut lancer la commande en ligne suivante :

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
[...]

Total Warnings: 0
Total Errors: 0

[...]

Pour finir avec Nagios lui-même, nous configurons le serveur de messagerie sendmail
pour pouvoir envoyer des emails d’alerte.

B.2 Installation de NDO

Nous voulons conserver les informations que collectent Nagios pour un traitement
ultérieur. Nous téléchargeons donc l”extension NDO sur le site de Nagios et le compilons.
L’utilisation de cette extension nécessite de modifier le fichier de configuration principal de
Nagios, nagios.cfg. Puis, il faut créer la base de données MySQL dans laquelle les données
seront stockées. Pous finir, nous relançons nagios.
1. http://www.nagios.org/download

32
B.3 Installation de Centreon
Après avoir téléchargé le logiciel Centreon, nous l’avons installé à l’aide du script
d’installation fourni. Ceci fut rapide et sans douleur. La configuration se termine à travers
l’interface Web de Centreon.
Une fois connecté, on constate qu’une machine est déjà surveillé : il s’agit du serveur
abritant Centreon et Nagios.

33
Annexe C

Installation de Zabbix

Ici encore nous nous sommes servi de la documentation officielle de Zabbix 1 et de

l’excellent blog de Nicolargo [14].
Une fois les dépendances installées (serveurs Apache, MySQL, SNMP), nous téléchar-
geons le code source de la version stable de Zabbix (version 1.6.4). Avant de le compiler,
nous devons créer un utilisateur nommé zabbix et une base de donnée MySQL. Cette
dernière est initialisée grâce à des scripts fournis par Zabbix. Nous pouvons maintenant
compiler et configurer le logiciel : tout d’abord la version serveur, puis l’agent.
Nous terminons la configuration de Zabbix à travers l’interface Web. Ici encore, le
serveur hébergeant est automatiquement surveillé par le logiciel.
Notons que nous pouvons compiler l’agent une fois pour toute et le copier sur tout
hôte de même configuration que le serveur Zabbix (CentOS 5.3). Cependant, pour un
autre type d’hôtes (OpenSolaris, par exemple), nous devons transférer le code dessus et
compiler l’agent.

1. téléchargeable sur http://www.zabbix.com/download

34
Bibliographie

[1] Mieux surveiller son réseau grâce aux outils open source.
http://www.01informatique.fr/reseaux-telecoms-117/
surveiller-reseau-open-source-11422/, Mis en ligne le 09/12/2008, consulté en
mai 2009.
[2] Supervision : ce que valent les outils open source. http://pro.01net.com/
editorial/344735/supervision-ce-que-valent-les-outils-open-source/,
Mis en ligne le 23/03/2007, consulté en mai 2009.
[3] Network monitoring. http://en.wikipedia.org/wiki/Network_monitoring, Der-
nière mise à jour en 2009, consulté en mai 2009.
[4] Le blog de nicolargo. http://blog.nicolargo.com/, Dernière mise à jour 2009,
consulté en mai 2009.
[5] Nagios. http://www.nagios.org/.
[6] Opennms. http://www.opennms.org/.
[7] Hyperic. http://www.hyperic.com/.
[8] Zabbix. http://www.zabbix.com/.
[9] Zenoss. http://www.zenoss.com/.
[10] Centreon. http://www.centreon.com/.
[11] Nagios core version 3. http://nagios.sourceforge.net/docs/3_0/, Dernière mise
à jour 16 juin 2009, consulté en juin 2009.
[12] Centreon 2 setup : Centos/fedora/rhel. http://en.doc.centreon.com/Setup:
Centos/Fedora/RHEL, Dernière mise à jour 16 août 2009, consulté en juin 2009.
[13] Le serveur de supervision libre - part 2. http://blog.nicolargo.com/2009/01/
le-serveur-de-supervision-libre-part-2.html, Dernière mise à jour 20 janvier
2009, consulté en juin 2009.
[14] Installation de zabbix sur linux. http://blog.nicolargo.com/2007/11/
installation-de-zabbix-sur-linux.html, Dernière mise à jour 20 novembre 2007,
consulté en juin 2009.

35
Table des matières

Remerciements 2

Résumé 3

1 Présentation 4
1.1 Le LIRMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Le service SI2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Axe « Système d’Information » . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Axe « Systèmes informatiques » . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Évolution du service . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Cahier des charges initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 La supervision ou surveillance systèmes et réseaux 7

2.1 Nécessité d’une surveillance des systèmes informatiques . . . . . . . . . . . 7
2.1.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Mode opératoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.4 Besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Panorama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Un détour par le « libre » . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Les solutions de surveillance offertes . . . . . . . . . . . . . . . . . . 9
2.3 Un cahier des charges revisité . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Choix et méthode de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 Solutions candidates . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2 Le système de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.3 Marche à suivre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Nagios/Centreon 13
3.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Nagios [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2 Centreon [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Mise en oeuvre de Nagios/Centreon . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Déclaration de gestionnaires . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3 Déclaration d’hôtes et de services . . . . . . . . . . . . . . . . . . . . 18
3.2.4 Définitions d’alerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.5 Arrêts de service ou d’hôte . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.6 Arrêt programmé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.7 Production de graphiques . . . . . . . . . . . . . . . . . . . . . . . . 18

36
4 Zabbix 20
4.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Mise en oeuvre de Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2 Déclaration de gestionnaires . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.3 Déclaration d’hôtes et de services . . . . . . . . . . . . . . . . . . . . 21
4.2.4 Définitions d’alerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.5 Arrêts de service ou d’hôte (intempestifs ou programmés) . . . . . . 21
4.2.6 Production de graphiques . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Choix et mise en oeuvre 23

5.1 Résumé comparatif des deux solutions . . . . . . . . . . . . . . . . . . . . . 23
5.2 Proposition de déployement de la solution choisie . . . . . . . . . . . . . . . 24
5.2.1 À court terme : pas d’agent . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.2 Évolution de la surveillance : avec agent . . . . . . . . . . . . . . . . 25
5.3 Déployement effectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 Conclusions 26

Annexes 27

A Le protocole SNMP 28
A.1 Le protocole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2 La MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.3 La sécurité avec SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.4 Interrogation d’un agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.5 Installation et utilisation de SNMP . . . . . . . . . . . . . . . . . . . . . . . 31
A.5.1 Sous CentOS 5.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.5.2 Sous OpenSolaris 2009.06 . . . . . . . . . . . . . . . . . . . . . . . . 31

B Installation de Centreon 32
B.1 Installation de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
B.2 Installation de NDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
B.3 Installation de Centreon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

C Installation de Zabbix 34

Bibliographie 35

37