FR2964280A1

FR2964280A1 - Procede de centralisation d’evenements pour systeme d’information hierarchique multi-niveaux

Info

Publication number: FR2964280A1
Application number: FR1056830A
Authority: FR
Inventors: Manuel Henry; Valerian Rossigneux
Original assignee: EADS Defence and Security Systems SA
Current assignee: Airbus DS SAS
Priority date: 2010-08-27
Filing date: 2010-08-27
Publication date: 2012-03-02
Anticipated expiration: 2030-08-27
Also published as: BR112013004618A2; US20130160030A1; CN103109498A; WO2012025631A1; EP2609715B1; EP2609715A1; CN103109498B; US9747142B2; FR2964280B1

Abstract

La présente invention concerne un procédé de centralisation d'événements pour un système d'information hiérarchique multi-niveaux, ledit système comprenant une pluralité d'équipements sources générateurs d'événements et une pluralité de collecteurs d'événements par niveau, ledit procédé comportant les étapes de : - sélectionner par un collecteur d'un niveau supérieur un collecteur d'un niveau inférieur en fonction de paramètres opérationnels et/ou d'une qualité de lien de service dudit collecteur de niveau inférieur ; - recevoir par ledit collecteur les événements dudit collecteur de niveau inférieur sélectionné ; - vérifier périodiquement si le collecteur sélectionné est disponible et dans la négative de réitérer l'étape de sélection ; et - comparer par ledit collecteur de niveau supérieur ses événements avec ceux des collecteurs de niveau inférieur non sélectionnés et recevoir d'un de ces collecteurs de niveau inférieur non sélectionnés les événements qui sont différents.

Description

PROCEDE DE CENTRALISATION D'EVENEMENTS POUR SYSTEME D'INFORMATION HIERARCHIQUE MULTI-NIVEAUX

DOMAINE TECHNIQUE DE L'INVENTION La présente invention concerne un procédé de centralisation d'événements pour un système hiérarchique multi-niveaux. L'invention concerne également un système hiérarchique multi-niveaux permettant de mettre en oeuvre ledit procédé.

Elle trouve une application particulière dans le domaine des centres de gestion de réseaux informatiques qui gèrent une pluralité de sites. ARRIÈRE-PLAN TECHNOLOGIQUE DE L'INVENTION Dans le domaine des centres de gestion de réseaux informatiques, un état de la technique connu de procédé de centralisation d'événements pour un système hiérarchique multi-niveaux comprend les étapes d'enregistrer les événements de chaque équipement source dans un premier collecteur d'événements. Si ce premier collecteur tombe en panne, alors un deuxième collecteur est mis en route manuellement par un opérateur pour enregistrer les événements à la place du premier collecteur qui est tombé en panne.

Un inconvénient de cet état de la technique est qu'il existe un temps de latence entre le temps où la panne du premier collecteur est détectée et le temps de mise en place du deuxième collecteur. Aussi, des événements sont perdus pendant ce temps de latence. Par ailleurs, la mise en place manuelle de ce deuxième collecteur est lourde à gérer.

DESCRIPTION GENERALE DE L'INVENTION La présente invention a pour but de définir un procédé de centralisation de journaux d'événements pour un système hiérarchique multiniveaux, qui permette de résoudre les problèmes posés ci-dessus.30 Ce but est atteint par un procédé de centralisation d'événements pour un système d'information hiérarchique multi-niveaux, ledit système comprenant une pluralité d'équipements sources générateurs d'événements et une pluralité de collecteurs d'événements par niveau, ledit procédé comportant les étapes de : - sélectionner par un collecteur d'un niveau supérieur un collecteur d'un niveau inférieur en fonction de paramètres opérationnels et/ou d'une qualité de lien de service dudit collecteur de niveau inférieur ; - recevoir par ledit collecteur les événements dudit collecteur de niveau inférieur sélectionné ; - vérifier périodiquement si le collecteur de niveau inférieur sélectionné est disponible et dans la négative réitérer l'étape de sélection ; et - comparer par ledit collecteur de niveau supérieur ses événements avec ceux des collecteurs de niveau inférieur non sélectionnés et recevoir d'un de ces collecteurs de niveau inférieur non sélectionnés les événements qui sont différents. Comme on va le voir en détail par la suite, la mise en place du procédé automatique qui sélectionne le meilleur collecteur à un instant donné et qui vérifie la concordance entre les événements d'un collecteur de niveau supérieur avec ceux de niveau inférieur permet d'être certain de centraliser l'ensemble des événements au niveau hiérarchique le plus élevé et ce sans intervention manuelle. De plus, le procédé permet une centralisation fiable puisque la centralisation des événements ne s'arrête pas si le collecteur sélectionné devient indisponible.

