ETUDE ET MISE EN ŒUVRE D UN OUTIL DE SUPERVISION DES SERVEURS

Transcription

1 Ministère de L Enseignement Supérieur et de la Recherche Scientifique République de Côte d Ivoire Union Discipline – Travail N d ordre : 1 / 10 / ESI / ING TLC / 2011 G 2 Génie Electrique & Electronique G2 Ecole Supérieure d Industrie E MEMOIRE DE FIN DE CYCLE THEME ETUDE ET MISE EN ŒUVRE D UN OUTIL DE SUPERVISION DES SERVEURS 04 Juillet 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

2 Ministère de L Enseignement Supérieur et de la Recherche Scientifique République de Côte d Ivoire Union Discipline – Travail N d ordre : 1 / 10 / ESI / ING TLC / 2011 Ecole Supérieure d Industrie 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 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

3 DEDICACE A mes parents, Pour leur soutien indéfectible. I

4 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

5 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 Création et missions de la SNDI Création de la SNDI Missions de la SNDI Organisation de la SNDI… 4 CHAPITRE 2 : CONTEXTE DU STAGE Département d accueil Positionnement du thème Cahier des charges Contraintes Méthodologie Etude de l existant Présentation de l environnement… 8 CHAPITRE 3 : LA SUPERVISION DES RESEAUX Le concept de supervision des réseaux La norme ISO Gestion des performances Gestion des configurations (Management Configuration) Gestion de la comptabilité (Accounting Management) Gestion des anomalies (Fault Management) Gestion de la sécurité (Security Management) Structure de gestion des réseaux (Network Management System) Le protocole SNMP Déploiement des logiciels de supervision PARTIE B : ETUDE ET CHOIX DE LA SOLUTION DE SUPERVISION CHAPITRE 4 : CRITERES DE CHOIX DE LA SOLUTION Les coûts élevés des licences propriétaires Le besoin d adaptabilité et de modularité La Transparence du mécanisme de remontée d alerte Les performances Mise en commun des expériences CHAPITRE 5 : LES OUTILS DE SUPERVISIONS ZABBIX III

6 5.1.1 Qu’est-ce que Zabbix? Qu’offre Zabbix? Les atouts de zabbix Le public visé par Zabbix Zenoss Généralités et fonctionnalités de Zenoss OpenNMS Description de OpenNMS Les fonctionnalités FAN (FULLY AUTOMATED NAGIOS) Présentation de FAN Nagios Centreon Nagvis CHAPITRE 6 : CHOIX DE LA SOLUTION Atouts de Nagios par rapport aux autres outils open source Zabbix : la supervision simplement Zenoss : très bonne supervision, mais pas complètement libre La supervision très SNMP Nagios, logiciel open source de supervision le plus utilisé CHAPITRE 7 : ETUDE DE NAGIOS Architecture de Nagios Les Plugins Les agents Fonctionnement Méthode d obtention des informations Données à définir dans Nagios PARTIE C : MISE EN ŒUVRE CHAPITRE 8 : IMPLEMENTATION DE LA SOLUTION Conception de l architecture de supervision Le mode de déploiement Regroupement par type Installation Configuration Première configuration Configuration des groupes de contacts Configuration des contacts Configuration des moyens de notification Configuration des hôtes Configuration des services Test CONCLUSION BIBLIOGRAPHIE… IX GLOSSAIRE… XI ANNEXES… XV IV

7 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) FIGURE 4. ARCHITECTURE DE NAGIOS FIGURE 5. FONCTIONNEMENT DE NRPE FIGURE 6. FONCTIONNEMENT DE NSCA FIGURE 8. INTERFACE D ACCUEIL DE CENTOS FIGURE 9. PAGE D ACCUEIL DE FAN FIGURE 10. INTERFACE D ACCUEIL DE CENTREON FIGURE 11. CREATION D UN GROUPE DE CONTACTS FIGURE 12. AJOUT D UN CONTACT FIGURE 13. INFORMATIONS GENERALES DE NOTIFICATION DES HOTES POUR LES CONTACTS FIGURE 14. MOYENS DE NOTIFICATIONS PRECONFIGURES FIGURE 15.DEFINITION DE LA COMMANDE D ENVOI D FIGURE 16. CONFIGURATION DE L ENVOI PAR SMS POUR LES SERVICES DANS CENTREON FIGURE 17. INFORMATIONS GENERALES DANS L AJOUT D UN HOTE FIGURE 18. CONFIGURATION D UN GROUPE D HOTES FIGURE 19. AJOUT D UNE COMMANDE FIGURE 20. MISE EN RELATION DES SERVICES ET HOTES SUPERVISES V

