Présente ... Livre Blanc La Supervision Open Source. État de l art de la supervision appliquée aux solutions open source. Version 1 Janvier 2005

Transcription

1 .. UPERTO DEVOTEAM GROUP Présente Livre Blanc La Supervision Open Source État de l art de la supervision appliquée aux solutions open source Version 1 Janvier 2005

2 SOMMAIRE 1 HISTORIQUE DE LA SUPERVISION LA NAISSANCE DU PROTOCOLE SNMP LE PROTOCOLE SNMP RMON SNMP V SNMP V LA GESTION DES SYSTEMES D INFORMATION LES FONCTIONS DE GESTION LA GESTION DE LA CONFIGURATION LA GESTION DE LA SECURITE LA GESTION DES PANNES ( FAULT MANAGEMENT OU AVAILABILITY MANAGEMENT) L AUDIT DE PERFORMANCE (PERFORMANCE MANAGEMENT) LA GESTION DE LA COMPTABILITE ( ACCOUNTING MANAGEMENT) IMPACTS ORGANISATIONNELS ET FONCTIONNALITES ORGANISATION TYPIQUE LA COUCHE D ADMINISTRATION FILTRAGE ET COMMUNICATION MOTEUR DE CORRELATION NOTIFICATION ET SUPERVISION PRO ACTIVE LE BAC A EVENEMENT CONSOLES INTERFACE AVEC LES SYSTEMES DE GESTION DE CONTRAT DE SERVICE (SLA) PERIMETRE TECHNIQUE MRTG (MULTI ROUTER TRAFFIC GRAPHER) MATURITE DU LOGICIEL / HISTORIQUE PERIMETRE FONCTIONNEL PERIMETRE TECHNIQUE RRD TOOL (ROUND ROBIN DATABASE TOOL) MATURITE DU LOGICIEL / HISTORIQUE PERIMETRE FONCTIONNEL PERIMETRE TECHNIQUE CACTI MATURITE DU LOGICIEL / HISTORIQUE PERIMETRE FONCTIONNEL PERIMETRE TECHNIQUE NETMRG MATURITE DU LOGICIEL / HISTORIQUE BIG BROTHER MATURITE DU LOGICIEL / HISTORIQUE PERIMETRE FONCTIONNEL ET TECHNIQUE BIG SYSTER MATURITE DU LOGICIEL / HISTORIQUE PERIMETRE FONCTIONNEL ET TECHNIQUE NAGIOS

3 12.1 MATURITE DU LOGICIEL / HISTORIQUE ARCHITECTURE DE NAGIOS PERIMETRE FONCTIONNEL OPENNMS MATURITE DU LOGICIEL / HISTORIQUE PERIMETRE FONCTIONNEL PERIMETRE TECHNIQUE ZABBIX MATURITE DU LOGICIEL / HISTORIQUE PERIMETRE FONCTIONNEL PERIMETRE TECHNIQUE :

4 Introduction Au cours des dernières décennies, les systèmes d information sont devenus des éléments stratégiques pour l ensemble des métiers de l entreprise quelques soient leurs secteurs. Satisfaire au besoin de qualité de services impose aux gestionnaires la vision de l état des éléments constituant le système d information et des événements qui s y produisent. C est l enjeu des outils de supervision de collecter, traiter, et d offrir une consolidation de ces événements. Malgré des efforts importants des organismes de standardisation, plusieurs implémentations techniques sont apparues afin de répondre à ce besoin. Ces solutions ont au fil du temps tenté de répondre à tous les enjeux posés par la supervision des SI. Les solutions propriétaires nées au fur et à mesure de la promulgation des standards offrent des solutions qui, même si elles sont satisfaisantes, sont souvent onéreuses et incompatibles entre elles, et imposent le choix d un fournisseur unique. Des logiciels Open Source sont apparus au départ dans le but de répondre aux aspects les plus simples de la supervision. La monté en maturité de ces solutions leur permettent aujourd hui d offrir une alternative crédible. Les solutions de supervision open source offrent les avantages de l open source : Faibles coûts d acquisition, Respect des standards, Indépendance des fournisseurs, Bonne qualité technique. 4

5 Vue d ensemble Les concepts de la supervision 5

6 1 Historique de la supervision 1.1 La naissance du protocole SNMP Au début d'internet, la majorité des équipements réseaux sont l œuvre de quelques fournisseurs proposant chacun leur système de supervision. Cependant avec la croissance d'internet et du nombre de fournisseurs d'équipements réseaux, le besoin d'un standard de supervision et de gestion apparaît. Cet effort de standardisation est l'oeuvre de l'i.a.b. (Internet Activities Board) qui, en 1988, publie la RFC 1052 intitulée: «IAB recommendations for the development of Internet network management standards». Dans cette publication, l'iab statue sur les travaux en cours : le H.E.M.S (High-Level Entity Management System), le SGMP (Simple Gateway Monitoring Protocol) et le CMIS / CMIP (Common Management Information Service/Protocol). Le H.E.M.S réalise l'étude et la définition détaillées de la gestion de réseaux (RFC 1021) ; il suscite l'intérêt de CISCO. Le SGMP est la réponse aux besoins de gestion des réseaux NYSERNET et SURAnet, dont l'implémentation et l utilisation par des applications sont fonctionnelles. Cependant, les fonctionnalités du SGMP sont faibles. Le CMIS/CMIP, oeuvre de l'iso, est documentée sans être implémentée à cette date. L'IAB conclue par ces préconisations: A court terme, la communauté Internet devra adopter et adapter le SNMP, succédant au SGMP. A moyen terme, le CMIS/CMIP de l ISO devra être testé et développé. La responsabilité du protocole SNMP sera placée dans les mains de l IETF. Enfin, il faudra définir une Management Information Base (MIB) étendue pour le SNMP et le CMIP afin de converger vers la MIB définie dans le HEMS. En 1988, basées sur le travail de l IETF et de l ISO les RFC suivantes sont publiées : RFC 1065 : Structure and Identification of Management Information for TCP/IP-based internets RFC 1066 : Management Information Base for Network Management of TCP/IP-based internets RFC 1067 : A Simple Network Management Protocol Elles jettent les bases du protocole SNMP dont la RFC définitive est publiée en 1989 sous la référence RFC 1098 «Simple Network Management Protocol (SNMP)». En parallèle, le développement du CMIS/CMIP se poursuit sous la dénomination CMOT (Common Management Information Services and Protocol over TCP/IP) dont la première RFC est publiée en 1989 sous la référence RFC 1095, puis modifiée dans la RFC 1189 de Mais la convergence de CMOT et de SNMP, nécessaire en vue de l évolution souhaitée de SNMP vers CMOT, apparaît de plus en plus difficile. En 1991, la première version de SNMP est rapidement atteinte. SNMP est devenu un standard Internet validé par IESG. Les RFC sont réécrites pour intégrer les nouvelles fonctionnalités : 6

7 La RFC 1155 remplace la RFC 1065; Elle décrit comment les informations de gestion sont désormais structurées dans une organisation unique. Elle introduit certaines restrictions pour conserver un protocole simple et des règles pour nommer un élément. La RFC 1156 remplace la RFC Elle décrit les spécifications techniques des Management Information Base. La RFC 1157 remplace la RFC 1098 et décrit le protocole SNMP. De nombreuses sociétés développent des MIB pour leurs équipements et pour de nombreux protocoles (Pont, switch, Hub, ASCII monitors, interface WAN, DS1, DS3, X25, Frame Relay, Ethernet, Token Ring, FDDI...) ce qui consolide la position de SNMP face à CMOP. En parallèle, un groupe de travail publie en 1990 la RFC 1158, devenue obsolète en 1991, puis remplacée par la RFC Ces RFC décrivent les fonctionnalités de la MIB 2. Cette seconde version devient un standard IESG en Cette nouvelle version comprend les fonctionnalités de la version 1 et ajoute le support de CMOT (Common Management Information and Services over TCP) et de SNMP. Malgré les efforts de l ISO pour promouvoir CMIS/CMIP et CMOT, son développement est pratiquement abandonné. Le groupe de travail de l IETF décide donc d introduire la supervision du protocole SNMP au sein des MIB. Le but étant de permettre le contrôle des équipements mais également du protocole d administration lui-même afin de connaître ses performances et ses défaillances pour assurer l'administration et la supervision de l ensemble de la solution. En 1993, une nouvelle version de SNMP apparaît sous la forme des RFC 1441 à 1452, sa dénomination technique est SNMPv2. C est un protocole expérimental pour IETF. SNMPv2 pose des problèmes de compatibilité avec la première version et n introduit toujours pas de fonctionnalité de sécurité et de restriction. Devant le manque de certaines fonctionnalités de sécurité non implémentées mais prévues à la création de SNMP et par le développement du protocole concurrent CMOT qui devait les intégrer, un groupe de travail décide d'améliorer le protocole en Les fruits de leurs études sont de les RFC 1905, 1906 et Ce nouveau protocole possède la dénomination SNMP2c. Il devient un standard en 2002, son architecture est décrite dans la RFC Dans le même temps, un groupe de travail développe la version 3 de SNMP. Les RFC sont publiées en décembre 2002 sous les références RFC 3411, 3412, 3413, 3414 et SNMPv3 possède le statut de standard auprès de l IESG. Cette version est de plus en plus utilisée par les constructeurs. 1.2 Le protocole SNMP SNMP est basé sur trois composants : un logiciel de supervision, un agent SNMP, une base d informations d administration. Le logiciel d administration (management software) est exécuté sur une station de gestion de réseaux (network management station, NMS). Ce logiciel est responsable de l interrogation des agents par le biais de commandes SNMP. 7