Selon des modes de réalisation non limitatifs, le procédé peut comporter en outre une ou plusieurs caractéristiques supplémentaires parmi les suivantes : - Le procédé de centralisation comporte une étape supplémentaire d'enregistrer l'ensemble des événements générés par les équipements sources dans les collecteurs de même niveau hiérarchique que les équipements sources. Cela permet à un collecteur de regrouper l'ensemble des événements générés par les équipements sources. - L'étape de comparer les événements du collecteur de niveau supérieur avec ceux des collecteurs de niveau inférieur non sélectionnés est effectuée périodiquement. Si des événements ont été perdus, cela permet d'enclencher une procédure de récupération d'événements et permet ainsi que l'ensemble des événements soit toujours remonté au collecteur supérieur. - L'étape de comparer des événements d'un collecteur de niveau supérieur avec ceux des collecteurs de niveau inférieur non sélectionnés s'effectue en fonction d'une empreinte associée aux événements. Cela permet de différencier les événements des uns des autres et d'identifier de manière unique chaque événement. - L'étape de comparer des événements d'un collecteur de niveau supérieur avec ceux des collecteurs de niveau inférieur non sélectionnés s'effectue en outre en fonction d'une estampille temporelle. Cela permet une classification des événements en fonction de leur date et de l'heure d'apparition et une recherche des événements par date et heure. - Les paramètres opérationnels utilisés à l'étape de sélectionner un collecteur de niveau inférieur, comprennent le nombre d'événements et/ou les capacités matérielles et/ou des paramètres de consommation. Ainsi, on prend en compte les capacités statiques, à savoir physiques du matériel, et les capacités dynamiques (en cours d'utilisation) d'un collecteur. - La sous-étape de recevoir des événements différents est effectuée par exemple selon le protocole de communication TCP/IP. Ce protocole est un protocole qui permet de délivrer les événements de manière fiable. Il vérifie que les paquets de données (événements) sont arrivés à destination, et garantit leur arrivée dans l'ordre. - Le procédé de centralisation comporte en outre une étape initiale de recherche des collecteurs de niveau inférieur par un collecteur de niveau supérieur. Cela permet de connaître l'ensemble des collecteurs de niveau inférieur, et en disposant ainsi d'un critère supplémentaire dans l'étape de sélectionner un collecteur de niveau inférieur, par la suite de sélectionner le meilleur collecteur de niveau inférieur parmi l'ensemble des collecteurs de niveau inférieur. - Le procédé comporte une étape supplémentaire de transmettre par un collecteur des événements qui lui sont propres à tous les autres collecteurs du même niveau hiérarchique. Ainsi, la centralisation des événements porte également sur les événements propres aux collecteurs. - L'étape de transmettre s'effectue par exemple selon le protocole de communication UDP. Ce protocole est simple à mettre en oeuvre.

En outre, il est également proposé un collecteur pour système d'information hiérarchique multi-niveaux, ledit système comprenant une pluralité d'équipements sources générateurs d'événements et une pluralité de collecteurs d'événements par niveau, ledit collecteur étant apte à centraliser des événements générés par des équipements sources dudit système d'information hiérarchique multi-niveaux, ledit système comportant : - des moyens de sélection d'un collecteur d'un niveau inférieur en fonction de paramètres opérationnels et/ou d'une qualité de lien de service dudit collecteur de niveau inférieur ; - des moyens de réception des événements dudit collecteur de niveau inférieur sélectionné ; - des moyens de vérification périodique de la disponibilité du collecteur sélectionné et dans la négative des moyens de réitération de l'étape de sélection ; - des moyens de comparaison de ses événements avec ceux des collecteurs de niveau inférieur non sélectionnés ; et - des moyens de réception d'un de ces collecteurs de niveau inférieur non sélectionnés des événements qui sont différents. Selon un mode de réalisation non limitatif, le collecteur comporte en outre des moyens d'enregistrement de l'ensemble des événements générés par les équipements sources de même niveau hiérarchique. En outre, il est également proposé un système d'information hiérarchique multi-niveaux apte à centraliser des événements générés par des équipements sources, ledit système comprenant une pluralité d'équipements sources générateurs d'événements et une pluralité de collecteurs d'événements par niveau, les collecteurs étant caractérisés selon l'une quelconque des caractéristiques précédentes. En outre, il est également proposé un produit programme d'ordinateur comportant une ou plusieurs séquences d'instructions exécutables par une unité de traitement d'information, l'exécution desdites séquences d'instructions permettant une mise en oeuvre du procédé selon l'une quelconque des caractéristiques précédentes, lorsqu'il est chargé sur un ordinateur.

L'invention et ses différentes applications seront mieux comprises à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent.

BREVE DESCRIPTION DES FIGURES Celles-ci ne sont présentées qu'à titre indicatif et nullement limitatif de l'invention. - La Fig.1 est un schéma simplifié d'un exemple non limitatif d'un système hiérarchique multi-niveaux comprenant une pluralité d'équipements sources générateurs d'événements et une pluralité de collecteurs d'événements, dans lequel le procédé de centralisation selon l'invention est mis en oeuvre ; - La Fig.2 est un organigramme simplifié d'un mode de réalisation non limitatif du procédé de centralisation selon l'invention ; - Les Fig.3, Fig.4, Fig.5, et Fig.6 illustrent schématiquement des étapes de centraliser des événements entre des collecteurs de niveaux différents selon un mode de réalisation non limitatif du procédé de la Fig. 2 - La Fig. 7 est un diagramme des temps qui illustre schématiquement une étape de vérifier la disponibilité d'un collecteur, étape du procédé de centralisation de la Fig. 2 ; et - La Fig. 8 illustre de manière simplifiée un système hiérarchique multiniveaux comprenant un collecteur apte à effectuer les étapes du procédé de centralisation de la Fig. 2.

DESCRIPTION DE MODES DE REALISATION DE L'INVENTION

Le procédé de centralisation d'événements (appelés « Log » en anglais) pour un système d'information hiérarchique multi-niveaux est décrit dans un mode de réalisation non limitatif à la Fig. 2. Il est mis en oeuvre dans un système d'information hiérarchique multiniveaux, ledit système comprenant une pluralité d'équipements sources générateurs d'événements et une pluralité de collecteurs d'événements par niveau.

Par équipement source on entend, tout équipement informatique tel qu'un serveur, un routeur ou un ordinateur personnel dans des exemples non limitatifs. Par événement, on entend tout événement émis par un équipement source S, tels que dans des exemples non limitatifs des événements de sécurité (un utilisateur se connecte à un équipement source, un processus redémarre, un équipement source redémarre, une connexion à des informations sensibles est établie, un changement de statut d'une ressource s'effectue...), ou des événements de débogage, ou encore des événements émis par les collecteurs eux-mêmes. Par disponibilité d'un collecteur, on entend un collecteur qui fonctionne et dont le lien réseau avec un collecteur supérieur n'est pas rompu.

Un exemple non limitatif de système d'information hiérarchique multi-niveaux SYS est illustré à la Fig. 1 de manière schématique. Dans cet exemple, le système d'information SYS est un système de gestion informatique d'un parc d'équipements informatiques au niveau d'une entreprise. Il comprend trois niveaux hiérarchiques : - un premier niveau L1 relatif à un département de l'entreprise ; - un deuxième niveau L2 relatif à un site où sont situés des locaux de l'entreprise ; - un troisième niveau L3 relatif à un pays dans lequel l'entreprise est implantée.

Dans l'exemple non limitatif de la Fig. 1 - le premier niveau L1 comprend des équipements sources S et une pluralité de premiers collecteurs Cl : C1_1 à C1_n. - le deuxième niveau L2 comprend une pluralité de deuxièmes collecteurs C2 : C2 1 à C2 n. - le troisième niveau L3 comprend un troisième collecteur C3 appelé collecteur central.

Le troisième niveau L3 est également appelé niveau supérieur LSUP par rapport au deuxième niveau L2 qui est appelé niveau inférieur par rapport au troisième niveau L3. De la même manière, le deuxième niveau L2 est également appelé niveau supérieur LSUP par rapport au premier niveau L1 qui est appelé niveau inférieur LINF par rapport au deuxième niveau L2.

Ainsi, les premiers collecteurs Cl sont appelés collecteurs de niveau inférieur CINF (ou collecteurs inférieurs) par rapport aux deuxièmes collecteurs C2. Ces deuxièmes collecteurs C2 sont appelés collecteurs de niveau supérieur CSUP (ou collecteurs supérieurs) par rapport aux collecteurs Cl, mais sont appelés collecteurs de niveau inférieur CINF par rapport au troisième collecteur C3. Ce dernier est appelé collecteur de niveau supérieur CSUP (ou collecteur supérieur) par rapport aux deuxièmes collecteurs C2. On notera que dans un système hiérarchique multi-niveaux, un collecteur de niveau supérieur connaît uniquement les collecteurs du niveau qui lui sont directement inférieurs. Ainsi, le collecteur C3 a connaissance uniquement des collecteurs C2. Il ne connaît pas (et n'a donc pas accès directement) aux collecteurs C1.

Dans un mode de réalisation non limitatif, le procédé de centralisation d'événements pour un système d'information hiérarchique multi-niveaux SYS comporte les étapes de (telles qu'illustrées à la Fig. 2): - sélectionner par un collecteur CSUP d'un niveau supérieur LSUP un collecteur CINF d'un niveau inférieur LINF en fonction de paramètres opérationnels POP et/ou d'une qualité de lien de service NTWL dudit collecteur CINF de niveau inférieur LINF (étape SELECT CINF(POP(NB, HDW, CONS), NTWL)) ; - recevoir par ledit collecteur CSUP les événements dudit collecteur de niveau inférieur sélectionné CINF (étape RXs(CINF)) ; - vérifier périodiquement si le collecteur sélectionné CINF est disponible et dans la négative réitérer l'étape de sélection (étape VERIF_DISP(CINF)) ; et - comparer par un collecteur CSUP de niveau supérieur LSUP ses événements E avec ceux des collecteurs de niveau inférieur non sélectionnés CINF (étape COMP(CSUP(E), CINF(E), TMS, HSH) et recevoir d'un de ces collecteurs de niveau inférieur non sélectionnés CINF les événements E qui sont différents (étape RXd(CINF)). Dans un mode de réalisation non limitatif, le procédé de centralisation d'événements E comporte en outre une étape initiale de recherche des collecteurs CINF de niveau inférieur LINF par un collecteur CSUP de niveau supérieur LSUP (étape FND(CINF)). Dans un mode de réalisation non limitatif, le procédé de centralisation d'événements E comporte une étape supplémentaire d'enregistrer l'ensemble des événements E générés par les équipements sources S dans les collecteurs C de même niveau hiérarchique que les équipements sources S (étape COLLECT_E(S, C)). Dans un mode de réalisation non limitatif, l'étape de comparer les événements du collecteur de niveau supérieur avec ceux des collecteurs de niveau inférieur non sélectionnés est effectuée périodiquement. Pour la suite de la description, dans le mode de réalisation non limitatif du procédé décrit, le procédé comprend cette étape initiale et ces étapes supplémentaires.

30 Ainsi, les étapes du procédé de centralisation d'événements sont décrites en détail ci-après en se référant aux Figs. 1 à 7.

Dans une étape initiale 0) illustrée à la Fig. 2, on recherche des25 collecteurs CINF de niveau inférieur LINF par un collecteur CSUP de niveau supérieur LSUP.

Dans l'exemple non limitatif de la Fig. 1, chaque collecteur de niveau supérieur C2 va rechercher l'ensemble des collecteurs de niveau inférieur Cl. Dans un premier exemple non limitatif, les collecteurs inférieurs Cl sont enregistrés au préalable dans une configuration de chaque collecteur supérieur C2 de sorte que ce dernier connaisse quels sont les collecteurs inférieurs Cl qui appartiennent au niveau inférieur L1. Cette configuration est faite en amont par un administrateur du système d'information SYS qui a les droits pour modifier ladite configuration. Dans un exemple non limitatif, la configuration est effectuée avec les adresses IP des collecteurs C1. Dans un deuxième exemple non limitatif, chaque collecteur C2 de niveau supérieur envoie un message de diffusion (appelé « broadcast message » en anglais) au niveau inférieur L1. Tous les collecteurs de niveau inférieur Cl qui sont disponibles reçoivent ce message de diffusion et envoient une réponse de retour lorsqu'ils reçoivent ledit message de diffusion. Le collecteur C2 reconnaît ainsi quels sont les collecteurs de niveau inférieurs Cl qui appartiennent au niveau inférieur L1. Dans un exemple non limitatif, le protocole UDP (« User Datagram Procotol » en anglais) bien connu de l'homme du métier est utilisé pour l'envoi d'un message de diffusion. Ce protocole est simple à utiliser, ne demande pas de ressources réseaux importantes et permet un envoi rapide de données (ici les messages). Dans un troisième exemple non limitatif, lorsqu'un collecteur Cl de niveau inférieur est installé, il envoie un message de diffusion (appelé « broadcast message » en anglais) à tous les collecteurs C2 de niveau supérieur L2. Tous les collecteurs de niveau supérieur C2 qui sont disponibles envoient une réponse de retour lorsqu'ils reçoivent ledit message de diffusion. Le collecteur Cl reconnaît ainsi quels sont les collecteurs de niveau supérieur C2. Dans un exemple non limitatif, le protocole UDP est utilisé pour l'envoi d'un message de diffusion.

Dans une première étape 1) illustrée à la Fig. 2 et à la Fig. 3, on enregistre l'ensemble des événements E générés par les équipements sources S dans les collecteurs C de même niveau hiérarchique que les équipements sources S.

Dans l'exemple non limitatif du système d'information hiérarchique multi-niveaux SYS de la Fig. 1, cet enregistrement s'effectue au niveau le plus bas, à savoir le premier niveau L1. Bien entendu, dans le cas d'autres exemples où le deuxième niveau L2 et/ou troisième niveau L3 comporteraient également des équipements sources S, cette étape s'appliquerait audit deuxième et/ou troisième niveau.

Dans un premier mode de réalisation non limitatif, l'enregistrement s'effectue à l'initiative des équipements sources S, c'est-à-dire des émetteurs d'un événement E. Ce mode est appelé mode « push » en anglais. Dès qu'un équipement source S émet un événement E, il l'envoie à tous les collecteurs du même niveau hiérarchique que lui. Dans un exemple de réalisation non limitatif, le protocole SYSLOG UDP bien connu de l'homme du métier est utilisé. Dans un deuxième mode de réalisation non limitatif, l'enregistrement s'effectue à l'initiative des collecteurs C c'est-à-dire des récepteurs d'un événement E. Ce mode est appelé mode « pull » en anglais. Dans ce cas, les collecteurs C accèdent à distance (par tout protocole de communication connu de l'homme du métier tel que FTP (« File Transfer Protocol »), ODBC (« Open Database Connectivity ») ou encore WMI (« Windows Management Instrumentation ») dans des exemples non limitatifs) aux équipements sources de même niveau hiérarchique et les collecteurs C recopient les événements en local chez eux. Dans un troisième mode de réalisation non limitatif, l'enregistrement s'effectue au moyen d'un agent déployé dans les équipements sources S.