8 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 TABLEAU 3. COMPARAISON DE L UTILISATION DES LOGICIELS OPEN SOURCE DE SUPERVISION TABLEAU 4. PARAMETRES DE CONFIGURATION DES DIFFERENTS SERVICES TABLEAU 5. SUPERVISION DES RESSOURCES PHYSIQUES LOCALES SUR LE SERVEUR LOCAL TABLEAU 6. SUPERVISION DES RESSOURCES PHYSIQUES SUR LES MACHINES LINUX DISTANTES TABLEAU 7. SUPERVISION DES MACHINES WINDOWS TABLEAU 8. SUPERVISION DE MYSQL ET POSTGRESQL TABLEAU 9. SUPERVISION DES BASES DE DONNEES ORACLE VI

9 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 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 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

10 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

11 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

12 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 , 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

13 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

14 CHAPITRE 1 : Présentation de la structure d accueil 1.1 Création et missions de la SNDI 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 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 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 , 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 ( ). 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

15 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

16 Conseil d Administration Direction Générale Direction Générale Adjointe DAL DEDFO DERT DFC DCM DRT 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

17 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

18 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 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 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

19 2.4 Etude de l existant 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 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

20 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) 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

21 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/4 1 définissant les principales fonctions que doivent implémenter les systèmes de supervision et d administration. Ces fonctions sont les suivantes : 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

22 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 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 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 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

23 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é 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

24 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 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

25 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

26 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

27 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

28 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 «FOSS 2» 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 FOSS( ) BIG 4( ) Coût de la licence 0 443,34 Coût de la Souscription 0 0 Coût de la maintenance 0 157,031 Coût de l implémentation 0 266,375 Total * 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

29 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

30 CHAPITRE 5 : Les outils de supervisions 5.1 ZABBIX 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 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 trapping 4. 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] 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 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

31 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 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 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

32 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 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 Description de OpenNMS Le projet OpenNMS a débuté en Juillet 1999 et a été enregistré sur SourceForge 5 en Mars 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 monitoring 6 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 Plate-forme d’hébergement de projets 6 Surveillance 21

33 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é 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

34 5.4 FAN (FULLY AUTOMATED NAGIOS) 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] 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 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 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

35 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 Centreon 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] 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

36 – 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 : – permet de suivre l’historique du fonctionnement du SI 7 (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 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

37 – 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

38 CHAPITRE 6 : CHOIX DE LA SOLUTION Le Tableau suivant récapitule la comparaison des différents logiciels présentés. Tableau 2. Comparaison des différents logiciels libre présentés Logiciel Modularité Performances Communauté Age Zabbix Moyenne Bonnes Grande 11 ans Zenoss Bonne Bonnes Grande 9 ans OpenNMS Moyenne Moyennes Grande 12 ans Nagios (FAN) Très bonne Très bonnes Très grande > membres 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 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] Zenoss : très bonne supervision, mais pas complètement libre Concurrent très sérieux de Nagios, il a comme particularité de ne pas être complètement libre. Là où Nagios est entièrement en GPL 8, 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

39 que l envoi d alertes, limité aux s 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 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 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

40 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 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 à 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

41 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 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

42 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. 7.2 Fonctionnement Figure 6. Fonctionnement de nsca 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

43 démon 9 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 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 ; 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

44 – 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 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 relatif à un événement sur un hôte, nous avons la définition suivante : define command{ command_name host-notify-by- command_line /bin/echo “Host $HOSTNAME$ is $HOSTSTATE$” /bin/mail $CONTACT $ } 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

45 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 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