8 Les agents représentent un ou plusieurs modules applicatifs opérant sur l équipement, par exemple une station de travail, un routeur ou un commutateur. Chaque agent enregistre des données et met à disposition celles-ci lors de son interrogation par le logiciel de supervision. La Management Information Base (MIB) est une base de données qui fournie une représentation standardisée des informations collectées. Cette base est structurée comme un arbre et inclus les groupes d objets gérés. La version 1 de la MIB inclus 114 objets dans 8 groupes. Le SNMP est un protocole applicatif transporté par le protocole UDP, lui-même au dessus de IP dans la pile de protocole TCP/IP. La structure des paquets SNMP est définie par ASN.1 (Abstract Syntax Notation 1). SNMP possède cinq commandes de base dont le format standard est référencé sous le terme de PDU (Protocol Data Units). Ces PDU incluent GetRequest, GetNextRequest, SetRequest, GetResponse et Trap. Le logiciel de supervision réalise un GetRequest pour obtenir une valeur de l agent SNMP, GetNextRequest permet de naviguer à travers la MIB de l agent SNMP. Quand l agent répond à l une ou l autre de ces requêtes, il utilise GetResponse. SetRequest donne au logiciel d administration la possibilité de modifier la MIB d un agent SNMP. Dans la version 1 de SNMP, il n y a pas de méthode de restriction à cette commande, qui peut altérer les paramètres de configurations ou les services réseaux. C est pourquoi un grand nombre de fournisseurs et de constructeurs ont décidé de ne pas supporter cette commande. SNMP étant un protocole permettant l interrogation aussi que l envoi d informations (questionréponse), un mécanisme est disponible pour alerter le logiciel d administration sur une situation anormale qui nécessite son attention. Ce mécanisme est la commande Trap réalisée par un agent à une station de supervision. 1.3 RMON En 1991, la RFC 1271 est publiée par un groupe d utilisateurs avec l aide de l IETF. Son but est de définir l administration et la supervision à distance d équipements en utilisant le protocole SNMP et les MIB (pour Ethernet). Son titre est «Remote Network Monitoring Management Information Base». Un problème apparaît avec le développement par les constructeurs des MIB spécifiques à leurs équipements. En effet, rien n interdit aux constructeurs d étendre les informations de leurs MIB, mais la lecture de ces informations par d autres constructeurs devient difficile, ce qui entraîne des problèmes d interopérabilités. Il est nécessaire de préciser qu à cette période, les stations d administration réseaux (NMS) sont des solutions techniques balbutiantes dont le fournisseur ou l éditeur est souvent le constructeur des équipements réseaux. De même, les NMS sont généralement situées sur le même brin réseaux que les équipements réseaux qu elles administrent. Pour réduire le risque d interopérabilité naissant, le Remote Monitoring (RMON) est développé comme standard pour l administration et la supervision des réseaux LAN. RMON fournit l infrastructure qui permet aux différents constructeurs de communiquer à un même logiciel d administration, permettant à une seule station d administration réseaux la gestion de l ensemble des équipements sans tenir compte du constructeur. 8

9 MIB RMON est une évolution logique à l utilisation du protocole SNMP. Il s agit d un futur standard (il le deviendra en 1995, la RFC 1271 évoluant en RFC 1757) définissant les spécifications des informations de la MIB pour la supervision et l administration entre des équipements réseaux et des consoles de supervision hétérogènes. Il autorise les agents distants à contrôler les flux de trafic circulant sur le réseau (cela sert notamment aux sondes). La MIB RMON est composée d objets organisés en neuf groupes : Statistics Contient les statistiques mesurées par la sonde RMON pour chaque interface réseau History Enregistre des mesures sur un intervalle de temps donné et les enregistre en vue d'une exploitation future Alarm Génère une alarme si une valeur mesurée dépasse un certain seuil Host Contient les mesures concernant chaque équipement découvert sur le réseau HostTopN Ce groupe est utilisé pour générer des rapports décrivant l équipement qui a le plus fort trafic ou le nombre d erreurs pour un intervalle de temps Matrix Enregistre les mesures de trafic et d erreurs entre deux adresses IP Filter Permet de configurer la sonde RMON pour surveiller un paquet spécifique sur le segment réseau Packet Capture Permet d enregistrer un paquet sur le segment réseau Event Contrôle la génération et la notification d événements depuis l équipement administré 1.4 SNMP v2 SNMP v2 introduit deux nouvelles commandes : GetBulkRequest et InformRequest. GetBulkRequest permet d interroger plusieurs champs de données d un agent SNMP, ce qui a pour but d optimiser la bande passante nécessaire à SNMP. InformRequest permet à un logiciel de gestion de transmettre des informations non sollicitées vers un autre logiciel de gestion. 9

10 1.5 SNMP v3 SNMP v3 n apporte pas de modification au protocole lui-même, mis à part l ajout du chiffrement des communications pour apporter une sécurité plus importante. Par contre, les développeurs ont complètement révisé les concepts et l architecture logique du protocole. Ainsi, la terminologie a particulièrement évoluée et permet maintenant une définition plus précise de l implémentation de SNMP. Les notions d agent et de manager (Network Management Station, NMS) sont abandonnées et deviennent des entités SNMP (SNMP entities). Chaque entité est constituée d un moteur SNMP et d une, ou plusieurs, applications SNMP. Les nouveaux concepts définissent une architecture, et non simplement la description des messages. Le but est de permettre une implémentation plus sécurisée. Le moteur SNMP est composé de quatre sous-ensembles : Le «Dispatcher» dont le rôle est la réception et l envoi de message, les messages peuvent être dans différentes versions (v1, v2 ou v3). Le «Message Processing Subsystem» prépare le message à envoyer ou extraie les données d un message reçu. Il est constitué de plusieurs modules, un module pour chaque version et d autres modules additionnels. Le «Security Subsystem» fourni le système d authentification et de chiffrement des messages. L authentification utilise les champs communauté (community strings) ou l authentification utilisateur fournie par SNMP v3. Cette authentification est basée sur les algorithmes RD5 ou SHA pour ne pas envoyer les mots de passe en clair. Le chiffrement des messages est assuré par l algorithme DES. Le «Access, Control Subsystem» est responsable du contrôle d accès aux MIB. Avec ce sous-ensemble, il est possible de limiter les accès ; par exemple en écriture aux champs de la MIB 2 et seulement en lecture aux champs des autres MIB. La version 3 a repensé la plupart des applications SNMP disponibles en les regroupant sous de nouveaux concepts : Générateur de commandes (Command Generator): Cette application génère les requêtes get, get-next, get-bulk et set et traite les réponses. Cette application est implémentée sur la station de gestion réseau pour interroger et paramétrer les entités comme les routeurs, les commutateurs, etc. Receveur de commande (Commande Responder) : Cette application répond aux requêtes get, get-next, get-bulk, et set (Pour les entités en SNMP version 1 et 2, c est l agent SNMP qui répond à ces requêtes). Générateur de notifications (Notification Originator) : Cette application est responsable de la génération des traps SNMP et de la notification. Receveur de notifications (Notification Receiver) : Cette application reçoit les traps et les messages d information émis par les équipements. Relais Proxy (Proxy Forwarder) : Cette application facilite le passage de messages entre les entités 10

11 2 La gestion des Systèmes d Information Les systèmes d'information (S.I.) des entreprises sont devenus au cours des dernières décennies un élément stratégique dans le fonctionnement des entreprises. Les systèmes d Information sont ainsi de plus en plus développés, offrant de plus en plus de services et de fonctionnalités. Leurs périmètres se sont fortement étendus tant en termes de fonctionnalités qu en termes de services, ce qui a entraîné l augmentation du nombre de serveurs, d équipements et d applications. Aujourd'hui C o t De plus, l entreprise est devenue une entité de plus en plus complexe, au cœur d échanges de plus en plus vastes et nombreux dont l environnement économique est en perpétuelle évolution. En conséquence, l augmentation des responsabilités des collaborateurs d une entreprise, les S.I. sont de plus en plus sollicités par les utilisateurs des infrastructures en place, et ce à tous les niveaux de l entreprise. Ainsi les S.I. se doivent de fournir une continuité de services qui, si elle n'est pas assurée, perturbe fortement l'activité des entreprises. Le développement exponentiel des architectures de S.I. rend extrêmement difficile la gestion des infrastructures. Rares sont les services ayant une visibilité englobant la totalité des architectures en place. Il est devenu très difficile dans des systèmes tentaculaires de déterminer la cause d'un dysfonctionnement, ou d une perturbation sans une organisation adaptée et des outils dédiés. 11