Cet exemple est intéressant lorsque la fonction d'envoi des événements n'est pas résidente sur les équipements sources. Dans ce cas, un processus local est exécuté par l'agent qui récupère les événements d'un équipement source et les envoie aux collecteurs associés (de même niveau hiérarchique). Dans un exemple de réalisation non limitatif, un protocole de communication chiffré est utilisé tel que le protocole TLS (« Transport Layer Security » en anglais) qui permet de chiffrer les événements avant de les envoyer aux collecteurs C. On notera que dans une étape supplémentaire 1') illustrée à la Fig. 2 et à la Fig. 3, chaque collecteur C transmet des événements E qui lui sont propres à tous les autres collecteurs C du même niveau hiérarchique L (étape COLLECT_E(C, C) illustrée sur la Fig. 1 par les flèches horizontales et aux Fig. 2 et 3). Dans un exemple non limitatif, le protocole UDP bien connu de l'homme du métier est utilisé. Par exemple, un collecteur peut comporter des éléments d'authentification d'un utilisateur qui s'est authentifié sur ledit collecteur ou encore des événements relatifs au lancement ou à l'arrêt d'applications sur ledit collecteur. Ainsi, l'ensemble des événements E sont enregistrés dans les collecteurs de même niveau (phase illustrée à la Fig. 2 par le cadre en traits 15 discontinus nommé COLLECT).