46 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 = 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 check_command check-host-alive check_interval 5 retry_interval 1 max_check_attempts 3 check_period 24×7 contact_groups web-admins notification_interval 30 notification_period 24×7 notification_options d, u, r } 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

47 É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

48 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 = 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 Contacts : qui et comment? 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 24×7 notification_interval 30 notification_period 24×7 notification_options w,c,r contact_groups admins-web } 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

49 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 l adresse 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 . } define contact { contact_name abserge alias ABBE SERGE host_notifications_enabled 1 service_notifications_enabled 1 service_notification_period 24×7 host_notification_period 24×7 service_notification_options w,u,c,r host_notification_options d,u,r service_notification_commands notify-by- , notify-by-sms host_notification_commands host-notify-by- abserge@sndi.ci 38

50 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 } 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

51 # Generic service definition template define service { name generic-service register 0 active_checks_enabled 1 passive_checks_enabled 1 parallelize_check 1 obsess_over_service 1 check_freshness 0 notifications_enabled 1 event_handler_enabled 1 flap_detection_enabled 1 process_perf_data 1 retain_status_information 1 retain_nonstatus_information 1 check_period 24×7 max_check_attempts 3 normal_check_interval 3 retry_check_interval 1 contact_groups labo-admins notification_interval 240 notification_period 24×7 notification_options c,r } define service { host_name use service_description check_command } define service { host_name use service_description check_command } SMTP DNS mailhost generic-service check_smtp ns generic-service 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

52 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

53 Chapitre 8 : Implémentation de la solution 8.1 Conception de l architecture de supervision 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é 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: 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

54 NagVis : cartographie avancée NDOUtils : stocke les données Nagios dans une base MySQL NRPE : permet de superviser les serveurs Windows 8.3 Configuration 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 La configuration réseau 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-eth 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 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 “GNOME Desktop Environment” “X Window System” (capture d écran) 43

55 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 : (Figure 9) 44

56 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

57 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 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 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

58 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 ( , 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 Configuration des moyens de notification Configuration des s La configuration des s, comme moyen de notification des services et des hôtes est déjà configuré dans Centreon. En allant dans Configuration Commands Notifications 47

59 Figure 14. Moyens de Notifications préconfigurés Nous voyons host-notify-by- et notify-by- qui gèrent respectivement la notification par des hôtes et des services. En cliquant sur notify-by- dans le champ Command Line nous voyons la commande d envoi d Figure 15.Définition de la commande d envoi d Elle réalise l envoi de l 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 . 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 est nécessaire sur le serveur de supervision. À ce propos, sur la distribution installée ici, c est le 48

60 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 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 s 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 : #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 Test d envoi d un sms 49

61 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$ is $HOSTSTATE$ – $OUTPUT$” gnokii config /etc/gnokiirc sendsms $CONTACTPAGER$ } 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 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

62 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 Configuration des services La configuration des services a été faite suivant les groupes d hôtes définis dans le 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

63 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

64 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

65 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. Nom du service Tableau 4. Paramètres de configuration des différents services Commande Ligne de commande Description de la commande contacts Nombre d hôte(s) Ldap Check_ldap $USER1$/check_ldap – H $HOSTADDRESS$ -b $ARG1$ DNS Check_dns $USER1$/check_dns -H $ARG1$ -s $HOSTADDRESS$ DHCP Check_dhcp $USER1$/check_dhcp -s $HOSTADDRESS$ -i $ARG1$ Suite du tableau 4. 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é. 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 1 SYSgroup 4 SYSgroup Nom du service Commande Ligne de commande Description de la commande contacts Nombre d hôte(s) HTTP Check_http $USER1$/check_http -H Elle prend comme argument SYSgroup 12 $HOSTADDRESS$ l adresse du service à tester par le paramètre -H. HTTPS Check_https $USER1$/check_http -H $HOSTADDRESS$ -S Elle prend comme argument l adresse du service à tester par le paramètre H, -S est utilisé pour renvoyer les requêtes vers le canal SSL. SYSgroup 5 FTP Check_ftp $USER1$/check_ftp -H $HOSTADDRESS$ SMTP Check_smtp $USER1$/check_smtp -H $HOSTADDRESS$ POP Check_pop $USER1$/check_pop -H $HOSTADDRESS$ IMAP Check_imap $USER1$/check_pop -H $HOSTADDRESS$ SAMBA Check_smb $USER1$/check_tcp -H $HOSTADDRESS$ -p 445 Elle prend comme argument l adresse du service à tester par le paramètre -H. Elle prend comme argument l adresse du service à tester par le paramètre -H. Elle prend comme argument l adresse du service à tester par le paramètre -H. Elle prend comme argument l adresse du service à tester par le paramètre -H. Elle prend comme argument l adresse du service à superviser et le port SYSgroup 5 SYSgroup 1 SYSgroup 1 SYSgroup 1 SYSgroup 11 54