12 Dans ce contexte, la mise en place des solutions dites de gestion (ou management en anglais), qui permettent via l'utilisation d'un seul ou plusieurs outils d'avoir une vision globale de la performance des architectures en place, est devenue indispensable pour les gestionnaires de Systèmes d'information. 3 Les fonctions de gestion L ISO a défini dans «OSI System Management Overview [ISO-10040]» cinq domaines fonctionnels : Gestion de la configuration (Configuration Management) Gestion de la sécurité (Security Management) Gestion des pannes (Fault management ou Availability Management) Gestion et audit de la performance (Performance Mangement) Gestion de la comptabilité (Accounting Managenent) 3.1 La gestion de la configuration La gestion de la configuration permet l inventaire des ressources nécessaires à l initialisation et au lancement de l infrastructure du Système d Information, la gestion des noms et des caractéristiques des éléments et la gestion des évolutions et des modifications. La gestion de la configuration d une infrastructure est réalisée à l aide des procédures suivantes : Collecter les informations sur l état et les propriétés précises du système, Contrôler l état et les propriétés du système, Sauvegarder cet état et ces propriétés en établissant un historique, Présenter l état du système. 3.2 La gestion de la sécurité La gestion de la sécurité doit permettre à travers une politique de sécurité de se prémunir contre les menaces potentielles. Les infractions sur un système peuvent être soit accidentelles, soit délibérées. Dans le premier cas, elles sont essentiellement dues à des erreurs lors de la configuration du système ou à un disfonctionnement du système. Dans le second cas, elles démontrent un certain savoir afin de passer outre les protections du système. 12

13 3.3 La gestion des pannes ( Fault Management ou Availability Management) Le fonctionnement anormal d un système est la conséquence de deux types de défauts : Les défauts internes résultent d un élément en panne, l utilisation de cet élément provoque l anomalie de manière manifeste. Les défauts externes dépendent de l environnement du système ou d un contexte particulier qui les fait apparaître. Ce contexte pouvant être le résultat de plusieurs facteurs, ils sont difficilement détectables par la seule analyse de l état des constituants du système. Le traitement des pannes est réalisé en quatre étapes : La signalisation et la détection d un fonctionnement anormal, La qualification et la localisation, La réparation, La confirmation du retour au fonctionnement normal. 3.4 L audit de performance (Performance Management) L audit de performance permet d évaluer les performances du Système d Information et l efficacité de ses éléments constitutifs. L audit fait intervenir en premier lieu la collecte d informations d un ensemble de compteurs et de temporisateurs (timers). Les compteurs reflètent les mesures observées du Système d Information (temps de réponse, nombre de connexions, mémoire utilisée, ). A ces mesures sont associés des temporisateurs qui servent à dater les informations des compteurs. Dans un deuxième temps les informations issues des compteurs sont stockées dans des fichiers ou dans une base de données. Enfin, ces statistiques sont analysées pour être présentées sous une forme facilement exploitable. 3.5 La gestion de la comptabilité ( Accounting Management) La gestion de la comptabilité a pour but de relever les informations permettant d évaluer les coûts du Système d Information. La gestion de la comptabilité est principalement présente au niveau des couches infrastructures du SI, car elle permet de calculer le coût réel des frais de communication de l entreprise et de mettre en vis à vis les résultats obtenus avec les contrats établis avec les fournisseurs. On le voit, la gestion du SI regroupe de nombreux aspects. De plus, la démarche ITIL conforte ce regroupement de fonctions. La démarche ITIL étant de plus en plus utilisée dans les entreprises, les solutions du marché tendent à répondre à tous les besoins posés par cette démarche. Nous allons nous intéresser plus spécifiquement à la gestion des pannes et à la gestion de la performance car il s agit des deux problématiques traitées par les logiciels de supervision. Les 13

14 autres problématiques, bien que traitées par les logiciels de «gestion» propriétaires, sont assez différentes en réalité et ne seront donc pas traitées dans ce document. 14

15 Les applications de la supervision en entreprise : Mise en œuvre des fonctions essentielles 15

16 4 Impacts organisationnels et fonctionnalités La plupart des solutions de supervision reposent sur une même organisation type. Quelques nuances peuvent être observées mais généralement l organisation type est plus ou moins respectée. La gestion technique du SI au sein de l entreprise est organisée autour de trois groupes d acteurs : Le HelpDesk ou centre de support. Ces acteurs ont des profils peu techniques, on parle de support niveau 1, dont le rôle est de gérer la relation avec les clients du SI (informer l utilisateur et gérer le suivi des incidents), de réaliser un premier diagnostique, résoudre les incidents simples, et remonter les incidents non résolus vers les administrateurs ou le support de niveau 2. Les Administrateurs, ou centre de support niveau 2, sont responsables de la bonne marche du SI par leurs actions et leurs compétences techniques. Ils sont sollicités par le support de niveau 1 pour entreprendre les actions permettant la résolution des incidents. Parfois, dans des organisations importantes, ils peuvent escalader à leur tour sur des experts techniques ayant des compétences plus spécifiques à un domaine technique ou pouvant modifier l architecture du SI les Responsable du SI, ou Manager, sont responsables de délivrer le service dont ils ont la charge (Réseaux, base de données, etc..) aux clients du SI, ainsi que les informations et les indicateurs pour la consolidation de tableaux de bord destinés aux clients du SI permettant la gestion et le suivi des contrats de services. La solution de supervision est destinée à ces trois acteurs. 16

17 Pour le support de niveau 1, elle s interface avec la solution de HelpDesk, permettant ainsi d informer le centre de support de la survenance d une défaillance, voire même l ouverture automatique d un incident. Le HelpDesk dispose ainsi d une vision de l état de fonctionnement du SI, permettant de donner un diagnostique plus rapide, d affecter les bonnes priorités aux incidents et d escalader les incidents dans les cas uniquement nécessaires ; en résumé une activité plus efficace et une communication claire et maîtrisée aux utilisateurs. Pour les Administrateurs, elle informe et alerte des défaillances, permettant une réactivité plus importante des actions de résolution, fournit des informations d aide au diagnostique, et permet la validation d un retour au fonctionnement normal. Elle peut également permettre une meilleure organisation par la validation de prise en charge des défaillances et d informer les différentes équipes à travers un cahier de consignes. Pour les Responsables, la solution de supervision est une source d indicateurs et de statistiques permettant la création de vue métier, de rapport et de tableaux de bord destinés aux clients du SI comme les Responsables «Métier» et les Chefs de Projet. Ces éléments permettent également la vérification du bon respect des contrats de service par une vision objective et mesurée. 17

18 4.1 Organisation typique 4.2 La couche d administration Une couche de base réalise l interrogation des équipements des réseaux, des systèmes, des SGBD et des applications à l aide des agents SNMP ou d agents propres à la solution de supervision embarquée sur l équipement. Son but est d obtenir les mesures et les indicateurs de base. Le paramétrage des équipements et de leurs mesures peut être facilité par la découverte automatique. Cet outil permet de découvrir les équipements par analyse ou scan du réseau mais également de déterminer les propriétés propres de l équipement (par exemple, le nombre d interfaces d un routeur et leur paramétrage IP). Cette première couche fournit également les informations nécessaires à la solution de gestion de performance qui peut être intégrée ou non à la solution de supervision en fonction de sa richesse fonctionnelle. La collecte de ces informations peut être réalisée au moyen de deux démarches : La démarche exhaustive qui consiste à la collecte des informations nécessaires pour chaque constituant du SI, 18

19 La démarche «bout en bout» ou «ping logiciel». L approche «bout en bout» propose de collecter les informations par la simulation des actions d un utilisateur utilisant une application. Son intérêt est d analyser les interactions des éléments utilisés par l application (analyse systémique) et d observer le comportement d une application de la manière la plus proche possible de celle de l utilisateur. 19

20 Les deux démarches sont en pratique assez complémentaires car les informations acquises en utilisant l un ou l autre sont différentes et possèdent leurs intérêts propres. Ainsi, les informations fournies par la démarche exhaustive permettent une vision détaillée de l état de fonctionnement du SI, mais peu d éléments de mesure sur le fonctionnement observé par les utilisateurs. A l inverse, les informations de la démarche «bout en bout» fournissent une visibilité proche de celle de l utilisateur mais des informations moins détaillées, du moins sans l utilisation d agents destinés à cette démarche sur chacun des éléments du SI et une grande fidélité de reproduction du comportement de l utilisateur. Cette démarche est généralement plus complexe dans son implémentation. 4.3 Filtrage et communication Ensuite une deuxième couche réalise le filtrage des informations obtenues afin de ne remonter que les informations pertinentes. Le filtrage est réalisé soit sur l agent SNMP ou par l agent propre à la solution, ce qui permet de diminuer le trafic réseau par le logiciel de supervision lui-même. Le filtrage est basé sur le paramétrage des seuils et la présence ou non d indicateurs. Les informations filtrées sont envoyées aux gestionnaires qui traduisent les informations transmises par les agents vers l application de supervision. Parfois, l utilisation d éléments applicatifs intermédiaires peut être nécessaire (greffons ou plugins). Il peut être l œuvre d un développement spécifique d une personne ou organisation tierce afin de gérer une application ou un équipement non pris en charge dans la version standard de la solution de supervision. 4.4 Moteur de corrélation La supervision, en fonction des événements reçus, réalise leur corrélation grâce à des fonctions logiques, par l analyse et la déduction logique. L objectif du moteur de corrélation est d obtenir l événement pertinent parmi l ensemble des événements présents. Ainsi, par exemple, si un routeur devient inaccessible pour une raison quelconque, il n est pas souhaitable d alarmer et de traiter les événements consécutifs, comme la perte du réseau sous-jacent et des éléments le constituant, mais d alarmer uniquement à propos de l événement déclencheur. Le bon fonctionnement du moteur de corrélation, ainsi que sa véracité, est très fortement déterminé par son implémentation et son paramétrage, ce qui peut se révéler très complexe dans le cas de SI étendus. 4.5 Notification et supervision pro active Après corrélation, l application de supervision peut réaliser deux actions : La notification de l événement, par l envoi d un popup, d un mail, d un mini-message ou de tout autre moyen de communication. Le but est de prévenir les personnes compétentes et responsables de la découverte d une défaillance. 20

21 La notification doit également prévenir le centre d appel (Help Desk) de la découverte d une défaillance. La notification peut-être réalisée, à travers un connecteur, directement dans l outil de HelpDesk. L exécution automatique de commandes sur des éléments du SI a pour but de corriger la défaillance ou d en réduire l impact. On peut par exemple imaginer le déclenchement de la procédure d arrêt du serveur en cas de perte de son alimentation ou, autre exemple, la relance d un service dans le cas ou il viendrait à s arrêter. 4.6 Le bac à événement Les événements sont stockés et historisés dans un bac à événements ou Repository. L objectif est de connaître l état actuel des constituants du SI, mais également leur état à une date antérieure, et ainsi constituer des éléments de rapport de disponibilité. 4.7 Consoles La ou les consoles sont réalisées par la génération de schémas et de représentations graphiques permettant la visualisation de l état des éléments constitutifs du SI. Les consoles permettent généralement, aussi, l affichage du bac des événements et des alarmes avec des outils de filtrage et de recherche. 4.8 Interface avec les systèmes de gestion de contrat de service (SLA) Les supervisions peuvent offrir des écrans de visualisation orientés «métier» et/ou contrat de service, ou simplement une solution pour obtenir ces informations (connecteurs, accès à une base de données, etc ) en fonction de leur richesse fonctionnelle. 21

22 5 Périmètre technique Serveurs d'applications MQ Series Grands Systèmes Bases de données Internet Internet Serveurs Web LAN Servers Print Servers Clients Partenaires Employés Bases de données Applications, ERP, CRM, Messageries Une solution de supervision doit s adresser à tous les éléments constitutifs du SI de l entreprise. Ainsi, elle doit permettre la supervision des équipements au niveau matériel à travers la vérification d un certain nombre de mesures et d indicateurs. Pour les équipements matériels : La température, La charge du processeur, L utilisation mémoire, Les interfaces et les connecteurs, Les disques durs et la gestion du Raid, Etc. Elle doit permettre également la supervision des systèmes d exploitation : La présence de processus, Les systèmes de fichiers (taille et espace disponible, fréquence d écriture et de lecture, etc.), L audit des fichiers de traces (logs), La gestion des connexions, La gestion du réseau (trafic, temps de réponse...). Etc. 22

23 Elle permet aussi la supervision des applications en fonction de leur nature, par exemple : Présence de l application, Le nombre de connexions répondues par l application, Délai de connexion, Bonne réponse de l application (requête SQL). Etc. Ainsi le périmètre technique des solutions de supervision est très vaste car il doit intégrer la majorité et si possible la totalité des éléments du SI. Pour obtenir ces mesures et indicateurs, les solutions de supervision se basent de manière importante sur le protocole SNMP. Mais elles se basent également sur des agents, surtout pour la supervision système et applicative, ceci pour deux raisons. Premièrement, le protocole n offre un grand nombre de fonctionnalités qu à partir de la version 3 qui n est pas encore un standard. Deuxièmement, le protocole SNMP est difficile à mettre en œuvre. Par exemple, il est beaucoup plus aisé d installer un agent sur un serveur et d effectuer une configuration légère dans le but de vérifier la présence d un fichier par le lancement d une commande. Évidement, l installation d agents sur les plates-formes serveurs pose la problématique du déploiement de ces agents, ce qui n est pas le cas avec SNMP. 23

24 Panorama des solutions Open Source La gestion de performance, La gestion des pannes Les solutions globales. 24

25 Les solutions orientées «gestion de performance» 6 MRTG (Multi Router Traffic Grapher) Référence web : Maturité du logiciel / Historique Tobias Oetiker est l auteur de ce projet Open Source. En 1994, il développe un programme en Perl permettant de visualiser la charge du lien 64K de son lieu de travail vers l Internet à travers une page web et une ou des images. En 1995, il publie un script Perl configurable appelé MRTG-1, après quelques mises à jour et corrections le développement du projet est ralenti par le changement de son employeur et par ses nouvelles fonctions. En 1996, Dave Rand cherche à savoir pourquoi le développement n est pas plus important et propose son aide par la réécriture du script Perl en C ce qui permet des performances 40 fois supérieures, et devient ainsi le cœur de MRTG-2. Une version bêta est donnée à la communauté des utilisateurs qui testent le logiciel et corrigent les bugs. Aujourd hui MRTG est en version , version mise à jour le 5/01/2005. C est un logiciel mature et largement répandu. 25

26 Caractéristiques Diffusion / Nature de la communauté de développements Soutien / Présence dans les distributions Licences Documentation Commentaires La communauté de développeurs est importante, le développement principal est réalisé par Tobias Oetiker et Dave Rand. MRTG n a pas de soutien officiel et il est présent dans la plupart des distributions GNU/Linux MRTG est distribué sous licence GNU GPL MRTG est un projet très bien documenté en anglais et en français, tant sur le site du projet que dans la littérature informatique ou sur d autres sites web. Tableau : MRTG 6.2 Périmètre fonctionnel MRTG permet la représentation à travers de graphiques contenus dans des pages web de différentes mesures réalisées à l aide de SNMP. A la base, il est destiné à la représentation des mesures de trafic sur les interfaces des routeurs mais il est tout à fait possible de l utiliser pour représenter d'autres mesures. MRTG affiche un graphique pour la journée, pour les 7 derniers jours, pour le mois et l année en cours. Il est possible d afficher deux mesures sur un même graphique et MRTG peut réaliser des calculs mais en utilisant deux entiers (pas de calcul sur des nombres flottants). Les informations sont stockées dans des fichiers dont la taille est faible et n évolue que faiblement grâce à un algorithme de consolidation. 6.3 Périmètre technique MRTG est capable de représenter toutes mesures obtenues à l aide de SNMP. Il dépend donc grandement de la disponibilité des fonctionnalités offertes par SNMP sur les équipements à superviser. MRTG supporte les versions 1 et 2 du protocole SNMP. MRTG fonctionne sur les systèmes GNU Linux et sur les plates-formes Microsoft Windows. 26

27 7 RRD Tool (Round Robin Database Tool) Référence web : Maturité du logiciel / Historique RRD Tool est un logiciel mature, actuellement en version La première version est apparue en 1999 (version 1.0.0). RRD Tool est l œuvre de Tobias Oetiker, tout comme MRTG. Caractéristiques Diffusion / Nature de la communauté de développements Soutien / Présence dans les distributions Licences Documentation Commentaires RRD Tool possède une communauté d utilisateurs et de développeurs importante, mais le développement principal est l œuvre de Tobias Oetiker. Le projet RRD Tool est soutenu par le CAIDA, (Cooperative Association for Internet Data Analysis). Ce logiciel est largement répandu dans les distributions GNU Linux. RRD Tool est distribué sous licence GNU GPL La documentation sur ce logiciel est abondante en anglais et en français, que ce soit sur le site officiel, sur d autres sites ou dans la littérature informatique. Tableau : RRD Tools 7.2 Périmètre fonctionnel RRD Tool est à la fois une base de données stockant des mesures et des outils permettant la génération d images graphiques. 27

28 C est une base de données ayant la particularité d avoir une taille fixe déterminée à sa création. En effet, toute nouvelle donnée stockée supprime la plus ancienne d où le terme de «Round Robin». Cette base permet de stocker les mesures obtenues par des scripts ou des développements additionnels (Front End, voir les logiciels suivants). C est également des outils permettant la génération d images graphiques mais ne génèrent pas de pages html. RRD Tool gère plus de deux valeurs et plusieurs sources de données. Il gère également les données non fournies, ainsi si les mesures ne peuvent plus être réalisées pendant un certains laps de temps, cette partie est représentée par exemple en gris sur le graphique. Il est possible de réaliser des calculs sur des nombres flottants. Il est possible d utiliser MRTG avec RRD Tool mais la création des pages html doit alors être prise en charge car elles ne sont pas fournies par le logiciel. 7.3 Périmètre Technique RDD Tool peut être utilisé pour représenter toutes sortes de mesures obtenues à partir de MRTG ou d autres logiciels développés autour de lui. En réalité RRD Tool n est qu une brique de base dans une application de gestion de performance. Mais, elle permet à un grand nombre de solution bâtie autour d elle d exister comme par exemple Cacti, APAN, NetMRG et bien d autres. 28

29 8 CACTI Référence web : Maturité du logiciel / Historique Cacti est un logiciel stable pouvant être utilisé en production. Sa version actuelle est la 0.8.6c datant du 19/12/2004. La première version a été distribuée sous la version 0.5 le 22/09/2001, et le logiciel a connu un développement assez constant depuis. Caractéristiques Diffusion / Nature de la communauté de développements Commentaires La communauté de développement est organisée autour d Andy Blyler, de Ian Berry (responsable du projet) et de Rob Sweet. Soutien / Présence dans les distributions Licences Cacti n a pas le soutien d une entreprise ou d un organisme. Cacti est largement répandu dans les distributions GNU Linux. Cacti est distribué sous GNU GPL Documentation Support La documentation sur ce logiciel est abondante en anglais et en français, que ce soit sur le site officiel, sur d autres sites ou dans la littérature informatique. le site officiel du logiciel offre un forum dans lequel il est possible d exposer ses problèmes et d obtenir une réponse dans la demi-journée, la communauté d utilisateurs est en effet assez importante. Tableau : CACTI 29

30 8.2 Périmètre fonctionnel Cacti est une application développée autour de RRD Tool. Cette application recueille les données à travers des mesures et des indicateurs pour créer des graphiques. Ces données sont stockées dans une base de données (en l occurrence MySQL). Cacti consolide les données dans une base puis les utilise pour créer les graphiques avec RRD Tool. (Figure 1) Il est possible d utiliser plusieurs sources de données, qui peuvent être fournies par des programmes externes (scripts et développements additionnels) ou à l aide du protocole SNMP. Cacti permet la création de graphiques depuis plusieurs sources de données en choisissant les couleurs à associer à chaque source (voir Figure 2). 30

31 Il est possible de choisir et de paramétrer l organisation des graphiques dans les pages de visualisation. Ainsi, la visualisation standard est une succession de graphiques les uns au-dessus des autres (voir les figures 3 et 4). Cependant il possible d organiser celle-ci sous la forme d un arbre pouvant schématiser une organisation technique ou fonctionnelle. On peut par exemple représenter tous les graphiques de tous les équipements par réseaux ou sous réseaux, ou par fonctions, tous les serveurs web, tous les routeurs, etc. (voir figure 1). 31

32 (Figure 3 et 4) 32

33 Cacti a été développé pour gérer des profils d utilisateurs différents. Il est possible de définir pour chaque utilisateur un mot de passe, le comportement de l application lors de la connexion de l utilisateur, et quels graphiques il est autorisé à visualiser (voir Figure 5). L utilisateur peut modifier cette visualisation, l application conservera ses préférences. L utilisateur a également la possibilité de modifier l intervalle de temps ou les dates pour lesquelles il souhaite visualiser les graphiques. (Figure 5) Dans le but de faciliter la mise en place de Cacti dans le cas de SI comprenant un grand nombre d équipements, les développeurs ont été utilisés pour la configuration par «templates» ou modèles. 33

34 Il n est donc pas nécessaire de réaliser la configuration de chaque équipement identique mais de définir la configuration d un équipement représentatif et d utiliser cette configuration pour les autres équipements (voir figure 6). 34

35 8.3 Périmètre technique Cacti repose sur PHP, MySQL, RDD Tool et Net-SNMP. Il peut utiliser Apache ou IIS comme serveur web. Cacti est développé pour plates-formes GNU Linux, BSD, UNIX ou Microsoft Windows. L utilisation en production est conseillée sur plates-formes GNU Linux, UNIX ou BSD. Cacti repose sur le protocole SNMP soit en utilisant les fonctions SNMP du langage PHP (supportant uniquement le SNMP v1), soit par l utilisation des commandes snmpwalk et snmpget fournies par Net-SNMP (supportant toutes les versions du protocole). L application ne gère, pour l instant, pas encore le protocole SNMP dans sa version 3 de manière officielle. Le périmètre technique de Cacti est donc fortement lié à celui de SNMP. Toutefois, l utilisation de commandes externes au programme permet d obtenir des données complémentaires. Ainsi, Cacti utilise un script pour réaliser un ping vers les machines à gérer, permettant ainsi d obtenir des mesures de disponibilité et temps de réponse. Un certains nombres de scripts externes sont disponibles sur le site du projet, ils permettent d obtenir : La mesure du nombre d utilisateurs d un serveur d authentification Free Radius, Différentes mesures du logiciel BIND utilisées sur un grand nombre de serveurs DNS, Des mesures de bande passante à l aide de NetFilter, Des mesures du logiciel Apache, Des mesures de disponibilité et de temps de réponse pour les serveurs web et mail, Des mesures sur le logiciel de supervision Nagios, Des mesures sur l application MySQL, On le voit, Cacti, est facilement adaptable à la plupart des besoins de gestion de performance du point de vue du périmètre technique. Toutefois, du au fait qu il se base de manière importante sur le protocole SNMP, Cacti hérite des problématiques de ce protocole : implémentation difficile dans les environnements fortement cloisonnés par des firewalls, problèmes de sécurité pour le protocole SNMP en version 1 et 2, et dépendances de l implémentation des MIB propriétaires pour certaines informations spécifiques. 35

36 9 NetMRG Référence web : Maturité du logiciel / Historique NetMRG est à l origine, en 1991, le projet scolaire de Brady Alleman. Il est rejoint par Doug Warner, qui travaille pour un fournisseur d accès. Bien qu encore trop immature, il offre des fonctionnalités intéressantes qui le rapprochent d une solution de supervsion. Sa version actuelle est la Caractéristiques Diffusion / Nature de la communauté de développements Commentaires La communauté de développement est constituée de Brady Alleman et de Doug Warner. La communauté d utilisateurs est assez faible. Soutien / Présence dans les distributions Le projet NetMRG n a pas de soutien officiel d entreprise ou organisation. Il est faiblement présent dans les distributions, le site propose des packages pour les distributions Debian, RedHat 9, Fedora 1, 2 et 3. Licences Documentation NetMRG est distribué sous licence MIT La documentation disponible est celle, en anglais, du site officiel. Elle est simple et assez claire. Support Le site officiel dispose d un forum ou il est possible d interroger les développeurs sur un problème ou poser une question technique à la communauté. Tableau : Net MRG Périmètre fonctionnel et technique 36

37 (Figure 1) NetMRG offre un peu moins de fonctionnalités que le logiciel dont il s inspire à savoir Cacti, mais l approche est la même. NetMRG est un front-end développé en PHP reposant sur une base de données pour le stockage et sur les outils RRD Tool pour la création des graphiques. NetMRG se base sur le protocole SNMP pour obtenir les mesures des équipements ou sur l utilisation de scripts externes ou de développements additionnels. Comme Cacti, il offre la possibilité de regrouper les graphiques ce qui est intéressant pour visualiser tous les équipements ayant les mêmes caractéristiques techniques ou simplement pour traduire l organisation du SI. La visualisation utilise une représentation sous forme d arbre (voir figure 2). 37

38 (Figure 2) Tout comme Cacti, le paramétrage est facilité par l utilisation de modèles ou «templates». NetMRG gère également des profils d utilisateurs auxquels il est possible de définir des droits et permissions d'accès. Là ou réside la singularité de NetMRG par rapport à Cacti, est dans l introduction de seuils qui peuvent s affecter à chaque mesure et dont le dépassement déclenche une notification par mail. NetMRG se rapproche donc d une solution de supervision mais ses fonctionnalités sont encore faibles face à des solutions plus complètes comme Nagios ou Zabbix. Toutefois NetMRG peut représenter un bon concurrent de Cacti dans un futur proche. 38

39 Les solutions orientées «gestion de pannes» 10 Big Brother La solution historique : Big Brother Référence web : Pour la version non commerciale : Pour la version commerciale : Maturité du logiciel / Historique Big Brother est une solution mature créé en 1998 par Sean MacGuire. Il s agit à la base d une solution Open Source qui est devenue un produit repris par l éditeur Quest Software. Caractéristiques Diffusion / Nature de la communauté de développements Soutien / Présence dans les distributions Licences Documentation Commentaires Big Brother est distribué par Quest Software, cette société assure maintenant son développement. Un support est disponible auprès de Quest Software. La version destinée à une utilisation non commerciale est parfois disponible dans certaines distributions. La licence de Big Brother est une licence spécifique restreignant son utilisation à un but non commercial, et restreignant également les possibilités de modification du code source mais autorisant sa distribution gratuite. Big Brother est assez bien documenté soit sur son site web (en anglais), soit dans la littérature informatique. 39