On notera que l'étape initiale 0) de recherche des collecteurs inférieurs est indépendante de la phase d'enregistrement des événements et peut donc se faire en parallèle, avant ou après. 20 Dans une deuxième étape 2), illustrée à la Fig. 2 et à la Fig. 3, on sélectionne par un collecteur CSUP d'un niveau supérieur LSUP un collecteur CINF d'un niveau inférieur LINF en fonction de paramètres opérationnels POP et/ou d'une qualité de lien de service NTWL dudit 25 collecteur CINF de niveau inférieur LINF. Cette sélection va permettre de sélectionner le meilleur collecteur CINF de niveau inférieur LINF à un instant donné. Dans un mode de réalisation non limitatif, les paramètres opérationnels POP comprennent : 30 - le nombre NB d'événements E, et/ou les capacités matérielles HDW, i.e. statiques telles que : - CPU (puissance par exemple), - mémoire (capacité par exemple), - caractéristiques du disque (vitesse, niveau de fiabilité, performance d'accès... par exemple), et/ou - des paramètres de consommation CONS, i.e. dynamiques en fonctionnement tels que : - CPU (vitesse par exemple) - temps de charge etc., - mémoire (consommation par exemple), - états des 10 (accès disque par exemple) dudit collecteur de niveau inférieur LINF.

Ainsi, par exemple, un collecteur qui aura un temps de charge CPU inférieur à 50% sera considéré comme meilleur qu'un collecteur qui aura un temps de charge CPU plus important. Dans des exemples non limitatifs, une qualité de lien de service NTWL concerne la bande passante allouée pour enregistrer des événements, une surcharge du lien réseau etc. Ainsi, par exemple un collecteur qui aura une remontée d'événements plus rapide sur le lien réseau sera meilleur qu'un collecteur dont la remontée sera plus lente du fait d'une surcharge de données sur son lien de communication réseau.

Ainsi, le meilleur collecteur de niveau inférieur CINF est choisi en fonction notamment des critères ci-dessus. On notera qu'un collecteur est le meilleur à un instant donné. En effet, les paramètres opérationnels POP (notamment dynamiques) et la qualité de lien de service NTWL variant au cours du temps, un collecteur qui était le meilleur à un instant donné peut ne plus l'être l'instant suivant. Aussi, un collecteur de niveau inférieur CINF peut être sélectionné comme meilleur par un collecteur de niveau supérieur CSUP, mais pas par un autre collecteur de niveau supérieur CSUP. Ce cas peut arriver par exemple à chaque redémarrage d'un collecteur de niveau supérieur CSUP. Dans ce cas, ledit collecteur CSUP va faire une nouvelle recherche du meilleur collecteur de niveau inférieur CINF selon les critères ci-dessus. Ainsi, le collecteur CSUP se resynchronisera avec le meilleur collecteur inférieur CINF.

Dans l'exemple non limitatif de la Fig. 1, les collecteurs de niveau supérieur C2 1 et C2 2 ont sélectionné le collecteur de niveau inférieur Cl 1 comme étant le meilleur (flèche continue), tandis que le collecteur de niveau supérieur C2_n a choisi le collecteur C1_2 comme étant le meilleur (flèche discontinue).

Ainsi, après la sélection du meilleur collecteur inférieur C1_1, la remontée d'événements E vers le collecteur supérieur C2_1 et C2_2 peut être effectuée (illustrée à la Fig. 2 par le cadre en traits discontinus nommé RETRV).

Il en est de même pour la remontée d'événements vers le collecteur C2_n à partir du collecteur C1_2. Par souci de concision, seul l'exemple avec les collecteurs C2_1 et C1_1 est décrit ci-après.

Dans une troisième étape 3), illustrée à la Fig. 2 et à la Fig. 4, on 15 reçoit par ledit collecteur CSUP les événements dudit collecteur de niveau inférieur sélectionné CINF. Dans un mode de réalisation non limitatif, la réception des événements E est effectuée par exemple selon le protocole de communication TCP/IP. Ce protocole permet une réception fiable des 20 événements par un collecteur supérieur CSUP puisque ledit protocole assure l'arrivée des données (événements) sans altération, dans l'ordre avec retransmission en cas de perte et élimine des données dupliquées.

