FR3075999A1 - Procede de controle de la gestion des traces d'evenements dans l'execution d'une application informatique sur une machine informatique - Google Patents
Procede de controle de la gestion des traces d'evenements dans l'execution d'une application informatique sur une machine informatique Download PDFInfo
- Publication number
- FR3075999A1 FR3075999A1 FR1763238A FR1763238A FR3075999A1 FR 3075999 A1 FR3075999 A1 FR 3075999A1 FR 1763238 A FR1763238 A FR 1763238A FR 1763238 A FR1763238 A FR 1763238A FR 3075999 A1 FR3075999 A1 FR 3075999A1
- Authority
- FR
- France
- Prior art keywords
- traces
- event
- manager
- events
- internal
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 125
- 238000004883 computer application Methods 0.000 title claims abstract description 12
- 230000008569 process Effects 0.000 claims abstract description 96
- 238000001914 filtration Methods 0.000 description 10
- 230000008859 change Effects 0.000 description 6
- 230000003993 interaction Effects 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 4
- 238000012876 topography Methods 0.000 description 2
- 244000309464 bull Species 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 239000010979 ruby Substances 0.000 description 1
- 229910001750 ruby Inorganic materials 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
- G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
-
- 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
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/86—Event-based monitoring
-
- 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/865—Monitoring of software
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Mathematical Physics (AREA)
- Debugging And Monitoring (AREA)
Abstract
L'invention concerne un procédé de contrôle de la gestion des traces d'événements dans l'exécution d'une application informatique (2) sur une machine informatique (1), comprenant : une étape de gestion des traces d'événements incluant : une première communication, interne à cette machine informatique (1), entre d'une part l'application (2) et d'autre part son gestionnaire (3) de traces d'événements, de manière à générer les traces d'événements, une deuxième communication, interne à cette machine informatique (1), entre d'une part un port interne du gestionnaire (3) de traces d'événements et un ou plusieurs ports internes d'un ou de plusieurs processus receveurs (4, 5) stockant les traces d'événements en provenance du gestionnaire (3) de traces d'événements, une étape de contrôle de la gestion des traces d'événements incluant : l'ouverture d'au moins un port interne de contrôle (6, 8) du gestionnaire (3) des traces d'événements, une troisième communication, entre d'une part un contrôleur de gestion (7) des traces d'événements localisé hors de l'application (2) et hors du gestionnaire (3) des traces d'événements et d'autre part le ou les processus receveurs (4, 5), par un ou plusieurs messages envoyés via ledit port interne de contrôle (6, 8) du gestionnaire (3) des traces d'événements, cette troisième communication permettant au contrôleur de gestion (7) des traces d'événements de reconfigurer dynamiquement le ou les processus receveurs (4, 5) sans reconfigurer l'application (2) et sans redémarrer l'application (2).
Description
PROCEDE DE CONTROLE DE LA GESTION DES TRACES D’EVENEMENTS DANS L’EXECUTION D’UNE APPLICATION INFORMATIQUE SUR UNE MACHINE INFORMATIQUE
DOMAINE DE L’INVENTION L’invention concerne le domaine des procédés de contrôle de la gestion des traces d’événements dans l’exécution d’une application informatique sur une machine informatique.
CONTEXTE DE L’INVENTION
Un mécanisme dit de « log », c’est-à-dire un mécanisme de gestion de traces d’événements, permet de tracer ce qui se passe au sein d’une application, en particulier dans le but pouvoir trouver plus rapidement la source d’un problème lorsqu’il survient. Un « log » contient un ensemble d’informations, notamment telles que le nom du programme, la date d’émission du « log », un message et un niveau de criticité. Un « log » est souvent soit affiché directement à rutilisateur sur la console, soit redirigé dans un fichier ou dans plusieurs fichiers. De manière générale, la configuration des « logs » concernant le niveau de détails, de criticité et les sorties à utiliser est déterminée au lancement du programme ou de l’application. Puis, pour modifier cette configuration, il faut stopper et relancer le programme ou l’application avec la nouvelle configuration. Ensuite, lorsqu’un programme ou une application s’exécute sur une machine distante, souvent les « logs » sont redirigés vers un fichier et l’utilisateur ne dispose pas de moyen efficace pour les visionner en temps réel tout en modifiant le filtrage sur ces « logs », en utilisant un mécanisme basé par exemple sur le niveau de criticité ou sur le nom du module qui est à l’origine du « log ».
Selon un premier art antérieur, par exemple décrit dans la demande de brevet WO2016038272, incorporée par référence, il est connu un procédé de gestion de traces d’événements incluant un procédé de contrôle de gestion des traces d’événements. Des processus receveurs stockent les traces d’événements en provenance du gestionnaire de traces d’événements. Le déroulement de la génération des traces d’événements par le gestionnaire de traces d’événements et de l’utilisation de ces traces d’événements par les processus receveurs correspond à une configuration de la gestion de ces traces d’événements relative à l’application concernée. Un contrôleur de gestion de traces d’événements permet la surveillance du déroulement de la gestion des traces d’événements en recevant des informations de la part du gestionnaire de traces d’événements, par une communication réceptrice.
Cependant, il n’est pas possible de modifier cette configuration pendant l’exécution de l’application. H faut d’abord attendre l’arrêt de l’application, puis reconfigurer l’application et relancer l’application. Il n’est donc pas possible de modifier cette configuration sans arrêter ni sans perturber l’exécution de cette application. En effet, la seule communication émettrice que peut effectuer le contrôleur de gestion de traces d’événements à destination des processus receveurs en passant par le gestionnaire de traces d’événements est une communication passant par l’application en train d’être exécutée, à laquelle est associé le gestionnaire de traces d’événements, entraînant alors l’arrêt ou la perturbation de l’exécution de cette application. La capacité d’action sur les processus receveurs associés ou la capacité de reconfiguration des processus receveurs associés de reconfiguration des processus receveurs associés sont donc limitées.
Selon un deuxième art antérieur, il existe une bibliothèque de gestion de logs dénommée « Log4j » par exemple disponible à l’adresse internet suivante : http://logging.apache.Org/log4j/2.x/manual/index.html
Cette bibliothèque de gestion de « logs » est utile mais elle ne fournit pas de reconfiguration à distance permettant d’ajouter à la volée des sorties de « logs », et elle ne propose pas non plus de mécanisme permettant, aussi bien sur la machine locale que sur des machines distantes, à un client de se connecter aux applications distantes bien que celles-ci n’aient pas été configurées a priori, tout en évitant de redémarrer les applications pour pouvoir effectuer la gestion de traces d’événements. Ce deuxième art antérieur n’est globalement pas meilleur que le premier art antérieur.
Selon un troisième art antérieur, il existe une autre bibliothèque de « log », elle aussi en Java, qui est dénommée la bibliothèque « java.util.logging », disponible à l’adresse internet suivante : https://does.oracle.eom/javase/7/does/api/java/util/logging/paekage-summ.ary.html
Cette autre bibliothèque présente les mêmes caractéristiques que la bibliothèque « Log4j », qui est d’ailleurs basée en grande partie sur elle, et elle présente donc les mêmes limitations. De manière plus générale, d’autres langages de programmation, comme par exemple « Python » et « Ruby », proposent également une bibliothèque de « log » proposant des fonctionnalités avancées telles que la mise en place de gestionnaires de traces d’événements et de contrôleurs de gestionnaires de traces d’événements, de port interne (« socket » en langue anglaise) d’envoi et de réception des « logs », avec généralement une fonctionnalité de filtrage. Ce troisième art antérieur n’est globalement pas non plus meilleur que le premier art antérieur.
RESUME DE L’INVENTION
Le but de la présente invention est de fournir un procédé de contrôle de gestion des traces d’événements palliant au moins partiellement les inconvénients précités.
Plus particulièrement, l’invention vise à fournir un procédé de contrôle de gestion des traces d’événements qui permette une reconfiguration des processus receveurs associés au gestionnaire des traces d’événements sans arrêter ni perturber l’exécution de l’application.
Pour cela, l’invention propose, d’une part l’ouverture d’au moins un port interne de contrôle du gestionnaire des traces d’événements, qui sera localisé hors de l’application, et d’autre part la possibilité, par lequel port interne de contrôle, pour le contrôleur de gestion, de pouvoir envoyer des messages à destination des processus receveurs du gestionnaire de traces d’événements associé à l’application en train de s’exécuter, sans passer par cette application en train de s’exécuter.
Le contrôleur de gestion va pour cela utiliser au moins une partie des fonctionnalités du gestionnaire de traces d’événements sans que l’interaction de ce gestionnaire de traces d’événements avec son application associée en cours d’exécution n’en soit perturbée.
Ce gestionnaire de traces d’événements est alors structuré dès le départ pour assurer une telle communication entre le contrôleur de gestion et les processus receveurs, sans perturber sa propre interaction en cours avec son application associée elle-même en cours d’exécution. Avantageusement, le gestionnaire de traces d’événements comprend un module dédié de gestion distante (« remote handler » en langue anglaise) avec lequel va pouvoir dialoguer le contrôleur de gestion.
Le contrôleur de gestion dispose alors, d’une part d’une porte d’entrée vers les processus receveurs qui est générée de manière à être indépendante de l’interaction entre gestionnaire de traces d’événements et application associée en cours d’exécution, et d’autre part d’une possibilité d’interaction avec le gestionnaire de traces d’événements, en disposant d’outils du gestionnaire de traces d’événements, qui est prévue dès le départ pour être indépendante de l’interaction en cours entre gestionnaire de traces d’événements et application associée en cours d’exécution. A cette fin, la présente invention propose un procédé de contrôle de la gestion des traces d’événements dans l’exécution d’une application informatique sur une machine informatique, comprenant : une étape de gestion des traces d’événements incluant : une première communication, interne à cette machine informatique, entre d’une part l’application et d’autre part son gestionnaire de traces d’événements, de manière à générer les traces d’événements, une deuxième communication, interne à cette machine informatique, entre d’une part un port interne du gestionnaire de traces d’événements et un ou plusieurs ports internes d’un ou de plusieurs processus receveurs stockant les traces d’événements en provenance du gestionnaire de traces d’événements, une étape de contrôle de la gestion des traces d’événements incluant : l’ouverture d’au moins un port interne de contrôle du gestionnaire des traces d’événements, une troisième communication, entre d’une part un contrôleur de gestion des traces d’événements localisé hors de l’application et hors du gestionnaire des traces d’événements et d’autre part le ou les processus receveurs, par un ou plusieurs messages envoyés via ledit port interne de contrôle du gestionnaire des traces d’événements, cette troisième communication permettant au contrôleur de gestion des traces d’événements de reconfigurer dynamiquement le ou les processus receveurs sans reconfigurer l’application et sans redémarrer l’application.
Selon des modes de réalisation préférentiels de l’invention, une architecture et des outils sont proposés pour permettre de visualiser et d’interagir avec les « logs » pour des applications distantes, en permettant aussi bien de visualiser en temps réel les « logs », en les filtrant éventuellement, et en changeant leur configuration à la volée, c’est-à-dire sans arrêter ni perturber les applications en cours d’exécution, et ceci pour un nombre éventuellement élevé d’applications.
Selon des modes de réalisation préférentiels de l’invention, dans un environnement distribué, avec de nombreux programmes ou applications s’exécutant sur plusieurs machines informatique, il va devenir possible pour un utilisateur, de visualiser en temps réel les « logs » d’un programme ou d’une application s’exécutant sur une machine distante en appliquant un filtrage multicritères, et/ou de pouvoir reconfigurer à la volée les « logs » d’une application s’exécutant sur une machine, aussi bien en local qu’en distant, et/ou d’ajouter ou de retirer des sorties de «logs», comme par exemple des fichiers, une console, ou un nouveau port interne, tout en appliquant dynamiquement un filtrage particulier, et/ou ne pas avoir à connaître tous les ports de « log » de toutes les applications sur chacune des machines informatique, locale et/ou distantes, pour pouvoir s’y connecter.
Suivant des modes de réalisation préférés, l’invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles.
De préférence, ledit port interne de contrôle du gestionnaire des traces d’événements, ou au moins l’un desdits ports internes de contrôle du gestionnaire des traces d’événements, est un port interne seulement local de cette machine informatique, inaccessible directement depuis l’extérieur de cette machine informatique, ladite troisième communication restant interne à cette machine informatique.
Ainsi, un contrôleur de gestion situé à l’intérieur de la machine informatique peut reconfigurer dynamiquement les processus receveurs sans perturber l’exécution de l’application.
De préférence, ledit port interne de contrôle du gestionnaire des traces d’événements, ou au moins l’un desdits ports internes de contrôle du gestionnaire des traces d’événements, est également ouvert vers l’extérieur de cette machine informatique et permet ladite troisième communication en externe vers un contrôleur de gestion des traces d’événements localisé sur une autre machine informatique distante de cette machine informatique.
Ainsi, un contrôleur de gestion situé à l’extérieur de la machine informatique peut reconfigurer dynamiquement les processus receveurs sans perturber l’exécution de l’application.
De préférence, l’étape de contrôle de la gestion des traces d’événements inclut aussi : l’ouverture d’un relais relié au port interne de contrôle du gestionnaire des traces d’événements de ladite application, ou bien relié à chacun des ports internes de contrôle respectivement des gestionnaires des traces d’événements de plusieurs applications s’exécutant sur cette machine informatique, ledit relais étant adapté pour : d’abord envoyer, à un port interne d’un contrôleur de gestion des traces d’événements, le cas échéant via un port interne de contrôle du gestionnaire ou des gestionnaires des traces d’événements également ouvert vers l’extérieur de cette machine informatique, l’identifiant dudit ou les identifiants desdits ports internes de contrôle auxquels il est relié et vers lesquels il peut connecter le port interne de ce contrôleur de gestion des traces d’événements, ensuite connecter au port interne de ce contrôleur de gestion des traces d’événements, ledit ou l’un desdits ports internes de contrôle auxquels il est relié, à la demande de ce contrôleur de gestion des traces d’événements.
De préférence, ledit relais est relié à chacun des ports internes de contrôle respectivement des gestionnaires des traces d’événements de plusieurs applications s’exécutant sur cette machine informatique.
Ainsi, non seulement un contrôleur de gestion peut gérer plusieurs applications en cours d’exécution et reconfigurer dynamiquement leurs processus receveurs sans perturber leurs exécutions, mais aussi ce contrôleur de gestion peut le faire sans connaître la topographie, à l’intérieur de la machine informatique, des différentes applications et de leurs gestionnaires de traces d’événements associés, et avantageusement ce contrôleur de gestion peut faire tout cela depuis l’extérieur de la machine informatique, c’est-à-dire par exemple depuis une machine distante ou déportée par rapport à la machine informatique sur laquelle s’exécutent les applications dont les processus receveurs des gestionnaires de traces d’événements sont à reconfigurer pendant l’exécution de ces mêmes applications.
De préférence, ledit relais est relié à un nombre moins élevé de ports internes de contrôle des gestionnaires des traces d’événements également ouverts vers l’extérieur de cette machine informatique que de ports internes de contrôle respectivement des gestionnaires des traces d’événements de plusieurs applications s’exécutant sur cette machine informatique, ledit relais étant avantageusement relié à un seul port interne de contrôle des gestionnaires des traces d’événements également ouvert vers l’extérieur de cette machine informatique.
Ainsi, le contrôleur de gestion peut gérer plusieurs applications en cours d’exécution, sans connaître leur topographie, et éventuellement depuis l’extérieur de la machine informatique sur laquelle ces applications s’exécutent, avec un nombre réduit, voire très réduit, de ports internes de contrôle ouverts.
De préférence, ladite reconfiguration dynamique du ou des processus receveurs sans reconfigurer l’application et sans redémarrer l’application inclut une reconfiguration dynamique de tout ou partie du ou des filtres utilisés au niveau du ou des processus receveurs.
Ainsi, la richesse des possibilités de reconfiguration dynamique est augmentée, et l’efficacité du contrôle de gestion de traces d’événements est améliorée.
De préférence, ce ou ces filtres pouvant notamment filtrer sur un ou plusieurs des critères suivants : un critère d’origine de l’événement, un critère de criticité de l’événement, un critère d’émetteur de l’événement. L’émetteur est le nom du programme ou de l’application. L’origine est le nom d’une bibliothèque à l’intérieur du programme ou de l’application qui en contient plusieurs (de telles bibliothèques).
Ainsi, la richesse des possibilités de reconfiguration dynamique est augmentée, et l’efficacité du contrôle de gestion de traces d’événements est améliorée.
De préférence, ladite reconfiguration dynamique du ou des processus receveurs sans reconfigurer l’application et sans redémarrer l’application inclut l’ajout d’un ou de plusieurs processus receveurs stockant les traces d’événements en provenance du gestionnaire de traces d’événements.
Ainsi, la richesse des possibilités de reconfiguration dynamique est augmentée, incluant même l’ajout de processus receveur(s), et l’efficacité comme l’étendue du contrôle de gestion de traces d’événements sont améliorées.
De préférence, ladite deuxième communication est réalisée sous une forme de publication / abonnement, les traces d’événements étant publiées par le gestionnaire de traces d’événements, les processus receveurs s’abonnant à cette publication pour ne stocker que ce qui les concerne respectivement.
Ainsi, la reconfiguration dynamique au niveau des processus receveurs va devenir particulièrement simple, en se réduisant à changer la liste des informations à conserver par chaque processus receveur dans le groupe d’informations complet reçu, ce groupe d’informations complet reçu étant le même pour tous les processus receveurs rattachés à un même gestionnaire de traces d’événements.
De préférence, ladite ouverture du ou des port(s) inteme(s) de contrôle est réalisée par un module spécifique dans une bibliothèque de gestion de traces d’événements dédiée à l’application.
Ainsi, le gestionnaire de traces d’événements est particulièrement bien placé pour ouvrir ce port interne de contrôle de gestion, puisque c’est ce même gestionnaire de traces d’événements qui va assurer la communication interne à la machine informatique entre ce port interne de contrôle et les processus receveurs qui lui sont rattachés.
De préférence, une trace d’événement comprend un ou plusieurs des éléments suivants : un descriptif de l’événement, un identifiant d’émetteur de l’événement, une condition de survenue de l’événement, un niveau de criticité de l’événement, une datation de l’événement, un contexte de l’événement.
Ainsi, la trace d’événement étant particulièrement complète, chaque processus receveur peut être configuré pour ne retenir que ce qui lui est utile, et la reconfiguration dynamique lui assure que la période de temps pendant laquelle il pourrait éventuellement être amené à stocker trop informations, ou beaucoup trop d’informations, selon la situation, sera très réduite, et tous cas sera bien plus réduite que le temps d’exécution de l’application, puisque cette reconfiguration étant dynamique, elle ne nécessitera pas d’attendre la fin de l’exécution de l’application concernée, pour être effectuée.
De préférence, le gestionnaire de traces d’événements est une bibliothèque de communication, de préférence la bibliothèque ZeroMQ.
Ainsi, cette bibliothèque de communication est particulièrement bien adaptée à pouvoir être modifiée facilement de manière à ensuite autoriser une reconfiguration dynamique des processus receveurs sans perturber l’exécution de l’application dont elle gère les traces d’événements. L’invention concerne aussi un procédé de gestion de pannes informatiques intégrant un procédé de contrôle selon l’invention.
Ainsi, ce procédé de gestion de pannes informatiques sera plus efficace, puisque le procédé de contrôle de gestion qu’il intègre est lui-même plus efficace. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d’un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés.
BREVE DESCRIPTION DES DESSINS
La figure 1 représente schématiquement un premier exemple de système informatique permettant la mise en œuvre locale du procédé de contrôle de gestion des traces d’événements dans l’exécution d’une application informatique sur une machine informatique selon un mode de réalisation de l’invention.
La figure 2 représente schématiquement un deuxième exemple de système informatique permettant la mise en œuvre distante du procédé de contrôle de gestion des traces d’événements dans l’exécution d’une application informatique sur une machine informatique selon un mode de réalisation de l’invention.
La figure 3 représente schématiquement un troisième exemple de système informatique permettant la mise en œuvre distante du procédé de contrôle de gestion des traces d’événements dans l’exécution de plusieurs applications informatiques sur une machine informatique selon un mode de réalisation de l’invention.
DESCRIPTION DETAILLEE DE L’INVENTION
La figure 1 représente schématiquement un premier exemple de système informatique permettant la mise en œuvre locale du procédé de contrôle de gestion des traces d’événements dans l’exécution d’une application informatique sur une machine informatique selon un mode de réalisation de l’invention.
Sur une machine locale 1, une application 2 est exécutée. A cette application 2 est associée un gestionnaire 3 de traces d’événements appelé « BXI log » (pour « Bull eXscale Interconnect » en langue anglaise). Ce gestionnaire 3 ouvre un premier processus receveur 4 de traces d’événements qui est par exemple un fichier de stockage des traces d’événements générées par le gestionnaire 3.
Conformément à un mode de réalisation de l’invention, le gestionnaire 3 ouvre un port interne de contrôle 6 du gestionnaire 3 de traces d’événements. Le gestionnaire 3 est structuré pour permettre une communication entre d’une part ce port interne de contrôle 6 et d’autre part le premier processus receveur 4, cette communication d’une part entraînant une reconfiguration dynamique du premier processus receveur 4 et d’autre part pouvant s’effectuer sans arrêter ni perturber le déroulement de l’application 2 qui peut continuer à s’exécuter sans difficulté sur la machine informatique 1.
Conformément à ce mode de réalisation de l’invention, le gestionnaire 3 est également structuré pour permettre une communication entre d’une part ce port interne de contrôle 6 et d’autre part lui-même de manière à créer un deuxième processus receveur 5, cette communication d’une part entraînant la création du deuxième processus receveur 5 avec la configuration souhaitée et d’autre part pouvant s’effectuer sans arrêter ni perturber le déroulement de l’application 2 qui peut continuer à s’exécuter sans difficulté sur la machine informatique 1. De la même manière que pour le premier processus receveur 4, le deuxième processus receveur 5 peut être ensuite également reconfiguré dynamiquement sans perturbation ni arrêt de l’application 2 continuant à s’exécuter sur la machine informatique 1, toujours par une communication via le port interne de contrôle 6.
La reconfiguration dynamique est effectuée par une communication de reconfiguration via le port interne de contrôle 6 et elle est effectuée par un contrôleur 7 de gestion de traces d’événements, localisé sur la machine informatique 1 pour la figure 1. L’information de reconfiguration des processus receveurs circule donc d’abord du contrôleur 7 de gestion vers le port interne de contrôle 6, puis du port interne de contrôle 6 vers le gestionnaire 3, puis du gestionnaire 3 vers le premier processus receveur 4 et/ou vers le deuxième processus receveur 5, lequel processus receveur, 4 et/ou 5, se reconfigure conformément à cette information de reconfiguration des processus receveurs laquelle comporte par exemple une demande de création du deuxième processus receveur 5 ou une demande de modification des critères de filtrage au niveau du processus receveur 4 et/ou 5.
La machine informatique 1 est une machine informatique physique qui peut héberger une ou plusieurs machines informatiques virtuelles différentes et/ou un ou plusieurs containers différents et/ou une ou plusieurs machines virtuelles différentes hébergeant chacune un ou plusieurs containers différents. L’utilisateur utilise un contrôleur de gestion 7 sur la machine informatique 1 locale. L’application 2 utilise un gestionnaire 3 de traces d’événements qui peut être par exemple une bibliothèque « BXI Log ». Le gestionnaire 3 de traces d’événements comprend un module dédié de gestion distante (« remote handler » en langue anglaise) avec lequel va pouvoir dialoguer le contrôleur de gestion 7. Par défaut, ou par configuration de Γutilisateur, les «logs» ou traces d’événements sont envoyés dans un fichier 4, et un port interne de contrôle 6 est ouvert en local seulement. Ainsi, sur cette machine informatique 1 peut être exécuté localement un programme de contrôle de gestion lancé sur un contrôleur de gestion 7 (« monitor » sur la figure 1) qui va se connecter au port interne de contrôle 6 de l’application 2. L’utilisateur va alors pouvoir, consulter en direct les « logs » de l’application 2 en appliquant les filtres qui l’intéressent, et ceci de manière dynamique, par conséquent sans à avoir à redémarrer ni l’application 2 ni le programme de contrôle de gestion du contrôleur de gestion 7, et/ou changer le niveau de « logs » et le filtrage de ce qui est écrit dans le fichier 4, et/ou créer une nouvelle sortie vers un deuxième fichier 5 avec par exemple un filtrage spécifique différent de celui utilisé pour la sortie vers le premier fichier 4.
La figure 2 représente schématiquement un deuxième exemple de système informatique permettant la mise en œuvre distante du procédé de contrôle de gestion des traces d’événements dans l’exécution d’une application informatique sur une machine informatique selon un mode de réalisation de l’invention.
Tout ce qui concerne la figure 1, mais qui n’est pas répété au niveau de la figure 2, tout en restant compatible avec la figure 2, reste valable, notamment comme la machine informatique 1 physique qui peut comprendre plusieurs machines virtuelles et/ou plusieurs containers et comme la création dynamique et/ou la reconfiguration dynamique d’un nouveau processus receveur 5.
Sur une machine distante 1, une application 2 est exécutée. A cette application 2 est associé un gestionnaire 3 de traces d’événements. Ce gestionnaire 3 ouvre un premier processus receveur 4 de traces d’événements qui est par exemple un fichier de stockage des traces d’événements générées par le gestionnaire 3.
Conformément à un autre mode de réalisation de l’invention, le gestionnaire 3 ouvre d’abord le même port interne de contrôle 6 du gestionnaire 3 de traces d’événements qu’au niveau de la figure 1.
Le gestionnaire 3 ouvre également un port interne de contrôle 8 du gestionnaire 3 de traces d’événements. Ce port interne de contrôle 8 est également ouvert vers l’extérieur de la machine informatique 1. Le gestionnaire 3 est structuré pour permettre une communication entre d’une part ce port interne de contrôle 8 et d’autre part le premier processus receveur 4, cette communication d’une part entraînant une reconfiguration dynamique du premier processus receveur 4 et d’autre part pouvant s’effectuer sans arrêter ni perturber le déroulement de l’application 2 qui peut continuer à s’exécuter sans difficulté sur la machine informatique 1.
Conformément à cet autre mode de réalisation de l’invention, le gestionnaire 3 est également structuré pour permettre une communication entre d’une part ce port interne de contrôle 8 et d’autre part lui-même de manière à créer un deuxième processus receveur non représenté sur la figure 2 pour des raisons de simplicité, cette communication d’une part entraînant la création du deuxième processus receveur avec la configuration souhaitée et d’autre part pouvant s’effectuer sans arrêter ni perturber le déroulement de l’application 2 qui peut continuer à s’exécuter sans difficulté sur la machine informatique 1. De la même manière que pour le premier processus receveur 4, le deuxième processus receveur peut être ensuite également reconfiguré dynamiquement sans perturbation ni arrêt de l’application 2 continuant à s’exécuter sur la machine informatique 1, par une communication via le port interne de contrôle 8 ouvert vers l’extérieur.
La reconfiguration dynamique est effectuée par une communication de reconfiguration via le port interne de contrôle 8 ouvert vers l’extérieur et elle est effectuée par un contrôleur 7 de gestion de traces d’événements, localisé sur une autre machine informatique 9 locale, les machines informatiques 1 et 9 étant distantes l’une par rapport à l’autre, c’est-à-dire situées à des endroits physiques différents et éloignés l’un de l’autre, par exemple des salles différentes, ou des immeubles différents, ou même des villes différentes, l’une des machines informatiques 9 et 1 étant appelée la machine locale, sur laquelle est effectuée le contrôle de gestion, et l’autre la machine distante, sur laquelle sont exécutées les applications. L’information de reconfiguration des processus receveurs circule donc d’abord du contrôleur 7 de gestion vers le port interne de contrôle 8 ouvert vers l’extérieur, puis du port interne de contrôle 8 ouvert vers l’extérieur vers le gestionnaire 3, puis du gestionnaire 3 vers le premier processus receveur 4 et/ou vers un deuxième processus receveur non représenté, lequel processus receveur 4 par exemple, se reconfigure conformément à cette information de reconfiguration des processus receveurs laquelle comporte par exemple une demande de modification des critères de filtrage au niveau du processus receveur 4. L’utilisateur utilise un contrôleur de gestion 7 sur la machine informatique 1 locale, ce qui représente rutilisation de la fonctionnalité de contrôle de gestion à distance de la machine informatique distante 9 sur laquelle s’exécute l’application 2 en utilisant un gestionnaire 3 de traces d’événements (par exemple une bibliothèque « BXI Log »), avec comme pour la figure 1 une sortie vers un fichier local 4 et vers un port interne de contrôle 6 purement local. Le gestionnaire 3 de traces d’événements comprend un module dédié de gestion distante (« remote handler » en langue anglaise) avec lequel va pouvoir dialoguer le contrôleur de gestion 7. Un port interne de contrôle 8 ouvert vers l’extérieur a également été configuré, permettant ainsi l’accès au contrôleur de gestion 7 s’exécutant sur une machine informatique 9 locale distante de la machine informatique 1 distante, afin de permettre à l’utilisateur de pouvoir se connecter et effectuer les mêmes opérations que s’il se connectait sur le port interne de contrôle 6 purement local, comme au niveau de la figure 1, opérations qu’il pourrait éventuellement toujours faire à partir d’un autre contrôleur de gestion localisé sur la machine informatique 1 si cet utilisateur se trouvait au niveau de cette machine informatique 1.
La figure 3 représente schématiquement un troisième exemple de système informatique permettant la mise en œuvre distante du procédé de contrôle de gestion des traces d’événements dans l’exécution de plusieurs applications informatiques sur une machine informatique selon un mode de réalisation de l’invention.
Tout ce qui concerne la figure 1, mais qui n’est pas répété au niveau de la figure 3, tout en restant compatible avec la figure 3, reste valable, notamment comme la machine informatique 1 physique qui peut comprendre plusieurs machines virtuelles et/ou plusieurs containers et comme la création dynamique et/ou la reconfiguration dynamique d’un nouveau processus receveur 5.
Sur une machine distante 1, plusieurs applications 2, 12, 22 et 32, sont exécutées. A ces applications 2, 12, 22 et 32 sont respectivement associés des gestionnaires 3, 13, 23 et 33, de traces d’événements. Ces gestionnaires 3, 13, 23 et 33, ouvrent respectivement des premiers processus receveurs 4, 14, 24 et 34, de traces d’événements qui sont par exemple des fichiers de stockage des traces d’événements générées par les gestionnaires 3, 13, 23 et 33.
Conformément à encore un autre mode de réalisation de l’invention, les gestionnaires 3, 13, 23 et 33, ouvrent d’abord des ports internes de contrôle 6, 16, 26 et 36, des gestionnaires 3, 13, 23 et 33, de traces d’événements, similaires au port interne 6 de la figure 1 et à celui de la figure 2.
Les gestionnaires 3, 13, 23 et 33, sont tous rattachés à un relais 10 lequel ouvre un port interne de contrôle 8 ouvert vers l’extérieur similaire à celui de la figure 2. Les communications peuvent être transmises bi-directionnellement entre ce relais 10 et le port interne de contrôle 8 ouvert vers l’extérieur. Ce port interne de contrôle 8 est ouvert vers l’extérieur de la machine informatique 1. Les gestionnaires 3, 13, 23 et 33, sont structurés pour permettre une communication entre d’une part le relais 10 et d’autre part l’un des premiers processus receveurs 4, 14, 24 et 34, cette communication d’une part entraînant une reconfiguration dynamique du premier processus receveur concerné 4, 14, 24 ou 34, et d’autre part pouvant s’effectuer sans arrêter ni perturber le déroulement de l’application correspondante, 2 12, 22 ou 32, qui peut continuer à s’exécuter sans difficulté sur la machine informatique 1.
Conformément à cet encore autre mode de réalisation de l’invention, les gestionnaires 3, 13, 23 et 33, sont également structurés pour permettre une communication entre d’une part ce relais 10 et d’autre part respectivement eux-mêmes de manière à créer un deuxième processus receveur non représenté sur la figure 2 pour des raisons de simplicité, cette communication d’une part entraînant la création du deuxième processus receveur avec la configuration souhaitée et d’autre part pouvant s’effectuer sans arrêter ni perturber le déroulement respectif de l’application 2, 12, 22 ou 32, qui peut continuer à s’exécuter sans difficulté sur la machine informatique 1. De la même manière que pour le premier processus receveur 4, 14, 24 ou 34, le deuxième processus receveur peut être ensuite également reconfiguré dynamiquement sans perturbation ni arrêt de l’application 2, 12, 22 ou 32, continuant à s’exécuter sur la machine informatique 1, toujours par une communication via d’abord le port interne de contrôle 8, puis via le relais 10, à partir du contrôleur de gestion 7 localisé sur la machine informatique 9.
La reconfiguration dynamique est effectuée par une communication de reconfiguration via le port interne de contrôle 8 ouvert vers l’extérieur et elle est effectuée par un contrôleur 7 de gestion de traces d’événements, localisé sur une autre machine informatique 9 locale, les machines informatiques 1 et 9 étant distantes l’une par rapport à l’autre, c’est-à-dire situées à des endroits physiques différents et éloignés l’un de l’autre, l’une des machines informatiques 9 et 1 étant appelée la machine locale et l’autre la machine distante. L’information de reconfiguration des processus receveurs circule donc d’abord du contrôleur 7 de gestion vers le port interne de contrôle 8 ouvert vers l’extérieur, puis du port interne de contrôle 8 ouvert vers l’extérieur vers le relais 10, enfin du relais 10 vers le gestionnaire concerné 3, 13, 23 ou 33, puis du gestionnaire concerné 3, 13, 23 ou 33, vers le premier processus receveur concerné 4, 14, 24 ou 34, et/ou vers un deuxième processus receveur non représenté concerné, lequel processus receveur 4, 14, 24 ou 34 par exemple, se reconfigure conformément à cette information de reconfiguration des processus receveurs laquelle comporte par exemple une demande de modification des critères de filtrage au niveau du processus receveur 4, 14, 24 ou 34. L’utilisation du relais 10 sur la machine informatique 1 distante permet à rutilisateur, via rutilisation d’un port interne de contrôle 8 ouvert l’extérieur de la machine informatique 1 distante, d’exposer les ports internes de contrôle, 6, 16, 26 et 36, locaux des applications 2, 12, 22 et 32, s’exécutant sur la machine informatique 1 distante. Le relais 10 se connecte à tous les ports internes de contrôle 6, 16, 26 et 36, locaux des applications 2, 12, 22 et 32, s’exécutant sur la même machine informatique 1 distante que ce relais 10. Le gestionnaire 3 de traces d’événements comprend un module dédié de gestion distante (« remote handler » en langue anglaise) avec lequel va pouvoir dialoguer le contrôleur de gestion 7. Ainsi, le contrôleur de gestion 7 s’exécutant sur la machine informatique 9 locale peut, en se connectant sur un seul port interne de contrôle 8 ouvert vers l’extérieur et distant, accéder aux « logs », c’est-à-dire aux traces d’événements, de toutes les applications distantes 2, 12, 22 et 32, en cours d’exécution sur la machine informatique 1 distante, de manière similaire au fonctionnement de la figure 2, mais cette fois-ci pour plusieurs applications 2, 12, 22 et 32, à la fois.
Cette implémentation de ce couple constitué par le relais 10 d’une part et par le port interne de contrôle 8 ouvert vers l’extérieur d’autre part, permet au contrôleur de gestion 7 et à Γ utilisateur qui le commande, de pouvoir, économiser des ressources comme les ports internes de contrôle, qu’ils soient locaux ou ouverts vers l’extérieur, allant jusqu’à permettre d’utiliser un seul port interne de contrôle 8 ouvert vers l’extérieur au lieu de quatre d’entre eux respectivement dédiés à chacune des applications 2, 12, 22 et 32, qui s’exécutent sur la machine informatique 1 distante, et/ou de pouvoir accéder aux « logs » d’une application 2, 12, 22 ou 32, distante, même si celle-ci n’a pas été configurée pour cela au démarrage, à cause par exemple soit d’un oubli de Γutilisateur soit d’un changement de besoin en cours d’exécution de cette application.
Par ailleurs, le relais 10 et sa mise en œuvre peuvent également être implantés dans le cas de plusieurs applications 2 ne s’exécutant pas ou ne tournant pas toutes sur la même machine informatique 1, requérant dans ce cas un relais 10 par même groupe d’applications 2 s’exécutant sur une même machine informatique 1.
De plus, le relais 10 peut également être mis en œuvre sur une machine informatique 1, même dans le cas de la figure 1, où le contrôleur 7 de gestion est localisé lui aussi sur la même machine informatique 1.
En considérant l’ensemble des figures 1, 2 et 3, il peut être constaté que la fonctionnalité proposée par ces modes de réalisation de l’invention utilisent la mise en place d’un module dédié dans le gestionnaire de traces d’événements, 3, 13, 23 ou 33, c’est-à-dire par exemple un module dédié de gestion distante dans la bibliothèque « BXI Log ». Ce module dédié est activé par défaut lors de l’exécution d’une application 2, 12, 22 ou 32, et avec sa configuration par défaut, ouvre un port interne de contrôle 6, 16, 26 et/ou 36, local et/ou 8 ouvert vers l’extérieur.
Il reste possible de changer ce comportement par défaut, par simple changement de configuration avant le lancement de l’application ou bien via une connexion sur le gestionnaire 3, 13, 23 ou 33, de traces d’événements de cette application 2, 12, 22 ou 32, par le contrôleur de gestion 7.
Il est également possible, par configuration préalable, de demander à ce que seul un port interne de contrôle 6, 16, 26 ou 36, local ou seul un port interne de contrôle 8 ouvert vers l’extérieur de la machine informatique sur laquelle s’exécute l’application 2, 12, 22 ou 32, permettant alors d’exécuter un client, un programme de contrôle de gestion sur le contrôleur de gestion 7, sur une autre machine informatique 9 distante de la machine informatique 1 sur laquelle s’exécute l’application 2, 12, 22 ou 32.
Un service de relais 10 peut aussi être déployé sur la machine informatique 1 afin de permettre la connexion aux ports internes de contrôle 6, 16, 26 et/ou 36, locaux depuis une autre machine informatique 9 distante de la machine informatique 1. C’est pour cette raison que par défaut est ouvert un port interne de contrôle 6 local, ainsi il suffit de démarrer un service de relais 10 pour pouvoir y accéder sans à avoir besoin de reconfigurer et redémarrer l’application 2, 12, 22 ou 32, à laquelle il est souhaité de se connecter. Ce service de relais 10 se connecte à tous les ports internes de contrôle 6, 16, 26 et 36, locaux des applications 2, 12, 22 et 32, en cours d’exécution sur la machine informatique 1, et ouvre un port interne de contrôle 8 ouvert vers l’extérieur de cette machine informatique 1, permettant au contrôleur de gestion 7 de s’y connecter et ainsi d’accéder à n’importe quel port interne de contrôle 6, 16, 26 ou 36, de n’importe quelle application 2, 12, 22 ou 32, en cours d’exécution sur la machine informatique 1.
Une fois connecté au port interne de contrôle choisi, 6, 16, 26 ou 36, soit directement soit en passant par un relais 10, un utilisateur peut agir sur la configuration des «logs » de l’application correspondante 2, 12, 22 ou 32. L’utilisateur peut alors observer en temps réel les « logs » de l’application choisie, en appliquant en direct des configurations de filtres, comme par exemple le niveau des logs, les sous-parties de logs, ou autres, et/ou changer la configuration des autres sorties ou processus receveurs, tels que l’écriture dans un ou plusieurs fichiers, l’écriture vers un démon « syslog », vers une console, par exemple en changeant le niveau des « logs », et/ou ajouter et/ou supprimer des sorties à la volée, comme par exemple des fichiers, une sortie vers un démon « syslog ».
Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art.
Claims (14)
- REVENDICATIONS1. Procédé de contrôle de la gestion des traces d’événements dans l’exécution d’une application informatique (2) sur une machine informatique (1), comprenant : > une étape de gestion des traces d’événements incluant : o une première communication, interne à cette machine informatique (1), entre d’une part l’application (2) et d’autre part son gestionnaire (3) de traces d’événements, de manière à générer les traces d’événements, o une deuxième communication, interne à cette machine informatique (1), entre d’une part un port interne du gestionnaire (3) de traces d’événements et un ou plusieurs ports internes d’un ou de plusieurs processus receveurs (4, 5) stockant les traces d’événements en provenance du gestionnaire (3) de traces d’événements, > une étape de contrôle de la gestion des traces d’événements incluant : o l’ouverture d’au moins un port interne de contrôle (6, 8) du gestionnaire (3) des traces d’événements, o une troisième communication, entre d’une part un contrôleur de gestion (7) des traces d’événements localisé hors de l’application (2) et hors du gestionnaire (3) des traces d’événements et d’autre part le ou les processus receveurs (4, 5), par un ou plusieurs messages envoyés via ledit port interne de contrôle (6, 8) du gestionnaire (3) des traces d’événements, cette troisième communication permettant au contrôleur de gestion (7) des traces d’événements de reconfigurer dynamiquement le ou les processus receveurs (4, 5) sans reconfigurer l’application (2) et sans redémarrer l’application (2).
- 2. Procédé de contrôle selon la revendication 1, caractérisé en ce que ledit port interne de contrôle (6, 8) du gestionnaire (3) des traces d’événements, ou au moins l’un desdits ports internes de contrôle (6, 8) du gestionnaire des traces d’événements, est un port interne seulement local (6) de cette machine informatique (1), inaccessible directement depuis l’extérieur de cette machine informatique (1), ladite troisième communication restant interne à cette machine informatique (1).
- 3. Procédé de contrôle selon la revendication 1 ou 2, caractérisé en ce que ledit port interne de contrôle (6, 8) du gestionnaire (3) des traces d’événements, ou au moins l’un desdits ports internes de contrôle (6, 8) du gestionnaire (3) des traces d’événements, est également ouvert (8) vers l’extérieur de cette machine informatique (1) et permet ladite troisième communication en externe vers un contrôleur de gestion (7) des traces d’événements localisé sur une autre machine informatique (9) distante de cette machine informatique (1).
- 4. Procédé de contrôle selon l’une quelconque des revendications précédentes, caractérisé en ce que : > l’étape de contrôle de la gestion des traces d’événements inclut aussi : o l’ouverture d’un relais (10) relié au port interne de contrôle (6) du gestionnaire (3) des traces d’événements de ladite application (2), ou bien relié à chacun des ports internes de contrôle (6, 16, 26, 36) respectivement des gestionnaires (3, 13, 23, 33) des traces d’événements de plusieurs applications (2, 12, 22, 32) s’exécutant sur cette machine informatique (1), o ledit relais (10) étant adapté pour : d’abord envoyer, à un port interne d’un contrôleur de gestion (7) des traces d’événements, le cas échéant via un port interne de contrôle (8) du gestionnaire (3) ou des gestionnaires (3, 13, 23, 33) des traces d’événements également ouvert vers l’extérieur de cette machine informatique (1), l’identifiant dudit port interne de contrôle (6) ou les identifiants desdits ports internes de contrôle (6, 16, 26, 36) au(x)quel(s) il est relié et vers le(s)quel(s) il peut connecter le port interne de ce contrôleur de gestion (7) des traces d’événements, ensuite connecter au port interne de ce contrôleur de gestion (7) des traces d’événements, ledit (6) ou l’un desdits ports internes de contrôle (6, 16, 26, 36) auxquels il est relié, à la demande de ce contrôleur de gestion (7) des traces d’événements.
- 5. Procédé de contrôle selon la revendication 4, caractérisé en ce que ledit relais (10) est relié à chacun des ports internes de contrôle (6, 16, 26, 36) respectivement des gestionnaires (3, 13, 23, 33) des traces d’événements de plusieurs applications (2, 12, 22, 32) s’exécutant sur cette machine informatique (1).
- 6. Procédé de contrôle selon la revendication 5, caractérisé en ce que ledit relais (10) est relié à un nombre moins élevé de ports internes de contrôle (8) des gestionnaires (3, 13, 23, 33) des traces d’événements également ouverts vers l’extérieur de cette machine informatique (1) que de ports internes de contrôle (6, 16, 26, 36) respectivement des gestionnaires (3, 13, 23, 33) des traces d’événements de plusieurs applications (2, 12, 22, 32) s’exécutant sur cette machine informatique (1), ledit relais (10) étant avantageusement relié à un seul port interne de contrôle (8) des gestionnaires (3, 13, 23, 33) des traces d’événements également ouvert vers l’extérieur de cette machine informatique (1).
- 7. Procédé de contrôle selon l’une quelconque des revendications précédentes, caractérisé en ce que ladite reconfiguration dynamique du ou des processus receveurs (4, 5) sans reconfigurer l’application et sans redémarrer l’application inclut une reconfiguration dynamique de tout ou partie du ou des filtres utilisés au niveau du ou des processus receveurs (4, 5).
- 8. Procédé de contrôle selon la revendication 7, caractérisé en ce que : > ce ou ces filtres pouvant notamment filtrer sur un ou plusieurs des critères suivants : o un critère d’origine de l’événement, o un critère de criticité de l’événement, o un critère d’émetteur de l’événement.
- 9. Procédé de contrôle selon l’une quelconque des revendications précédentes, caractérisé en ce que ladite reconfiguration dynamique du ou des processus receveurs (4, 5) sans reconfigurer l’application (2) et sans redémarrer l’application (2) inclut l’ajout d’un ou de plusieurs processus receveurs (5) stockant les traces d’événements en provenance du gestionnaire (3) de traces d’événements.
- 10. Procédé de contrôle selon l’une quelconque des revendications précédentes, caractérisé en ce que ladite deuxième communication est réalisée sous une forme de publication / abonnement, les traces d’événements étant publiées par le gestionnaire (3) de traces d’événements, les processus receveurs (4, 5) s’abonnant à cette publication pour ne stocker que ce qui les concerne respectivement.
- 11. Procédé de contrôle selon l’une quelconque des revendications précédentes, caractérisé en ce que ladite ouverture du ou des port(s) interne(s) de contrôle (6, 8) est réalisée par un module spécifique dans une bibliothèque de gestion de traces d’événements dédiée à l’application (2).
- 12. Procédé de contrôle selon l’une quelconque des revendications précédentes, caractérisé en ce que : > une trace d’événement comprend un ou plusieurs des éléments suivants : o un descriptif de l’événement, o un identifiant d’émetteur de l’événement, o une condition de survenue de l’événement, o un niveau de criticité de l’événement, o une datation de l’événement, o un contexte de l’événement.
- 13. Procédé de contrôle selon l’une quelconque des revendications précédentes, caractérisé en ce que le gestionnaire (3) de traces d’événements est une bibliothèque de communication, de préférence la bibliothèque ZeroMQ.
- 14. Procédé de gestion de pannes informatiques intégrant un procédé de contrôle selon l’une quelconque des revendications précédentes.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1763238A FR3075999B1 (fr) | 2017-12-27 | 2017-12-27 | Procede de controle de la gestion des traces d'evenements dans l'execution d'une application informatique sur une machine informatique |
| PCT/FR2018/053446 WO2019129957A1 (fr) | 2017-12-27 | 2018-12-20 | Procede de controle de la gestion des traces d'evenements dans l'execution d'une application informatique sur une machine informatique |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1763238 | 2017-12-27 | ||
| FR1763238A FR3075999B1 (fr) | 2017-12-27 | 2017-12-27 | Procede de controle de la gestion des traces d'evenements dans l'execution d'une application informatique sur une machine informatique |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3075999A1 true FR3075999A1 (fr) | 2019-06-28 |
| FR3075999B1 FR3075999B1 (fr) | 2021-02-19 |
Family
ID=62067637
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1763238A Active FR3075999B1 (fr) | 2017-12-27 | 2017-12-27 | Procede de controle de la gestion des traces d'evenements dans l'execution d'une application informatique sur une machine informatique |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR3075999B1 (fr) |
| WO (1) | WO2019129957A1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117493127A (zh) * | 2023-12-29 | 2024-02-02 | 太平金融科技服务（上海）有限公司 | 一种应用程序检测方法、装置、设备及介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5857190A (en) * | 1996-06-27 | 1999-01-05 | Microsoft Corporation | Event logging system and method for logging events in a network system |
| US20050010929A1 (en) * | 2003-06-20 | 2005-01-13 | Gongqian Wang | System and method for electronic event logging |
| US20110246826A1 (en) * | 2010-03-31 | 2011-10-06 | Cloudera, Inc. | Collecting and aggregating log data with fault tolerance |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3025627B1 (fr) | 2014-09-10 | 2018-03-23 | Bull Sas | Mecanisme haute performance pour generation d'informations de journalisation d'un processus informatique |
-
2017
- 2017-12-27 FR FR1763238A patent/FR3075999B1/fr active Active
-
2018
- 2018-12-20 WO PCT/FR2018/053446 patent/WO2019129957A1/fr active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5857190A (en) * | 1996-06-27 | 1999-01-05 | Microsoft Corporation | Event logging system and method for logging events in a network system |
| US20050010929A1 (en) * | 2003-06-20 | 2005-01-13 | Gongqian Wang | System and method for electronic event logging |
| US20110246826A1 (en) * | 2010-03-31 | 2011-10-06 | Cloudera, Inc. | Collecting and aggregating log data with fault tolerance |
Non-Patent Citations (1)
| Title |
|---|
| JAN CHRIN ET AL: "Accelerator Modelling and Message Logging with ZeroMQ", PROCEEDINGS OF ICALEPCS 2015, MELBOURNE, AUSTRALIA, 1 January 2015 (2015-01-01), pages 610 - 614, XP055501788, ISBN: 978-3-95450-148-9, DOI: 10.18429/JACoW-ICALEPCS2015-WEB3O04 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117493127A (zh) * | 2023-12-29 | 2024-02-02 | 太平金融科技服务（上海）有限公司 | 一种应用程序检测方法、装置、设备及介质 |
| CN117493127B (zh) * | 2023-12-29 | 2024-04-05 | 太平金融科技服务（上海）有限公司 | 一种应用程序检测方法、装置、设备及介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2019129957A1 (fr) | 2019-07-04 |
| FR3075999B1 (fr) | 2021-02-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20090063225A1 (en) | Tool for automated transformation of a business process definition into a web application package | |
| FR2914802A1 (fr) | Procede et dispositif de gestion de canaux de communication pour des echanges de donnees a partir d'un aeronef | |
| EP0572307A1 (fr) | Système logiciel à objets répliqués exploitant une messagerie dynamique, notamment pour installation de contrôle/commande à architecture redondante | |
| EP2791798B1 (fr) | Bus logiciel | |
| EP2616983B1 (fr) | Dispositif de gestion de comptes utilisateurs apte a cooperer avec un dispositif de signature unique | |
| FR2918232A1 (fr) | Procedes et dispositifs pour la communication de donnees de diagnostic dans un reseau de communication temps reel | |
| EP3555745B1 (fr) | Dispositif de chargement de données dans des unités informatiques de traitement depuis une source de données | |
| EP1684177A1 (fr) | Procédé et systeme d'administration dans un environement JMX comprenant une application d'administration et des systemes logiciels à administrer | |
| FR3075999A1 (fr) | Procede de controle de la gestion des traces d'evenements dans l'execution d'une application informatique sur une machine informatique | |
| EP2176759B1 (fr) | Procede de mesure des performances d'un serveur cible logeant un outil de suivi dynamique | |
| FR2829337A1 (fr) | Equipement d'automatisme connecte a un reseau tcp/ip | |
| EP3191961A1 (fr) | Mecanisme haute performance pour generation d'informations de journalisation d'un processus informatique | |
| FR2923113A1 (fr) | Procede de gestion d'operations d'administration, de maintenance et de maintien en condition operationnelle, entite de gestion, et produit programme d'ordinateur correspondant. | |
| EP2737686B1 (fr) | Procédé de gestion de l'accès à un ensemble de ressources délivrées par un dispositif électronique | |
| WO2018065705A1 (fr) | Procédé d'audit d'une ressource virtualisée déployée dans un réseau informatique en nuage | |
| EP3394740B1 (fr) | Procede de configuration d'un systeme d'exploitation | |
| FR2944617A1 (fr) | Procede de chargement d'une base de donnees a bord d'un aeronef. | |
| EP3387795B1 (fr) | Routeur d'un reseau domestique, interface de supervision et un procede de supervision de l'utilisation d'un reseau domestique | |
| FR3041450A1 (fr) | Architecture client/serveur pour l'administration d'un supercalculateur | |
| FR3021831A1 (fr) | Procede et dispositif de partage d'application | |
| EP3391623B1 (fr) | Déploiement de service dans un réseau local | |
| EP4064063A1 (fr) | Système de communication comprenant une pluralité de processeurs et au moins un commutateur, et un procédé de communication associé | |
| FR2925965A1 (fr) | Systeme informatique a haute disponibilite | |
| WO2021084184A1 (fr) | Procédé de diffusion d'une vidéo par un dispositif client, dispositif client et système associé | |
| EP1187020A1 (fr) | Service de communication permettant la transmission d'evenements entre elements logiciels de facon independante des applications |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20190628 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| TQ | Partial transmission of property |
Owner name: BULL SAS, FR Effective date: 20220809 Owner name: COMMISSARIAT A L'ENERGIE ATOMIQUE ET AUX ENERG, FR Effective date: 20220809 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |