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