WO2016038272A1 - Mecanisme haute performance pour generation d'informations de journalisation d'un processus informatique - Google Patents

Mecanisme haute performance pour generation d'informations de journalisation d'un processus informatique Download PDF

Info

Publication number
WO2016038272A1
WO2016038272A1 PCT/FR2015/052267 FR2015052267W WO2016038272A1 WO 2016038272 A1 WO2016038272 A1 WO 2016038272A1 FR 2015052267 W FR2015052267 W FR 2015052267W WO 2016038272 A1 WO2016038272 A1 WO 2016038272A1
Authority
WO
WIPO (PCT)
Prior art keywords
logging
thread
information
application
log
Prior art date
Application number
PCT/FR2015/052267
Other languages
English (en)
Inventor
Pierre VIGNERAS
Original Assignee
Bull Sas
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull Sas filed Critical Bull Sas
Priority to EP15763052.6A priority Critical patent/EP3191961A1/fr
Priority to US15/510,638 priority patent/US11874758B2/en
Priority to JP2017534008A priority patent/JP6498770B2/ja
Priority to CN201580060764.2A priority patent/CN107003927A/zh
Publication of WO2016038272A1 publication Critical patent/WO2016038272A1/fr
Priority to IL251095A priority patent/IL251095A0/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/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/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3612—Software analysis for verifying properties of programs by runtime analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • 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
    • 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/3068—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data format conversion
    • 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/3404—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 for parallel or distributed programming
    • 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