Dans l'exemple pris de la Fig. 4, les collecteurs supérieurs C2_1 et C2_2 25 reçoivent ainsi les événements E du collecteur inférieur C1_1.

Dans une quatrième étape 4) illustrée à la Fig. 2 et à la Fig. 4, lorsque le meilleur collecteur de niveau inférieur CINF est sélectionné, on 30 vérifie périodiquement si le collecteur sélectionné CINF est disponible et dans la négative, on réitère l'étape précédente de sélection (soit l'étape 2).

La vérification est basée sur la génération d'un signal de façon périodique pour vérifier que le collecteur inférieur fonctionne toujours. 35 Dans un premier exemple non limitatif, on peut utiliser un mécanisme de vérification couramment appelé « heartbeat » en anglais bien connu de l'homme du métier. Dans ce cas, c'est le collecteur inférieur CINF qui prévient les collecteurs supérieurs CSUP qu'il est disponible, en envoyant un message auxdits collecteurs supérieurs CSUP. Dans un deuxième exemple non limitatif, on peut utiliser un utilitaire « ping » applicatif (« Packet Internet Groper » en anglais) bien connu de l'homme du métier. Dans ce cas, la vérification se fait par chaque collecteur supérieur CSUP qui envoie un message à un collecteur inférieur CINF pour vérifier sa disponibilité. Ainsi, si un collecteur de niveau inférieur CINF sélectionné devient indisponible (i.e. qu'un collecteur supérieur CSUP ne pourra plus accéder audit collecteur inférieur CINF), alors un autre collecteur inférieur CINF sera sélectionné à la place. Ainsi, l'étape précédente de sélectionner est exécutée de nouveau ainsi que les étapes de comparer et recevoir décrites plus loin. Ainsi, la centralisation d'événements continue même si un collecteur inférieur CINF devient indisponible. On rappelle que dans des exemples non limitatifs, un collecteur inférieur devient indisponible lorsqu'il ne fonctionne plus, lorsque le lien de communication entre lui et le collecteur supérieur est rompu etc. La Fig. 7 est un diagramme des temps illustrant schématiquement cette étape de vérification par le collecteur supérieur C2_1. - Au temps t0, le collecteur inférieur C1_1 a déjà été sélectionné et est disponible. Les événements E sont récupérés par le collecteur C2_1 à partir du collecteur C1_1. Le collecteur C1_2 est indisponible ainsi que le collecteur C1_3. - Au temps t1, une première vérification est faite, le collecteur inférieur C1_1 est toujours disponible, le collecteur C1_3 est devenu disponible, le collecteur Cl 2 est toujours indisponible. - Au temps t2, une deuxième vérification est faite, le collecteur inférieur C1_1 est toujours disponible, le collecteur C1_3 est toujours disponible, le collecteur C1_2 est devenu disponible. - Au temps t3, une troisième vérification est faite, le collecteur inférieur C1_1 est toujours disponible, le collecteur C1_3 est devenu indisponible, le collecteur C1_2 est toujours disponible. Ainsi, jusqu'au temps t4, les événements E sont récupérés par le collecteur C2-1 à partir du collecteur C1_1. - Au temps t4, une quatrième vérification est faite, le collecteur inférieur C1_1 est devenu indisponible, le collecteur C1_3 est redevenu disponible, le collecteur C1_2 est toujours disponible. A ce moment l'étape de sélection (étape 2 vue précédemment) est réitérée. Dans l'exemple, le collecteur C1_3 sera sélectionné comme étant le meilleur. Le collecteur supérieur C2_1 récupère alors les événements E à partir de ce meilleur collecteur C1_3. - Au temps t5, une cinquième vérification est faite, le collecteur inférieur C1_1 est toujours indisponible, le collecteur C1_3 est devenu indisponible, le collecteur C1_2 est toujours disponible. A ce moment l'étape de sélection (étape 2 vue précédemment) est réitérée. Dans l'exemple, le collecteur C1_2 sera sélectionné comme étant le meilleur. Le collecteur supérieur C2_1 récupère alors les événements E à partir de ce meilleur collecteur C1_2.

Dans un mode de réalisation non limitatif, l'étape de réitérer l'étape de sélection d'un autre collecteur inférieur CINF s'effectue à partir du dernier événement E reçu du collecteur de niveau inférieur sélectionné précédemment. Le collecteur supérieur CSUP sélectionne un autre meilleur collecteur inférieur CINF en tenant compte du dernier événement E enregistré reçu du collecteur inférieur CINF sélectionné précédemment. Ainsi, le collecteur supérieur CSUP se resynchronise avec un nouveau collecteur inférieur CINF à partir de ce dernier événement E (en tenant donc compte de son estampille temporelle et de son empreinte). Il reçoit donc du nouveau collecteur inférieur CINF les événements E reçus postérieurement au dernier événement E reçu du collecteur inférieur antérieur CINF (en comparant leur empreinte et estampille temporelle avec ceux dudit dernier événement E). Dans le cas où le collecteur supérieur CSUP ne trouve pas ce dernier événement E dans le nouveau collecteur inférieur sélectionné CINF, il demande à recevoir de ce dernier les événements E qui ont une estampille temporelle (notamment l'heure) TMP antérieure d'une durée donnée T à l'estampille temporelle TMP dudit dernier événement E (reçu du meilleur collecteur inférieur précédent). Ainsi, dans l'exemple décrit précédemment, au temps t4, par exemple le collecteur supérieur C2_1 recevra du nouveau collecteur inférieur sélectionné C1_3 tous les événements E qui ont une estampille temporelle TMP datant d'une minute plus tôt que le dernier événement enregistré reçu de l'ancien meilleur collecteur sélectionné C1_1. Bien entendu, la périodicité d'une minute n'est qu'un exemple non limitatif, une périodicité différente pourrait être appliquée.

Dans l'exemple de la Fig. 4, ce qui a été décrit ci-dessus pour la vérification de disponibilité s'applique de la même manière au collecteur supérieur C2_2 par rapport au collecteur inférieur C1_1.

On notera que bien entendu, cette étape peut être déclenchée dès qu'un meilleur collecteur est sélectionné par un collecteur supérieur, et à chaque fois qu'un nouveau meilleur collecteur est sélectionné par un collecteur supérieur.

Il en est de même avec la comparaison périodique des événements de l'étape 5) expliquée par la suite.

On notera que cette étape de vérification se fait dans des modes de réalisation non limitatifs, soit de manière asynchrone par rapport aux étapes de remontée d'événements suivantes 5) et 6), soit de manière synchrone, à savoir avant ou après chaque remontée d'un événement ou avant ou après chaque remontée d'un ensemble d'événements.

Dans une cinquième étape 5) illustrée à la Fig. 2 et à la Fig. 4, on compare par ledit collecteur CSUP de niveau supérieur LSUP ses événements E avec ceux des collecteurs de niveau inférieur non sélectionnés CINF.

Dans un mode de réalisation non limitatif, l'étape de comparer des événements E d'un collecteur de niveau supérieur CSUP avec ceux des collecteurs de niveau inférieur non sélectionnés CINF s'effectue en fonction d'une empreinte HSH (appelée « hash » en anglais) associée aux événements E desdits collecteurs de niveau inférieur CINF.

Une empreinte HSH permet d'identifier un événement. Une empreinte est calculée par exemple par des fonctions de hachage qui permettent de contrôler l'intégrité des données. Les fonctions de hachage étant connues de l'homme du métier, elles ne sont pas décrites ici. Ainsi, l'empreinte HSH permet d'identifier de manière unique un événement.

Dans un mode de réalisation non limitatif, l'étape de comparer des événements E d'un collecteur de niveau supérieur CSUP avec ceux des collecteurs de niveau inférieur non sélectionnés CINF s'effectue en outre en fonction d'une estampille temporelle TMS (appelée « timestamp » en anglais). On notera que l'estampille temporelle TMS permet d'attester l'instant d'apparition d'un événement (chaque événement ayant une même référence temporelle). Une telle estampille temporelle comporte de manière générale la date et l'heure d'apparition de l'événement.

Cela permet également de faciliter la classification des événements et leur recherche lors de l'étape de comparaison. Ainsi, l'estampille temporelle TMS est combinée avec l'empreinte HSH.

Dans l'exemple pris de la Fig. 4, les collecteurs supérieurs C2_1 et 30 C2_2 comparent leurs événements E avec ceux des collecteurs de niveau inférieur non sélectionnés C1_2 à C1 n.

Ainsi, lors de la comparaison, si un collecteur supérieur CSUP s'aperçoit qu'il lui manque des événements par rapport à ceux sauvegardés dans un collecteur inférieur non sélectionné CINF, il récupère lesdits événements dudit collecteur inférieur non sélectionné CINF. Cela signifie que le collecteur de niveau inférieur sélectionné CINF a perdu des événements E enregistrés, et dans l'affirmative, le collecteur de niveau supérieur CSUP reçoit les événements perdus à partir d'un autre collecteur de niveau inférieur CINF (étape RXd(CINF) illustrée à la Fig. 2 et à la Fig. 4). On notera que cette comparaison s'applique pour l'ensemble des événements enregistrés dans un collecteur non sélectionné, à savoir les événements issus de l'ensemble des équipements sources S, les événements propres audit collecteur inférieur non sélectionné, ainsi que les événements propres aux autres collecteurs de même niveau hiérarchique (puisque ces derniers événements on été également transmis aux collecteurs inférieurs non sélectionnés).

Dans un mode de réalisation non limitatif, l'étape de comparer les événements du collecteur de niveau supérieur avec ceux des collecteurs de niveau inférieur non sélectionnés est effectuée périodiquement. Dans un mode de réalisation non limitatif, la comparaison se fait de la manière suivante. Dans l'exemple de la Fig. 5 le collecteur supérieur C2_1 interroge périodiquement tous les collecteurs inférieurs non sélectionnés Cl pour leurs événements E. L'interrogation se fait dans un exemple non limitatif toutes les minutes. Chaque collecteur inférieur non sélectionné, ici C1_2 à Cl_n, envoie une réponse avec les informations suivantes : - l'estampille temporelle TMP et l'empreinte HSH de chaque événement E qu'il comprend depuis la minute précédente. Le collecteur supérieur C2_1 compare ainsi ses événements E reçus depuis la dernière minute avec les événements E de chaque collecteur inférieur non sélectionné Cl (C1_2, Cl_n), et si les informations d'identification (estampille temporelle + empreinte) d'au moins un événement E sont différentes, cela signifie que le collecteur inférieur sélectionné C1_1 a perdu des événements E.

Dans ce cas, le collecteur supérieur C2_1 demande à recevoir le ou les événements E qui manquent à partir du collecteur inférieur non sélectionné Cl qui comporte les événements manquant. A cet effet, le collecteur supérieur C2_1 désigne l'événement qui manque en envoyant au collecteur inférieur non sélectionné Cl concerné l'estampille temporelle TMP et l'empreinte HSH de l'événement manquant E (qu'il a comparé précédemment). Dans l'exemple non limitatif de la Fig. 4, le collecteur supérieur C2_1 récupère les événements manquants du collecteur inférieur non sélectionné C1_2.

Dans l'exemple pris, ce qui a été décrit ci-dessus s'applique également au collecteur supérieur C2_2. On notera que la comparaison se fait par chaque collecteur supérieur CSUP. Ainsi, dans une sixième étape 6) illustrée à la Fig. 2 et à la Fig. 4, le collecteur supérieur CSUP reçoit d'un de ces collecteurs de niveau inférieur non sélectionnés CINF les événements qui sont différents des siens (via l'empreinte ou via l'empreinte plus l'estampille temporelle). 20 Dans un mode de réalisation non limitatif, la réception des événements E différents est effectuée par exemple selon le protocole de communication TCP/IP. Ce protocole permet une réception fiable des événements par un collecteur supérieur CSUP puisque ledit protocole assure l'arrivée des données (événements) sans altération, dans l'ordre avec 25 retransmission en cas de perte et élimine des données dupliquées.