66 Alias du service Charge moyenne RAM mem check_mem.pl -w 90 -c 95 Tableau 5. Supervision des ressources physiques locales sur le serveur local Commande Ligne de commande Description de la commande contacts Nombre d hôte(s) load check_load -w 1,1,1 -c 2,2,2 Permet de vérifier «charge SYSgroup 40 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 SYSgroup 40 mémoire est utilisée à 90% et un critical à 95% SWAP swap check_swap -w 80% -c 50% Suite du Tableau 5 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 Alias du service Commande Ligne de commande Description de la commande DISQUE disk check_disk -w 80 -c 90 Lève un warning dès que la mémoire est utilisée à 80% et un critical à 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% contacts Nombre d hôte(s) SYSgroup 40 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 : 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

67 Tableau 6. Supervision des ressources physiques sur les machines Linux distantes Nom du service Alias Ligne de commande Description de la commande contacts Nombre d hôte(s) Load_remote Etat de la Charge moyenne sur une machine distante check_nrpe -H $HOSTADDRESS$ -c load On donne en paramètre l adresse du serveur distant et le nom de la commande à lancer sur l hôte distant SYSgroup 40 RAM_remote SWAP_remote Disk_remote Cpu_remote Procs_remote Etat de la RAM sur une machine distante 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 check_nrpe -H $HOSTADDRESS$ -c mem check_nrpe -H $HOSTADDRESS$ -c swap check_nrpe -H $HOSTADDRESS$ -c disk check_nrpe -H $HOSTADDRESS$ -c cpu check_nrpe -H $HOSTADDRESS$ -c procs Vérifie l état de la mémoire sur le serveur distant 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 Vérifie la charge du processeur sur une machine distante Vérifie le nombre de processus utilisé par un service sur une machine distante SYSgroup 40 SYSgroup 40 SYSgroup 40 SYSgroup 40 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 Win_mem Alias Ligne de commande Description de la commande Etat de la charge check_nt -H serveur -v Lève un warning si la du processeur sur CPULOAD l 15, 90, charge des 15 une machine 95 dernières minutes est windows à 90% et un critical à 95% Etat de la mémoire sur une machine windows check_nt -H serveur -v MEMUSE -w 90 -c 95 Lève un warning dès que la mémoire est utilisée à 90% et un critical à 95% contacts Nombre d hôte(s) SYSgroup 40 SYSgroup 40 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% Lève un warning dès que la mémoire est utilisée à 90% et un critical à 95% SYSgroup 40 56

68 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 Alias Ligne de commande Description de la commande Mysql Service MySQL $USER1$/check_tcp -H On donne en $HOSTADDRESS$ -p paramètre l adresse du 3306 serveur distant et le port du service MySQL PgSQL Service PostgreSQL $USER1$/check_tcp -H $HOSTADDRESS$ -p 5432 On donne en paramètre l adresse du serveur distant et le port du service PostgreSQL contacts Nombre d hôte(s) DBgroup 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 : La configuration de check_oracle_health va utiliser l agent nrpe. La configuration des différentes métriques s est faite comme suit : 57

69 Nom de la métrique tnsping Connection-time Connected-users sga-data-bufferhit-ratio Tableau 9. Supervision des bases de données oracle Ligne de commande Commande dans nrpe Description de la commande $USER1$/check_oracle_health Check_nrpe!tnsping Vérifie la connexion au mode tnsping listener $USER1$/check_oracle_health Check_nrpe!connection-time Le temps de se mode connection-time connecter au serveur $USER1$/check_oracle_health Check_nrpe!connected-users Nombre d utilisateurs mode connected-users actuellement connectés $USER1$/check_oracle_health mode sga-data-buffer-hitratio Check_nrpe! sga-data-buffer-hitratio Taux d’accès au Buffer de données sga-library-cachehit-ratio sga-dictionnary – cache-hit-ratio Check_nrpe! sga-dictionnarycache-hit-ratio sga-shared-poolfree pga-in-memorysort-ratio tablespace-usage tablespaceremaining-time tablespace-iobalance redo-io-traffic roll-avgactivesize $USER1$/check_oracle_health mode sga-library-cache-hitratio $USER1$/check_oracle_health mode sga-dictionnary-cachehit-ratio $USER1$/check_oracle_health mode sga-shared-pool-free $USER1$/check_oracle_health mode pga-in-memory-sortratio $USER1$/check_oracle_health mode tablespace-usage tablespace $USER1$/check_oracle_health mode tablespace-usage tablespace $USER1$/check_oracle_health mode tablespace-io-balance $USER1$/check_oracle_health mode redo-io-traffic $USER1$/check_oracle_health mode roll-avgactivesize Check_nrpe! sga-library-cachehit-ratio Check_nrpe! sga-shared-poolfree Check_nrpe!pga-in-memory-sortratio Check_nrpe! tablespace-usage Check_nrpe! tablespaceremaining-time Check_nrpe! tablespace- iobalance Check_nrpe! redo-io-traffic Check_nrpe! roll-avgactivesize Taux d’accès au library cache Taux d’accès au dictionnary cache 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 Temps restant jusqu au remplissage d un tablespace Equilibre des fichiers de données Input- Output 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

70 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 et par sms sont en cours de configuration. Pour les notifications par , 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 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 . 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

71 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 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

72 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), < [5] Zabbix : Interview d Alexei Vladishev, (Page consultée 10 Juillet 2011 à 15h 12), < [6] Zenoss Installation, (Page consultée 13 Juillet 2011 à 8h20), < [7] About opennms, (Page consultée 9 Juillet 2011 à 22h), < [8] FAN Documentation, (Page consultée le 20 juillet 2011 à 4h), < [9] Nagios Documentation, (Page consultée le 20 juillet 2011 à 7h), < [10] Centreon Overview, (Page consultée le 16 Juillet à 9h), < [11]Nagvis Documentation, (Page consultée le 16 Juillet à 10h), < [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), < [14] NRPE Documentation, (Page consultée le 27 juillet à 7h), < IX

73 [15] Nagios, (Page consultée le 22 juillet à 7h), < 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

74 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 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 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 E : ETHERNET : Ethernet est un protocole de réseau local à commutation de paquets. Voir 3.3 XI

75 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 I : IETF: Internet Engineering Task Force Groupe de travail qui développe les nouveaux standards pour l Internet. Voir 3.3 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 XII

76 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 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 POLLING : un client obtient des informations en lançant une requête au serveur. Voir 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 XIII

77 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 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 TRAPPING : L élément réseau envoie une information sous la forme d une alerte à un démon distant. Voir 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

78 ANNEXES XV

79 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

80 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

81 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

82 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. I.1 Sur votre serveur Nagios Figure 1. Fonctionnement de nrpe 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

83 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 j ACCEPT Attention il faut mettre deux – (- -) avant l’option dport XX

84 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 } XXI

85 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 NRPE. Il est bien entendu possible d’écrire son propre plugin Nagios et de le faire exécuter par XXII

86 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

87 “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 Si tout se passe bien, le client doit envoyer la version de NSClient (0.2.5e) XXIV

88 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 } XXV

89 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

90 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

91 En Allemagne Figure 2. Etude comparée des logiciels open source de supervision en Allemagne XXVIII

92 En France Figure 3. Etude comparée des logiciels open source de supervision en France XXIX

93 Aux Etats Unis Figure 4. Etude comparée des logiciels open source de supervision aux Etats-Unis XXX