40 10.2 Périmètre fonctionnel et technique Big Brother est une solution historique assez connue, d où sa présence dans cet état de l art malgré sa licence actuelle. Big Brother permet la supervision de la disponibilité d un certain nombre d applications et des principaux services réseaux : ftp, http, https, smtp, pop3, dns, telnet, imap, nntp, et ssh. La disponibilité est représentée sous forme de pages web (voir ci-dessus). Pour cela, Big Brother utilise un mode client-serveur : Le serveur réalise des vérifications vers chaque équipement, Un agent peut être installé sur les équipements pour remonter des informations vers le serveur, ceci principalement pour la supervision système. L utilisation d un greffon (plugin) permet l utilisation limitée du protocole SNMP. La détection d une défaillance entraîne la notification par mail ou par SMS si l on dispose d une passerelle d envoi de SMS. Big Brother fonctionne sur plate forme GNU Linux, UNIX et Microsoft Windows. 40

41 11 Big Syster Référence web Maturité du logiciel / Historique Big Sister a été créé par Thomas Aeby en Juillet La version actuelle est la 0.98c8 qui est considérée comme une version stable pouvant être utilisée en production. Le but initial du projet est de réécrire le projet Big Brother en perl pour obtenir de meilleures performances. Par la suite son développeur a apporté un certain nombre de fonctionnalités supplémentaires. Caractéristiques Diffusion / Nature de la communauté de développements Commentaires Le développement est assuré par Thomas Aeby qui a été rejoint par Joseph Gooch, Richard Cross, Derek Douville, Mike Lowe. Big Syster est assez peu présent dans les distributions GNU Linux. Soutien / Présence dans les distributions Un petit nombre de sociétés suisses soutiennent le projet. Licences Big Sister est distribué sous licence GNU GPL Documentation La documentation en anglais du site officiel est faible.. 41

42 11.2 Périmètre fonctionnel et technique Big Sister a pour but de vérifier la disponibilité d applications, de services réseaux, et de réaliser certaines mesures. Pour cela, il est architecturé autour de deux composants : un collecteur et un agent. Le collecteur a pour but de collecter les informations émissent pas les agents installés sur les équipements. Il peut également utiliser le protocole SNMP pour obtenir ces informations. C est également cet élément qui est à l origine de la création des rapports, des pages web et de la notification par mail. 42

43 Les agents déployés sur les serveurs permettent la supervision du système (CPU, système de fichiers, mémoire, etc.). Ils peuvent également réaliser la supervision des équipements environnants dans le cas d une implémentation dans un environnement cloisonné par des firewalls. Les agents permettent la supervision des applications et des éléments des systèmes d exploitation suivants: oracle: Test Oracle database, tripwire: Test de consistance Tripwire system, bbscript: Pour exploiter les agents de Big Brother (cf. : Big Brother), cpuload: Charge CPU (uptime), eventlog: Monitoring NT EventLog, logfile: Vérification générique pour fichiers de log, procs: Vérification des processus courants, ping: Vérifie la présence d'un hôte, fs: Test d utilisation du système de fichiers, rpc_ping: Test de réponse aux requêtes RPC, tcp: generic TCP monitor, syslog: Test des fichiers de log system, OV: HP Openview trap monitor, dns: Check DNS servers, radius: Radius, http/realhttp: Web Server... Big Sister permet de visualiser le bac à événements sous la forme d un historique. 43

44 Il offre également la possibilité d avoir une vue synthétique des éléments supervisés par équipements. 44

45 Et de visualiser les détails par serveurs. 45

46 12 NAGIOS Le leader : Nagios Référence web : Maturité du logiciel / Historique Le projet est apparu sous le nom de NetSaint, puis en 2002 il devient Nagios. Il s agit d une solution mature, largement utilisée. Sa version actuelle est la 1.2 et date du 02/02/2004. Caractéristiques Diffusion / Nature de la communauté de développements Soutien / Présence dans les distributions Licences Documentation Support Commentaires Nagios est largement répandu, il possède ainsi une communauté de développeurs importante. Cependant le cœur du logiciel est l œuvre de Ethan Galstad qui assure la quasi-totalité de son développement. Il est possible d obtenir un support technique auprès de plusieurs sociétés que ce soit en France, en Europe ou aux Etats-Unis. Nagios est présent dans la plupart des distributions GNU Linux. Nagios est distribué sous licence GNU GPL Nagios possède une documentation importante que ce soit sur le site officiel, sur d autres sites ou dans la littérature informatique. le site officiel du logiciel offre un forum dans lequel il est possible d exposer ses problèmes et d obtenir une réponse dans la demi-journée, la communauté d utilisateurs est en effet assez importante. 46

47 12.2 Architecture de Nagios Nagios est architecturé autour de trois éléments : 1. Un ordonnanceur qui organise et traite l exécution des vérifications. Il détermine en fonction des réponses qu'il obtient les actions à entreprendre : génération d événements, notification, escalade, modification de l affichage de la console, actions pro-actives, 2. D une console web qui permet la visualisation de l état de fonctionnement du SI, 3. De greffons ou plugins qui réalisent les vérifications de disponibilité des équipements, des services et des applications en local ou sur des équipements ou services distants. 47

48 Principe de fonctionnement des greffons ou «plugin» Les différentes vérifications possibles sont donc fonction des greffons disponibles. Nagios en fournis certains en standard mais la communauté en a développé un grand nombre. De plus, il est très facile de développer un plugin pour un besoin spécifique. Un greffon permettant d interroger les équipements à l aide du protocole SNMP a été développé. Il est donc possible de réaliser en standard la supervision d un grand nombre d équipements d infrastructure. Afin de permettre des vérifications plus avancées des équipements distants, deux agents ont été développés. Ils permettent de réaliser des vérifications sur les systèmes et les applications des équipements sur lesquels ils sont déployés tout en assurant la communication des informations L agent NRPE (Nagios Remote Plugin Executor) Il s agit en fait d un plugin à part entière présent sur le serveur Nagios, mais qui a la particularité de permettre l exécution d un autre plugin (le dæmon nrpe), cette fois-ci, sur la machine distante à superviser. Ce plugin NRPE peut alors exécuter la vérification de paramètre du système sur lequel il est installé en utilisant les plugin «normaux» L agent NSCA (Nagios Service Check Acceptor) La surveillance permise par l utilisation de NRPE est dite active. En effet la vérification est réalisée à l initiative du serveur de supervision Nagios. Une communication est donc établie depuis le serveur Nagios vers l équipement distant ce qui peut nécessiter l ouverture d un port sur les firewalls dans le cas d un environnement cloisonné. Cette exigence est parfois impossible à réaliser dans le cas où tout flux entrant est interdit. Une autre solution envisageable est alors la méthode dite passive. Dans ce cas, ce n est plus la machine Nagios qui est à l origine des vérifications. Un client NSCA (Nagios Service Check Acceptor) est déployé sur chaque équipement distant, cet agent réalise les vérifications suivant son paramétrage puis envoie les résultats au serveur Nagios qui reçoit ces informations à travers un connecteur (daemon) NSCA. 48

49 Cette méthode présente l avantage de ne pas avoir à ouvrir de port sur les firewalls et les flux sortants sont souvent plus facilement acceptés. Principe de fonctionnement des agents NRPE et NSCA 49

50 12.3 Périmètre fonctionnel Gestion réseau Nagios, gère la gestion des réseaux, des systèmes et des applications à l aide de greffons, d agents, du protocole SNMP et de commandes externes. Ceci est la grande force de ce logiciel qui s adapte particulièrement bien aux réseaux des entreprises moyennes et grandes Gestion de l organisation logique de l infrastructure Il est possible de configurer Nagios pour créer une arborescence des équipements à superviser, traduisant ainsi l infrastructure logique du SI. Cette notion permet également d obtenir une cartographie réaliste des équipements. De même, Nagios peut gérer les dépendances entre les équipements ce qui permet de réaliser un premier niveau de corrélation des événements. Ainsi, si un routeur devient défaillant et rend inaccessible tout un sous-réseau, seule une notification concernant la défaillance du routeur sera émisse Notification Comme la plupart des solutions de gestion de pannes, lorsque une défaillance est constatée, un événement est créé. Cet événement peut engendrer une notification. Les notifications peuvent être fonction de l équipement impacté, du type de service impacté ce qui permet d alerter uniquement les équipes responsables du support de ces équipements et services. Nagios permet également d escalader les notifications si aucun retour à la normale n est constaté au bout d un certain temps. Les notifications peuvent être envoyées sous forme de mail ou de SMS. 50

51 Console de supervision La console de supervision permet la visualisation de la disponibilité des équipements (voir figure 1) et de leurs temps de réponse. Figure 1 51

52 Elle permet également de visualiser l état des services (voir figure 2) Figure 2 52

53 Une visualisation synthétique de l état de fonctionnement de l architecture supervisée est offerte (voir figure 3) Figure 3 Il est possible de regrouper les équipements pour traduire une organisation physique ou logique (serveurs web, serveurs de base de données, routeurs, etc ) 53

