FR 3075999 A1 20190628 FR 1763238 A 20171227 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 à l'utilisateur 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 ». 2 Selon un premier art antérieur, par exemple décrit dans la demande de brevet W02016038272, 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 5 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 10 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. Il faut d'abord attendre l'arrêt de 15 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 20 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 25 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/indexlitml Cette bibliothèque de gestion de « logs » est utile mais elle ne fournit 30 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 3 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 5 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 : haps ://doc s oracl e. com/j av a se/7/doc s/api/j av a/util/loggin g/packa ge- 10 summary .ht rn I 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 », 15 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 20 troisième art antérieur n'est globalement pas non plus meilleur que le premier art antérieur. RESUME DE L'INVENTION 25 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 30 reconfiguration des processus receveurs associés au gestionnaire des traces d'événements sans arrêter ni perturber l'exécution de l'application. 4 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 5 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 10 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 15 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 20 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 25 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 30 gestion des traces d'événements incluant : une première communication, interne à cette machine informatique, entre d'une part l'application et 5 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 5 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 10 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 15 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 20 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 25 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 » 30 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 6 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. 5 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 10 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. 15 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 20 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 25 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 30 bien relié à chacun des ports internes de contrôle respectivement des gestionnaires des traces d'événements de plusieurs applications s'exécutant 7 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 5 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 10 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. 15 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 20 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 25 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 30 de contrôle respectivement des gestionnaires des traces d'événements de plusieurs applications s'exécutant sur cette machine informatique, ledit 8 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 5 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 10 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 15 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 20 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. 25 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 30 augmentée, incluant même l'ajout de processus receveur(s), et l'efficacité 9 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 5 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 10 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) interne(s) de contrôle 15 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 20 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 25 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 30 pendant laquelle il pourrait éventuellement être amené à stocker trop informations, ou beaucoup trop d'informations, selon la situation, sera très 10 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. 5 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 10 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- 15 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. 20 BREVE DESCRIPTION DES DESSINS La figure 1 représente schématiquement un premier exemple de système informatique permettant la mise en oeuvre locale du procédé de contrôle de gestion des traces d'événements dans l'exécution d'une 25 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 oeuvre distante du procédé de contrôle de gestion des traces d'événements dans l'exécution d'une 30 application informatique sur une machine informatique selon un mode de réalisation de l'invention. 11 La figure 3 représente schématiquement un troisième exemple de système informatique permettant la mise en oeuvre 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 5 réalisation de l'invention. DESCRIPTION DETAILLEE DE L'INVENTION La figure 1 représente schématiquement un premier exemple de 10 système informatique permettant la mise en oeuvre 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 15 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. 20 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 25 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 30 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 12 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 5 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. 10 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 15 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 20 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 25 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 30 gestionnaire 3 de traces d'événements comprend un module dédié de gestion distante (« remote handler » en langue anglaise) avec lequel va 13 pouvoir dialoguer le contrôleur de gestion 7. Par défaut, ou par configuration de l'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é 5 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 10 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 15 fichier 4. La figure 2 représente schématiquement un deuxième exemple de système informatique permettant la mise en oeuvre 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 20 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 25 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 30 d'événements qui est par exemple un fichier de stockage des traces d'événements générées par le gestionnaire 3. 14 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 5 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 10 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 15 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 20 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 25 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 30 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 15 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 5 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 10 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 15 informatique 1 locale, ce qui représente l'utilisation 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 20 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 25 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 30 localisé sur la machine informatique 1 si cet utilisateur se trouvait au niveau de cette machine informatique 1. 16 La figure 3 représente schématiquement un troisième exemple de système informatique permettant la mise en oeuvre 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 5 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 10 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 15 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, 20 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 25 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 bidirectionnellement 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 30 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 17 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 5 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 10 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 15 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 20 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, 25 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 30 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 18 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 5 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 10 permet à l'utilisateur, via l'utilisation 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 15 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 20 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 25 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 à l'utilisateur qui le commande, de pouvoir, économiser des ressources comme les ports internes de contrôle, 30 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 19 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 5 exemple soit d'un oubli de l'utilisateur soit d'un changement de besoin en cours d'exécution de cette application. Par ailleurs, le relais 10 et sa mise en oeuvre 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 10 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 oeuvre 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. 15 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 20 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 25 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 30 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 20 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 5 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 10 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 à 15 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 20 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 25 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 30 au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art. 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). 22 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) 5 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). 10 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 15 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 20 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 25 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), 30 o ledit relais (10) étant adapté pour : 23 -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 5 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 10 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, 15 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) 20 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 25 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 30 applications (2, 12, 22, 32) s'exécutant sur cette machine informatique (1), ledit relais (10) étant avantageusement relié à un seul port interne de 24 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 5 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). 10 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, 15 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 20 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. 25 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 30 publication pour ne stocker que ce qui les concerne respectivement. 25 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 à 5 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 10 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, 15 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 20 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. 25