FR 2844368 A1 20040312 FR 0211230 A 20020911 L'invention concerne les moyens qui permettent de superviser les équipements de réseaux IP (Internet Protocol), notamment par le protocole SNMP (Simple Network Management Protocol). Ces moyens traitent typiquement, au sens analyse et classement, des événements envoyés par les équipements. Les événements (appelés aussi traps SNMP) sont des informations remontées sur l'initiative des équipements. Ces informations permettent de connaître à chaque instant l'état dans lequel se trouve l'équipement (supervision temps réel) : état physique mais également état du service fourni par l'équipement. Les équipements dont il est question ici peuvent être des firewalls (pare-feu), routeurs, concentrateurs VPN, etc., en particulier tout équipement capable de générer des traps SNMP. Parmi tous les événements générés par ces équipements, certains d'entre-eux ne sont pas exploitables par les moyens logiques de supervision connus. En effet, les moyens de supervision existants ne savent qu'afficher et trier les traps SNMP en ne prenant en compte qu'une partie bien spécifique de ceux-ci. Si les traps SNMP reçus ne sont pas conformes à ce que le logiciel attend, il est impossible de différencier les événements, et par conséquent de déterminer le degré de sévérité de l'évènement et l'action ad hoc que doit effectuer le superviseur. Dans les cas où les traps SNMP générés ne sont donc pas conformes aux attentes des moyens logiques, aucune solution n'a été fournie à ce jour. Le but de l'invention est d'être en mesure de traiter les cas particuliers identifiés plus haut, et ce afin de permettre une supervision plus fine et plus complète des équipements. Ce but est atteint selon l'invention grâce à un dispositif d'indication de l'état physique ou de l'état du service d'au moins un équipement dans un réseau informatique, comprenant une machine de supervision apte à effectuer un classement d'évènements reçus de cet équipement et à diagnostiquer l'état de cet équipement en fonction des événements ainsi classés, cette machine de supervision étant prévue pour effectuer le classement des événements en fonction du contenu d'une partie seulement de chaque évènement reçu, le dispositif étant caractérisé en ce qu'il comprend en outre un dispositif transformateur d'évènements situé entre la machine de supervision et l'équipement, ce dispositif transformateur d'évènements prélevant dans un évènement une donnée qui appartient à une partie autre que celle prise en compte pour le classement par la machine de supervision, puis introduisant cette donnée dans la partie prise en compte, cette donnée introduite formant ainsi une donnée différenciatrice de l'évènement pour son classement. On propose également selon l'invention un procédé de supervision de l'état physique ou de l'état du service d'au moins un équipement dans un réseau informatique, le procédé comprenant une étape consistant à effectuer un classement d'évènements reçus de cet équipement et une étape consistant à diagnostiquer l'état de cet équipement en fonction des événements ainsi classés, dans lequel procédé on effectue ce classement des événements en fonction du contenu d'une partie seulement de chaque évènement reçu, le procédé étant caractérisé en ce qu'il comprend une étape préliminaire au classement, consistant à prélever dans un évènement une donnée qui appartient à une partie différente de celle prise en compte pour le classement, puis introduire cette donnée dans la partie prise en compte pour le classement, cette donnée ainsi introduite formant alors une donnée différenciatrice de l'évènement pour le classement. On propose en outre selon l'invention un module de traitement intermédiaire destiné à agir entre un équipement de réseau informatique et un module de supervision de l'état physique ou de l'état du service de cet équipement, ce module de supervision étant du type effectuant un classement d'évènements reçus de l'équipement et diagnostiquant l'état de cet équipement en fonction des événements ainsi classés, ce module de supervision étant en outre prévu pour effectuer le classement des événements en fonction du contenu d'une partie seulement de chaque évènement reçu, le module de traitement intermédiaire étant caractérisé en ce qu'il prélève, dans un évènement, une donnée qui appartient à une partie différente de celle prise en compte par le module de supervision pour le classement, et en ce qu'il introduit cette donnée dans la partie prise en compte par le module de supervision, cette donnée introduite formant ainsi une donnée différenciatrice de l'évènement pour son classement. D'autres caractéristiques, buts et avantages de l'invention apparaîtront à la lecture de la description détaillée qui va suivre, faite en référence aux figures annexées sur lesquelles : - la figure 1 représente schématiquement un réseau et son dispositif de supervision selon un exemple de réalisation de l'invention ; - la figure 2 représente sous forme de diagramme un procédé selon un exemple de mise en #uvre de l'invention. On suppose, dans le présent exemple de réalisation, qu'une architecture de réseau est constituée d'un concentrateur 100 de réseau d'entreprise (réseau 200) et d'un utilisateur nomade 300 (figure 1). Le concentrateur 100 permet à un ensemble d'utilisateurs nomades tels que l'utilisateur 300 de se connecter via Internet à leur réseau d'entreprise 200, de façon à pouvoir accéder aux informations disponibles sur l'intranet (réseau interne) de l'entreprise (messagerie, Web, etc.,..). La disponibilité de ce service et le bon fonctionnement du concentrateur 100 sont surveillés par une machine de supervision 400. Cette supervision est assurée grâce à des remontées d'événements SNMP du concentrateur vers la machine de supervision 400. Ces événements sont typiquement définis par un identificateur et des arguments. La machine de supervision 400 différencie les événements en utilisant l'identificateur uniquement. Or, il s'avère que le concentrateur 100 génère des évènements SNMP distincts mais possédant un identificateur commun. Dans un dispositif de supervision classique, il ne serait donc pas possible à la machine de supervision de trier, ni d'analyser ces événements. Par exemple, un évènement majeur de type interface réseau hors service (évènement A) n'est pas distingué par le concentrateur 100 d'un évènement normal de type utilisateur nomade X connecté (évènement B). Ce cas précis est celui de la figure 1. Les événements A et B sont tous deux en traits à tirets à la sortie du concentrateur et possèdent le même identificateur, ce qui empêche la machine de supervision de les distinguer. Les identificateurs des événements A et B, qui sont ici des chiffres, ont donc la même valeur en sortie du concentrateur 100. Les événements constitués d'un identificateur et d'arguments, sont aussi les données d'entrée du transformateur d'évènement 500. L'évènement A est le suivant à la sortie du concentrateur 100 : Normal. mar. févr. 12 11 :14:3 VPN Nomade USEI NANTES Received event .1.3.6.1.4.1.3076.1.2.1.1.1.2.0.0(enterprise :1.3.6.1.4.1.3076.1.2.1.1. 2. generic : 6 spécifie : 0), no format in trapd. conf. 2 args : mgmt.mib- 2. system.sysUpTime (Ticks) : 79692 [2] private.enterprises.altigaRoot.altigaGeneric.altigaMib.altigaEvents.alEvents Event. 10.2 (OctetString) : 316 02/12/2002 11.15 :05.140 SEV=3 IP/2 RPT=4 \n IP Interface 1 status changed to Link Down. Dans cet évènement A, les valeurs 1.3.6.1.4.1.3076.1.2.1.1.1.2.0.0 (en gras ci-dessus) constituent l'identificateur. L'évènement B est le suivant à la sortie du concentrateur 100. Normal mar. févr. 12 11:20:4 VPN Nomade USEI NANTES Received Event .1.3.6.1.4.1.3076.1.2.1.1.1.2.0.0 (enterprise : . 1.3.6.1.4.1.30 76. 1.2.1.1.1.2 generic : 6 spécifie : 0), no format in trapd. conf. 2 args : [1]mgmt.mib-2.system.sysUpTime(Ticks) : 117082 [2] private.enterprises.altigaRoot.altigaGeneric.altigaMib.altigaEvents.alEvents Event. 37.79 (OctetString) : 478 02/12/2002 11 :21:18.970 SEV=5 IKE/79 RPT=1 193. 250.38.216 \nGroup [VPNC~Base~Group] Validation of certificate successful\n(CN=cazenave, SN=6105157B000000000013). Dans cet évènement B, les valeurs 1.3.6.1.4.1.3076.1.2.1.1.1.2.0.0 constituent l'identificateur également en sortie du concentrateur 100, les événements A et B ont donc le même identificateur. S'ils étaient acheminés tels quels jusqu'à la machine de supervision 400, il ne serait pas possible d'exploiter ces événements. Grâce à un transformateur d'événement 500 placé entre le concentrateur 100 et la machine de supervision 400, ces événements sont interprétés et recréés avant d'être transmis à la machine de supervision 400. Voici le détail précis du traitement des données réalisé ici par le transformateur d'événement 500. Le transformateur d'évènement 500 va parcourir tous les arguments de l'évènement jusqu'à trouver l'information utile qui permettra de distinguer cet évènement précis d'un autre évènement. Cette information est une donnée unique pour un évènement donné. Les informations utiles sont la donnée 10. 2 pour l'évènement A et la donnée 37. 79 pour l'évènement B. Nous appellerons dans la suite cette donnée donnée utile . A partir de cette donnée utile, le transformateur d'évènement 500 créé un nouvel évènement dont l'identificateur contient la donnée utile comme donnée différenciatrice. Les arguments de ce nouvel évènement restent quant à eux inchangés par rapport aux données d'entrée. L'algorithme de ce traitement est schématisé à la figure 2. Dans la variante illustrée, le transformateur 500 réalise ici une fonction de recherche d'une information différenciant l'évènement considéré. Le transformateur y est donc programmé pour identifier lui-même un emplacement susceptible de contenir une telle donnée spécifique. Cette fonction est par exemple mise en #uvre par comparaison systématique des arguments des deux événements à différencier afin d'aboutir sur le premier de ces arguments à être différent selon l'évènement considéré. Dans une variante, le transformateur d'événement 500 est programmé pour prélever la donnée différenciatrice ou donnée utile à un emplacement prédéterminé. Les événements A et B obtenus ensuite sont alors distincts et symbolisés sur la figure 2 par des traits respectivement continu et à tirets, qui illustrent leur différence. Plus précisément, les événements A et B sont, après transformation, les suivants : Evènement A : normal mar.févr. 12 11 :14:3 VPN~Nomade~USEI~NANTES Received event.1.3.6.1.4.1.3076.10.2 (enterprise : . 1.3.6.1.4.1.3076.10.2. generic : 6 spécifie : 0), no format in trapd conf. 2 args : mgmt.mib-2. system.sysUpTime (Ticks) : 79692 [2] private.enterprises.altigaRoot.altigaGeneric.altigaMib.altigaEvents.alEvents Event. 10.2 (Octet String) : 316 02/12/2002 11. 15 : 05.140 SEV=3 IP/2 RPT =4 \n IP Interface 1 status changed to Link Down L'identificateur de l'évènement A est donc maintenant . 1.3.6.1.4.1.3076.10.2. Evènement B : Normal mar. févr. 12 11:20:4 VPN Nomade USEI NANTES Received event . 1.3.6.1.4.1.3076.37.79 (enterprise :.1.3.6.1.4.1.3076.37.79 generic:6 spécifie:.0), no format in trapd.conf. 2 args : mgmt.mib-2. system.sysUpTime (Ticks) : 117082 [2] private.enterprises.altigaRoot.altigaGeneric.altigaMib.altigaEvents.alEvents Event. 37.79 (OctetString) : 478 02/12/2002 11:21:18.970 SEV-5 IKE/79 RPT=1 193.250.38.216 \ nGroup [VPNC~Base~Group] Validation of certificate successful \n (CN=cazenave, SN=6105157B000000000013). L'identificateur de l'évènement B est donc maintenant : . 1.3.6.1.4.1.3076.37.79 Les identificateurs des événements A et B sont maintenant différents, du fait que l'argument 10.2 de l'évènement A a été introduit dans son identificateur, et que l'évènement 37. 79 de l'évènement B a été introduit dans l'identificateur de cet évènement B. Ces deux arguments respectifs jouent donc maintenant le rôle de donnée différenciatrice dans les identificateurs respectifs de A et B. Ces nouveaux événements sont les résultats de sortie du transformateur d'événement . Les identificateurs de ces évènements sont maintenant différents. Ces résultats peuvent dès lors être transmis à la machine de supervision 400 qui est alors en mesure d'analyser et de classer ces événements. La machine de supervision, le transformateur d'événement et le ou les équipements supervisés sont ici décrits en tant que moyens matériels distincts et séparés physiquement. Bien entendu, les moyens ici exposés, dans leur fonction propre, pourront être mis en #uvre sur la base d'implémentation matérielle différente. Notamment, l'invention vise également le cas où le transformateur d'événement fait partie intégrante de la machine de supervision, ou, à l'inverse, est intégré dans les équipements supervisés. L'homme de l'art, à l'aide de ses connaissances habituelles, pourra mettre, bien entendu, en #uvre d'autres implémentations également couvertes par l'invention. REVENDICATIONS 1. Dispositif d'indication de l'état physique ou de l'état du service d'au moins un équipement (100) dans un réseau informatique, comprenant un module de supervision (400) apte à effectuer un classement d'événements reçus de cet équipement (100) et à diagnostiquer l'état de cet équipement (100) en fonction des événements ainsi classés, ce module de supervision étant prévu pour effectuer le classement des événements en fonction du contenu d'une partie seulement de chaque évènement reçu, le dispositif étant caractérisé en ce qu'il comprend en outre un module transformateur d'évènements (500) agissant entre le module de supervision (400) et l'équipement (100), ce module transformateur d'évènements (500) prélevant dans un évènement une donnée qui appartient à une partie autre que celle prise en compte pour le classement par le module de supervision (400), puis introduisant cette donnée dans la partie prise en compte, cette donnée introduite formant ainsi une donnée différenciatrice de l'évènement pour son classement. 2. Dispositif selon la revendication 1, caractérisé en ce que le module transformateur d'évènement (500) est prévu pour parcourir un évènement dans sa partie non prise en compte par le module de supervision (400), examiner chaque donnée de cette partie jusqu'à identifier une donnée qui est différente de celle ayant la même position dans un évènement précédemment examiné, et introduire cette donnée différente dans la partie de l'évènement qui est prise en compte pour son classement. 3. Dispositif selon la revendication 1, caractérisé en ce que le transformateur d'évènement (500) est programmé pour extraire d'un évènement une donnée à une position fixe et prédéterminée dans sa partie non prise en compte par le module de supervision (400) et est programmé pour ensuite introduire cette donnée dans la partie de cet évènement qui est prise en compte par le module de supervision (400). 4. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il est placé en supervision d'un réseau de type Internet Protocol (ou protocole Internet). 5. Dispositif selon la revendication 4, caractérisé en ce que les événements sont des événements de type SNMP (Simple Network Management Protocol), la partie prise en compte par le module de supervision (400) étant l'identificateur de l'évènement, les données introduites dans l'identificateur par le module transformateur d'événements (500) étant constituées de données prélevées parmi les arguments de l'évènement considéré. 6. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que le module transformateur d'évènements (500) est programmé pour extraire et replacer une donnée qui présente des valeurs différentes en fonction d'alternatives différentes d'un critère de classement mis en oeuvre par le module de supervision (400). 7. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il est placé en supervision d'un concentrateur (100) de réseau local, ce concentrateur (100) remplissant le rôle d'interface entre le réseau internet et ce réseau local (200). 8. Procédé de supervision de l'état physique ou de l'état du service d'au moins un équipement (100) dans un réseau informatique, le procédé comprenant une étape consistant à effectuer un classement d'événements reçus de cet équipement (100) et une étape consistant à diagnostiquer l'état de cet équipement (100) en fonction des événements ainsi classés, dans lequel procédé on effectue ce classement des événements en fonction du contenu d'une partie seulement de chaque évènement reçu, le procédé étant caractérisé en ce qu'il comprend une étape préliminaire au classement, consistant à prélever dans un évènement une donnée qui appartient à une partie différente de celle prise en compte pour le classement, puis introduire cette donnée dans la partie prise en compte pour le classement, cette donnée ainsi introduite formant alors une donnée différenciatrice de l'évènement pour le classement. 9. Module de traitement intermédiaire (500) destiné à agir entre un équipement (100) de réseau informatique et un module de supervision (400) de l'état physique ou de l'état du service de cet équipement (100), ce module de supervision (400) étant du type effectuant un classement d'évènements reçus de l'équipement (100) et diagnostiquant l'état de cet équipement (100) en fonction des événements ainsi classés, ce module de supervision (400) étant en outre prévu pour effectuer le classement des événements en fonction du contenu d'une partie seulement de chaque évènement reçu, le module de traitement intermédiaire (500) étant caractérisé en ce qu'il prélève, dans un évènement, une donnée qui appartient à une partie différente de celle prise en compte par le module de supervision (400) pour le classement, et en ce qu'il introduit cette donnée dans la partie prise en compte par le module de supervision (400), cette donnée introduite formant ainsi une donnée différenciatrice de l'évènement pour son classement. 10. Module de traitement intermédiaire (500) selon la revendication 9, caractérisé en ce qu'il est prévu pour le traitement d'évènements de type SNMP (Simple Network Management Protocol) dans un réseau de type IP (Internet Protocol), et en ce qu'il est prévu pour prélever les données différenciatrices parmi les arguments de l'évènement considéré, et les introduire dans l'identificateur de l'évènement considéré.