FR2806494A1 - Procede de transformation, de transport et d'analyse de fichiers de journaux d'evenements (logs) - Google Patents

Procede de transformation, de transport et d'analyse de fichiers de journaux d'evenements (logs) Download PDF

Info

Publication number
FR2806494A1
FR2806494A1 FR0003386A FR0003386A FR2806494A1 FR 2806494 A1 FR2806494 A1 FR 2806494A1 FR 0003386 A FR0003386 A FR 0003386A FR 0003386 A FR0003386 A FR 0003386A FR 2806494 A1 FR2806494 A1 FR 2806494A1
Authority
FR
France
Prior art keywords
event log
notification
subsystem
agent
monitor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0003386A
Other languages
English (en)
Other versions
FR2806494B1 (fr
Inventor
Andre Freyssinet
Serge Lacourte
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull SA
Original Assignee
Bull SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull SA filed Critical Bull SA
Priority to FR0003386A priority Critical patent/FR2806494B1/fr
Publication of FR2806494A1 publication Critical patent/FR2806494A1/fr
Application granted granted Critical
Publication of FR2806494B1 publication Critical patent/FR2806494B1/fr
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3495—Performance evaluation by tracing or monitoring for systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86—Event-based monitoring

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention concerne un procédé de gestion et mise à jour d'un journal d'événements d'un sous-système d'archivage appartenant à un réseau reliant une pluralité de sous-systèmes d'archivage comprenant des moyens de mémorisation, chacun des sous-systèmes d'archivage étant responsable d'un niveau de journal d'événements, sur chacun des sous-systèmes d'archivage fonctionne au moins une pluralité d'agents autonomes communiquant par notifications, la gestion du journal d'événements consistant en : - une étape d'acquisition, cette phase consistant à récupérer une partie du journal d'événements dans un fichier afin d'en permettre le traitement; - une étape de filtrage consistant à sélectionner et transformer l'information contenue dans le fichier de journal d'événements; une étape d'archivage consistant à conserver les fichiers de journal d'événements afin d'en permettre la consultation durant un temps donné constituant la période de conservation.

Description

<U>Procédé de transformation, de transport et d'analyse de fichiers</U> <U>de journaux d'événements</U> (logs). La presente invention concerne un procédé de mise à jour de journal d'événements dans un système informatique distribué comportant une pluralité de sous-systèmes d'archivage chacun responsable d'un "niveau de journal d'événements, comprenant un système d'exploitation permettant d'administrer cette pluralité de sous-systèmes d'archivage.
L'invention concerne la construction de journaux d'événements à partir d'autres journaux (sources d'événements distribuées), elle peut avoir différentes utilisations : génération d'informations synthétiques (statistiques, alarmes) à partir d'informations distribuées, gestion de la durée de vie de l'information (archivage, compression, destruction), etc.
L'invention se place dans le cadre de la gestion de journal d'événements (log), elle permet notamment la gestion distribuée d'informations de recueil chronologique automatique (logging) générées par des machines interconnectées par un réseau. Le journal d'événements (log) est un concept informatique visant à conserver la trace des événements produits par composant matériel ou logiciel. Le journal d'événements (log) est un flux continu d'informations, il peut-être décomposé séquentiellement en fichiers ; chaque fichier de journal d'événements (log) contient une portion contiguë du journal (log).
II connu par la demande de brevet français déposée le 9 octobre par la demanderesse sous le numéro FR 98 12652, un procédé mise à jour d'un journal centralisé d'événements. Contrairement à l'art anterieur où chaque application de capture d'événements de chaque machine peut demander directement au serveur d'écrire dans le journal d'événements par l'intermédiaire du gestionnaire du journal, selon ce procédé, service spécifique d'un serveur exécute toutes les demandes d'écriture dans le journal d'événements. Pour pouvoir écrire les événements dans le journal, le service spécifique doit avoir accès aux informations recueillies chaque application de capture d'événements sur chaque machine. A effet, dès qu'un événement se produit sur une quelconque machine, l'application récoltant les informations sur l'événement envoie un message contenant toutes les informations sur l'événement vers le serveur. Dès la reception, ce message est stocké sur les moyens de mémorisation du serveur. Ces informations sont stockées, par exemple, dans un fichier affecté à chaque machine. Le nombre de messages émis augmente avec le nombre de machines, et peut finir par saturer le réseau du système. Par ailleurs, plus le nombre de machines gérées est important, plus le volume d'informations généré est très important. Ainsi un pare-feu (firewall) peut génerer plus de 200Mo de fichier de journal (log) par jour. Ce qui est trop important pour être conservé très longtemps et aussi pour être réellement observé. Le but recherché ici est donc de filtrer l'information pour tenter de faire ressortir et conserver les événements importants. L'invention concerne un procédé de gestion de journaux d'événements qui peut avoir pour buts, d'une part de réduire le volume d'informations contenues dans le fichier de journal d'événements (log) en ne conservant que l'information pertinente et, d'autre part, de rechercher des événements, ou des séquences d'événements particuliers, à fins d'analyse, de facturation, etc. Ce but est atteint par le procédé de gestion et mise à jour d'un journal d'événements d'un sous-système d'archivage appartenant à un réseau reliant une pluralité de sous-systèmes d'archivage comprenant des moyens de mémorisation, des moyens permettant de réveiller un agent ou un service en fonction d'un événement déterminé, chacun sous- systèmes d'archivage étant responsable d'un niveau de journal d'événements, sur chacun des sous-systèmes d'archivage fonctionne au moins une pluralité d'agents autonomes communiquant par notifications pour constituer une interface identique entre tous les sous systèmes destinés à envoyer des journaux d'événements et dans lequel la gestion du journal d'événements consiste en - une étape d'acquisition, cette phase consistant à recupérer une partie du journal d'événements source dans un fichier afin permettre le traitement ; - étape de filtrage consistant à sélectionner transformer l'information contenue dans le fichier de journal d'événements. - étape d'archivage consistant à conserver la partie de journal d'événements produit dans un fichier afin d'en permettre la consultation durant un temps donné constituant la période de conservation. autre but est de structurer le système de gestion distribuée d'un journal d'evénements (log) de manière à obtenir un procédé fiable, aisément configurable, extensible et ouvert. Ce but est atteint par le fait que le système de gestion et mise à jour d'un journal d'événements est constitué de composants configurables de haut niveau pouvant être assemblés entre eux, appelés sous-systèmes d'archivage, chacun des sous-système d'archivage étant responsable d'un niveau de journal d'événements, l'architecture interne du sous-système d'archivage étant composée d'agents autonomes et constituée d'un agent moniteur d'autres agents, les agents et les sous-systèmes communiquant grâce à dialogue spécifique, par notifications, externes entre sous- systèmes, internes entre agents d'un sous-système, pour constituer une interface identique entre tous les sous-systèmes et les agents et le transfert du fichier de journal d'événements (log) s'effectue par un canal TCP. L'aspect fiabilité consiste ici à assurer que chaque fichier de journal (log) sera bien traité comme spécifié.
Ce but est atteint du fait de l'utilisation d'agents autonomes communiquant par notifications. Selon une autre particularité le transfert est fiabilisé grâce à un dialogue spécifique entre sous-systèmes d'archivage.
Un autre but est de proposer un sous-système d'archivage utilisable dans le procédé de l'invention. Ce est atteint du fait que chaque sous-système d'archivage est constitué ensemble d'agents - un agent moniteur (agent Monitor), dont le rôle est d'interagir avec les composants extérieurs (sous-systèmes) et de coordonner les composants intérieurs (agents d'un sous-système) ; - un agent TcpServer pour permettre l'accès aux fichiers de journal d'événements d'un sous-système d'archivage par des sous-systèmes distants et qui est prévu pour interagir avec l'agent TcpClient ; - un agent Client qui a la responsabilité d'accéder au journal d'événements entrant, de le transformer en notifications (une notification RecordNot par enregistrement) et de diffuser ces notifications dans la chaîne de traitement ; cet agent peut-être un FileClient pour un accès local, un TcpClient pour un accès distant, etc. - des agents de traitements du flux, et - un agent rapporteur qui est responsable de la persistance, pour produire journaux d'événements ainsi que les informations de reprise en fonction données transmises par chaque agent compteur, cet agent rapporteur collaborant avec l'agent moniteur afin d'assurer persistance et la reprise procédé. D'autres particularités et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ' après faite en référence dessins annexés dans lesquels - la figure 1 représente l'architecture globale d'un système permettant la mise en ceuvre du procédé selon l'invention comportant un ensemble sous-systèmes d'archivage configurables ; - la figure 2 représente l'utilisation de sous-systèmes d'archivage pour produire plusieurs niveau de journal ; - la figure 3 représente la procédure de dialogue lors d'une connexion entre deux sous-systèmes d'archivage ; - la figure 4 représente la structure d'un sous-système d'archivage - la figure 5 représente schématiquement un diagramme temporel du principe de gestion de la persistance ; - la figure 6 représente l'architecture constitutive des différents agents utilisés par le sous-système d'archivage. L'invention, qui va être décrite en relation avec les figures 1 à 6 comporte un système dont l'architecture globale en composants configurables de haut niveau pouvant être assemblés entre eux, permet la mise en oeuvre du procédé de gestion de journal d'événements (logs) mémorisé sur les moyens de mémorisation. Ces composants SSAI SSA2, SSA3.. sont appelés sous-systèmes d'archivage et communiquent entre eux par notifications de dialogue NOT1, NOT2 , NOT3 envoyées sur le réseau L'architecture interne de chaque sous-système d'archivage est composée (figure 4) d'agents autonomes (MO;, AC;, LF;lo, LF;11, 120, ...Lfijk, LC;lo, LC;2o,...Lcijk, AR;). Tous les sous-systèmes d'archivage respectent une interface 11, 12, 13 (fig.1) identique leur permettant dialoguer et d'interagir avec les autres. L'unité d'échange entre composants SSA; est la portion PJ; de journal (log) mémorisée sur les moyens de mémorisation de chaque sous-système d'archivage. Chaque sous-système d'archivage SSA; est composé d'une structure prédéterminée d'agents permettant le dialogue avec les autres sous-systèmes SSA; pour réaliser, premièrement l'acquisition des fichiers, de journal d'événements (log) produits par le(s) sous-système(s) d'archivage(s) "amont(s)", deuxièmement la gestion des fichiers de journal d'événements produits, troisièmement la fourniture des fichiers de journaux d'évenements produits aux sous-systèmes d'archivage "avals".
Par sous-système d'archivage "aval", par exemple SSA2 et SSA3, on doit comprendre le ou les sous-systèmes d'archivage SSA2 et SSA3 qui se sont abonnes à un autre sous-système d'archivage, par exemple SSA1, que l'on désigne par sous-système "amont".
Chaque sous système d'archivage SSA; peut avoir un rôle et une composition propre permettant: l'acquisition du fichier PJ; de journal d'événements, les opérations de filtrage, transfert, encodage (par exemple, cryptage, compression, mise au format...) du fichier de journal d'événements, l'analyse, la facturation, etc...
Le est de structurer le logiciel de gestion distribuée du journal (log) de manière à obtenir un procédé fiable, aisément configurable, extensible et ouvert.
L'architecture globale, telle qu'elle est présentée, permet la décomposition du procédé global de traitement des journaux d'événements (logs) en tâches de complexité moindre, la répartition des tâches sur différents sites, l'ajout, la configuration et la reconfiguration de tâches, et la scalabilité.
Cette structure prédéterminée d'agents est ouverte et peut-être étendue l'ajout de composants agents dont le rôle le traitement du fichier courant PJ;, de journal d'événements (log).
agents (5, figure 6) sont des entités programmation élémentaire et d'exécution. Les agents (5) sont autonomes pour obtenir la propriété d'extensibilité de la structure en pouvant ajouter et enlever facilement des agents dans l'architecture. Ils sont rendus autonomes en définissant parfaitement l'interface de ces agents. Ils sont autonomes aussi en termes de communication. Ils communiquent en utilisant des notifications et non par appel de procédure, ce qui permet d'ouvrir l'architecture. Un événement est représenté par une notification. Les notifications passent par le canal (2, fig. 6) et sont contrôlées par le moteur d'exécution (1) (Engine) de la machine à agents. Les notifications sont portées aux agents via canal de communication (2), par exemple de type TCP (Channel). agents (5) sont des objets persistants, leur état est fait de données existent en dehors de toute structure d'exécution. Un agent (5) est une machine indépendante qui réagit aux notifications. Tous les agents sont indépendants et seuls les agents réactifs ont besoin d'être chargés dans la mémoire. On appelle agent réactif un agent qui vient de recevoir une notification et dont le comportement est imposé par la fonction 'React' de l'agent appelée par le moteur d'exécution (1) (Engine). Ces agents réactifs peuvent ensuite être replacés sur le disque à la fin de la boucle de programme du moteur d'exécution (1). Chaque agent est un objet d'une classe et est identifié par un identificateur (Agentld) unique qui permet de localiser. Un agent peut être créé sur un serveur à distance. L'entité création est responsable de la création de l'identificateur. En référence à figure 6, la machine à agents comprend un moteur d'exécution (1) (Engine), un canal (2) de communication ou bus de message (channel) associé moteur d'exécution (1), le canal (2) possède deux queues, une queue locale ou interne (3) (mqin) et une queue externe (4) (mq0ut). Le serveur d'agents (10) comporte aussi une couche de stockage (storage). Les queues (3, 4), le canal (2) et les agents (5) s'appuient sur la couche de stockage.
Tous les agents (5), le canal (2) de communication et le moteur d'exécution ( ) de la machine à agents sont des objets Java dans un processus. persistance est réalisée en utilisant la sérialisation d'objets et un système fichiers. Chaque agent possède un identificateur unique et persistant.
La structure de traitement d'un sous-système d'archivage SSA; est constituée d'un graphe d'agents (figure 4), le fichier courant PJic du journal d'événements (log) traverse ce graphe sous la forme d'un flot de notifications (une notification par événements du journal). L'architecture interne, présentée ici et en figure 4, permet la définition et la configuration de tâches par la composition d'agents de traitement existants (filtres et compteurs variés), par l'ajout d'agents de traitements spécialisés, de façon à procurer l'extensibilité des sous-systèmes d'archivages SSA;.
La partie traitement du journal d'événements des sous-systèmes d'archivage SSA; nécessite des performances élevées. Chaque événement du journal d'événements est transforme en une notification et va nécessiter la réaction de plusieurs agents. Afin d'offrir de meilleures performances, ces agents vont être exécutés dans une machine à agents où l'atomicité des réactions et la persistance des agents sont invalidées de façon à réduire la demande en en CPU et IIO. La persistance du procédé est représentée par le fichier de journal d'événements produit dont les modifications s'effectuent en dehors de la portée de la transaction. En conséquence, afin de garantir le bon fonctionnement de l'application en cas panne, on conserve dans la partie persistante du sous-système SSA; un état de la machine de traitement. Typiquement, le volume d'informations généré est très important, ainsi un pare-feu (firewall) peut générer plus de 200Mo de fichier de journal log par jour, ce qui est trop important pour être conservé très longtemps et aussi pour être réellement observé. recherché ici est donc de filtrer l'information pour tenter de faire ressortir et conserver les événements importants. Un premier scénario de fonctionnement est celui où l'archivage s'effectue en chaîne avec, par exemple comme représenté figure 2, le sous- système SSA2 ayant pour sous-système amont SSA, et pour sous-système aval SSA3. Dans ce scénario type, journal d'événements (log) traverse successivement plusieurs sous-systèmes d'archivage SSA, , respectivement SSA2, respectivement SSA3 (fig.2). Chaque sous-système SSA; possède une chaîne de filtrage dont le but est de réduire le volume d'informations, en supprimant l'information jugée non pertinente, ou en agrégeant des informations de même nature. Chaque sous-système SSA; produira donc successivement un niveau de journal d'événements J; (sous forme de fichiers PJ;) de taille de plus en plus réduite et dont la durée vie pourra être de plus en plus longue. Le niveau J2 est le résultat du traitement par le sous-système SSA2 du journal J, produit par le sous-système SSA, et le niveau J3, est le résultat du traitement du niveau de journal J2 par le sous- système SSA3. Ce scénario est utilisé pour permettre la transformation séquentielle d'un journal d'événements. autre scénario possible avec l'architecture de l'invention est le cas, representé par exemple figure 1, où des journaux d'événements J2, respectivement J3 (logs) sont produits chacun par une machine distribuée, par exemple SSA2 et respectivement SSA3, d'un ensemble de machines distribuees, à partir, par exemple, du journal J, de SSA1. Le traitement du journal d'evénements J2 respectivement J3 va être séparé en deux : d'une part un filtrage en local permettant la réduction du volume d'informations, puis archivage et son transfert, et d'autre part une analyse en central prenant compte l'ensemble des informations de J2 et J3 transférées et permettant la corrélation d'événements survenus sur des sites différents. système est donc constitué d'un ensemble de sous-systèmes d'archivage SSA;, chacun responsable d'un "niveau de journal d'événements"; l'ensemble pouvant être éventuellement piloté par un composant superviseur SV. Dans le cas où il n'y a pas de superviseur SV, celui est remplacé par un sous-système SSA.
Un sous-système d'archivage SSA; est constitué ensemble d'agents autonomes qui ont la responsabilité de la gestion niveau PJ; d'archivage du fichier de journal d'événements. Chaque sous-système d'archivage est responsable des fichiers qu'il produit, création, exportation et destruction. Un sous-système définit, d'une part une période de comptage PC (figure 5) qui détermine la granularité des agrégats produits, d'autre part une periode d'archivage PA (figure 5) qui détermine l'intervalle de temps couvert chaque fichier produit. La gestion des périodes de comptage PC (figure 5) (resp. d'archivage PA) devra évoluer sous la forme d'un calendrier d'événements de début de période de comptage (resp. d'archivage). Un sous-système comporte des "propriétés" concernant la gestion des fichiers de journaux d'événements (logs) produits (durée de conservation, format, etc.). Un sous-système constitue une chaîne de traitement qui permet production du niveau de journal d'événements résultats à partir du, ou fichiers source. L'interface 1,,12, 13, Ii des sous-systèmes d'archivage est prévue pour permettre leur interconnexion. Chaque sous-système conserve donc mémorisé dans les moyens de mémorisation une liste LAi des sous- systèmes d'archivage qui se sont déclarés intéressés par les fichiers qu'il produit. Ainsi, dans l'exemple de la figure 1, SSA, comporte dans sa liste LA, les sous-systèmes SSA2 et SSA3. Chaque fois qu'un sous-système SSAi produit un nouveau fichier, il peut donc émettre, grâce à sa liste LAi, une notification de création à destination des sous-systèmes intéressés.
Lorsqu'un sous-système d'archivage, par exemple SSA2, est notifié par exemple par la notification NOT1 de la création d'un nouveau fichier journal d'événements résultat PJ, par le sous-système SSA,, il peut alors demander, par la notification NOT2, le contenu afin de le traiter. Le dialogue externe entre sous-systèmes d'archivage est défini dans la suite de ce document par les cinq notifications de dialogue. Le traitement de la notification et du journal est effectué par un ensemble d'agents non persistants qui ont la responsabilité de lire le (ou les) fichier(s) de journal d'événements sources PJkc, de traiter ses enregistrements et de produire le fichier de journal résultant PJir. L'interface de chaque sous-système d'archivage ainsi que le pilotage de partie traitement (TI, T2, T3) sont assures par un agent persistant, le moniteur (MO,, M02, M03). Chaque sous-système d'archivage peut être localisé sur une machine différente. Eventuellement, l'ensemble des sous-systèmes peut etre connecté à un composant superviseur SV pour apporter un supplément fonctions. Ce composant peut, entre autres, conserver un catalogue CAT de l'ensemble journaux d'événements accessibles PJI, PJ;, différer les destructions de journaux d'événements en fonction conditions globales, permettre l'accès interactif à des séquences déterminées des journaux d'événements conservés dans chaque sous-système, etc.
Le dialogue par notifications NOTi entre les sous-système d'archivage est représenté figure 3 et constitué de cinq notifications de dialogue décrites ci-dessous. Ces notifications de dialogue (LogReady, OpenLog, LogFiles, CIoseLog, FreeLog) sont échangées entre les agents moniteurs contrôle MO,, M02, M03 (Monitor) des différents sous- systèmes d'archivage SSA;. Le fonctionnement des notifications de dialogue est le suivant. La première notification LogReady permet de signaler la création d'un nouveau fichier de journal. Cette notification contient l'identité du sous- système d'archivage producteur et les caractéristiques du journal d'événements produit, à savoir la période d'archivage (début, durée) et la période de comptage. Cette notification est envoyée à tous les sous- systèmes d'archivage inscrits.
La deuxième notification OpenLog permet de demander la lecture d'une portion du journal d'événements désigné par ses caractéristiques. Cette notification est émise à destination de l'agent de contrôle MO du sous- système d'archivage SSA; responsable (émetteur de la notification LogReady correspondante) afin d'initialiser le traitement du journal d'événements. Un superviseur peut utiliser cette notification afin de rechercher des informations dans les journaux d'événements PJ1, PJ2, PJ3 conservés par chaque sous-système d'archivage. La troisième notification LogFiles est constituée informations de connexion pour la mise en place du flot de données fichier de journal centralisé d'événements log. Cette notification constitue la réponse à une notification ReadLog. quatrième notification CIoseLog indique la fin de lecture d'un fichier journal d'événements désigné par son nom. Cette notification est émise en réponse à la fin d'une session de lecture d'un journal d'événements. La cinquième notification FreeLog indique la libération par un sous- système consommateur d'un fichier de journal d'événements désigné par ses caractéristiques, cette notification est émise en réponse à la fin du traitement d'une notification LogReady. Le dialogue constitué des première et cinquième notifications de dialogue LogReady et FreeLog est réservé fonctionnement producteur/consommateur entre les sous-systèmes d'archivage. Chaque sous-système producteur (par exemple SSA1, figure1) notifie au moyen d'une première notification de dialogue LogReady, les sous- systèmes SSA2, SSA3 déclarés consommateurs de production d'un nouveau fichier PJ, de journal d'événements Chacun des sous-systèmes SSA2, SSA3 consommateur notifie au moyen d'une cinquième notification de dialogue FreeLog le sous-système producteur SSA, de la consommation du fichier correspondant. Par consommation on doit comprendre la transformation permanente réussie, c'est à dire la génération par le sous-système consommateur de toutes les informations nécessaires à une éventuelle reprise du procédé en cas d'arrêt ou de panne. Le producteur SSA, conserve le fichier jusqu'à ce que tous ses consommateurs SSA2, SSA3 aient envoyé une cinquième notification de dialogue FreeLog, et que la période conservation (fig. 4) du fichier soit écoulée. Le dialogue constitué deuxième, troisième, quatrième notifications OpenLog, LogFiles CloseLog est beaucoup plus ouvert, il permet la consultation d'une portion quelconque PJ; du journal d'événements conservé par un sous-système d'archivage SSA;. Ce dialogue peut-être utilisé par un client quelconque, indépendamment du fonctionnement producteur consommateur. Le transfert d'informations entre deux sous-systèmes d'archivage(par exemple SSA1, SSA2) est initié sous-système consommateur (SSA2 dans l'exemple de la figure 1). Lorsque celui-ci SSA2, peut prendre en compte une nouvelle période de journal d'événements pour la traiter, son moniteur émet une deuxième notification de dialogue OpenLog à destination du moniteur du sous-système producteur SSA1. L'architecture permet de connecter plusieurs sous- systèmes producteurs à un sous-système consommateur. Dans ce cas le moniteur du sous système consommateur attendra la disponibilité (temporisée) des différentes sources l'agent Client fusionnera les sources de journaux afin de rendre ce fonctionnement invisible aux agents de traitements. Le sous-système consommateur SSA2 analyse les informations transmises (date de début de période, durée) et répond avec une troisième notification de dialogue LogFiles contenant les informations d'accès aux données demandées (nom du ou des fichiers de log). Dans le cas d'accès partiel à un fichier de journal (début et/ou fin de période), des fichiers temporaires TPJ peuvent être générés.
Le moniteur M02 du sous-système consommateur SSA2 transmet ces informations à l'agent Client AC2 qui a la responsabilité de l'accès aux données, soit directement au(x) fichier(s) produit(s) PJ, par le producteur SSA, (agent FileClient), soit au travers d'une connexion TCP (agent TcpClient). L'agent client du sous-système consommateur SSA2 analyse le fichier PJ, du journal d'evénements reçu, et transforme les enregistrements en notifications d'enregistrement RecordNot (voir description ci-après des notifications de controle flux) qu'il transmet à la chaîne de traitement. Chaque enregistrement etant daté, l'agent client AC2 du sous-système consommateur SSA2 génère dynamiquement des notifications de synchronisation SyncNot et de vidange FIushNot (voir description ci-après des notifications de contrôle de flux) correspondant aux fins de périodes respectivement de comptage et d'archivage de ce sous-système (figure 5). Lors de la du transfert, l'agent client AC2 du sous-système consommateur SSA2 génère une notification de fin EOFNot (voir description ci-après des notifications de contrôle de flux) qu'il émet dans la chaîne de traitement du sous-système consommateur SSA2. Il émet alors vers le moniteur M02 du sous système consommateur SSA2 une notification de changement d'état (StatusNot, voir description ci-après des notifications de contrôle) signalant la de lecture du fichier. Sur réception de cette notification, le moniteur transmet au sous-système producteur SSAI une notification de dialogue CloseLog. Sur réception la quatrième notification de dialogue CloseLog, le producteur SSA, peut detruire les fichiers temporaires TPJ, éventuellement créés. Lorsque le journal d'événements aura été complètement traité par la chaîne de traitement sous-système consommateur SSA2 (la notification EOFNot ayant été traitee par le moniteur), la notification EOFNot atteignant le moniteur M02 du sous-système consommateur, celui-ci transmettra au sous-système producteur SSA, une notification de dialogue FreeLog. Comme cela est représenté figures 1 et 4 chaque sous-système d'archivage (SSA1, SSA2, SSA3, SSA;, etc.) est constitué ensemble d'agents : Moniteur, TcpServer, Client, agents de Traitements Flux (filtres, compteur) Rapporteur. Le moniteur (MO,, M02, M03, MO;,etc.) (agent Monitor), déjà décrit ci-dessus, a pour rôle d'interagir avec les composants extérieurs au sous- système d'archivage et de coordonner les composants intérieurs au sous- système d'archivage. II réalise donc trois actions. Premièrement il réagit aux premières notifications de dialogue LogReady qui indiquent disponibilité d'un nouveau fichier de journal d'événements. Deuxièmement, lorsque la machine de traitement de journal d'événements est libre et qu'il y a un fichier de journal d'événements à traiter, le moniteur MO; met en place l'accès au journal d'événements et réactive un agent client AC; afin d'accéder à ce journal d'événements. Le moniteur va dès lors suivre le traitement du journal d'événements les agents non persistants (remontée des notifications de contrôle vers moniteur), afin de contrôler une éventuelle reprise en cas de panne. Troisiemement, le moniteur signale la disponibilité des journaux d'événements produits à ses clients consommateurs, et il en gere l'accès. L'agent moniteur réagit aux notifications externes de dialogue de la façon suivante. Le traitement de ces notifications de dialogue décrit dans le dialogue entre sous-systèmes d'archivage décrit précédemment, on rappelle uniquement ici les principaux aspects. Lors de la réception d'une première notification LogReady provenant d'un autre sous-système, l'agent moniteur effectue la mémorisation du fichier de journal d'événements à consommer et le démarrage de l'analyse dès que possible (arrivée de tous les fichiers source de journaux d'événements correspondant à la période, fin de l'analyse précédente, etc.). Lors de la réception d'une cinquième notification de dialogue FreeLog provenant d'un autre sous-système, l'agent moniteur effectue la libération du fichier de journal d'événements correspondant. Lorsque tous les consommateurs auront libérés fichier et que sa période de conservation PC sera écoulée il pourra être detruit. Lors de la réception d'une deuxième notification OpenLog provenant d'un autre sous-système, l'agent moniteur effectue le verrouillage des fichiers de journal d'événements concernés, la génération des éventuels fichiers temporaires nécessaires dans le cas d'accès partiels à un (des) fichier(s) de journal d'événements et l'envoi d'une troisième notification LogFiles contenant les informations d'accès à la portion de journal d'événements souhaitée. Lors de la réception d'une troisième notification LogFiles provenant d'un autre sous- système, l'agent moniteur traite les informations pour la mise en place du flot de données d'accès à une portion de journal d'événements ( en réponse à une deuxième notification OpenLog). Lors de la réception d'une quatrième notification CloseLog provenant d'un autre sous-système, l'agent moniteur effectue fin de lecture d'une portion de journal d'événements et la libération eventuelle des fichiers temporaires TPJ créés ' cette occasion. L'agent moniteur réagit aux notifications internes de contrôle décrites ci-après remontées par l'agent rapporteur AR; (voir ' après) de la façon suivante. Lors de la réception d'une notification de gestion de flux FIushNot venant l'agent rapporteur du sous-système, l'agent moniteur récupère le fichier journal d'événements produit par le rapporteur, met à jour le catalogue CAT des journaux d'événements PJ; et notifie l'ensemble des consommateurs (agents moniteur des sous-système d'archivage consommateurs) qui en ont fait la demande. Lors de réception d'une notification de contrôle EOFNot venant de l'agent rapporteur du sous- système, l'agent moniteur MO; a entièrement analysé et transfomé le fichier de journal d'événements entrant, les informations de reprise ont été enregistrées par l'agent rapporteur. Ce fichier de journal d'événements peut- être libére l'agent moniteur envoie une cinquième notification de dialogue FreeLog a l'émetteur de la première notification LogReady correspondante. Les notifications de contrôle ou gestion de flux SyncNot et FIushNot remontées par l'agent rapporteur permettent au moniteur de conserver l'état courant sa chaîne de traitement. En particulier, notifications lui permettent de connaître l'état d'avancement du traitement cours. L'agent TcpServer (ATCP1, ATCP2, ATCP3, ATCPi, etc.) est un agent de gestion flux (voir définition ci-après) qui permet l'accès distant par TCP aux fichiers respectifs PJ1, PJ2, PJ3, PJi, de journal d'evénements d'un sous-système d'archivage producteur, par exemple SSA1, par des sous- systèmes distants, par exemple SSA2, SSA3. II est prévu pour interagir avec l'agent TcpClient décrit ci-dessous. L'agent Client AC,, AC2, AC3, ACi, a la responsabilité d'accéder au journal d'évenements entrant, par exemple PJI, de le transformer en notifications (une notification RecordNot par enregistrement) et de diffuser ces notifications dans la chaîne de traitement ATFi sous-système respectif, en l'occurrence SSA2, SSA3. Cet agent AC; est creé par le moniteur MOi pour le traitement d'un fichier de journal d'événements donné. Suivant le mode d'acces au fichier de journal d'événements, l'agent client ACi créé pourra être différente nature, par exemple (voir définition des agents de gestion de flux ci-après), de type FileClient pour un accès local ou de type TcpClient pour un accès distant via TCP. L'agent Client ACi a la responsabilité d'insérer les notifications de contrôle ou gestion de flux (SyncNot, FlushNot, EOFNot, etc.) dans le flux notifications d'événement. Les agents de traitements du flux (ATF, ATF2, ATF3, ATFi,etc.)comprennent les agents de filtrage, les agents de duplication, les agents de transformation et les agents compteurs.
Les agents de filtrage LogFilter (par exemple LFilo, LFili, LFi2o, figure 4) permettent la séparation du flux des enregistrements en fonction de l'évaluation d'une condition portant sur la valeur des champs de la notification. Les agents de duplication du flux permettent de dupliquer le flux des notifications afin d'effectuer différents traitements sur un même journal d'événements. Les agents de transformation permettent diverses modifications enregistrements du flux : soit modification de chaque enregistrement independamment, soit globalement (unification de divers enregistrements, etc Les agents compteurs LogCounter ( par exemple LCilo, LCi2o, LCilk) ont pour rôle de décompter les occurrences de chaque type d'enregistrement et de produire un résumé pour chaque période de comptage PC (fig. 5). permettent le masquage de certains champs des enregistrements afin limiter la dispersion. Ils fournissent un rapport condensé de tous événements qu'il ont pris en compte à chaque fin de période de comptage. L'agent rapporteur (AR,, AR2, AR3, AR;, etc.) est responsable de persistance. II produit les journaux d'événements ainsi que les informations de reprise en fonction des données transmises par les agents de traitement de flux. II collabore avec le moniteur afin d'assurer la persistance et la reprise du procédé. Dans un sous-système d'archivage SSAi, seuls les agents moniteurs MO; sont des agents persistants, tous les autres agents s'exécutent sur serveurs d'agents dont les propriétés de persistance et d'atomicité la réaction sont débrayées. Les notifications de contrôle ou de gestion de flux comprennent notifications RecordNot, SyncNot, FIushNot ou EOFNot et StatusNot fonctionnent de la manière suivante. La notification RecordNot véhicule un ou plusieurs enregistrement du fichier de journal d'événements. Chaque enregistrement contient la date, l'heure et le nombre d'occurrences de l'événement. La notification est spécialisée en fonction de la nature du journal d'événements traité. Dans le cas, par exemple, du journal Netwall relatif à un pare-feu, la notification d'enregistrement correspondante NWRecordNot contient les informations suivantes : protocole, @source, port source, @destination, port destination, interface d'entrée, etc. Les différentes notifications RecordNot peuvent avoir un cheminement très différent dans le graphe, représenté figure 4, des agents de traitement (filtres et compteurs) situés entre l'agent client AC; et l'agent rapporteur ARi du graphe.
Les notifications de contrôle ci-dessous permettent de bien séparer les notifications appartenant à des périodes de comptage PC différentes.
La notification de synchronisation SyncNot signale la fin d'une période de comptage PC. Cette notification est signalée par l'agent Client lorsque ce dernier détecte un changement de période de comptage lors de la lecture du flot de données. Elle parcourt l'ensemble des agents la chaîne de filtrage. Lors de sa réception, les agents compteurs LCijk génerent le rapport concernant la période écoulée et l'envoient via la notification SyncNot à l'agent rapporteur AR;. Ce dernier écrit l'ensemble des rapports reçus dans le fichier de journal correspondant, puis il transmet la notification au moniteur Moi; celui-ci valide alors la période écoulée. Ainsi grâce ' ce mécanisme, ' une panne survient, la reprise pourra s'effectuer à partir de cet état.
La notification FIushNot signale la fin d'une période d'archivage Elle est traitee par tous les agents filtres et compteurs comme notification synchronisation SyncNot. Lors de sa réception, l'agent rapporteur , enregistre les rapports dans le fichier de journal courant PJ;,, le ferme puis le nomme définitivement. II transmet alors la notification au moniteur MOi avec le nom du fichier résultat PJ;r généré. Le moniteur MO; enregistre la création du nouveau journal d'événements et la signale aux sous-systèmes d'archivage enregistrés.
La notification de contrôle EOFNot signale la fin du fichier en cours de traitement. Le système doit pouvoir enregistrer de manière persistante les résultats du traitement de ce fichier afin de pouvoir les utiliser en cas de reprise. Cette notification parcourt l'ensemble des agents de la chaîne de filtrage en collectant les informations qui seront nécessaires à chaque agent lors d'un éventuelle reprise après panne. Les agents d'interface TcpServer et Client (TcpClient, ou FileClient) sont des agents de gestion de flux. Le flux de données entre deux sous- systèmes d'archivage distants (par exemple SSAI producteur, SSA3 consommateur) est réalisé au moyen d'un flot (stream) TCP établi entre deux agents : TcpServer et TcpClient. Le rôle de l'agent TcpServer de SSA3 est d'assurer un service d'accès distant aux journaux d'événements conserves sur la machine productrice SSA1. Le rôle de l'agent TcpClient est d'établir la connexion avec le serveur TcpServer, puis d'analyser (parser) le flux des données et de générer notifications de contrôle interne correspondantes : RecordNot, pour un plusieurs enregistrements du journal d'événements ; SyncNot, à chaque fin de période de comptage détectée, par observation des dates de chaque enregistrement.; FIushNot, à chaque fin de période d'archivage ; EOFNot, lors la fin du flot d'entrée. Lorsque les sous-systèmes producteurs et consommateurs sont sur la meure machine, on peut utiliser à la place de TcpClient un agent FileClient qui realise la même fonction mais en accédant directement aux fichiers créés par sous-système d'archivage producteur. L'agent TcpServer permet le transfert de fichiers via TCP. Lors l'ouverture de la connexion, il récupère le chemin d'accès au fichier a transmettre, il renvoie sa taille puis transmet le contenu du fichier. L'agent TcpClient gère le transfert de fichiers via la connexion à l'agent TcpServer, il génère le flot de notifications de contrôle et de gestion à destination de la chaîne de traitement. L'ensemble des agents de traitement de flux appartiennent à la classe LogAgent. Cette classe implémente le comportement par défaut (initialisation, gestion du flux des enregistrements, etc.) des agents de traitement de journaux d'événements. Les agents filtres LogFilter, agents compteurs LogCounter, et les agents rapporteurs AR; héritent de classe LogAgent.
Une notification de commande d'initialisation InitNot permet l'initialisation flot de données. En particulier cela permet à chaque agent du graphe sous-système d'archivage de connaître ses sources de données, donc de savoir de qui il doit attendre des notifications de contrôles.
L'ensemble des agents de traitement de flux (LogFilter, LogCounter, etc.) hérite comportement de LogAgent concernant l'initialisation. sous-classes de LogAgent permettent d'assurer le contrôle de flux entre agents d'un sous-système d'archivage. II s'agit là de séparer les notifications RecordNot contenant des événements appartenant à des périodes de comptage PC différentes. Lorsqu'un agent reçoit une notification de contrôle de flux (SyncNot, FIushNot ou EOFNot) d'une de ses sources de données, l'agent, premièrement, bloque cette source dont les évenements sont postérieurs à la période en cours ; deuxièmement, il continue a traiter ses autres sources dont les événements sont antérieurs ; troisièmement, au fur et à mesure de l'arrivée des notifications de contrôle il bloque à une ses sources ; quatrièmement, lorsqu'il a reçu toutes les notifications de contrôle correspondant à un changement de périodede comptage, il transmet la notification à l'ensemble de ses destinations, puis il débloque ses sources.
Ce comportement peut-être réalisé par les sous-classes de LogAgent en surchargeant diverses méthodes. Ainsi, lors chaque acceptation (par réception d'une notification de contrôle dont l'estampille correspond au traitement en cours, car dans certains , plusieurs notifications de contrôle peuvent arriver sur une source alors qu'une autre est en attente) d'une notification de contrôle, une méthode correspondant au type de notification est appelée. De même, lorsque toutes les notifications de controle correspondant à un changement de période sont arrivees, une autre méthode est appelée.
L'agent de la classe LogFilter permet de séparer le des enregistrements en deux, en fonction du résultat de l'évaluation d'une condition sur les données de chacun des enregistrements.
agents de traitement du flux réagissent aux notifications de contrôle flux SyncNot, FIushNot et EOFNot de la manière suivante. Le comportement d'un agent LogFilter est identique à celui d'un agent LogAgent dont il hérite. Lors de la réception d'une notification RecordNot, l'agent évalue une condition prédéterminée sur chacun des enregistrements. Il transmet alors sur l'une de ses sorties (accept) une notification RecordNot contenant les enregistrements acceptés, c'est-à-dire les enregistrements dont l'évaluation est vraie et sur l'autre (reject) une notification contenant les enregistrements refusés.
L'évaluation d'un enregistrement est réalisée par la fonction "eval" déclarée par la classe LogFilter. Cette fonction doit être implantée par les sous-classes de LogFilter. Dans le cas de l'analyse du journal d'un logiciel pare-feux par exemple, cette fonction évalue une expression booléenne portant sur l'ensemble des champs d'un enregistrement NWRecord : date, heure, protocole, @ source, port source, @ destination, port destination, interface d'entrée, n de règle Netwall déclenchée, etc.
L'agent compteur agrégateur LogCounter applique un masque défini par la fonction "mask" sur chaque enregistrement, et pour chaque periode de comptage il regroupe les enregistrements identiques. Au final, il genère un rapport contenant les différents enregistrements et le nombre d'occurrences de chacun.
Pour les notifications de contrôle de flux, cet agent compteur LogCounter hérite du comportement de LogAgent. Lorsque toutes les occurrences d'une notification SyncNot ou FIushNot lui sont parvenues, génère un rapport concernant la période de comptage écoulée. Pour notifications de contrôle de flux SyncNot, FIushNot , il y a génération l'agent rapport (SyncNot ou FIushNot selon le cas) concernant la derniere période temps écoulée. L'agent nettoie ensuite ses tables afin de pouvoir décompter la période suivante. Pour les notifications de contrôle de flux EOFNot, il y a génération par l'agent d'un rapport contenant les informations de reprise concernant la période de temps courante (du début de cette période à la fin du fichier de journal d'évènements). Pour les notifications de contrôle flux RecordNot il y a application par l'agent d'une fonction de masquage décompte de la notification selon sa valeur. L'agent compteur LogCounter comporte un sélecteur de masquage. Le masquage est réalisé par l'appel de la fonction de masquage "mask" définie par la classe LogAgent. Seul le champ "date" du journal est pris en compte à ce niveau. Le masque de date, s'il est défini, donne la précision en secondes à conserver sur l'enregistrement. Par défaut, tous les enregistrements sont datés de la date de début de période. La fonction de masquage "mask" doit être surchargée par les sous-classes. Le masquage consiste à supprimer un ou plusieurs champs résultants ou à appliquer un masque spécifique à la nature champ (date, ou adresse IP par exemple). La fonction d'agrégation offerte l'agent compteur consiste à comptabiliser les enregistrements identiques après masquage. deux fonctions permettent, en supprimant la partie très variable (dispersee) d'un enregistrement, d'obtenir un bon taux de compression de l'information du journal d'événements tout en préservant sa pertinence. Dans le cas du traitement de log d'un logiciel pare-feux par exemple, le sélecteur est essentiellement constitué d'un ensemble de valeurs booléennes, une pour chaque champ de l'enregistrement indiquant si le champ doit être ou non conservé. Les champs d'adresse (source, destination) sont eux masqués par un masque binaire similaire au masque réseau.
Le rôle de chaque agent rapporteur ARi est la gestion informations persistantes, celles-ci sont de deux ordres, premièrement gestion des fichiers de journaux d'événements générés à chaque fin période d'archivage, qui constituent l'information utile du système ; deuxièmement la gestion des informations de reprise en cas de pannes.
A chaque fin de période de comptage, les informations générées sont enregistrées dans le fichier de journal d'événements en cours construction (voir fin de période 2 de la figure 5). Ceci permet, en cas panne, de reprendre uniquement le traitement du journal d'événements depuis le début de la période de comptage en cours.
A fin du traitement d'un fichier de journal d'événements, les informations emmagasinées par les compteurs depuis le début de la période de comptage en cours et la fin du fichier sont enregistrés dans un fichier spécifique de reprise SJ (voir fin de période 3 de la figure 5). Ceci permet libérer le fichier de journal d'événements traité sans risquer de perdre informations non encore enregistrées dans le journal d'événements sortant.
La persistance des informations d'état est gérée par l'agent moniteur. Lors de la réception d'une notification de contrôle de flux (SyncNot, FIushNot, EOFNot), l'agent rapporteur ARi mémorise le rapport associé.
Lorsque toutes les occurrences d'une notification SyncNot FIushNot sont parvenues à l'agent rapporteur ARi, il enregistre informations relatives à la période dans le fichier de journal d'événements courant. Dans le cas d'une notification SyncNot, l'agent rapporteur ARi contente alors de transmettre (forward) cette notification à l'agent moniteur du même sous-système. Dans le cas d'une notification FlushNot, l'agent rapporteur ARi génère le fichier de journal d'événements correspondant à la période d'archivage en cours (renommage atomique du fichier travail) et transmet les informations (à savoir, période d'archivage, du fichier généré, etc) le concernant au moniteur par l'intermédiaire d'une notification FIushNot (voir fin de période 1 de la figure 5). Lorsque toutes les occurrences d'une notification EOFNot sont parvenues à l'agent rapporteur celui-ci génère un fichier de reprise SJ contenant l'ensemble des rapports lui ont été transmis (voir fin de période 3 de la figure 5). Ces informations concernent la période de temps courante, du début de la période à la fin du fichier journal d'événements, elles permettent une reprise du traitement en cas panne et d'indisponibilité des sources d'information.
Bien qu'étant produit régulièrement de manière asynchrone, il est assez probable que les fichiers de journal d'événements correspondent exactement aux périodes d'archivage. En conséquence, lors de la fin du journal d'événements entrant, il est nécessaire de sauvegarder l'analyse de la période écoulée depuis la fin de la dernière période de comptage PC.
En effet, dès la fin de l'analyse du fichier de journal d'événements entrant celui-ci pourra être détruit par son sous-système d'archivage, il faut donc mémoriser de manière persistante les informations extraites de ce fichier ; ces informations sont de trois types ; premièrement les informations déjà stockées dans un fichier PJ;r de journal d'événements produit (voir fin de période 1 de la figure 5), et donc pérennes ; deuxièmement les informations stockées dans le fichier de journal d'événements en cours de production PJic (voir fin de période 2 de la figure 5) que l'on peut considérer comme pérennes elles aussi, il s'agit des informations concernant les périodes de comptage passées dont les compteurs ont déjà envoyé les rapports à l'agent rapporteur ARi ; troisièmement les informations traitées par les compteurs mais encore non synthétisées sous forme de rapport envoyé à l'agent rapporteur ARi (voir fin de période 3 de la figure 5).
Ce sont ces dernières informations qu'il faut rendre pérennes avant de notifier la fin de traitement du fichier source ; pour ce faire chaque agent compteur LC;jk envoie un état intermédiaire à l'agent rapporteur AR; afin qu'il le stocke (notification EOF). Ainsi le système d'archivage décrit permet l'acquisition, cette phase consistant à récupérer une partie du journal d'évenements dans un fichier afin d'en permettre le traitement, la transformation peut consister à filtrer et/ou transformer l'information contenue dans fichier de journal d'événements, et l'archivage qui consiste à conserver les fichiers de journal centralisé d'événements log afin d'en permettre la consultation durant un temps. La phase de transformation peut avoir entre autres buts, de réduire le volume d'informations contenues dans le fichier de journal d'événements en ne conservant que l'information pertinente. Cette réduction peut essentiellement s'opérer de deux manières, premièrement destructive, en supprimant de l'information jugée non pertinente événements complets, ou champs particuliers d'événements ; deuxièmement cumulative, en agrégeant des événements de nature identique. Un autre but la phase de filtrage est de rechercher des événements, ou des sequences d'événements, particuliers à des fins d'analyse, de génération d'alertes, de facturation, etc.

Claims (1)

<B><U>REVENDICATIONS</U></B> 1 - Procédé de gestion et mise à jour d'un journal d'événements sous-systeme d'archivage appartenant à un réseau reliant une pluralité sous-systemes d'archivage comprenant des moyens de mémorisation, moyens permettant de réveiller un agent ou un service en fonction événement déterminé, chacun des sous-systèmes d'archivage etant responsable d'un niveau de journal d'événements, sur chacun des sous systèmes d'archivage fonctionne au moins une pluralité d'agents autonomes communiquant par notifications pour constituer une interface identique entre tous les sous systèmes et destinée à envoyer des journaux d'événements caractérisé en ce que la gestion du journal d'événements consiste en - une étape d'acquisition, cette phase consistant à récupérer une partie du journal d'événements dans un fichier afin d'en permettre le traitement ; - une étape de filtrage consistant à sélectionner et transformer l'information contenue dans le fichier de journal d'événements. - une étape d'archivage consistant à conserver les fichiers de journal d'événements afin d'en permettre la consultation durant un temps donné constituant la période de conservation ; 2 - Procédé de gestion et mise à jour d'un journal d'événements selon la revendication 1, caractérisé en ce qu'il comporte une étape de conservation d'un état de la machine de traitement, dans une partie persistante du sous-système d'archivage 3 - Procédé de gestion et de mise à jour d'un journal d'événements selon la revendication 1, caractérisé en ce qu'il comporte: - une étape d'émission par un agent moniteur d'au moins un sous- systeme consommateur d'une notification OpenLog à destination agent moniteur du sous-système producteur. - une étape d'analyse par le sous-système producteur des informations transmises (date de début de période, durée) et - une étape de réponse par le sous-système producteur avec une notification LogFiles contenant les informations d'accès données demandées par le ou les sous-systèmes consommateurs (nom du des fichiers de log). 4 - Procédé de gestion et de mise à jour d'un journal d'événements selon la revendication 3, caractérisé en ce qu'il comporte une étape de transmission par le moniteur des informations à un agent Client a la responsabilité de l'accès aux données : soit directement sur le(s) fichier(s) produit(s) (agent FileClient), soit au travers d'une connexion (agent TcpClient). 5 - Procédé de gestion et de mise à jour d'un journal d'évenements selon la revendication 4, caractérisé en ce qu'il comporte une étape d'analyse par un agent client du fichier de journal d'événements reçu, et de transformation des enregistrements en des notifications d'enregistrements RecordNot qu'il transmet à la chaîne de traitement, chaque enregistrement étant daté, l'agent client génère dynamiquement des notifications de contrôle de SyncNot et FIushNot correspondant aux fins de périodes. 6 - Procédé de gestion et de mise à jour d'un journal d'événements selon la revendication 4, caractérisé en ce qu'il comporte une etape de géneration, lors de la fin du transfert, d'une notification EOFNot l'agent client, notification qu'il émet dans la chaîne de traitement, cet agent emettant alors vers le moniteur une notification de changement d'état (StatusNot) signalant la fin de lecture du fichier, sur réception de cette notification le moniteur transmet au sous-système producteur une notification CIoseLog. - Procédé de gestion et de mise à jour d'un journal d'événements selon revendication 3, caractérisé en ce qu'il comporte une étape de destruction par le sous-système producteur des fichiers temporaires éventuellement créés sur réception d'une notification CIoseLog. 8 - Procédé de gestion et de mise à jour d'un journal d'événements selon la revendication 3, caractérisé en ce qu'il comporte une étape de transmission au sous-système producteur par le moniteur d'une notification FreeLog, lorsque le journal centralisé d'événements aura été complètement traité la chaîne de traitement, la notification EOFNot ayant ôte traitée par le moniteur. - Procédé de gestion et de mise à jour d'un journal d'evénements selon revendication 8 ou 3, caractérisé en ce que lors de réception d'une notification LogReady provenant d'un autre sous-système producteur, l'agent moniteur du sous-système consommateur effectue la mémorisation du fichier de journal d'événements à consommer et le démarrage de l'analyse dès que possible (arrivée de tous les fichiers source de journaux d'événements correspondant à la période, fin de l'analyse précédente, etc.), lors de la réception de la notification FreeLog provenant d'un autre sous- système producteur, l'agent moniteur du sous-système consommateur effectue la libération du fichier de journal d'événements correspondant, lors de la réception d'une notification OpenLog provenant d'un autre sous- système, l'agent moniteur du sous-système consommateur effectue le verrouillage des fichiers de journal d'événements concernés, génération des éventuels fichiers temporaires nécessaires dans le cas d'acces partiels à un (des) fichier(s) de journal d'événements et l'envoi d'une notification LogFiles contenant les informations d'accès à la portion de journal d'événements souhaitée, lors de la réception d'une notification LogFiles provenant d'un autre sous-système, l'agent moniteur du sous-système consommateur traite les informations pour la mise en place du flot de données d'accès à une portion de journal d'événements ( en réponse à une notification openLog), lors de réception d'une notification CIoseLog provenant d'un autre sous-systeme, l'agent moniteur du sous-système consommateur effectue la fin de lecture d'une portion de journal d'événements et la libération éventuelle des fichiers temporaires créés à cette occasion. 10 - Procédé de gestion et mise à jour d'un journal d'événements selon une des revendications 3 à caractérisé en ce que chaque sous- système producteur (par exemple SSA,) notifie au moyen d'une notification LogReady les sous-systèmes SSA2, SSA3 déclarés consommateurs de la production d'un nouveau fichier PJ1 de journal d'événements, chacun des sous-systèmes SSA2, SSA3 consommateur notifiant au moyen d'une notification FreeLog le sous-système producteur SSA, de la consommation du fichier correspondant. 11 - Procédé de gestion et mise à jour d'un journal d'événements selon la revendication 10, caracterisé en ce que le producteur SSA, conserve le fichier jusqu'à ce que tous ses consommateurs SSA2, SSA3 aient envoyé une notification FreeLog, et que 1a période de conservation du fichier soit écoulée. 12 - Procédé de gestion mise à jour d'un journal d'événements selon la revendication 10, caracterisé en ce que lorsque le sous-système consommateur SSA2 peut prendre en compte une nouvelle période de journal d'événements pour la traiter, son moniteur émet une notification OpenLog à destination du moniteur du sous-système producteur SSA,; - le sous-système producteur SSA, analyse les informations transmises (date de début période, durée) et répond avec une notifications LogFiles contenant informations d'accès aux données demandées (nom du ou des fichiers de log), le moniteur MO, du sous- système producteur SSA, transmet informations à l'agent Client AC2 qui a la responsabilité de l'accès aux données, soit directement au(x) fichier(s) produit(s) PJ1, soit au travers d'une connexion TCP ; - l'agent client du sous-système consommateur SSA2 analyse le fichier PJ1 de journal d'evénements reçu, et transforme les enregistrements en notifications d'enregistrement RecordNot qu'il transmet à la chaîne de traitement ; - lors de la transfert, l'agent client AC2 du sous-système consommateur SSA2 genere une notification de fin EOFNot qu'il émet dans la chaîne de traitement sous-système consommateur SSA2, il émet alors vers le moniteur M02 du sous-système consommateur SSA2 une notification de changement d'état (StatusNot) signalant la fin de lecture du fichier, sur réception de cette notification le moniteur M02 transmet au sous-système producteur SSA, une notification CIoseLog ; - sur réception de la notification CIoseLog, le producteur SSA, peut détruire les fichiers temporaires éventuellement créés ; - lorsque le journal d'événements aura été complètement traité par la chaîne de traitement du sous-système consommateur SSA2, la notification EOFNot atteignant le moniteur celui-ci transmettra au sous-système producteur SSA, une notification FreeLog. 13 - Système de gestion et mise à jour d'un journal d'événements, caractérisé en ce qu'il est constitué de composants configurables de haut niveau pouvant être assemblés entre eux, appelés sous-systèmes d'archivage, chacun des sous-système d'archivage étant responsable d'un niveau de journal d'événements, l'architecture interne du sous-système d'archivage étant composée d'agents autonomes et constituée d'un agent moniteur et d'autres agents, les agents et les sous-systèmes communiquant grâce à un dialogue spécifique, par notifications, pour constituer une interface identique entre tous les sous systèmes. 14 - Système gestion et mise à jour d'un journal d'événements selon la revendication 3, caractérisé en ce que chaque sous-système d'archivage est constitué ensemble d'agents - un agent moniteur (agent Monitor), , dont le rôle est d'interagir avec les composants extérieurs (sous-systèmes) et de coordonner les composants intérieurs (agents d'un sous-système) ; - un agent TcpServer pour permettre l'accès aux fichiers de journal d'événements d'un sous-système d'archivage par des sous-systèmes distants et qui est prévu pour interagir avec l'agent TcpClient ; - un agent Client (TcpClient, FileClient, etc.) qui a la responsabilité d'accéder au journal d'événements entrant, de le transformer en notifications (une notification RecordNot par enregistrement) et de diffuser ces notifications dans la chaîne de traitement . des agents de traitements du flux, et - un agent rapporteur qui est responsable de la persistance, pour produire journaux d'événements ainsi que les informations de reprise en fonction données transmises par chaque agent compteur, cet agent rapporteur collaborant avec l'agent moniteur afin d'assurer persistance et la reprise procédé.
1 - Système de gestion et mise à jour d'un journal d'événements selon la revendication 14, caractérisé en ce qu' il utilise des agents autonomes communiquant par notifications. 16 Système de gestion et mise à jour d'un journal d'événements selon la revendication 13 ou 14, caractérisé en ce que dialogue par notifications NOTi entre les sous-systèmes d'archivage SSA; constitué de cinq notifications (A) LogReady, FreeLog permettant le dialogue producteur/consommateur entre sous-systèmes d'archivage, (B) OpenLog, LogFiles et CloseLog permettant l'accès à portion du journal sous-système d'archivage. Ces notifications de dialogue sont échangées entre les agents moniteurs , M02, M03 (Monitor) des différents sous système d'archivage ;. 17 Système de gestion et mise à jour d'un journal d'évenements selon la revendication 16-A, caractérisé en ce que la notification LogReady permet de signaler la création d'un nouveau fichier de journal, cette notification contient l'identité du sous-système d'archivage producteur et les caractéristiques du journal d'événements produit, à savoir la période d'archivage (début, durée), et la période de comptage, cette notification est envoyée à tous les sous-systèmes d'archivage inscrits. 18- Système de gestion et mise à jour d'un journal d'événements selon la revendication 16-B, caractérisé en ce que la notification OpenLog permet de demander la lecture d'une portion du journal d'événements désigné par ses caractéristiques, cette notification est émise à destination de l'agent de contrôle du sous-système d'archivage responsable afin d'initialiser le traitement du journal d'événements. Cette notification peut-être utilisée par un superviseur afin de rechercher informations dans les journaux d'événements PJ1, PJ2, PJ3 conservés chaque sous-système d'archivage. 19 - Système de gestion et mise à jour d'un journal d'événements selon la revendication 16-B, caractérisé en ce que la notification LogFiles est constituée informations de connexion pour la mise en place du flot de données fichier de journal d'événements log, cette notification constitue la réponse a notification OpenLog. 20 - Système de gestion et mise à jour d'un journal d'événements selon la revendication 16-B, caractérisé en ce que la notification CIoseLog indique la fin lecture d'un fichier de journal d'événements désigne par son nom, cette notification est émise en réponse à la fin d'une session lecture d'un journal d'événements. 21 - Système de gestion et mise à jour d'un journal d'événements selon la revendication 16-A, caractérisé en ce que la notification FreeLog indique la libération par un sous-système consommateur d'un fichier journal d'événements désigné par ses caractéristiques, cette notification émise en reponse à la fin du traitement d'une notification LogReady. 22 - Système de gestion et mise à jour d'un journal d'événements selon la revendication 14, caractérisé en ce que l' agent client est crée temporairement par l'agent moniteur pour le traitement d'un fichier de journal d'événements donné, suivant le mode d'accès au fichier de journal d'événements, l'agent créé pourra être de différente nature : FileClient pour un accès local, TcpClient pour un accès distant via TCP par exemple. 23 Système de gestion et mise à jour d'un journal d'événements selon la revendication 14, caractérisé en ce que l'agent Client a responsabilité d'insérer des notifications de contrôles de flux (SyncNot, FlushNot, EOFNot, etc.) dans le flux des notifications d'événement 24 - Système selon la revendication 14, caractérisé en ce que agents de traitement de flux peuvent être de nature - agent de filtrage (LogFilter par exemple) permettant la séparation du flux enregistrements en fonction de l'évaluation d'une condition portant sur valeur des champs de la notification; - agent de duplication du flux permettant d'effectuer différents traitements sur un même journal d'événements; - agent de transformation permettant diverses modifications enregistrements du flux : modification de chaque enregistrement indépendamment, unification de divers enregistrements, etc; - agent compteur (LogCounter) dont le rôle est de décompter les occurrences de chaque type d'enregistrement et de produire un résumé pour chaque période de comptage, de permettre le masquage de certains champs des enregistrements afin de limiter la dispersion et de fournir un rapport condense de tous les événements qu'il ont pris en compte à chaque fin de période comptage. - Système de gestion et mise à jour d'un journal d'événements selon la revendication 14, caractérisé en ce que seuls agents moniteurs sont des agents persistants, tous les autres agents exécutent sur des serveurs d'agents dont les propriétés de persistance d'atomicité de la réaction sont débrayées. - Système de gestion et mise à jour d'un journal d'événements selon des revendications 13 à 25, caractérisé en ce qu' un superviseur administre une pluralité de sous-systèmes d'archivage.
FR0003386A 2000-03-16 2000-03-16 Procede de transformation, de transport et d'analyse de fichiers de journaux d'evenements (logs) Expired - Lifetime FR2806494B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0003386A FR2806494B1 (fr) 2000-03-16 2000-03-16 Procede de transformation, de transport et d'analyse de fichiers de journaux d'evenements (logs)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0003386A FR2806494B1 (fr) 2000-03-16 2000-03-16 Procede de transformation, de transport et d'analyse de fichiers de journaux d'evenements (logs)

Publications (2)

Publication Number Publication Date
FR2806494A1 true FR2806494A1 (fr) 2001-09-21
FR2806494B1 FR2806494B1 (fr) 2005-01-21

Family

ID=8848170

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0003386A Expired - Lifetime FR2806494B1 (fr) 2000-03-16 2000-03-16 Procede de transformation, de transport et d'analyse de fichiers de journaux d'evenements (logs)

Country Status (1)

Country Link
FR (1) FR2806494B1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2927819A1 (fr) * 2014-04-04 2015-10-07 Siemens Aktiengesellschaft Procédé de traitement automatique de plusieurs fichiers journaux d'un système d'automatisation

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0759591A1 (fr) * 1995-08-18 1997-02-26 International Business Machines Corporation Service de gestion d'événements
US5655081A (en) * 1995-03-08 1997-08-05 Bmc Software, Inc. System for monitoring and managing computer resources and applications across a distributed computing environment using an intelligent autonomous agent architecture
GB2328043A (en) * 1997-07-26 1999-02-10 Ibm Managing a distributed data processing system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5655081A (en) * 1995-03-08 1997-08-05 Bmc Software, Inc. System for monitoring and managing computer resources and applications across a distributed computing environment using an intelligent autonomous agent architecture
EP0759591A1 (fr) * 1995-08-18 1997-02-26 International Business Machines Corporation Service de gestion d'événements
GB2328043A (en) * 1997-07-26 1999-02-10 Ibm Managing a distributed data processing system

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2927819A1 (fr) * 2014-04-04 2015-10-07 Siemens Aktiengesellschaft Procédé de traitement automatique de plusieurs fichiers journaux d'un système d'automatisation
WO2015150164A1 (fr) 2014-04-04 2015-10-08 Siemens Aktiengesellschaft Procédé de traitement automatique d'un nombre de fichiers journaux d'un système d'automatisation
US11113236B2 (en) 2014-04-04 2021-09-07 Siemens Aktiengesellschaft Method for automatic processing of a number of protocol files of an automation system

Also Published As

Publication number Publication date
FR2806494B1 (fr) 2005-01-21

Similar Documents

Publication Publication Date Title
US11194552B1 (en) Assisted visual programming for iterative message processing system
US10775976B1 (en) Visual previews for programming an iterative publish-subscribe message processing system
EP0820013B1 (fr) Procédé de surveillance en temps réel d&#39;un système informatique pour son administration et l&#39;aide à sa maintenance en phase d&#39;exploitation
EP0572307B1 (fr) Système logiciel à objets répliqués exploitant une messagerie dynamique, notamment pour installation de contrÔle/commande à architecture redondante
US8707336B2 (en) Data event processing and application integration in a network
EP0822498A1 (fr) Procédé de surveillance d&#39;une pluralité de types d&#39;objets d&#39;une pluralité de noeuds à partir d&#39;un noeud d&#39;administration dans un système informatique
WO2021222395A1 (fr) Interfaces de double programmation textuelle/graphique de pipelines de traitement de données de diffusion en continu
US20100293147A1 (en) System and method for providing automated electronic information backup, storage and recovery
US10698745B2 (en) Adapter extension for inbound messages from robotic automation platforms to unified automation platform
JP2010539572A (ja) ネットワークを管理する方法、ネットワーク管理システム及びコンピュータ・プログラム
EP3543837A1 (fr) Mise en file d&#39;attente et boucle de rétroaction simultanées de commande de contrôle dans l&#39;automatisation unifiée
WO2007036932A2 (fr) Systeme de gestion de table de donnees et methodes associes
JP7254975B2 (ja) 実行可能論理を用いて構造化データアイテムを処理するためのキーベースのロギング
CN110351532B (zh) 视频大数据云平台云存储服务方法
FR2684472A1 (fr) Systeme expert supportant les contraintes du temps reel.
CN110928934A (zh) 一种用于业务分析的数据处理方法和装置
CN113486095A (zh) 一种民航空管跨网安全数据交换管理平台
WO2009053356A1 (fr) Procede de gestion d&#39;operations d&#39;administration, de maintenance et de maintien en condition operationnelle, entite de gestion, et produit programme d&#39;ordinateur correspondant
FR2806494A1 (fr) Procede de transformation, de transport et d&#39;analyse de fichiers de journaux d&#39;evenements (logs)
US11811894B2 (en) Reduction of data transmissions based on end-user context
CN115333942B (zh) 事件重试方法及装置、存储介质及电子设备
US10353792B2 (en) Data layering in a network management system
EP2109979B1 (fr) Procédé et dispositif de gestion de connexions dans un réseau de télécommunications
CA2389530A1 (fr) Systeme et procedes destines aux files d&#39;attente de messages
FR3089500A1 (fr) système D’AIDE A LA RESOLUTION de PANNES D’AERONEFS

Legal Events

Date Code Title Description
TP Transmission of property
TP Transmission of property
PLFP Fee payment

Year of fee payment: 17

PLFP Fee payment

Year of fee payment: 18

PLFP Fee payment

Year of fee payment: 19

PLFP Fee payment

Year of fee payment: 20