Dans l'exemple pris de la Fig. 4, les collecteurs supérieurs C2_1 et C2_2 reçoivent ainsi les événements E du collecteur inférieur non sélectionné C1_2. 30 Ainsi, lorsque chaque collecteur C2 a reçu les événements de niveau inférieur L1 via au moins un meilleur collecteur inférieur Cl, les étapes du procédé de centralisation sont réitérées (Cf. Fig. 5 et Fig. 6) par les collecteurs supérieurs aux collecteurs C2 vers lesdits collecteurs C2 (ces derniers devenant des collecteurs inférieurs), soit ici le collecteur C3 du niveau supérieur L3, tel qu'illustré sur la Fig. 2.

Ainsi, le procédé de centralisation d'événements permet de récupérer de manière automatique l'ensemble des événements d'un système hiérarchique multi-niveaux dans un collecteur de central CSUP et ce sans perte d'événements.

Le procédé de centralisation d'événements est mis en oeuvre par un système d'information hiérarchique multi-niveaux SYS apte à centraliser des événements E générés par des équipements sources S, ledit système comprenant une pluralité d'équipements sources S générateurs d'événements E et une pluralité de collecteurs C d'événements E par niveau, tel qu'illustré schématiquement à la Fig. 8 selon un mode de réalisation non limitatif. Plus particulièrement, le collecteur C pour système d'information hiérarchique multi-niveaux SYS comprenant une pluralité d'équipements sources S générateurs d'événements E et une pluralité de collecteurs C d'événements E par niveau, est apte à centraliser des événements E générés par des équipements sources S dudit système d'information hiérarchique multi-niveaux SYS, et comporte : - des moyens de sélection d'un collecteur CINF d'un niveau inférieur LINF en fonction de paramètres opérationnels POP et/ou d'une qualité de lien de service NTWL dudit collecteur CINF de niveau inférieur LINF ; - des moyens de réception des événements dudit collecteur de niveau inférieur sélectionné CINF ; - des moyens de vérification périodique de la disponibilité du collecteur sélectionné CINF et dans la négative des moyens de réitération de l'étape de sélection ; - des moyens de comparaison de ses événements E avec ceux des collecteurs de niveau inférieur non sélectionnés CINF ; et - des moyens de réception d'un de ces collecteurs de niveau inférieur non sélectionnés CINF des événements E qui sont différents. Dans un mode de réalisation non limitatif, le collecteur C comporte en outre des moyens d'enregistrement de l'ensemble des événements E générés par les équipements sources S de même niveau hiérarchique.

10 On notera que la mise en oeuvre du procédé exposé ci-dessus peut être effectuée au moyen d'un dispositif micro programmé « software », d'une logique câblée et/ou de composants électroniques « hardware ». Ainsi, le système d'information hiérarchique multi-niveaux SYS peut 15 comporter un ou plusieurs produits programmes d'ordinateur PG comportant une ou plusieurs séquences d'instructions exécutables par une unité de traitement d'information telle qu'un microprocesseur, ou d'une unité de traitement d'un microcontrôleur, d'un ASIC, d'un ordinateur etc., l'exécution desdites séquences d'instructions permettant une mise en oeuvre du 20 procédé décrit. Un tel programme d'ordinateur PG peut être inscrit en mémoire non volatile inscriptible de type ROM ou en mémoire non volatile réinscriptible de type EEPROM ou FLASH. Ledit programme d'ordinateur PG peut être inscrit en mémoire en usine ou encore chargé en mémoire ou téléchargé à distance 25 en mémoire. Les séquences d'instructions peuvent être des séquences d'instructions machine, ou encore des séquences d'un langage de commande interprétées par l'unité de traitement au moment de leur exécution. Dans l'exemple non limitatif de la Fig. 8, le programme d'ordinateur PG est 30 inscrit dans une mémoire d'un collecteur C. Dans ce cas, dans un mode de réalisation non limitatif, on peut prévoir d'activer l'exécution des séquences d'instructions selon que le programme est exécuté dans un collecteur de niveau supérieur ou dans un collecteur de niveau inférieur ou dans un collecteur inférieur appartenant au niveau le plus bas (soit dans l'exemple de 35 la Fig. 2 le niveau L1). En effet, dans ce dernier cas, seule l'étape5 d'enregistrement de l'ensemble des événements E générés par les équipements sources S de même niveau hiérarchique sera exécutée.

Bien entendu la description n'est pas limitée à l'application, aux modes de réalisation ni aux exemples décrits ci-dessus.

Ainsi, d'autres paramètres que ceux cités précédemment peuvent être pris en compte pour la sélection du meilleur collecteur inférieur. Ainsi, dans un exemple non limitatif, un critère qui limite le nombre de collecteurs supérieurs auquel un collecteur inférieur peut remonter des événements peut être pris en compte. En effet, plus ce nombre sera petit, plus la surcharge du lien réseau entre le collecteur inférieur et un collecteur supérieur sera moindre et meilleure sera la transmission des événements.

Ainsi, dans le cas où les collecteurs d'un niveau inférieur seraient tous indisponibles, dans un mode de réalisation non limitatif, une temporisation peut être mise en place dans le collecteur supérieur pour vérifier si un collecteur inférieur est redevenu disponible.

Ainsi, l'invention décrite présente notamment les avantages suivants : - elle est simple à mettre en oeuvre ; - elle évite une réplication de l'ensemble des événements des collecteurs d'un niveau dans tous les collecteurs d'un autre niveau ; - elle permet la sélection du meilleur collecteur inférieur à un instant donné ; - elle évite la perte d'événements si un collecteur est défaillant ou qu'un lien est rompu entre un collecteur inférieur et un collecteur supérieur par exemple ; - elle permet de synchroniser les événements contenus dans un collecteur supérieur avec ceux du meilleur collecteur inférieur à un instant donné, ce qui permet d'éviter d'avoir des doublons et donc d'avoir de fausses alertes d'intrusion par exemple ; - elle permet une remontée d'événements entre un niveau inférieur et un niveau supérieur fiable du fait de l'utilisation du protocole TCP/IP ; - elle permet une remontée d'événements depuis un seul collecteur à un instant donné, ce qui évite les encombrements sur les liens de communication ; - elle permet d'être sûr de collecter les événements au niveau supérieur à partir d'un collecteur inférieur qui étant le meilleur sera celui qui perdra le moins d'événements et donc sera le plus représentatif des événements générés par les équipements sources notamment ; - elle permet, grâce à la vérification de la disponibilité du collecteur sélectionné, de garantir le bon fonctionnement de la centralisation d'événements. En effet, il n'y a plus de risque qu'un collecteur supérieur fasse confiance à un collecteur inférieur qui n'est plus disponible, et donc il y a beaucoup moins de risque d'erreurs sur la remontée d'événements ; - elle permet une supervision complète de l'ensemble des événements d'un système d'information hiérarchique multi-niveaux par un collecteur supérieur situé au niveau le plus haut ; et - elle permet au collecteur supérieur situé au niveau le plus haut d'effectuer des calculs mathématiques (ex: agrégation ou corrélation) en temps réel même en cas de perte de disponibilité d'un collecteur ou d'un lien entre le collecteur inférieur et le collecteur supérieur situé au niveau le plus haut.