54 Une visualisation cartographique des équipements est également offerte (voir figure 4) Figure 4 Il est possible de visualiser le bac à événement à l aide de la console web par service et par équipement et les notifications engendrées Reporting La console permet la création de rapport de disponibilité d un équipement (voir figure 5) ou d un service, tout comme le calcul du taux de disponibilité (voir Figure 6) 54

55 Figure 5 Figure 6 55

56 Cependant les fonctionnalités de reporting sont faibles par rapport aux solutions orientées gestion de performance Gestion des utilisateurs Il est possible de restreindre l affichage des informations. Pour cela Nagios utilise l authentification réalisée par l utilisateur pour affecter les droits correspondants. L utilisateur accèdera alors uniquement aux équipements, services, événements pour lesquels il est autorisé. Toutefois la configuration des droits est difficile à implémenter pour un grand nombre de profils utilisateurs Gestion de la configuration C est une des grandes faiblesses de ce logiciel, car sa configuration est uniquement réalisée à travers des fichiers plats. La gestion de la configuration est donc difficile pour des utilisateurs ou des administrateurs peu habitués aux éditeurs de fichiers en ligne de commandes. De plus, dans le cas d une supervision d un grand nombre d équipements, la modification de la configuration peut être ardue si aucune règle de nomenclature n est utilisée. Nagios fonctionne sur plate forme GNU Linux et peut également fonctionner sur plate forme UNIX. 56

57 Les solutions dites «Complètes» 13 OpenNMS Référence web : Maturité du logiciel / Historique Open NMS est au départ un logiciel développé par la société Oculan qui l a donné à la communauté Open Source. Tarus Balog et Ranger Rick décident de maintenir ce logiciel et de continuer son développement dans le but de concurrencer HP Network Node Manager. Ils sont rejoints par un nombre assez important de développeurs, et l employeur de Tarus Balog, Sortova Consulting Group participe au projet. Sortova Consulting Group change de nom en OpenNMS Group. Caractéristiques Diffusion / Nature de la communauté de développements Soutien / Présence dans les distributions Licences Documentation Commentaires La communauté de développement est importante (19 développeurs officiels sur SourceForge), plus un grand nombre de développeurs non officiels. OpenNMS offre des contrats de support, du consulting et de la formation au Etats-Unis. Ce logiciel est soutenu par la sociéte OpenNMS Group. Il est peu présent dans les distributions mais de nombreux packages existent pour la plupart des distributions. OpenNMS est distribué sous licence GNU GPL La documentation est disponible en Anglais sur le site Officiel. 57

58 13.2 Périmètre fonctionnel OpenNMS a pour objectif de réaliser la gestion de la supervision à travers ces deux aspects, la gestion des pannes et la gestion de la performance. Pour cela, OpenNMS dispose de sondes qui simulent la connexion d un utilisateur à un service offert par une application (web, mail, base de données,..) à travers le réseau dans le but de détecter les défaillance et la disponibilité du service. OpenNMS dispose d une collection de moteurs applicatifs permettant d obtenir et de calculer les performances de l application. Le point de vue des développeurs de OpenNMS est de ne pas utiliser d agent à déployer afin de résoudre les problématique de déploiement et de configuration, mais plutôt de vérifier le fonctionnement de l infrastructure du SI en partant des couches applicatives vers les couches réseaux. Leur but est d offrir une visualisation orientée «utilisateur». Il est destiné aux infrastructures client/serveur sur réseaux IP. OpenNMS est développé en langage Java, ce qui lui permet de fonctionner sur un grand nombre de plateforme mais il est principalement destiné aux plateforme GNU Linux. OpenNMS est architecturé autour des éléments suivants : Un système d auto découverte des éléments à superviser, ce qui diminue l effort de configuration. Au lancement de l application, celle-ci teste la présence des équipements (ping) qui ont été définis. Si un équipement répond positivement, alors l application teste la disponibilité des services réseaux qu elle peut superviser et ajoute les services découverts à la base. La manière dont sont supervisés ces services est ensuite entièrement paramétrable à travers des fichiers de 58

59 configuration en XML. La phase d auto découverte est ensuite répétée toutes les 24 heures afin de découvrir de nouveaux services. Un moteur d interrogation adaptatif. Son rôle est de réaliser les différents tests configurés préalablement afin de détecter toutes défaillances. Il a pour rôle également d obtenir les mesures de performance. Si le test d un service est négatif, une défaillance est détectée, et le moteur peut réaliser un test dans un intervalle de temps plus bref que celui par défaut afin de confirmer cette défaillance. A l opposé, si un service n est plus présent depuis un intervalle de temps assez long (ceci est paramétrable), les tests seront espacés pour ne pas surcharger le réseau. Un second moteur d interrogation est présent dont le rôle est plus particulièrement la gestion de la performance. Il est décoléré du moteur d interrogation car il est moins essentiel par rapport à la gestion des pannes traitées par le premier moteur. Ce moteur utilise le protocole SNMP pour obtenir des mesures applicatives, systèmes et réseaux. Les seuils associés aux mesures peuvent être paramétrés en fonction de l équipement, du service, mais également par contrat de service : le seuil est différent pour les serveurs sous contrat «gold» que sous contrat «silver» par exemple. Le moteur de notification permet d alerter par mail ou SMS les personnes nécessaires dans le cas d une défaillance ou d un dépassement de seuil d une mesure. OpenNMS gère les profils utilisateurs, il est donc possible d envoyer un mail à un groupe de personne en fonction de l équipement ou du service impacté. La gestion de l escalade est implémentée. Un bac à événements visualisable à travers l interface web de l application. Il est possible de filtrer les événements (voir figure 2 et 3). Il est également possible d acquitter un événement et d indiquer l heure et la personne réalisant l acquittement (voir figure 4) tout en indiquant une instruction (cahier de consigne). Les événements sont classés suivants 7 états de criticités : Indéterminé, retour à la normal (cleared), Normal, Warning, Minor, Major, Critical. Les événements peuvent être aussi générés à partir de Trap SNMP ou de commandes sur le serveur OpenNMS permettant l interfaçage avec d autre solution de supervision. 59

60 (Figure 2) (Figure 3) 60

61 (Figure 4) OpenNMS gère les profils utilisateurs à travers l authentification de l utilisateur. Il possible de configurer la console pour restreinte l affichages des équipements, des services, des événements, des alertes et des rapports en fonction des droits de l utilisateur. OpenNMS offre de plus la possibilité de générer des rapports : De performance, en fonction des mesure obtenues à l aide du protocole SNMP De disponibilité, en fonction du calcul du taux de service pour un service, pour une catégorie de service ou pour tous les équipements sous forme numérique ou graphique. Les intervalles de temps sont la semaine, le mois, le trimestre et l année. De temps de réponse, en fonction des mesures réalisées par l application sur la journée, la semaine, le mois et l année (voir figure 5). Un rapport personnalisable pouvant reprendre un certain nombre des éléments des autres rapports sur des intervalles de temps paramétrables. 61

62 Figure Périmètre technique OpenNMS repose sur un grand nombre de briques logicielles. Ainsi, il repose en standard sur : Java, la plupart du code de OpenNMS est en Java Tomcat4, afin d exécuter les servlets Java nécessaires à la console web RRD Tool, pour l enregistrement des mesures et la génération des graphiques PostgreSQL, comme Back-end pour la gestion des événements et de la configuration Metamail pour réaliser l envoi par mail des rapports au format PDF. Son implémentation peut être difficile pour certains, plus habitués à PHP, mais ce peut être à l inverse un avantage pour les moyennes ou grandes entreprises qui dispose plus facilement de développeurs Java. 62

63 OpenNMS permet la supervision des équipements supportant le protocole SNMP. Il permet également la supervision en standard des services suivants : 1. Citrix 2. DHCP 3. DNS 4. Domino IIOP 5. FTP 6. HTTP 7. HTTPS 8. ICMP 9. IMAP 10. LDAP 11. Microsoft Exchange 12. Notes HTTP 13. POP3 14. SMB 15. SMTP 16. TCP Un certain nombre de développements additionnels permet par exemple le support du logiciel Open Source SNORT, servant à la détection d intrusion. On le voit OpenNMS est en solution plutôt destinés aux infrastructures basées sur IP, comme les hébergeurs, les fournisseurs d accès ou les services centraux des entreprises qui ont la charge du support des serveurs web, mails ou DNS. 63

64 14 ZABBIX Référence web : et Maturité du logiciel / Historique Zabbix est projet Open Source assez récent (sa première version stable date de Mars 2004) en raison d une longue phase de bêta-test et de qualification (la toute première version alpha 1 date de 2001). Ce logiciel offre tout de même un grand nombre de fonctionnalités pour une première version, et il est en constant développement (la dernière version, 1.1 alpha 4 date de fin décembre). Caractéristiques Diffusion / Nature de la communauté de développements Soutien / Présence dans les distributions Licences Documentation Commentaires Zabbix est disponible sous forme de sources à compiler, des utilisateurs réalisent des packages pour certaines distributions GNU Linux. Zabbix est un projet dirigé par Alexei Vladishev, qui a développé la majorité du code de l application. Il est aidé par une communauté d une trentaine de développeurs. Un contrat de support est disponible pour les pays Baltes (Estonie, Lettonie et Lituanie). Le site web propose un forum permettant un premier niveau de support par la communauté de développeurs et d utilisateurs. Zabbix est distribué sous licence GNU GPL Le site web officiel du projet propose une documentation claire en anglais. 64