Definitions

  • the invention relates to the field of process logging within a software application running on a set of information processing devices. More particularly, the invention relates to a method for process logging in the case of a software application operating with multiple processes and / or threads.
  • English-language logging is a mechanism for exporting running information from a software application to the developer, tester, or other people on a technical team that is responsible for supporting the application. software application. This information makes it possible to reveal certain dysfunctions, or, these known, to facilitate the determination of the cause and the correction.
  • the export of logging information can be done during software application development phases, or in the test phase within a community of testers, but also in the production phase. The logging information is then exported to the users of the application, but can be "uploaded” in one way or another to the technical team in charge of the software.
  • the logging information can be exported to a display terminal, or to a memory, in particular a "hard disk” type mass memory.
  • Some "critical" software applications require highly constrained response times but require a large amount of computation. To reconcile these two requirements, they are conventionally deployed on systems composed of a set of data processing devices. Parallel programming techniques are then used to take advantage of these processing devices.
  • logging requires inputs / outputs, to a display terminal or a memory, for example.
  • Input / output mechanisms are expensive in terms of processing time.
  • logging impacts the performance of a software application.
  • the object of the present invention is to improve the state of the art by providing mechanisms to enable efficient logging, including for critical software applications, including parallel software applications.
  • the present invention provides a logging method comprising steps of: Execute a process with at least one application thread and at least one journal thread on a set of information processing devices;
  • the invention comprises one or more of the following features which can be used separately or in partial combination with one another or in total combination with one another:
  • said at least one processing element comprises an output wire belonging to said process.
  • said at least one processing element comprises a thread of a logging process separate from said process, said application thread transmits said first information to said at least one log thread asynchronously through a communication interface.
  • said communication interface and said publishing interface are of socket type and conform to the ZeroMQ library.
  • said at least one application thread waits for the initialization of said at least one journaling thread prior to continuing execution, and wherein said logging son initializes by synchronizing with a subset of said at least one processing element, said first log information includes a name and a level.
  • said at least one logging thread is completed and restarted within the initial parent process.
  • said at least one logging son when said at least one logging son receives a signal, it publishes second logging information related to said signal and then triggers the processing code associated with said signal.
  • said application son when said application son receives a signal, it transmits first logging information related to said signal to said at least one logging thread, waits for a given time and causes the termination of said process.
  • FIG 1 shows schematically an example of implementation of the invention.
  • FIG. 2 diagrammatically represents a finite state machine according to one embodiment of the invention.
  • a software application consists of one or more processes.
  • a process, or "process” in English, can be seen as a program running by an information processing system (or computer).
  • a process can be defined as comprising:
  • a set of instructions to execute which can be in the ROM, but most often loaded from the mass memory to the RAM;
  • Resources such as network ports.
  • the same process can have multiple threads or "threads" in English, or a light task or process. Unlike a process, a thread does not have its own virtual memory but shares it with all threads in the same process.
  • an application has two processes P 1; P 2 .
  • the process Pi comprises three execution threads F 1; F 2 , F 3 . Whatever it is not shown in the figure, the process P 2 may also include several threads.
  • the threads can have a life different from that of the processes, and, a fortiori, the duration of execution of the application: the son can be executed dynamically during the execution of the processes and completed at any time, once the task for which they are planned completed.
  • Figure 1 therefore illustrates a situation at a given time of the execution of the software application.
  • the execution threads F 1; F 2 will be called “application son", to distinguish them from the log son or F j and the output wire F s which will be described later.
  • the information processing system for executing the software application is typically a parallel system consisting of a set of information processing devices.
  • Each information processing device may be for example a microprocessor with associated circuits (memory ...), and the system is then formed of a set of interconnected microprocessors.
  • a microprocessor with associated circuits (memory 8)
  • the system is then formed of a set of interconnected microprocessors.
  • Another example is that of a single microprocessor forming a system, and composed of a set of physical cores.
  • Such a microprocessor is generally called multi-core (or "multicore" in English).
  • the logging thread when it starts, it creates:
  • An I c communication interface enabling the reception of the first logging information of the application threads F 1; F 2 , that is to say the main application thread and any son he can then create;
  • processing elements An I P publishing interface to publish second logging information to processing elements
  • processing elements the threads and processes.
  • the logging process Pj and the output thread Fs form such processing elements that are likely to receive the logging information.
  • these interfaces are of the "socket” type.
  • a “socket” is a communication mechanism well known to those skilled in the art, appeared on operating systems of "Unix” type but today present under most operating systems.
  • ZeroMQ can be ZeroMQ compliant.
  • ZeroMQ is a middleware platform that is inserted between the underlying operating system and applications to provide additional infrastructure services independent of the operating system.
  • CORBA Common Object Request Broker Architecture
  • ZeroMQ brings a great ease of use and very good performances: the code is very short for the threads application, generating little overload of treatment, and the processing within the ZeroMQ library is also very fast.
  • ZeroMQ meets the requirements of the invention and allows to fulfill the desired services without adding a detrimental treatment.
  • the communication interface is an asynchronous interface: it allows the application thread to send logging information and then continue processing, without having to wait for an acknowledgment from the logging thread Fj .
  • this communication interface I c may be of the push / pull type.
  • the logging thread creates a "pull" type socket.
  • the application threads F 1; F 2 can then transmit the logging information through a "push" socket connected to the "pull" socket of the logging thread Fj.
  • an inter-wire and intra-process transport protocol such as the "inproc" protocol can be implemented.
  • This protocol allows the transmission of messages between wires within the same process: the information is transmitted directly by the memory belonging to the context associated with the process. This mechanism therefore does not generate inputs / outputs, and therefore contributes to the high performance of the method according to the invention.
  • the publication interface I P may comprise a pub type socket created within the logging thread Fj.
  • the processing elements (processes or threads) Pj, F s can create sub-type sockets in order to subscribe ("subscribe" in English) to the "pub" socket of the logging thread Pj.
  • the "publish-subscribe" model managed by ZeroMQ thus makes it possible to transmit messages to all previously subscribed processing elements.
  • the application thread waits for the initialization of this logging thread Fj before continuing its execution.
  • the thread (main) of the process Pi may specify a number of processing elements that must receive logging information. He will receive a acknowledgment by the logging thread Fj only when this number of subscriber processing elements is reached. Once the acknowledgment is received, the thread can then continue execution. Likewise, the log thread Fj initializes by synchronizing with the number of processing elements that are to receive logging information.
  • journal thread Fj can publish synchronization information. Upon receipt, the processing elements that received them will transmit an acknowledgment to the logging thread. This can count the acknowledgments received and easily determine when the specified number is reached.
  • This synchronization phase makes it possible to ensure that no logging information is lost: in fact, establishing the connection between the logging thread Fj and the processing elements may take a certain amount of time. In addition, the processing elements themselves may be initializing as well. During this time, if the log thread Fj immediately started sending log information, the log information would be lost due to the lack of acknowledgment in the transmission of the published log information from the receiving processing elements. . This absence of acknowledgment makes it possible to reach good performances
  • This number of elements determines a subset of all subscriber processing elements, because once the initialization phase is complete, it is quite possible that other processing elements subscribe to Fj journaling publications. However, these may miss the first publications of the journal thread Fj.
  • the logging method according to the invention comprises a step of executing the process Pi. As previously described, this execution involves the execution of at least one application thread Fi and a log thread Fj. In the case of a process written in C language, this application thread Fi may correspond to the execution of the main () function.
  • the application son (s) execute the code of the software application.
  • the method then consists in detecting a log event in the one or more application threads and immediately transmitting first logging information el, e2 to the logging thread Fj.
  • Detecting a log event is a known technique, which involves inserting milestones (or "loggers") into the code to trigger a log event when certain conditions are met. These conditions can be simply the passage through a specific point of the code (to allow to follow the progress of the code), or a situation of error, etc.
  • This logging information generated by the application thread F 1; F 2 are here called “first logging information" to distinguish them from the second logging information that will be published by the journal thread Fj.
  • This information may have only one name and one level. According to one embodiment, these first information only include this name and this level.
  • the name can be a string identifying a milestone within the application code.
  • the level is usually an integer, identifying a degree of criticality of the event. This level can belong to a previously defined list which can include: "Critical”: to indicate a critical error which, in general, causes the termination of the process.
  • This first information may also include:
  • timestamp a date of occurrence of the log event
  • kernel thread identifier (“kernel")
  • software application name the application name
  • file name the application code line number
  • the application wire immediately transmits these first logging information to the logging wire Fj through the communication interface I c .
  • this interface is asynchronous and does not require acknowledgment. No lock is set up either, so that once the transmission is done (and without worrying about reception by the logging wire), the application thread F 1; F 2 can continue application processing immediately.
  • no further processing is applied between detecting a logging event and sending the first logging information.
  • only a formatting process is applied.
  • the application thread implements input / output mechanisms: these mechanisms are implemented by the log thread Fj, and therefore off the application thread F 1; F 2 .
  • the application code is divided into modules. Each module is associated with a name or identifier, which can be embedded in the name of the logging milestone.
  • the journal thread Fj asynchronously receives the first logging information sent by the application son or F 1; F 2. Its role is then to develop second logging information from the first logging information received from the application son, and possibly additional information. This additional information may be information common to all the application threads of the process.
  • the processing implemented by the log thread Fj can be limited to the development of these second logging information.
  • the development can comprise on the one hand the addition of any additional information but also formatting, according to a predefined format allowing its operation by processing elements.
  • This formatting can be very simple and only consist of formatting so that the second information is in a format independent of the computer language used.
  • This second information is then published by the journal thread Fj through the publication interface I P. They can then be received by one or more processing elements F s , Pj previously registered with the logging wire, as previously described.
  • These processing elements may comprise an output thread F s belonging to the process P1.
  • This output wire may be provided for producing an output of the second logging information on a display terminal (screen %), in a file stored on a memory, especially a mass memory, etc.
  • the processing elements may also include a logging process Pj distinct from said process Pi.
  • This process can also implement output mechanisms in the same way as an output thread F s .
  • the log thread Fj and the eventual output thread Fs are completed and then restarted within the initial parent process Pi.
  • two wires are not restarted (they go into a "finalized” state, as will be described later).
  • the child process will trigger the execution of an "exec ()” function that will replace and “overwrite” the content of the child process with a new program: it is therefore unnecessary to trigger an automatic restart of journaling and output threads, and even counterproductive.
  • Forking or fork, in English, is the mechanism for creating a new process in a software application running under a "Unix" operating system, or compliant with the Posix standard.
  • the mechanism implemented by the invention makes it possible to avoid them.
  • management of a state machine can be implemented to better manage fork () duplication.
  • FIG. 2 illustrates such a state machine of the log thread Fj. It is considered that the thread Fj can be in 5 main states. These states are classic:
  • duplication may be permitted and not give rise to particular processing.
  • the arrow “fork ()” loops back to the current state.
  • the duplication causes the transition to the finalizing state to complete the logging thread.
  • the son Fj and F s can be restarted.
  • the threads are restarted in the state where they were before the duplication, that is, the "initialized” state.
  • the threads start in a state "Unset”: the application thread of the child process must then initiate its initialization to make it change state.
  • a process Pi operating under a system of the Posix or unix type can receive signals. These signals can be provided to terminate the process, such as SIGINT, SIGTERM, SIGQUIT, SIGSEGV, SIGBUS signals.
  • the log thread Fj When such a signal is received by the log thread Fj, it may choose to treat or not according to their nature. For example, the signals
  • SIGINT, SIGTERM and SIGQUIT can be considered as being to be processed by the application thread and therefore not considered by the journal thread. On the other hand, it can consider other types of signals such as SIGSEGV and SIGBUS signals.
  • the log thread Fj may consider it to be a log event, and then publish logging information related to that signal.
  • Normal The normal processing of a signal is provided by a processing code, typically called “handler”, and associated with this signal.
  • the normal processing of this signal SIGSEGV or SIGBUS causes the termination of the process.
  • the process adopts the expected behavior of being terminated, but it is also ensured that a logging takes place related to the reception of this event: also, if a processing element subscribes to the logging thread , it will be informed of the cause of the termination of the process Pi. If a signal is received by the application thread, it can determine that it is a log event. To do this, a specific code can be associated with the signal as "handler": on receipt of a given signal, it is this specific code that is triggered by the operating system.
  • This specific code allows the immediate transmission of (first) logging information to the logging thread through the communication interface I c .
  • This code can also provide a wait time for the journal thread to develop second log information from this first logging information and publish it through the publish interface.
  • the subscriber process elements can be informed of the cause of termination of the process.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Multimedia (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L'invention concerne un procédé de journalisation comportant des étapes consistant à: Exécuter un processus (P1) comportant au moins un fil applicatif (F1, F2) et au moins un fil de journalisation (Fj) sur un ensemble de dispositifs de traitement de l'information; Détecter au sein du au moins un fil applicatif un événement de journalisation et transmettre immédiatement des premières informations de journalisation au fil de journalisation (Fj); Recevoir lesdites premières informations de journalisation et élaborer des secondes informations de journalisation à partir des premières informations de journalisation; et, Publier ces secondes informations de journalisation à travers une interface de publication (Ip) vers au moins un élément de traitement (Fs, Pj) préalablement inscrit auprès du fil de journalisation.

Description

MECANISME HAUTE PERFORMANCE POUR GENERATION D'INFORMATIONS DE JOURNALISATION D'UN PROCESSUS
INFORMATIQUE
DOMAINE DE L'INVENTION
L'invention concerne le domaine de la journalisation de processus au sein d'une application logicielle exécutée sur un ensemble de dispositifs de traitement de l'information. Plus particulièrement, l'invention concerne un procédé permettant la journalisation de processus dans le cas d'une application logicielle fonctionnant avec plusieurs processus et/ou fils d'exécution. CONTEXTE DE L'INVENTION
La journalisation ou « logging » en langue anglaise est un mécanisme permettant d'exporter des informations en cours d'exécution d'une application logicielle destinée au développeur, au testeur, ou à d'autres personnes d'une équipe technique ayant en charge l'application logicielle. Ces informations permettent de révéler certains dysfonctionnements, ou, ceux-ci connus, d'en faciliter la détermination de la cause et la correction. L'exportation des informations de journalisation peut se faire pendant des phases de développement de l'application logicielle, ou en phase de tests au sein d'une communauté de testeurs, mais également en phase de production. Les informations de journalisation sont alors exportées chez les utilisateurs de l'application, mais peuvent être « remontées » d'une façon ou d'une autre à l'équipe technique en charge du logiciel.
Les informations de journalisation peuvent être exportées vers un terminal de visualisation, ou vers une mémoire, notamment une mémoire de masse de type « disque dur ». Certains applications logicielles « critiques » nécessitent des temps de réponse fortement contraints mais requièrent une grande quantité de calculs. Pour concilier ces deux exigences, elles sont classiquement déployées sur des systèmes composés d'un ensemble de dispositifs de traitement de l'information. Il est alors fait appel à des techniques de programmation parallèle afin de tirer profit de ces dispositifs de traitement.
Toutefois, malgré ce parallélisme qui peut être massif, concilier le temps de réponse et le traitement d'une très grande quantité de calculs reste une contrainte forte.
Or, la journalisation nécessite des entrées/sorties, vers un terminal de visualisation ou une mémoire, par exemples. Les mécanismes d'entrée/sorties sont coûteux en termes de temps de traitement. Par conséquent, la journalisation impacte les performances d'une application logicielle.
Dans le cadre d'une application logicielle critique, il est même très souvent choisi de ne pas effectuer de journalisation afin de ne pas diminuer ses performances. Il en résulte alors une difficulté pour révéler et corriger les dysfonctionnements de cette application logicielle.
RESUME DE L'INVENTION
Le but de la présente invention est d'améliorer l'état de la technique en fournissant des mécanismes pour permettre une journalisation efficace, y compris pour des applications logicielles critiques, notamment des applications logicielles parallèles.
A cette fin, la présente invention propose un procédé de journalisation comportant des étapes consistant à : Exécuter un processus comportant au moins un fil applicatif et au moins un fil de journalisation sur un ensemble de dispositifs de traitement de l'information ;
Détecter au sein du au moins un fil applicatif un événement de journalisation et transmettre immédiatement des premières informations de journalisation audit au moins un fil de journalisation;
Recevoir lesdites premières informations de journalisation et élaborer des secondes informations de journalisation à partir desdites premières informations de journalisation; et,
Publier lesdites secondes informations de journalisation à travers une interface de publication vers au moins un élément de traitement inscrit auprès dudit au moins un fil de journalisation.
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 :
ledit au moins un élément de traitement comprend un fil de sortie appartenant audit processus.
ledit au moins un élément de traitement comprend un fil d'un processus de journalisation distinct dudit processus, ledit fil applicatif transmet lesdites premières informations audit au moins un fil de journalisation de façon asynchrone à travers une interface de communication.
ladite interface de communication et ladite interface de publication sont de type socket et conformes à la bibliothèque ZeroMQ.
au démarrage dudit processus, ledit au moins un fil applicatif attend l'initialisation dudit au moins un fils de journalisation avant de poursuivre son exécution, et dans lequel ledit fils de journalisation s'initialise en se synchronisant avec un sous- ensemble dudit au moins un élément de traitement, lesdites premières informations de journalisation comprennent un nom et un niveau.
lorsque ledit processus est dupliqué, ledit au moins un fil de journalisation est terminée, puis redémarrée au sein du processus parent initial.
lorsque ledit au moins un fils de journalisation reçoit un signal, il publie des secondes informations de journalisation liées audit signal, puis déclenche le code de traitement associé audit signal.
lorsque ledit fils applicatif reçoit un signal, il transmet des premières informations de journalisation liées audit signal audit au moins un fil de journalisation, attend durant un temps déterminé puis provoque la terminaison dudit processus.
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 exemple de mise en œuvre de l'invention.
La figure 2 représente schématiquement une machine à états finis selon un mode de réalisation de l'invention. DESCRIPTION DETAILLEE DE L'INVENTION
D'une façon logicielle, une application logicielle est constituée d'un ou plusieurs processus.
Un processus, ou « process » en langue anglaise, peut être vu comme un programme en cours d'exécution par un système de traitement de l'information (ou ordinateur). Un processus peut être défini comme comportant :
Un ensemble d'instructions à exécuter, pouvant être dans la mémoire morte, mais le plus souvent chargé depuis la mémoire de masse vers la mémoire vive ;
un espace d'adressage en mémoire vive pour stocker la pile, les données de travail, etc. ;
Des ressources telles que les ports réseau.
Un même processus peut comporter plusieurs fils d'exécution ou, « threads » en langue anglaise, ou encore tâche ou processus léger. A la différence d'un processus, un fil d'exécution ne dispose pas de sa propre mémoire virtuelle mais la partage avec tous les fils d'un même processus.
Dans l'exemple illustré par la figure 1, une application comporte deux processus P1; P2. Le processus Pi comporte trois fils d'exécution F1; F2, F3. Quoi que cela ne soit pas représenté sur la figure, le processus P2 peut également comporter plusieurs fils d'exécution.
Il est à noter que les fils d'exécution peuvent avoir une durée de vie différente de celle des processus, et, a fortiori, de la durée d'exécution de l'application : les fils peuvent être exécutés dynamiquement en cours d'exécution du processus et terminés à tout moment, une fois la tâche pour laquelle ils sont prévus achevée. La figure 1 illustre donc une situation à un moment donné de l'exécution de l'application logicielle. Dans la suite, les fils d'exécution F1; F2 seront appelés « fils applicatif », afin de les distinguer du ou des fils de journalisation Fj et du fil de sortie Fs qui seront décrit plus loin. Le système de traitement de l'information permettant d'exécuter l'application logicielle est typiquement un système parallèle formé d'ensemble de dispositifs de traitement de l'information.
Chaque dispositif de traitement de l'information peut être par exemple un microprocesseur avec des circuits associés (mémoire...), et le système est alors formé d'un ensemble de microprocesseurs interconnectés. Un autre exemple est celui d'un microprocesseur unique formant un système, et composé d'un ensemble de cœurs physiques. Un tel microprocesseur est généralement appelé multi-cœurs (ou « multicore » en langue anglaise).
Quelque soit l'architecture mise en œuvre, les processus P1; P2, Pj de l'exemple de la figure 1 et les fils d'exécution qu'ils comportent peuvent être exécutés en parallèle.
Lorsque le processus PI démarre au moins un fil d'exécution démarre également. Ce premier fil peut par la suite lancer l'exécution d'autres fils. Ces fils peuvent bien évidemment être des fils applicatifs (c'est-à-dire appartenant à l'application et permettant de mettre en œuvre la « logique » de l'application), mais aussi notamment des fils de journalisation Fj.
Dans la suite, ainsi qu'illustré sur la figure 1, un seul fil de journalisation est décrit. Il est toutefois possible de prévoir plusieurs fils de journalisation, notamment afin de permettre une répartition de charge.
Selon un mode de réalisation, lorsque le fil de journalisation démarre il créé :
Une interface de communication Ic, permettant la réception de premières informations de journalisation des fils applicatifs F1; F2, c'est-à-dire du fil applicatif principal et d'éventuels fils qu'il pourra ensuite créer ;
Une interface de publication IP permettant de publier des secondes informations de journalisation vers des éléments de traitement On appelle ici « éléments de traitement » les fils d'exécution et les processus. Sur la figure 1, comme nous le verrons ultérieurement, le processus de journalisation Pj et le fil de sortie Fs forme de tels éléments de traitement qui sont susceptibles de recevoir les informations de journalisation.
Selon un mode de réalisation de l'invention, ces interfaces sont de type « socket ». Un « socket » est un mécanisme de communication bien connu de l'homme du métier, apparu sur les systèmes d'exploitation de type « Unix » mais aujourd'hui présent sous la plupart des systèmes d'exploitation.
Elles peuvent par exemple être conformes à ZeroMQ. ZeroMQ est une plateforme de type « middleware » qui s'insère entre le système d'exploitation sous-jacent et les applications afin d'apporter des services d'infrastructure supplémentaires et indépendants du système d'exploitation. Par rapport à des plateformes concurrentes telles CORBA, par exemple (Common Object Request Broker Architecture), ZeroMQ apporte une grande facilité d'utilisation et de très bonnes performances : le code est très court pour les fils application, engendrant peu de surcharge de traitement, et le traitement au sein-même de la bibliothèque ZeroMQ est également très rapide. De sorte, ZeroMQ répond aux exigences de l'invention et permet de remplir les services souhaités sans ajout d'un traitement préjudiciable.
Les mécanismes offerts par ZeroMQ sont notamment accessibles à travers une bibliothèque à du code applicatif en langage C. Les mécanismes et avantages de l'invention sont donc accessibles pour des processus développés en langage C. Selon un mode de réalisation, l'interface de communication le est une interface asynchrone : elle permet au fil applicatif d'émettre des informations de journalisation, puis de poursuivre son traitement, sans avoir à attendre un acquittement de la part du fil de journalisation Fj.
Dans le cadre d'une mise en œuvre utilisant ZeroMQ, cette interface de communication Ic peut être de type push/pull. Auquel cas, dès son démarrage, le fil de journalisation créé un socket de type « pull ». Les fils applicatifs F1; F2 peuvent alors transmettre les informations de journalisation à travers un socket de type « push » connectée au socket « pull » du fil de journalisation Fj.
Entre les deux types de sockets formant l'interface de communication le un protocole de transport inter-fil et intraprocessus comme le protocole « inproc » peut être mis en place. Ce protocole permet la transmission de messages entre fils à l'intérieur d'un même processus : l'information est transmise directement par la mémoire appartenant au contexte associé au processus. Ce mécanisme n'engendre donc pas d'entrées/sorties, et contribue donc aux hautes performances du procédé selon l'invention.
L'interface de publication IP peut comprendre un socket de type « pub » créé au sein du fil de journalisation Fj. Les éléments de traitement (processus ou fils) Pj, Fs peuvent créer des sockets de type « sub » afin de s'abonner (« subscribe » en anglais) au socket « pub » du fil de journalisation Pj. Le modèle « publish-subscribe » géré par ZeroMQ permet ainsi de transmettre des messages vers tous les éléments de traitement préalablement abonnés.
Selon un mode de réalisation de l'invention, au démarrage du processus P1; le fil applicatif attend l'initialisation de ce fils de journalisation Fj avant de poursuivre son exécution.
Lorsqu'il lance l'exécution du fil de journalisation Fj, le fil (principal) du processus Pi peut préciser un nombre d'éléments de traitement qui doivent recevoir des informations de journalisation. Il recevra un acquittement de la part du fil de journalisation Fj que lorsque ce nombre d'éléments de traitement abonné sera atteint. Une fois l'acquittement reçu, le fil d'exécution peut alors poursuivre son exécution. De même, le fil de journalisation Fj s'initialise en se synchronisant avec le nombre d'éléments de traitement qui doivent recevoir des informations de journalisation.
Pour ce faire, le fil de journalisation Fj peut publier des informations de synchronisation. A leur réception, les éléments de traitement qui les ont reçus vont transmettre un acquittement au fil de journalisation. Celui-ci peut compter les acquittements reçus et aisément déterminer lorsque le nombre spécifié est atteint.
Cette phase de synchronisation permet de s'assurer qu'aucune information de journalisation n'est perdue : en effet, l'établissement de la connexion entre le fil de journalisation Fj et les éléments de traitement peut prendre un certain temps. En outre, les éléments de traitement eux-mêmes peuvent être en cours d'initialisation également. Durant ce temps, si le fil de journalisation Fj commençait immédiatement à émettre des informations de journalisation, celles-ci seraient perdues, du fait de l'absence d'acquittement dans la transmission des informations de journalisation publiées de la part des éléments de traitement récepteurs. Cette absence d'acquittement permet d'atteindre des bonnes performances
Or, dans certaines situations, il peut être important voire crucial de ne perdre aucune information de journalisation.
Selon cette mise en œuvre, il est donc possible de spécifier le nombre des éléments de traitement pour lesquels la réception de l'ensemble des informations de synchronisation doit être garantie par ce mécanisme de synchronisation.
Ce nombre d'éléments détermine un sous ensemble de l'ensemble des éléments de traitements abonnés, car une fois la phase d'initialisation terminée, il est tout à fait possible que d'autres éléments de traitement s'abonnent aux publications du fil de journalisation Fj. Toutefois, ceux-ci peuvent manquer les premières publications du fil de journalisation Fj.
Le procédé de journalisation selon l'invention comporte une étape d'exécution du processus Pi. Comme précédemment décrit, cette exécution implique l'exécution d'au moins un fil applicatif Fi et d'un fil de journalisation Fj. Dans le cas d'un processus écrit en langage C, ce fil applicatif Fi peut correspondre à l'exécution de la fonction main().
Une fois la phase d'initialisation terminée, le ou les fils applicatifs exécutent le code de l'application logicielle.
Le procédé consiste alors à détecter au sein du ou des fils applicatifs un événement de journalisation et à transmettre immédiatement des premières informations de journalisation el, e2 au fil de journalisation Fj.
La détection d'un événement de journalisation est une technique connue en soi, qui consiste à insérer des jalons (ou « logger ») dans le code afin de déclencher un événement de journalisation lorsque certaines conditions sont remplies. Ces conditions peuvent être tout simplement le passage par un point précis du code (afin de permettre de suivre le déroulement du code), ou bien une situation d'erreur, etc.
Ces informations de journalisation générées par le fil applicatif F1; F2 sont ici appelées « premières informations de journalisation » afin de les distinguer des secondes informations de journalisation qui seront celles publiées par le fil de journalisation Fj.
Ces informations peuvent ne comporter qu'un nom et un niveau. Selon un mode de réalisation, ces premières informations ne comportent que ce nom et ce niveau.
Le nom peut être une chaîne de caractères identifiant un jalon au sein du code applicatif.
Le niveau est généralement un nombre entier, identifiant un degré de criticité de l'événement. Ce niveau peut appartenir à une liste préalablement définie qui peut comprendre : « Critical » : pour indiquer une erreur critique qui, en général, engendre la terminaison du processus.
« Error » : pour indiquer une erreur normale
« Warning » : pour indiquer une erreur peu importante
- « Output » : pour indiquer un message normal, non lié à une erreur.
« Info » : pour indiquer un message destiné à l'utilisateur de l'application (et non pas uniquement au développeur ou testeur) « Debug » : pour indiquer un message davantage de détail, destiné à des testeurs (ou « débogueurs ») de l'application
- « Trace » : pour indiquer un message lié au niveau le plus détaillé.
Son utilisation est sans doute destinée au stade de développement de l'application.
Cette liste est évidement non exhaustive. Bien d'autres niveaux peuvent être définis par le développeur de l'application.
II est important que toutes les sorties destinées aux développeurs ou testeurs soient conformes à ce formalisme afin d'être prises en compte par les mécanismes de l'invention. Il est notamment donc important pour le développeur d'éviter des sorties directes, notamment par la fonction printf() du langage C : elles peuvent être remplacées par le niveau « Output » par exemple.
Ces premières informations peuvent également comprendre :
une date (« timestamp ») de survenue de l'événement de journalisation ;
- un identifiant du processus P1;
d'autres informations sur le contexte d'exécution : identifiant du fil du noyau (« kernel »), nom de l'application logicielle, nom du fichier, numéro de la ligne du code applicatif, nom de la fonction en cours d'exécution, etc. Selon l'invention, le fil applicatif transmet immédiatement ces premières informations de journalisation au fil de journalisation Fj au travers de l'interface de communication Ic. Comme il a été vu précédemment, cette interface est asynchrone et ne nécessite pas d'acquittement. Aucun verrou n'est non plus mis en place, de sorte qu'une fois l'émission effectuée (et sans se préoccuper de la réception par le fil de journalisation), le fil applicatif F1; F2 peut poursuivre immédiatement le traitement applicatif.
Selon un mode de réalisation, aucun autre traitement n'est appliqué entre la détection d'un événement de journalisation et l'émission des premières informations de journalisation.
Selon un mode de réalisation, uniquement un traitement de mise au format est appliqué.
En aucun cas, selon l'invention, le fil applicatif ne met en place des mécanismes d'entrées/sorties : ces mécanismes sont mis en œuvre par le fil de journalisation Fj, et donc déportés hors du fil applicatif F1; F2.
Il en résulte que pour le fil applicatif, le surcoût est réduit au minimum. Selon un mode de réalisation de l'invention, le code applicatif est divisé en modules. Chaque module est associé à un nom ou identifiant, qui peut être incorporé dans le nom du jalon de journalisation.
Par exemple, dans un module « Modulel », des jalons de noms « Module l.jalonl », « Module l.jalon2 », etc.
Ce mécanisme permet de nommer de façon plus claire les différents événements de journalisation : en fin de chaîne, on peut ainsi déterminer directement l'emplacement du code où a eu lien l'événement en fonction du nom de module inclut dans son nom. Le fil de journalisation Fj reçoit de façon asynchrone les premières informations de journalisation émises par le ou les fils applicatifs F1; F2. Son rôle est alors d'élaborer des secondes informations de journalisation à partir de des premières informations de journalisation reçues des fils applicatifs, et, éventuellement, d'informations complémentaires. Ces informations complémentaires peuvent être des informations communes à l'ensemble des fils applicatifs du processus.
Le traitement mis en œuvre par le fil de journalisation Fj peut se limiter à l'élaboration de ces secondes informations de journalisation. L'élaboration peut comprendre d'une part l'adjonction des éventuelles informations complémentaire mais aussi une mise en forme, selon un format prédéfini permettant son exploitation par des éléments de traitement.
Cette mise au format peut être très simple et uniquement consister en un formatage de sorte que les secondes informations soient dans un format indépendant du langage informatique utilisé.
Ces secondes informations sont ensuite publiées par le fil de journalisation Fj à travers l'interface de publication IP. Elles peuvent alors être reçues par un ou plusieurs éléments de traitement Fs, Pj préalablement inscrits auprès du fil de journalisation, ainsi que précédemment décrit.
Ces éléments de traitement peuvent comprendre un fil de sortie Fs appartenant au processus Pl. Ce fil de sortie peut être prévu pour réaliser une sortie des secondes informations de journalisation sur un terminal de visualisation (écran...), dans un fichier stocké sur une mémoire, notamment une mémoire de masse, etc.
Ces mécanismes de sortie sont en général coûteux en temps de traitement du fait de l'interaction nécessaire avec du matériel et, en général, de la nécessité d'un acquittement (le fil doit s'assurer que l'information a bien été mémorisée sur le disque dur, etc.). Grâce à l'invention, ces mécanismes n'impactent pas le fil applicatif qui suit son déroulement de façon parallèle à celui du fil de journalisation. Les éléments de traitement peuvent également comprendre un processus de journalisation Pj distinct dudit processus Pi.
Ce processus peut également mettre en œuvre des mécanismes de sortie de la même façon qu'un fil de sortie Fs.
Il peut aussi mettre en œuvre des mécanismes plus complexes d'exploitation des informations de journalisation : filtrage, etc.
Selon une mise en œuvre de l'invention, lorsque le processus Pi est dupliqué, le fil de journalisation Fj et l'éventuel fil de sortie Fs sont terminées, puis redémarrées au sein du processus parent initial Pi. Au sein du processus fils, ces deux fils ne sont pas redémarrés (ils passent dans un état « finalized », comme il sera décrit plus loin). En effet, très souvent, le processus fils va déclencher l'exécution d'une fonction « exec() » qui va remplacer et « écraser » le contenu du processus fils par un nouveau programme : il est donc inutile de déclencher un redémarrage automatique des fils de journalisation et de sortie, et même contre-productif.
La duplication, ou fourche, « fork » en langue anglaise, est le mécanisme de création d'un nouveau processus dans une application logicielle fonctionnant sous un système d'exploitation de type « Unix », ou conforme à la norme Posix.
La duplication d'un processus comportant plusieurs fils d'exécution
(« multithreaded » selon la terminologie anglaise) pose des problèmes importants. Cette problématique est notamment exposée dans la norme Posix, IEEE 1003.1, notamment dans la partie « Rationales »
Le mécanisme mis en œuvre par l'invention permet de les éviter. En outre, une gestion d'une machine à états peut être mise en place afin de gérer au mieux les duplications « fork() ».
La figure 2 illustre une telle machine à états du fil de journalisation Fj. On considère que le fil Fj peut être dans 5 états principaux. Ces états sont classiques :
« Unset » (indéterminé), correspondant à un état « non démarré ». Cela correspondant à l'état dans lequel le fil peut être avant que le fil applicatif ne déclenche son initialisation.
« Initializing » (initialisation), correspondant à un état d'initialisation du fil, durant lequel notamment ont lieu l'étape de synchronisation préalablement décrite.
« initialized » (initialisé), correspondant au fonctionnement normal du fil de journalisation.
« finalizing » (terminaison) correspondant à la terminaison du fil de journalisation
« Finalized » (terminé) correspondant à un état où le fil est terminé
Dans certains états, selon ce mode de réalisation de l'invention, les duplications sont interdites. C'est le cas des états « initializing » et « finalizing » : le flèche « fork() » aboutit à un état « illégal »
Dans les états particuliers « unset » et « finalized », la duplication peut être autorisée et ne pas donner lieu à des traitements particuliers. La flèche « fork() » reboucle sur l'état courant.
Dans l'état « initialized », la duplication amène la transition vers l'état « finalizing » afin de terminer le fil de journalisation.
Il en va de même pour l'éventuel fil de sortie Fs.
Une fois les fils terminés, le processus peut être dupliqué.
Une fois la duplication effectuée, les fils Fj et Fs peut être redémarrés. Dans le processus parent (c'est-à-dire le processus initial PO, les fils sont redémarrés dans l'état où ils étaient avant la duplication, c'est-à-dire l'état « Initialized ». Dans le processus fils, les fils démarrent dans un état « unset » : le fil applicatif du processus fils doit alors lancer son initialisation pour le faire changer d'état.
Par ailleurs, un processus Pi fonctionnant sous un système de type Posix ou unix peut recevoir des signaux. Ces signaux peuvent être prévus pour terminer le processus, comme les signaux SIGINT, SIGTERM, SIGQUIT, SIGSEGV, SIGBUS.
Lorsqu'un tel signal est reçu par le fil de journalisation Fj, celui-ci peut choisir de les traiter ou non selon leur nature. Par exemple, les signaux
SIGINT, SIGTERM et SIGQUIT peuvent être considérés comme devant être traités par le fil applicatif et donc non considérés par le fil de journalisation. Il peut par contre considérer d'autres types de signaux comme les signaux SIGSEGV et SIGBUS.
A la réception d'un tel signal, le fil de journalisation Fj peut considérer qu'il s'agit d'un événement de journalisation, et publier alors des informations de journalisation, liées à ce signal.
Ensuite, il peut à nouveau déclencher ce signal et son traitement
« normal ». Le traitement normal d'un signal est assuré par un code de traitement, appelé typiquement « handler », et associé à ce signal. Le traitement normal de ce signal SIGSEGV ou SIGBUS entraine la terminaison du processus.
Ainsi, grâce à ce mécanisme, le processus adopte le comportement attendu consistant à se terminer, mais il est aussi assuré qu'une journalisation a lieu lié à la réception de cet événement : aussi, si un élément de traitement est abonné au fil de journalisation, il sera informé de la cause de la terminaison du processus Pi. Si un signal est reçu par le fil applicatif, celui-ci peut déterminer qu'il s'agit d'un événement de journalisation. Pour ce faire, un code spécifique peut être associé au signal en tant que « handler » : à la réception d'un signal donné, c'est ce code spécifique qui est déclenché par le système d'exploitation.
Ce code spécifique permet la transmission immédiate de (premières) informations de journalisation vers le fil de journalisation au travers de l'interface de communication Ic.
Ce code peut également prévoir un temps d'attente permettant au fil de journalisation d'élaborer des secondes informations de journalisation à partir de ces premières informations de journalisation et de les publier via l'interface de publication.
Seulement alors, le code spécifique peut appeler le code normal de traitement pour réaliser la terminaison du processus ou terminer lui-même le processus.
Ainsi, les éléments de traitement abonnés peuvent être informés de la cause de la terminaison du processus.
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

REVENDICATIONS
Procédé de journalisation comportant des étapes consistant à :
Exécuter un processus (PI) comportant au moins un fil applicatif (Fl, F2) et au moins un fil de journalisation (Fj) sur un ensemble de dispositifs de traitement de l'information ;
Détecter au sein du au moins un fil applicatif un événement de journalisation et transmettre immédiatement des premières informations de journalisation audit au moins un fil de journalisation (Fj) ;
Recevoir lesdites premières informations de journalisation et élaborer des secondes informations de journalisation à partir desdites premières informations de journalisation; et,
Publier lesdites secondes informations de journalisation à travers une interface de publication (IP) vers au moins un élément de traitement (Fs, Pj) préalablement inscrit auprès dudit au moins un fil de journalisation.
Procédé selon la revendication 1, dans lequel ledit au moins un élément de traitement comprend un fil de sortie (Fs) appartenant audit processus
(Pi).
Procédé selon l'une des revendications 1 ou 2, dans lequel ledit au moins un élément de traitement comprend un fil d'un processus de journalisation (Pj) distinct dudit processus (P .
Procédé selon l'une des revendications précédentes dans lequel ledit fil applicatif (F transmet lesdites premières informations audit au moins un fil de journalisation de façon asynchrone à travers une interface de communication (le).
5. Procédé selon la revendication précédente, dans lequel ladite interface de communication et la dite interface de publication sont de type socket et conformes à la bibliothèque ZeroMQ.
6. Procédé selon l'une des revendications précédentes, dans lequel au démarrage dudit processus (PO, ledit au moins un fil applicatif (Fl, F2) attend l'initialisation dudit au moins un fils de journalisation (Fj) avant de poursuivre son exécution, et dans lequel ledit fils de journalisation s'initialise en se synchronisant avec un sous-ensemble dudit au moins un élément de traitement (Fs, Pj).
7. Procédé selon l'une des revendications précédentes dans lequel lesdites premières informations de journalisation comprennent un nom et un niveau.
8. Procédé selon l'une des revendications précédentes, dans lequel lorsque ledit processus (P est dupliqué, ledit au moins un fil de journalisation (Fj) est terminée, puis redémarrée au sein du processus parent initial
(PO-
9. Procédé selon l'une des revendications précédentes, dans lequel lorsque ledit au moins un fils de journalisation reçoit un signal, il publie des secondes informations de journalisation liées audit signal, puis déclenche le code de traitement associé audit signal.
10. Procédé selon l'une des revendications précédentes, dans lequel lorsque ledit fils applicatif reçoit un signal, il transmet des premières informations de journalisation liées audit signal audit au moins un fil de journalisation, attend durant un temps déterminé puis provoque la terminaison dudit processus.
PCT/FR2015/052267 2014-09-10 2015-08-25 Mecanisme haute performance pour generation d'informations de journalisation d'un processus informatique WO2016038272A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP15763052.6A EP3191961A1 (fr) 2014-09-10 2015-08-25 Mecanisme haute performance pour generation d'informations de journalisation d'un processus informatique
US15/510,638 US11874758B2 (en) 2014-09-10 2015-08-25 High-performance mechanism for generating logging information within application thread in respect of a logging event of a computer process
JP2017534008A JP6498770B2 (ja) 2014-09-10 2015-08-25 コンピュータプロセスに関するロギング情報を生成するための高性能機構
CN201580060764.2A CN107003927A (zh) 2014-09-10 2015-08-25 用于产生关于计算机进程的日志记录信息的高性能机制
IL251095A IL251095A0 (en) 2014-09-10 2017-03-12 A high-performance mechanism for generating input information about a computer process

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1458511 2014-09-10
FR1458511A FR3025627B1 (fr) 2014-09-10 2014-09-10 Mecanisme haute performance pour generation d'informations de journalisation d'un processus informatique

Publications (1)

Publication Number Publication Date
WO2016038272A1 true WO2016038272A1 (fr) 2016-03-17

Family

ID=52450276

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2015/052267 WO2016038272A1 (fr) 2014-09-10 2015-08-25 Mecanisme haute performance pour generation d'informations de journalisation d'un processus informatique

Country Status (7)

Country Link
US (1) US11874758B2 (fr)
EP (1) EP3191961A1 (fr)
JP (1) JP6498770B2 (fr)
CN (1) CN107003927A (fr)
FR (1) FR3025627B1 (fr)
IL (1) IL251095A0 (fr)
WO (1) WO2016038272A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106649071A (zh) * 2016-12-30 2017-05-10 广州华多网络科技有限公司 进程内部日志上报的方法和装置
WO2019129957A1 (fr) 2017-12-27 2019-07-04 Bull Sas Procede de controle de la gestion des traces d'evenements dans l'execution d'une application informatique sur une machine informatique

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113434362A (zh) * 2021-06-24 2021-09-24 广州欢网科技有限责任公司 Android程序发生异常时自动预警的方法及装置
CN113190418A (zh) * 2021-07-01 2021-07-30 奇安信科技集团股份有限公司 日志接收方法、装置、电子设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7086064B1 (en) * 2000-05-27 2006-08-01 International Business Machines Corporation Performance profiling tool
US20130036404A1 (en) * 2011-08-01 2013-02-07 Vmware, Inc. Testing of a software system using instrumentation at a logging module
US8499299B1 (en) * 2010-06-29 2013-07-30 Ca, Inc. Ensuring deterministic thread context switching in virtual machine applications
US8667472B1 (en) * 2010-07-29 2014-03-04 Disney Enterprises, Inc. System and method of instrumenting code for in-production monitoring

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5870588A (en) * 1995-10-23 1999-02-09 Interuniversitair Micro-Elektronica Centrum(Imec Vzw) Design environment and a design method for hardware/software co-design
US6256775B1 (en) * 1997-12-11 2001-07-03 International Business Machines Corporation Facilities for detailed software performance analysis in a multithreaded processor
FI114663B (fi) * 2001-12-20 2004-11-30 Nokia Corp Menetelmä ja järjestelmä käyttöjärjestelmätoimintojen suorittamiseksi sekä elektroniikkalaite
JP4686226B2 (ja) * 2005-03-22 2011-05-25 株式会社東芝 駅務中継機
US7661036B1 (en) * 2005-11-08 2010-02-09 Oakley Networks Cache for collecting events on a monitored computer
JP5050357B2 (ja) * 2006-01-25 2012-10-17 富士通株式会社 ロギング情報管理方法およびロギング情報管理システムおよびロギング情報管理手段
US20080250412A1 (en) * 2007-04-06 2008-10-09 Elizabeth An-Li Clark Cooperative process-wide synchronization
CN101414255A (zh) * 2007-10-19 2009-04-22 国际商业机器公司 日志事件处理方法与设备
KR20100022171A (ko) * 2008-08-19 2010-03-02 삼성전자주식회사 스레드 지향 로깅 시스템에서 로그 저장 방법 및 장치
CN101763593A (zh) * 2009-12-17 2010-06-30 中国电力科学研究院 一种实现系统审计日志的方法及装置
US9384112B2 (en) * 2010-07-01 2016-07-05 Logrhythm, Inc. Log collection, structuring and processing
CN103154893B (zh) * 2010-10-05 2016-05-04 富士通株式会社 多核处理器系统、监视控制方法以及监视控制程序
CN102455889B (zh) * 2010-10-29 2014-03-26 金蝶软件（中国）有限公司 一种获取进程输出日志的方法、装置及企业系统
WO2013016299A1 (fr) * 2011-07-22 2013-01-31 Yilin Wang Système d'événements et procédés d'utilisation
JP5906883B2 (ja) * 2012-03-28 2016-04-20 富士通株式会社 ログ出力装置、ログ出力方法およびログ出力プログラム
US9202047B2 (en) * 2012-05-14 2015-12-01 Qualcomm Incorporated System, apparatus, and method for adaptive observation of mobile device behavior
US10192261B2 (en) * 2012-08-23 2019-01-29 Openet Telecom Ltd. System and method for performing offline revenue assurance of data usage
US20140237474A1 (en) * 2013-02-19 2014-08-21 Appsense Limited Systems and methods for organizing dependent and sequential software threads

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7086064B1 (en) * 2000-05-27 2006-08-01 International Business Machines Corporation Performance profiling tool
US8499299B1 (en) * 2010-06-29 2013-07-30 Ca, Inc. Ensuring deterministic thread context switching in virtual machine applications
US8667472B1 (en) * 2010-07-29 2014-03-04 Disney Enterprises, Inc. System and method of instrumenting code for in-production monitoring
US20130036404A1 (en) * 2011-08-01 2013-02-07 Vmware, Inc. Testing of a software system using instrumentation at a logging module

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MONAJJEMI VALIALLAH ET AL: "Drums: A Middleware-Aware Distributed Robot Monitoring System", 2014 CANADIAN CONFERENCE ON COMPUTER AND ROBOT VISION, IEEE, 6 May 2014 (2014-05-06), pages 211 - 218, XP032596789, DOI: 10.1109/CRV.2014.36 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106649071A (zh) * 2016-12-30 2017-05-10 广州华多网络科技有限公司 进程内部日志上报的方法和装置
CN106649071B (zh) * 2016-12-30 2019-12-20 广州华多网络科技有限公司 进程内部日志上报的方法和装置
WO2019129957A1 (fr) 2017-12-27 2019-07-04 Bull Sas Procede de controle de la gestion des traces d'evenements dans l'execution d'une application informatique sur une machine informatique

Also Published As

Publication number Publication date
IL251095A0 (en) 2017-04-30
FR3025627B1 (fr) 2018-03-23
JP6498770B2 (ja) 2019-04-10
JP2017532703A (ja) 2017-11-02
US11874758B2 (en) 2024-01-16
EP3191961A1 (fr) 2017-07-19
CN107003927A (zh) 2017-08-01
FR3025627A1 (fr) 2016-03-11
US20170255540A1 (en) 2017-09-07

Similar Documents

Publication Publication Date Title
US8205215B2 (en) Automated event correlation
WO2016038272A1 (fr) Mecanisme haute performance pour generation d'informations de journalisation d'un processus informatique
EP2257876B1 (fr) Methode de prechargement dans une hierarchie de memoires des configurations d'un systeme heterogene reconfigurable de traitement de l'information
FR2969334A1 (fr) Module materiel de securite et procede de debogage d'un tel module
FR2958059A1 (fr) Procede, programme d'ordinateur et dispositif de validation d'execution de taches dans des systemes informatiques evolutifs
FR2780589A1 (fr) Agent de communication entre un administrateur de systeme informatique et un systeme de ressources distribuees et outils de creation d'un tel agent
FR3031822A1 (fr) Telechargement de donnees sur un equipement distant
EP2278466A1 (fr) Dispositif et procédé pour l'exécution distribuée de traitements de données numériques
EP1907931A1 (fr) Architecture a composants logiciels pour les applications a plate-forme d'execution donnant acces au niveau metaprogramme
EP2996036B1 (fr) Procédé de surveillance d'une architecture applicative comportant une pluralité de services
EP3881515B1 (fr) Système de supervision formelle de communications
FR3071630A1 (fr) Procede de gestion de modules logiciels embarques pour un calculateur electronique d'un appareil electrique de coupure
EP3729273B1 (fr) Systeme et procede d'elaboration et d'execution de tests fonctionnels pour grappe de serveurs
FR2990533A1 (fr) Procede de suivi d'execution d'un logiciel et logiciel pour la mise en oeuvre du procede
EP3195113B1 (fr) Procédé de vérification de traçabilité de premières instructions en un langage de programmation procédurale générées à partir de secondes instructions en un langage de modélisation
EP3144812A1 (fr) Architecture client/serveur pour l administration d'un supercalculateur
FR2806498A1 (fr) Systeme informatique de calcul et procede de calcul mis en oeuvre au moyen d'un tel systeme
WO2019129957A1 (fr) Procede de controle de la gestion des traces d'evenements dans l'execution d'une application informatique sur une machine informatique
FR3118815A1 (fr) Estimation de la progression de l'exécution d'une tâche logicielle
FR2938087A1 (fr) Procede d'implementation d'une machine a etats finis via l'utilisation d'annotations java.
FR3031820A1 (fr) Procede de determination de la validite d'un modele
FR2911971A1 (fr) Procede et systeme de verification de proprietes d'un programme informatique.
FR3101973A1 (fr) Dispositif de surveillance
FR3141301A1 (fr) Procédé de traitement d’une requête d’exécution d’un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d’ordinateur correspondants
WO2024121266A1 (fr) Systeme de deploiement et de test d' un composant d' un logiciel sur un ensemble de ressources materielles

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15763052

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017534008

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 251095

Country of ref document: IL

REEP Request for entry into the european phase

Ref document number: 2015763052

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2015763052

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 15510638

Country of ref document: US