Claims

REVENDICATIONS1- Procédé de centralisation d'événements (E) pour un système d'information hiérarchique multi-niveaux (SYS), ledit système comprenant une pluralité d'équipements sources (S) générateurs d'événements (E) et une pluralité de collecteurs (C) d'événements (E) par niveau, ledit procédé comportant les étapes de : - sélectionner par un collecteur (CSUP) d'un niveau supérieur (LSUP) un collecteur (CINF) d'un niveau inférieur (LINF) en fonction de paramètres opérationnels (POP) et/ou d'une qualité de lien de service (NTWL) dudit collecteur (CINF) de niveau inférieur (LINF) ; - recevoir par ledit collecteur (CSUP) les événements dudit collecteur de niveau inférieur sélectionné (CINF) ; - vérifier périodiquement si le collecteur sélectionné (CINF) est disponible et dans la négative de réitérer l'étape de sélection ; et - comparer par ledit collecteur (CSUP) de niveau supérieur (LSUP) ses événements (E) avec ceux des collecteurs de niveau inférieur non sélectionnés (CINF) et recevoir d'un de ces collecteurs de niveau inférieur non sélectionnés (CINF) les événements (E) qui sont différents.
2- Procédé de centralisation d'événements (E) selon la revendication 1, selon lequel il comporte une étape supplémentaire d'enregistrer l'ensemble des événements (E) générés par les équipements sources (S) dans les collecteurs (C) de même niveau hiérarchique que les équipements sources (S).
3- Procédé de centralisation d'événements (E) selon l'une quelconque des revendications précédentes, selon lequel l'étape de comparer les événements du collecteur de niveau supérieur avec ceux des collecteurs de niveau inférieur non sélectionnés est effectuée périodiquement.
4- Procédé de centralisation d'événements (E) selon l'une quelconque des revendications précédentes, selon lequel l'étape de comparer desévénements (E) d'un collecteur de niveau supérieur (CSUP) avec ceux des collecteurs de niveau inférieur non sélectionnés (CINF) s'effectue en fonction d'une empreinte (HSH) associée aux événements (E).
5- Procédé de centralisation d'événements (E) selon la revendication précédente, selon lequel l'étape de comparer des événements (E) d'un collecteur de niveau supérieur (CSUP) avec ceux des collecteurs de niveau inférieur non sélectionnés (CINF) s'effectue en outre en fonction d'une estampille temporelle (TMS).
6- Procédé de centralisation d'événements (E) selon l'une quelconque des revendications précédentes, selon lequel les paramètres opérationnels (POP) utilisés à l'étape de sélectionner un collecteur de niveau inférieur, comprennent le nombre (NB) d'événements (E) et/ou les capacités matérielles (HDW) et/ou des paramètres de consommation (CONS).
7- Procédé de centralisation d'événements (E) selon l'une quelconque des revendications précédentes, selon lequel la sous-étape de recevoir des événements (E) différents est effectuée selon le protocole de communication TCP/I P.
8- Procédé de centralisation d'événements (E) selon l'une quelconque des revendications précédentes, selon lequel il comporte en outre une étape initiale de recherche des collecteurs (CINF) de niveaux inférieurs (LINF) par un collecteur (CSUP) de niveau supérieur (LSUP).
9- Procédé de centralisation d'événements (E) selon l'une quelconque des revendications précédentes, selon lequel il comporte une étape supplémentaire de transmettre par un collecteur (C) des événements (E) qui lui sont propres à tous les autres collecteurs (C) du même niveau hiérarchique (L).
10-Procédé de centralisation d'événements (E) selon la revendication précédente, selon lequel l'étape de transmettre s'effectue par exemple selon le protocole de communication UDP.
11-Collecteur (C) pour système d'information hiérarchique multi-niveaux (SYS), ledit système comprenant une pluralité d'équipements sources (S) générateurs d'événements (E) et une pluralité de collecteurs (C) d'événements (E) par niveau, ledit collecteur étant apte à centraliser des événements (E) générés par des équipements sources (S) dudit système d'information hiérarchique multi-niveaux (SYS), ledit collecteur comportant: - des moyens de sélection d'un collecteur (CINF) d'un niveau inférieur (LINF) en fonction de paramètres opérationnels (POP) et/ou d'une qualité de lien de service (NTWL) dudit collecteur (CINF) de niveau inférieur (LINF) ; - des moyens de réception des événements dudit collecteur de niveau inférieur sélectionné (CINF) ; - des moyens de vérification périodique de la disponibilité du collecteur sélectionné (CINF) et dans la négative des moyens de réitération de l'étape précédente de sélection ; - des moyens de comparaison de ses événements (E) avec ceux des collecteurs de niveau inférieur non sélectionnés (CINF) ; et - des moyens de réception d'un de ces collecteurs de niveau inférieur non sélectionnés (CINF) des événements (E) qui sont différents.
12-Collecteur (C) selon la revendication précédente, selon lequel il comporte en outre des moyens d'enregistrement de l'ensemble des événements (E) générés par les équipements sources (S) de même niveau hiérarchique.
13-Système d'information hiérarchique multi-niveaux (SYS) apte à centraliser des événements (E) générés par des équipements sources (S), ledit système comprenant une pluralité d'équipements sources (S) générateurs d'événements (E) et une pluralité de collecteurs (C)d'événements (E) par niveau, les collecteurs (C) étant caractérisés selon l'une quelconque des revendications 11 ou 12.
14-Produit programme d'ordinateur (PG) comportant une ou plusieurs séquences d'instructions exécutables par une unité de traitement d'information, l'exécution desdites séquences d'instructions permettant une mise en oeuvre du procédé selon l'une quelconque des revendications précédentes 1 à 10, lorsqu'il est chargé sur un ordinateur.10