65 14.2 Périmètre fonctionnel Figure 1 Zabbix est une solution de supervision qui intègre à la fois la gestion des pannes et la gestion des performances (il intègre également certaines des notions de tableaux de bord et de suivi de contrat de service, voir figure 2) Pour cela, Zabbix est architecturé autour d un moteur applicatif, développé en C dans le but d obtenir les meilleures performances. Le moteur applicatif confie à une base de données la gestion de la configuration et le stockage des mesures et des données collectées. Les mesures peuvent être réalisées à l aide du protocole SNMP et/ou à l aide d un agent à déployer sur les plates formes à superviser. Les agents peuvent soit être interrogés (pull), soit renvoyer à leur initiative leurs mesures au serveur de supervision (push). Ceci dans le but de permettre de superviser les infrastructures cloisonnées par des firewall. 65

66 Figure 2, la vue orientée métier Gestion des événements Zabbix propose une gestion des événements basée soit sur la présence (ou la non présence) d un indicateur, soit sur le dépassement d un seuil d une mesure, soit sur un ensemble d indicateur et de dépassement de seuil. A un événement on peut attribuer une criticité, Zabbix propose six niveaux critique : Information, warning, average, high, disarter et not classified. A chaque niveau est associée une couleur de visualisation. Zabbix offre un certain niveau de corrélation. Il est possible de générer des événements en fonction de plusieurs critères, Zabbix offrant une grande souplesse à ce niveau. De plus toute la configuration est réalisée à l aide de l interface web. 66

67 Zabbix dispose de fonctions de gestion d événements : (voir Figure 3) Abschange Avg Delta Change Count Date Diff Last Max Min Nodata Now Prev Str Sum Time Retourne la différence absolue entre la dernière et précédente valeur Valeur moyenne pour une période de temps. La période est définie en paramètre en secondes. Ecart entre le maximum et le minimum Retourne la différence entre la dernière et précédente valeur. Nombre de vérifications correctes d une mesure pour une période de temps spécifiée en paramètre. Retourne la date courante sous le format YYYYMMDD Retourne 1 si la dernière et la précédente mesure sont différentes. Retourne la dernière mesure Retourne la mesure maximale pour une période de temps spécifiée en paramètre Retourne la mesure minimale pour une période de temps spécifiée en paramètre Retourne 1 si aucune mesure n est réalisée pour une période de temps spécifiée en paramètre Retourne le nombre de seconde depuis le premier Janvier Retourne la mesure précédente. Cherche un champ de caractère dans la dernière mesure réalisée et retourne 1 si le champ est trouvé, sinon 0 Somme des mesures pour une période de temps spécifiée en paramètre Retourne l heure courante 67

68 Et il propose un certain nombre d opérateurs logiques et arithmétiques - Le - arithmétique + Le + arithmétique * Le * arithmétique / Le / arithmétique > Supérieur à < Inférieur à = Egal à # Différent de Ou logique & Et logique A l aide de ces fonctions et opérateur,s il est possible de définir un grand nombre de critères comme par exemple : La charge CPU est trop élevée pour l hôte zabbix.sf.net. {zabbix.sf.net:system[procload].last(0)}>5 La bande passante utilisée par l interface réseau eth0 est supérieure à 100k pendant 5 min pour l hôte zabbix.sf.net : ({zabbix.sf.net:netloadin1[eth0].min(300)})>100k Chaque noeud d un cluster de mail est défaillant : ({smtp1.zabbix.com:check_service[smtp].last(0)}=0)&({smtp2.zabbix.com:check_service[smtp].last(0)}=0) On le voit, ce système est très souple au fonctionnel, et n est limité que par les possibilités techniques de mesure des agents et du protocole SNMP. De plus, il est possible d ajouter un commentaire (cahier de consignes) pour chaque événement, le commentaire apparaîtra sur la console web et sera ajouté à la notification. 68

69 Gestion des notifications Une fois un événement généré, Zabbix peut notifier les personnes nécessaires par mail et SMS. La notification est paramétrable par profil utilisateur, par équipement et par service Gestion des utilisateurs Zabbix propose la définition de profil utilisateur permettant d affecter des droits de configuration (en lecture, écrit, modification) et visualisation, et du type de notification (voir Figure 3). L ensemble se configure à travers l interface web. La gestion des droits est réalisée à travers l authentification des utilisateurs. 69

70 Figure 4 La console de supervision : La console de supervision permet l affichage des informations concernant : Les mesures et les indicateurs relevés, ainsi que les graphiques associés (voir Figure 5) Le statut des seuils La file d attente des collectes à réaliser Les alarmes en cours et leur historique Les notifications générées (Figure 6) La cartographie des éléments supervisés Les graphiques de performances consolidés (voir figure 7) Il s agit de mesures de performance qui peuvent être consolidés sur un même graphique comme par exemple la bande passante en entrée et en sortie d un serveur ainsi que leurs sommes. La visualisation orientée «métier» La visualisation orientée «Centre de support» Cette visualisation entièrement paramétrable pouvant regrouper des graphiques, des graphiques de performances et des cartographies est destinée à être visualisée sur un grand écran ou projetée (voir Figure 8) 70

71 Figure 5 71

72 Figure 6 72

73 Figure Gestion du reporting : Zabbix offre à travers la console web la possibilité de visualiser des rapports sur la disponibilité de services ou d équipements. (Voir les figure 9 et 10) 73

74 Figure 9 74

75 Figure Périmètre technique : Zabbix est disponible pour les plates formes GNU Linux et UNIX. Il repose sur une base de données SQL et supporte en standard MySQL et PostgreSQL. Il supportera bientôt les bases de données Oracle. Zabbix utilise le protocole SNMP dans ces versions 1, 2 et 3. Il supporte en standard les MIB des équipements suivant : Cisco, Juniper, 3Com, Nortel, Foundry, et les firewalls Netscreen, Fortinet, Cisco ou Checkpoint. De plus l agent de supervision est disponible pour les plates formes GNU Linux, UNIX et Windows. La liste des mesures possibles est très importante. Elle est disponible à l adresse web suivante 75

76 Si toutefois, une mesure ne serait pas disponible en standard, il est parfaitement possible de réaliser une commande externe collectant l information désirée puis de renvoyer celle-ci à l agent pour sa prise en charge par la supervision. Ceci est documenté sur le site officiel qui fournit également des exemples. Il est possible de configurer le port d écoute des agents ainsi que leur mode de fonctionnement à savoir en réception ou en émission (pull / push). Il également possible de restreindre l accès aux agents en spécifiant l adresse du serveur de supervision. L architecture et la disponibilité d agent pour la plupart des plates formes systèmes permettent à Zabbix de facilement s implémenter dans une infrastructure de SI complexe, étendue et cloisonnée. 76

77 Conclusion La Gestion des Système d Information est devenue, de part l importance croissante du SI dans les entreprises, un besoin stratégique pour les responsables des infrastructures en place. Ceci devant offrir un niveau de service de plus en plus élevé avec des investissements moins importants, la supervision permet de répondre à une partie de cette problématique par l optimisation des ressources. Elle permet également d offrir dans le cas de défaillances une communication claire et maîtrisée des centres de supports. Ainsi qu une aide précieuse dans la résolution des incidents. Pour les managers, la gestion du SI doit leur permettre d offrir des outils de pilotage afin d avoir une vision globale et détaillée de la qualité de service. Cependant, la gestion des Systèmes d Information se heurte à la grande diversité de nature et de fonctionnement des éléments qui le constituent. Et malgré les efforts des organismes de normalisation tels que ISO ou IETF, il existe toujours de nombreuses problématiques rendant difficile l implémentation des solutions techniques. Aujourd hui, un nombre important d entreprises ne possède pas de telles solutions en raison des prix des solutions propriétaires et de leurs coûts induits. De plus il arrive que celles-ci ne supervisent pas l ensemble du SI, mais privilégient les éléments névralgiques. C est dans cette optique, que les solutions de supervision Open Source peuvent offrir aux entreprises une réponse pertinente. Elles permettent de répondre à la problématique de la gestion de performance avec des solutions particulièrement abouties comme Cacti, à la gestion des pannes avec des outils tels que Nagios ou à l ensemble comme le réalisent les solutions Zabbix et OpenNMS. Il est vrai que leurs périmètres techniques et fonctionnels ne sont pas aussi étendus que ceux des solutions propriétaires. Mais par leur nature, les projets Open Source peuvent aisément être enrichis, le coût de développement additionnel restant de toute façon bien plus faible que l implémentation d une solution propriétaire. La supervision Open Source est une réelle zone d opportunité pour les entreprises. 77