Log Management System, Method, Device, Storage Medium, and Program Product

Abstract

The present invention provides a log management system, which can be applied to the field of data processing technology. The system includes a management controller of a server, and the management controller is used to perform the following operations: running a log acquisition engine, where the log acquisition engine is used to acquire log information generated by each thread of an application process in the management controller during the process of processing business requests; transmitting the log information to an identification allocation engine, and the identification allocation engine uses a lock-free operation mechanism shared by multiple threads in the application process to allocate corresponding storage identifiers for each log information through shared variables; inputting the log information with storage identifiers into a storage engine, and the storage engine writes each log information and the function call chain of the log information when the function call relationship changes into corresponding storage locations in a memory space pre-allocated to the application process according to the storage identifiers; and managing the log information based on the function call chain in the storage engine through a log management engine.

Description

Technical Field

[0001] The present invention relates to the field of data processing, and particularly to a log management system, method, device, medium and program product. Background Art

[0002] Logs are one of the important bases for monitoring the running status of a server. By recording and analyzing logs, potential problems of the server can be discovered in a timely manner. In the related art, in a multi-threaded running environment, thread locks are usually used to record the debug logs generated by each thread into memory and viewed through specific commands.

[0003] In the process of implementing the inventive concept of the present invention, it is found that at least the following problems exist in the related art. In a multi-threaded concurrent environment, since multiple threads need to perform write operations on a shared memory area, thread synchronization is achieved through a mutex mechanism, which not only significantly reduces the storage efficiency of log recording, but also makes it difficult to trace the logs. Summary of the Invention

[0004] In view of the above problems, the present invention provides a log management system, method, device, medium and program product.

[0005] According to a first aspect of the present invention, a log management system is provided. The system includes a management controller of a server, and the management controller is configured to perform the following operations: running a log acquisition engine, where the log acquisition engine is used to acquire log information generated by each thread of an application process in the management controller during the process of processing a service request; transmitting the log information to an identifier allocation engine, and the identifier allocation engine uses a lock-free operation mechanism shared by multiple threads in the application process to allocate corresponding storage identifiers to each of the log information through a shared variable; inputting the log information with the storage identifier into a storage engine, and the storage engine writes each of the log information and the function call chain of the log information when the function call relationship changes into a corresponding storage location in a memory space pre-allocated to the application process according to the storage identifier; and managing the log information through a log management engine based on the function call chain in the storage engine.

[0006] A second aspect of the present invention provides a log management method, which is applied to a management controller and includes: acquiring log information generated by each thread of an application process in the management controller during the process of processing a service request; using a lock-free operation mechanism shared by multiple threads in the application process to allocate corresponding storage identifiers to each of the log information through a shared variable; writing each of the log information and the function call chain of the log information when the function call relationship changes into a corresponding storage location in a memory space pre-allocated to the application process according to the storage identifier; and managing the log information through the function call chain.

[0007] A third aspect of the present invention provides an electronic device, including: one or more processors; a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the above method.

[0008] A fourth aspect of the present invention further provides a computer-readable storage medium, on which a computer program or instruction is stored, and when the computer program or instruction is executed by a processor, the steps of the above method are implemented.

[0009] A fifth aspect of the present invention further provides a computer program product, including a computer program or instruction, and when the computer program or instruction is executed by a processor, the steps of the above method are implemented.

[0010] According to an embodiment of the present invention, log information generated when each thread in an application process processes a service request is obtained through a log acquisition engine, and by using a lock-free operation mechanism shared by multiple threads in an identifier allocation engine, storage identifiers are allocated to these log information through shared variables, so that performance loss caused by thread mutual exclusion can be eliminated without using thread locks during the log storage process. Subsequently, according to the storage identifiers, the log information and its corresponding thread function call relationship are written into a pre-allocated memory space by using a storage engine, realizing effective management of the log information. This method can not only accurately record the source of the log information, but also quickly locate the problem source through the function call relationship, improving the efficiency of log management and problem troubleshooting. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Through the following description of the embodiments of the present invention with reference to the drawings, the above content and other objects, features, and advantages of the present invention will become clearer.

[0012] Figure 1 The application scenario diagram of the log management system, method, device, medium, and program product according to the embodiment of the present invention is shown.

[0013] Figure 2 The interaction flowchart of the log management system according to the embodiment of the present invention is shown.

[0014] Figure 3 The update flowchart of the thread structure in the log management system according to the embodiment of the present invention is shown.

[0015] Figure 4 The flowchart for determining the cause of an exception in the log management system according to the embodiment of the present invention is shown.

[0016] Figure 5 The flowchart of persistent storage in the log management system according to the embodiment of the present invention is shown.

[0017] Figure 6 Shows a module interaction diagram of a log management system according to another embodiment of the present invention.

[0018] Figure 7 Shows a flowchart of a log management method according to an embodiment of the present invention.

[0019] Figure 8 Shows a block diagram of an electronic device suitable for implementing the log management method according to an embodiment of the present invention. Detailed implementation manners

[0020] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. In the following detailed description, for the sake of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present invention. However, it is obvious that one or more embodiments can also be implemented without these specific details. In addition, in the following description, descriptions of well-known structures and technologies are omitted to avoid unnecessarily obscuring the concepts of the present invention.

[0021] The terms used herein are merely for describing specific embodiments and are not intended to limit the present invention. The terms "including", "comprising", etc. used herein indicate the presence of the described features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0022] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0023] In the case of using expressions such as "at least one of A, B, and C", generally, it should be interpreted according to the meaning commonly understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include, but is not limited to, a system having only A, only B, only C, having A and B, having A and C, having B and C, and / or having A, B, and C, etc.).

[0024] In the technical solution of the present invention, the user information involved (including but not limited to user personal information, user image information, user device information, such as location information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) are all information and data authorized by the user or fully authorized by all parties. Moreover, for the processing of relevant data, such as collection, storage, use, processing, transmission, provision, disclosure, and application, etc., all comply with relevant laws, regulations, and standards, adopt necessary confidentiality measures, do not violate public order and good customs, and provide corresponding operation entrances for users to choose to authorize or reject.

[0025] An embodiment of the present invention provides a log management system, which includes a management controller of a server. The management controller is used to perform the following operations: run a log acquisition engine, which is used to acquire log information generated by each thread of an application process in the management controller during the process of processing business requests; transmit the log information to an identification assignment engine, and the identification assignment engine uses a lock-free operation mechanism shared by multiple threads in the application process to assign corresponding storage identifiers to each log information through shared variables; input the log information with storage identifiers into a storage engine, and the storage engine writes each log information and the function call chain of the log information when the function call relationship changes into corresponding storage locations in the memory space pre-allocated to the application process according to the storage identifiers; manage the log information based on the function call chain in the storage engine through a log management engine.

[0026] As Figure 1 shown, the application scenario 100 according to this embodiment may include a management controller 101, a persistent storage medium 102, and a processor 103. The management controller 101 is communicatively connected to the persistent storage medium 102 and the processor 103. This communication connection has various types, including wired connections, wireless communication links, and fiber optic cables, etc., to ensure the efficiency and stability of data transmission.

[0027] The management controller 101 can be a microcontroller capable of providing various services. For example: a Baseboard Management Controller (BMC). The management controller 101 can monitor and manage the server hardware, covering functions such as temperature monitoring, power management, and hardware fault detection.

[0028] The management controller 101 consists of four different independent modules, namely the log acquisition engine 1011, the identification assignment engine 1012, the storage engine 1013, and the log management engine 1014. The log acquisition engine 1011 is responsible for collecting and receiving log information generated by the system, such as operation logs, event logs, etc., and can perform preliminary screening and classification on the logs for subsequent processing. Next, the identification assignment engine 1012 assigns a unique identifier to each log entry for easy tracking and management of the logs. The storage engine 1013 is responsible for storing the logs with assigned identifiers into corresponding storage media, such as hard disks, databases, etc., and provides efficient data read / write and retrieval functions. Finally, the log management engine 1014 manages and maintains the stored logs, such as operations like log backup, archiving, cleaning, and providing log query and analysis interfaces.

[0029] The processor 103 is used to receive instructions from the management controller 101 and perform data processing. For example, in a server environment, the processor 103 is responsible for processing various business requests, performing data operations and logical judgments, etc.

[0030] The persistent storage medium 102 is used to store data and programs, ensuring that the data is not lost after the system is powered off or restarted, and guaranteeing the security and availability of the data. In practical applications, the persistent storage medium 102 can include storage devices such as hard disks and solid-state drives, storing important information such as the operating system, application programs, and user data.

[0031] The following will be based on Figure 1 the described scenario, and through Figures 2 to 6 a detailed description of the log management system of the disclosed embodiments will be given.

[0032] As Figure 2 shown, the management controller in the system of this embodiment includes a log acquisition engine 1011, an identification assignment engine 1012, a storage engine 1013, and a log management engine 1014.

[0033] According to an embodiment of the present invention, the management controller is configured to perform the following operations: Run a log acquisition engine, which is used to acquire log information generated by each thread of the application process in the management controller during the processing of business requests. Transmit the log information to an identification assignment engine, which uses a lock-free operation mechanism shared by multiple threads in the application process and, through shared variables, assigns corresponding storage identifiers to each piece of the log information. Input the log information with storage identifiers into a storage engine, which, according to the storage identifiers, writes each piece of the log information and the function call chain of the log information when the function call relationship changes into corresponding storage locations in the memory space pre-allocated to the application process; Manage the log information based on the function call chain in the storage engine through a log management engine.

[0034] According to an embodiment of the present invention, with the improvement of server performance and the continuous increase in the requirements of the artificial intelligence industry for servers, the monitoring and remote management system needs to more accurately grasp the operating state of the server. As the core monitoring and management component in the server system, the management controller is responsible for collecting, processing, and analyzing data at all levels of the server to achieve comprehensive monitoring and remote management of the server operating state and ensure the stable operation of the server.

[0035] In the operating system of the server, an application process is an execution process of a program in the operating system and is the basic unit for the system to allocate and schedule resources. Each application process can contain one or more threads. A thread is an execution unit within a process and is the basic unit for the processor to schedule and dispatch. Each thread can execute in parallel, thereby improving the execution efficiency of the application program.

[0036] As one of the important bases for monitoring, logs play a crucial role in the management and debugging process. They detail various information during the operation of the server, covering the status, exceptions, and detailed debugging information when each thread in the application process processes business requests. By deeply analyzing these logs, the monitoring system can timely detect potential problems, give early warnings, and take corresponding measures to avoid system failures. Therefore, effective log management is crucial for ensuring the stable operation of the server, improving system performance, and quickly locating and solving problems.

[0037] During the process of log management, the log acquisition engine 1011 is used to acquire the log information generated when each thread in the application process processes business requests, and the identity allocation mechanism shared by multiple threads in the identity allocation engine 1012 is used to allocate a unique storage identity for each log. Since different application processes can be automatically isolated through independent memory spaces and log files, there is no mutual exclusion problem between processes. However, within a single application process, when multiple threads write log information to the shared memory space, mutual exclusion processing is required.

[0038] To optimize the impact of log recording on the performance of the application process, the mutual exclusion processing does not use the thread lock mechanism to lock the entire memory space, but is based on the multi-thread shared lock-free operation mechanism, and mutual exclusion is achieved through shared variables. This design not only ensures that the size of a single log record does not affect the log recording performance, but also effectively avoids the performance bottleneck problem brought by the traditional lock mechanism.

[0039] The storage engine 1013 is used to record the log information in the memory space of the application process. These memory spaces are allocated when the application process is created and automatically released when the application process terminates. After determining the storage identity of each thread, according to the corresponding storage identity, the log information generated by each thread and the function call chain of the log information when the function call relationship changes are stored in the specified location of the memory space. This mechanism not only ensures the integrity and orderliness of the log information, but also provides a reliable data basis for the subsequent log management engine 1014 to track and manage the log information.

[0040] According to the embodiments of the present invention, the log acquisition engine is used to acquire the log information generated when each thread in the application process processes business requests, and the lock-free operation mechanism shared by multiple threads in the identity allocation engine is used to allocate storage identities for these log information through shared variables, so that the performance loss caused by thread mutual exclusion can be eliminated without using thread locks during the log storage process. Subsequently, according to the storage identity, the storage engine is used to write the log information and its corresponding thread function call relationship into the pre-allocated memory space, realizing the effective management of the log information. This method can not only accurately record the source of the log information, but also quickly locate the problem source through the function call relationship, improving the efficiency of log management and problem troubleshooting.

[0041] According to the embodiments of the present invention, the lock-free operation mechanism shared by multiple threads in the application process is used to allocate corresponding storage identities for each log information through shared variables, including: using the lock-free operation mechanism to generate an identity sequence for each log information through shared variables; based on the total capacity of the memory space, performing a modulo operation on each identity in the identity sequence to obtain the storage identity corresponding to each log information.

[0042] Based on the lock-free operation mechanism, a unique identifier is generated for each log message by incrementing a shared variable sequentially, thereby forming an ordered identifier sequence. The specific means can be implemented by incrementing the variable. For example, starting from an initial value of 0 and incrementing for allocation, the identifier of the first log message is 1, the identifier of the second log message is 2, and so on. This linearly increasing allocation method not only ensures the uniqueness of the identifier but also provides a reliable basis for subsequent log tracking.

[0043] In the log storage phase, first determine the total number of storage rows in the memory space pre-allocated to the application process. For example, assume that the memory space can store 1000 log messages, then these 1000 rows are the total capacity of the space. Perform a modulo operation on the identifier of each log message, that is, "identifier % total space capacity". Taking the log message with an identifier of 1500 as an example, the total space capacity is 1000 rows, then the result of 1500 % 1000 is 500, and this log message will be stored in the row position with the corresponding number 500 in the memory space. In this way, log messages can be efficiently stored in the pre-allocated memory space, which not only improves the storage utilization rate but also facilitates subsequent log query and management.

[0044] According to an embodiment of the present invention, the management controller further includes an initialization engine for loading and parsing the log configuration file corresponding to the application process to determine the total capacity of the memory space pre-allocated to the application process when receiving the start instruction of the application process.

[0045] The initialization process of the log management system adopts an automated design. When the upper-layer application is in use, there is no need to perform explicit initialization operations, and only the log recording function needs to be directly called. All necessary initialization work has been encapsulated and implemented inside the log recording function. This design not only simplifies the calling process but also ensures the reliability of the system.

[0046] When the application process starts, it will automatically trigger the configuration loading process and execute the initialization engine. First, load and parse the log configuration file corresponding to the application process to complete the initialization work of the configuration parameters. It should be noted that this initialization process only needs to be executed once during the life cycle of the application process. Although all application processes share the same configuration template, each application process has its own independent log configuration file to achieve configuration isolation. The configuration parameters in the log configuration file include key operating parameters such as log level, memory space size, and exception trigger conditions.

[0047] In terms of memory management, according to the parameter settings in the log configuration file, a dedicated memory space is allocated for each application process to store logs. When allocating, the total capacity of the memory space is determined, that is, the upper limit of the number of log lines that can be stored. Among them, the size of the memory space supports flexible configuration and reasonable default values are also provided to ensure stable operation in various scenarios. From the implementation details, the memory space is essentially a two-dimensional array structure: the first dimension limits the maximum number of logs that can be stored, and the second dimension stipulates the upper limit of the capacity of a single log. This structural design not only meets the basic requirements of log storage but also facilitates subsequent log query and management.

[0048] According to an embodiment of the present invention, the management controller further includes a configuration engine for: configuring the memory space according to the total capacity to obtain a memory structure including multiple storage locations, and each storage location is marked with a corresponding storage identifier; wherein, the memory structure includes: a control identifier for starting or stopping writing log information at the storage location; a counter for implementing storage identifier allocation through a shared variable using a lock-free operation mechanism, the counter is used to count the events of log information generation, and when receiving the log information generated by a thread, the counter is triggered and reset at a preset time interval, and the count value of the counter is used to determine the storage identifier.

[0049] The memory space of the application process is managed using a structured solution. According to the total capacity defined in the log configuration file, a memory structure is constructed. This memory structure is optimized to meet the requirements of high performance and thread safety at the same time.

[0050] The memory structure includes three core functional modules: First is the control management module, which coordinates the entire process of writing log information through a dedicated control identifier. The control identifier is like a switch that can start or stop the log writing operation to the storage location at any time, ensuring that the system can be kept under control at all times. When encountering special situations, the control module can immediately pause log recording to avoid system exceptions.

[0051] Second is the counter module, which is a key part of the memory structure. It uses a lock-free operation mechanism, is implemented through a shared variable, and sets 0 as the reference value during initialization. Compared with the traditional thread lock mechanism, this design significantly reduces thread blocking and competition problems. Whenever new log information needs to be recorded, the counter can automatically increment and generate a globally unique storage identifier for each log information according to the count value. This lock-free design enables the system to maintain excellent performance in high-concurrency scenarios.

[0052] Finally, there is the storage area module, which is the actual storage location. The storage area module is organized in a two-dimensional structure. The first dimension manages the number of log entries, and the second dimension controls the capacity of a single log message. This design not only improves the storage efficiency but also facilitates subsequent log retrieval and analysis. All storage units use continuous memory allocation, further optimizing the access performance.

[0053] According to an embodiment of the present invention, when the function call chain of the log information changes along with each log information and the storage identifier, the function call chain of the log information is written to the corresponding storage location in the memory space pre-allocated to the application process, including: when it is determined that the control identifier indicates starting to write the log information to the storage location, determining the corresponding target storage location in the memory structure according to the storage identifier; writing the function call chain of the log information when the log information and the function call relationship change to the target storage location.

[0054] In terms of memory management, the system adopts a dual mechanism of a control identifier and a storage identifier to achieve efficient and controllable logging. Among them, the control identifier is used to manage the start and stop states of logging, while the storage identifier is responsible for accurately positioning the storage location of the log information in the memory structure. When the control identifier is in the enabled state, the target storage location is determined according to the storage identifier, and the log information and its associated function call relationship are written to this location.

[0055] Specifically, each log message not only includes the basic log content but also metadata such as a timestamp, log level, and log source. In addition, the function call relationship (i.e., the call stack information) when the log is generated is also recorded, and these information are crucial for subsequent debugging and problem tracking. All relevant data will be uniformly written to the calculated target storage location.

[0056] For example, when the system is initialized, the control identifier is defaulted to false (indicating stop), and the counter initial value is 0. When the application process enables the logging function (the control identifier is set to true, indicating start), when the first log message is generated, the counter increments to 1. At this time, the storage location is determined to be 1 by calculating 1 % of the total space capacity, and the log information and the function call relationship are stored in the corresponding location of the memory structure.

[0057] This mechanism not only ensures the efficiency of logging but also reduces thread contention through a lock-free operation mechanism and improves the system's concurrent processing ability by using shared variables. At the same time, the structured storage method also facilitates subsequent log retrieval and analysis.

[0058] According to an embodiment of the present invention, the management controller further includes a pre-recording engine, which is configured to: for each thread, when it is determined that the thread calls a function to process a service request, write the function name called by the thread, the flag variable corresponding to the called function, and the storage identifier of the log information generated by the thread into the thread structure in the thread-private storage space, where the thread structure is initialized as an empty structure when the thread is created; and update the thread structure in response to the continuous call of the function by the thread or the log information generated during the call process.

[0059] For each thread in the application process, the initialization of the thread-private storage space mainly initializes the keys of the thread-private data. The setting of the thread-private data is designed to track the call relationship between functions. By utilizing its property of isolation between threads, the function call chain within a single thread can be accurately obtained. This mechanism can be used as an auxiliary means for debugging logs. When a problem occurs, the function call relationship of a specific thread can be clearly printed out, enabling developers to intuitively analyze the execution flow of a single thread.

[0060] The key of the thread-private data is only initialized once in each thread. When it is detected that the key has not been initialized, the initialization operation will be automatically executed to construct the thread structure. In the thread structure constructed here, both the precursor pointer and the successor pointer point to the thread structure itself, thus forming an initialized linked list node. The thread structure mainly stores three types of key information: the function name, the storage list for storing the log information storage identifier, and the flag variable and its corresponding memory address. These information together constitute the basis for tracking the function call relationship. To effectively record the function call relationship, the system uses a doubly linked list structure to store the call information.

[0061] The thread structure constructed when the thread is created is initially empty. As the function calls are executed, the function call chain is dynamically filled into this thread structure. In each function call, a new node is added to the linked list to record the function name of the current function, the storage identifier of the log information, and the memory address of the flag variable. At the same time, the precursor and successor pointers are updated to ensure the coherence of the linked list. This dynamic update mechanism not only completely preserves the call relationship between functions but also supports forward tracking of the call order and backward tracing of the call source, providing complete and reliable call chain information for problem troubleshooting and greatly improving the debugging efficiency and accuracy.

[0062] According to an embodiment of the present invention, the management controller further includes a change determination engine, which is configured to perform the following operations in response to each function call during the thread running process: generate a flag variable corresponding to each function through a predefined macro instruction; record the memory address of the flag variable corresponding to the function call; and determine the change situation of the function call relationship by comparing the offset value between the memory addresses during two adjacent function calls.

[0063] The flag variable is a key design for implementing function call relationship tracking. When the upper-layer application calls the log recording interface, it must pass an integer local variable as the flag variable, which serves as the unique identifier for the function call and is used to construct a complete call relationship chain.

[0064] A predefined macro instruction scheme is adopted to ensure that the flag variable can be correctly defined and captured at the beginning of function execution. These macro instructions will automatically insert the necessary variable definition and initialization code during the compilation stage, which not only simplifies the use by developers but also ensures the reliability of the system. During actual operation, whenever a function is called, the macro instruction at the function entry will automatically create an instance of the flag variable and immediately register its memory address in the log system.

[0065] This automated processing mechanism is completely transparent to developers. It can not only accurately record the call of each function but also maintain the function call relationship in the thread-private storage space in real time. In this way, the context environment of the function call is completely preserved, and a clear function call relationship topology diagram is constructed. To accurately track the function call relationship of threads, a comparison method based on the memory address offset value is adopted.

[0066] During each function call, the predefined macro instruction will record the memory address of the current function's flag variable and store it in the thread structure in the thread-private storage space. When a new function is called, the system will record the memory address of the new flag variable again and calculate the offset value between the new address and the previously recorded address through a simple subtraction operation of addresses. This offset value can not only reflect the order of function calls but also accurately reflect the hierarchical relationship of the calls.

[0067] Specifically, when the offset value is positive, it indicates that the current function is a sub-function of the previous function, that is, the current function is called by the previous function; when the offset value is negative, it indicates that the current function is the parent function of the previous function, that is, the previous function returns from the current function. This comparison method based on address offset is simple to implement and efficient in operation, and can accurately reflect the hierarchical structure of function calls, providing reliable technical support for system log recording and debugging analysis.

[0068] According to an embodiment of the present invention, the management controller further includes a call chain generation engine, which is used to perform the following operations when a thread executes a function call: establish a mapping relationship between the called function name and the corresponding memory address; determine the call order of the thread to multiple functions according to the physical distribution law of multiple memory addresses; based on the mapping relationship, associate the call order with the function name to generate a function call chain of the thread, wherein the function call chain is stored in the thread structure in the form of a doubly linked list.

[0069] When a thread executes a function call, it is necessary to establish a mapping relationship between the name of the called function and the corresponding memory address. Specifically, this work can be accomplished by means of data structures such as hash tables or dictionaries. Use the function name as the key of the hash table and the actual memory address of the function as the value. Establishing such a mapping relationship can lay the foundation for subsequent analysis of the function call order. Through this mapping relationship, the corresponding memory address can be quickly found based on the function name.

[0070] Determine the call order of multiple functions by the thread according to the physical distribution law of multiple memory addresses. In memory, function calls usually follow a certain physical distribution law. For example, when one function calls another function, a specific call stack structure will be formed in the stack space of memory. By analyzing the changes in the stack pointer and the sequence of memory addresses, the call order of the functions can be inferred. Sort out the call order of the functions according to the changes in the memory addresses. For example, the change in memory addresses from the bottom to the top of the stack reflects the nested order of function calls.

[0071] Based on the established mapping relationship, associate the sorted call order with the function names to generate the function call chain of the thread. For the convenience of managing and operating these function call relationships, the function call chain in the thread structure is stored in the form of a doubly linked list. Each node of the doubly linked list represents a function call, including the function name and the corresponding memory address. With the help of the forward and backward pointers of the doubly linked list, it is convenient to traverse, insert, and delete operations in the linked list. When debugging a program, the call order of the functions and the nested relationship between the functions can be quickly viewed through the doubly linked list. The storage method of the doubly linked list makes the management of function call relationships more flexible and efficient, facilitating the monitoring and adjustment of the running state of the thread.

[0072] Figure 3 Shows the update flowchart of the thread structure in the log management method according to an embodiment of the present invention.

[0073] As Figure 3 shown, the update of the thread structure in the pre-recording engine includes operation S301 to operation S306.

[0074] In operation S301, determine whether the function call chain recorded in the thread structure is empty. If not, execute operation S302; if so, execute operation S305.

[0075] In operation S302, determine whether the flag variable of the function currently called by the thread is consistent with the function call chain recorded in the thread structure. If not, execute operation S303; if so, execute operation S306.

[0076] In operation S303, determine whether the penultimate flag variable in the function call chain recorded in the thread structure is consistent with the flag variable of the current calling function. If not, perform operation S305; if so, perform operation S304.

[0077] In operation S304, perform a modification operation to delete the call relationship on the function call chain in the thread structure.

[0078] In operation S305, perform a modification operation to add a call relationship on the function call chain in the thread structure.

[0079] In operation S306, update the storage identifier of the log information generated by the thread to the thread structure.

[0080] According to an embodiment of the present invention, when the flag variable of the current calling function of the thread is consistent with the information recorded in the thread structure, the storage identifier of the newly generated log information will be directly updated to the thread structure to maintain the continuity of the call information. This process only makes an incremental update of the log information and maintains the stability of the existing function call relationship.

[0081] If it is detected that the flag variable of the current calling function of the thread is offset from the content recorded in the thread structure, the system will start the function call relationship correction process. By analyzing the address offset, the call direction of the function can be determined. If, in the function call chain recorded in the thread structure, the penultimate flag variable is consistent with the flag variable of the current calling function, a modification operation to delete the call relationship will be performed to remove the corresponding end node of the call chain. If they are inconsistent, a modification operation to add a call relationship will be performed to add a call relationship node in the thread structure. This dynamic adjustment of the function call relationship based on the memory address offset can accurately reflect the actual execution path of the function call.

[0082] After the function call relationship correction is completed, the storage identifier of the newly generated log information is synchronously updated to the adjusted thread structure. The entire process maintains the accuracy of the function call relationship and ensures the strict correspondence between the log information and the function call chain. Finally, according to the function name sequence recorded in the thread structure and the associated storage identifier, a normalized call chain log is generated to provide complete and reliable data support for subsequent debugging and analysis.

[0083] Figure 4 Shows a flowchart for determining the cause of an exception in a log management system according to an embodiment of the present invention.

[0084] As Figure 4As shown in the figure, when the exception determination engine detects an exception signal generated during the operation of the application process, it performs operations S401 to S403. The management controller further includes an exception traversal engine, which is used to perform operations S404 to S406 when it is determined that the signal type determined by the exception determination engine is the target type.

[0085] In operation S401, determine the signal type of the exception signal.

[0086] In operation S402, determine whether the signal type is the target type. If not, perform operation S403; if so, perform operation S404.

[0087] In operation S403, determine the exception cause corresponding to the signal type through the preset mapping relationship between the signal type and the exception cause.

[0088] In operation S404, export the log information of the storage location in the memory space and the corresponding function call chain.

[0089] In operation S405, construct a call relationship tree based on the function call chain, and the corresponding log information is stored on the tree nodes in the call relationship tree.

[0090] In operation S406, locate the exception node whose log information includes exception characteristics by traversing the call relationship tree to determine the exception cause.

[0091] According to the embodiments of the present invention, in the running environment, different operations or error conditions will trigger different types of exception signals. For example, when the user clicks the keyboard interrupt key, an interrupt signal will be generated; and when a specific instruction is sent to the application process manually or in certain operations, a termination signal, a forced termination signal, etc. may be generated. Detecting and identifying these received exception signals and determining which specific signal type they belong to is the basis for subsequent processing.

[0092] When an exception signal is generated during the operation of the application process, determine the signal type of the exception signal. After determining the signal type, use the preset mapping relationship between the signal type and the exception cause to determine the exception cause corresponding to the current signal type. This mapping relationship is established based on long-term programming experience and understanding of the characteristics of various signals. For example, if the detected exception signal type is a floating-point exception signal, according to the preset mapping relationship, it can be known that the corresponding exception cause is probably a floating-point data operation error, and there may be a situation where the divisor is 0; if a bus error signal is detected, it means that there may not only be a floating-point data operation error (the divisor also needs to be checked for 0), but also a memory alignment problem may be involved. If there is a forced revalue of floating-point data, corresponding processing also needs to be carried out. Through the matching of this mapping relationship, the root cause of the exception can be quickly located.

[0093] From the perspective of development and debugging, the exception cause determined based on the signal type can help developers quickly locate the problematic code. For example, when it is determined that the exception is caused by a floating-point exception signal, the code segments involving floating-point operations can be directly checked to see if there are errors such as a divisor of zero, which greatly improves the debugging efficiency and reduces the time and effort spent on troubleshooting. In terms of program stability, timely and accurately locating the exception cause and handling it can effectively prevent the application process from crashing due to the exception signal, ensure the continuous and stable operation of the program, and enhance the user experience. At the same time, by continuously processing and analyzing the exception signals, the preset mapping relationship can be further improved to make it more accurate and comprehensive, providing a more reliable basis for handling similar problems in the future.

[0094] When the application process detects an exception signal of the target type (such as a segmentation fault signal) during operation, it will immediately export the log information and function call chain data stored in the memory space. During operation, the memory space records the log information of various operations and the call associations between functions. At this time, these information are extracted from the memory space to provide a data basis for subsequent analysis. These log information include detailed operation timestamps, key data contents involved, and the complete function call order and hierarchical relationship, providing a reliable data basis for subsequent exception analysis.

[0095] Based on the exported function call chain, a hierarchical call relationship tree structure is constructed. This tree structure presents the call logic between functions in an intuitive way. Each tree node corresponds to a specific function call instance and is associated with the corresponding operation log. Through this structured display, the originally complex execution path becomes clear and distinguishable, just like obtaining a complete roadmap of the program operation process, and can accurately trace the call context of each function.

[0096] By deeply traversing the call relationship tree, the nodes containing exception characteristics can be accurately identified. During the traversal process, the log data associated with each node will be carefully checked. When characteristics such as data anomalies and pointer errors are found, the node can be determined as the exception source. This method can not only locate the specific location where the exception occurs but also restore the complete execution context when the exception is triggered, providing a comprehensive basis for problem fixing.

[0097] According to an embodiment of the present invention, locating the exception node whose log information includes exception characteristics includes: performing feature matching on the log information of each tree node in the call relationship tree based on a preset exception discrimination rule set to obtain a matching result, where the exception discrimination rule set includes an error code regular expression template and an exception stack feature fingerprint; analyzing the memory data change trend between adjacent tree nodes in the call relationship tree to obtain an analysis result; and determining the exception node by synthesizing the matching result and the analysis result.

[0098] When troubleshooting exceptions, feature matching is performed on the log information of each tree node in the call relationship tree based on the preset exception identification rule set. The exception identification rule set contains error code regular expression templates and exception stack feature fingerprints. The error code regular expression template is used to measure whether the error code in the log conforms to a specific error pattern. For example, when processing file read and write errors, regular expressions are used to match the error code in the log to see if it conforms to the coding characteristics of error types such as insufficient file permissions and non-existent files. The exception stack feature fingerprint is a unique identifier of the call stack state when the exception occurs. When an exception occurs in the program, the call stack will exhibit a specific structure and element combination, and the exception stack feature fingerprint identifies the exception based on these characteristics. By matching the log information of the tree node with these two rules, it is possible to preliminarily determine whether the node has an abnormal tendency.

[0099] Analyze memory data change trends between adjacent nodes in the call tree. Memory data constantly changes during function calls, and data changes between adjacent nodes can reflect the program's execution status. For example, during memory allocation and deallocation, if a node allocates memory but a subsequent node experiences memory loss or illegal access, the memory data change trend can reveal an anomaly. By analyzing changes in data size, content, and address, we can determine whether memory operations are normal.

[0100] The above matching and analysis results are combined to identify abnormal nodes. If a node matches the error code regular expression template or the exception stack signature during feature matching, and the memory data change trend between adjacent nodes also shows an anomaly, then this node is considered an abnormal node. This comprehensive judgment method avoids the limitations of a single judgment method and improves the accuracy of abnormal node identification.

[0101] If the cause of an anomaly cannot be accurately determined based on the anomaly identification rule set, it is necessary to fully record the key information at the time of the anomaly trigger, including signal type, function call relationships, etc. These records provide the original basis for subsequent manual analysis. By summarizing new analysis experience and continuously supplementing it in the anomaly handling module, the rule base can be dynamically optimized and continuously improved.

[0102] For various special anomaly scenarios, we first handle them according to the proprietary detection rules of each functional module. If the proprietary rules are still unable to effectively resolve the anomaly, we automatically switch to manual analysis. Through human-machine collaboration, we ensure comprehensive coverage and in-depth resolution of anomaly issues, and continuously improve the adaptability and reliability of the anomaly detection system.

[0103] According to an embodiment of the present invention, the management controller further includes a persistence engine for: parsing the log configuration file of the application process to obtain a predefined persistent storage path and file name format; based on the persistent storage path and file name format, writing the log information associated with the abnormal node and the memory data generated during the execution of the abnormal node into the persistent storage medium.

[0104] The abnormal detection work of the application process is responsible for a dedicated abnormal detection module, which includes two core parts: built-in abnormal detection and customized abnormal detection. The built-in abnormal detection adopts a distributed processing architecture to monitor common scenarios such as application process signal interruption, bus hang, and module function abnormality in real time. When an abnormal determination condition is detected, the persistent operation of the memory log will be immediately executed to ensure the integrity of key data.

[0105] The customized abnormal detection realizes the ability expansion through specific scripts imported by users. The scripts are parsed and executed by a unified process. Once an abnormal situation that meets the preset rules is detected, the log persistence process is triggered. This mode relies on a centralized management mechanism to ensure the configuration consistency and execution controllability of all customized detection tasks.

[0106] In practical applications, when an abnormality is triggered, the abnormal detection module starts the collection process of multi-dimensional memory data. The collection scope covers the memory logs and function call relationships of the local and dependent processes, the memory state snapshots of the application process, the system resource occupancy indicators (number of file descriptors, memory usage, processor utilization, etc.), the bus operation state parameters, and the interruption frequency and register data of the baseboard management controller. By cross-analyzing these data, the cause of the abnormality is initially inferred, and the analysis conclusion is temporarily stored in the memory space.

[0107] On this basis, the exception handling enters the persistence stage. The persistence of abnormal data is implemented based on a hierarchical persistent storage medium, which is divided into a persistent peripheral module and a persistent core module. The peripheral module, as an external interaction interface, supports being triggered by signals or methods registered through the desktop bus communication protocol, and at the same time is compatible with the native inter-process communication methods of the operating system, including various communication mechanisms such as pipes, sockets, and shared memory file systems, ensuring flexible and efficient docking with the abnormal detection module and other system components.

[0108] After receiving the persistence instruction passed by the peripheral module, the core module parses the log configuration file of the application process to obtain the predefined storage path and file name format. Subsequently, the log information associated with the abnormal node in the memory (including function call relationships and error code details) and the memory data generated during execution (variable values, pointer states, memory allocation records) are formatted and serialized and then written to the target log file. This process ensures data integrity through transactional file input / output operations and synchronously updates the index metadata, recording the file path, size, and the time of the exception occurrence to provide a complete data chain for subsequent traceability and in-depth analysis.

[0109] Figure 5 The flowchart of persistent storage in the log management system according to an embodiment of the present invention is shown.

[0110] As Figure 5 shown, the persistence engine is also used to execute operations S501 to S506.

[0111] In operation S501, it is judged whether the log information meets the abnormal trigger condition defined in the log configuration file. If so, operation S502 is executed; if not, operation S504 is executed.

[0112] In operation S502, by performing backtracking analysis on the function call chain corresponding to the log information, multiple memory addresses at the time of function call are determined.

[0113] In operation S503, based on the multiple memory addresses, the memory data generated at the time of function call is obtained.

[0114] In operation S504, it is judged whether a data record request triggered by an object is received. If so, operation S505 is executed; if not, the process ends.

[0115] In operation S505, the record start address and data record length in the data record request are parsed to extract the corresponding memory data according to the record start address and data record length.

[0116] In operation group S506, the memory data and the serialized log information are written to the persistent storage medium.

[0117] According to an embodiment of the present invention, when it is detected that the log information meets the abnormal trigger condition specified in the log configuration file, it is necessary to perform backtracking analysis on the function call chain corresponding to the log information. During the program execution, function calls will form a clear call chain, and each function call will leave corresponding traces in the memory. By backtracking this call chain, multiple memory addresses involved in the function call can be gradually determined.

[0118] Specifically, the backtrace analysis can start from the function where the current exception is triggered and trace upward along the call stack to find the relevant information of each caller. Each function call allocates a certain amount of space on the stack to store local variables, parameters, return addresses, etc. By parsing the structure of the stack frame, the memory addresses at the time of these function calls can be accurately obtained. For example, when a function is called, the stack pointer points to the start position of the function's stack frame. By analyzing the stack pointer and related offsets, the memory addresses of each local variable and parameter inside the function can be determined.

[0119] Based on the multiple memory addresses obtained from the backtrace analysis, obtain the memory data generated during the function call. These memory data contain key information during the function execution, such as the values of local variables, parameter passing situations, etc. By reading the data in these memory addresses and organizing it into a format suitable for analysis.

[0120] After obtaining the memory data, perform a structured conversion on the memory data according to the preset serialization rules, and map the memory data to log information that can be persistently stored. Write the converted log data and the original log information together into a persistent storage medium. By analyzing these data, the context of the function call can be deeply understood, and the problem can be quickly located. Especially for exception logs of a severe level, these complete call chains and memory state data provide key basis for diagnosing complex problems, significantly improving the efficiency of problem troubleshooting and repair.

[0121] When it is detected that an object issues a data recording request, first parse the key parameters in the data recording request to determine the recording start address and the data recording length. The recording start address points to the first byte position of the data to be collected in memory, and the data recording length clearly defines the collection range. These two parameters together constitute the basic basis for log information extraction. For example, if the recording start address is 0x1000 and the data recording length is 128 bytes, it means that 128 bytes of data need to be continuously extracted starting from the memory position 0x1000 as the log information source.

[0122] According to the obtained recording start address and data recording length, extract the corresponding memory data. Through the memory addressing mechanism, locate to the recording start address and read the data byte by byte according to the specified length. The extracted memory data will be subjected to a structured conversion according to the preset serialization rules, mapping the original memory data to log information that can be persistently stored. The memory data after serialization processing is finally written into a persistent storage device, realizing the diverse requirements for memory data recording.

[0123] According to an embodiment of the present invention, the management controller further includes a restart engine, which is used to: when it is detected that an application process is restarted due to an exception, reconfigure the memory space based on the log configuration file of the application process to obtain the configured memory space for writing the log information generated by each thread.

[0124] When it is detected that an application process is restarted due to an exception, the memory space needs to be reconfigured according to the log configuration file. The specific configuration is shown in Table 1. This reconfiguration process reuses the initialization logic when the process starts to ensure the integrity and coherence of the log recording system.

[0125] Table 1

[0126]

[0127] As shown in Table 1, after the application process restarts, it first performs configuration parameter initialization, reloading the core parameters (such as log level, memory space size, and exception trigger conditions) in the log configuration file into the specified area of the memory. This operation is only performed once when the process starts, providing basic parameter support for subsequent operations. At this time, the memory space initialization is carried out synchronously, reconstructing the storage identification system and the log structure according to the configuration parameters. This step is also only performed once when the application process starts, aiming to build a log data storage architecture, form a fast retrieval index, and ensure the orderliness and efficient access of log records.

[0128] When each thread in the application process starts, it triggers the initialization of the thread-private storage space. In this stage, a dedicated memory area is allocated for each thread to store the unique function call relationships of the thread. This operation is generated one by one according to the number of threads to ensure the independence and integrity of log records in a multi-threaded environment and avoid data interference between threads.

[0129] The memory space reconfigured through the above steps not only inherits the core rules of the original log configuration file but also eliminates the influence of abnormal residues, and can efficiently carry the log information generated after each thread restarts, providing a complete and pure data record for subsequent exception review and operation analysis.

[0130] Figure 6 Shows a module interaction diagram of a log management system according to another embodiment of the present invention.

[0131] As Figure 6 shown, when performing the log management of the application process, according to the modular design idea, the overall function is divided into multiple modules and engines to work together.

[0132] First, it is started by the initialization module 610. The initialization module 610 is responsible for completing resource application and initialization operations, including basic preparation work such as configuration loading and memory space allocation, laying the foundation for the subsequent log management process.

[0133] If the application process runs normally after initialization, it will enter the pre-recording module 620. The pre-recording module 620 is responsible for processing the storage identifier application of log information, handling function call relationships, and preprocessing the recorded memory data, while continuously monitoring the running status of the application process.

[0134] After the pre-recording stage is completed, the log information is obtained through the target acquisition engine, and the storage identifier is allocated to the log by the identifier allocation engine, and then it enters the log recording module 640. During the normal operation of the application process, the log recording module 640 writes the preprocessed log information into the memory space through the storage engine, realizing the efficient recording of multi-threaded logs.

[0135] When a segment fault, power failure, or other functional abnormalities are detected, the exception detection module 650 will be triggered. Based on the log information and function call relationships in the memory, combined with built-in rules and user-defined conditions, it determines whether a persistence operation needs to be performed. If the conditions are met, a preliminary exception analysis report will be generated, and the report and the log information will be passed to the subsequent processing link together.

[0136] The core hub of log management is implemented by the target management engine 1014, which interacts with the persistence module 630, the exception detection module 650, and the log recording module 640 in coordination to overall manage the entire log life cycle. Whether it is triggered by an exception, the abnormal restart of the application process, or manual intervention, ultimately, the log information in the memory will be written into the persistent storage medium through the persistence module 630 to ensure the complete retention of the log information, providing reliable support for fault analysis and system optimization. The entire process combines modular design and engine processing to achieve efficient and stable log management functions.

[0137] Based on the above log management method, the present invention also provides a log management method. The following will be combined with Figure 7 Describe this method in detail.

[0138] Figure 7 Shows a flowchart of the log management method according to an embodiment of the present invention.

[0139] As Figure 7 Shown, the log management method of this embodiment includes operations S710 to S730.

[0140] In operation S710, obtain the log information generated by each thread of the application process in the management controller during the process of processing business requests.,

[0141] In operation S720, use the lock-free operation mechanism shared by multiple threads in the application process to allocate corresponding storage identifiers to each log information through shared variables.

[0142] In operation S730, according to the storage identifier, each piece of log information and the function call chain of the log information when the function call relationship changes are written into the corresponding storage location in the memory space pre-allocated to the application process, and the log information is managed through the function call chain.

[0143] It should be noted that the log management method part in the embodiments of the present invention corresponds to the log management system part in the embodiments of the present invention. For the description of the log management method part, specifically refer to the log management system part, and details will not be repeated here.

[0144] Figure 8 The block diagram of an electronic device suitable for implementing the log management method according to an embodiment of the present invention is shown.

[0145] As Figure 8 shown, the electronic device 800 according to an embodiment of the present invention includes a processor 801, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 802 or the program loaded from the storage section 808 into the random access memory (RAM) 803. The processor 801 may include, for example, a general microprocessor (such as a CPU), an instruction set processor, and / or a related chipset, and / or a dedicated microprocessor (such as an application specific integrated circuit (ASIC)), etc. The processor 801 may also include on-board memory for caching purposes. The processor 801 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present invention.

[0146] In the RAM 803, various programs and data required for the operation of the electronic device 800 are stored. The processor 801, the ROM 802, and the RAM 803 are connected to each other through a bus 804. The processor 801 performs various operations of the method flow according to an embodiment of the present invention by executing the programs in the ROM 802 and / or the RAM 803. It should be noted that the program may also be stored in one or more memories other than the ROM 802 and the RAM 803. The processor 801 may also perform various operations of the method flow according to an embodiment of the present invention by executing the programs stored in one or more memories.

[0147] According to an embodiment of the present invention, the electronic device 800 may further include an input / output (I / O) interface 805, and the input / output (I / O) interface 805 is also connected to the bus 804. The electronic device 800 may further include one or more of the following components connected to the input / output (I / O) interface 805: an input portion 806 including a keyboard, a mouse, etc.; an output portion 807 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc. and a speaker, etc.; a storage portion 808 including a hard disk, etc.; and a communication portion 809 including a network interface card such as a LAN card, a modem, etc. The communication portion 809 performs communication processing via a network such as the Internet. The drive 810 is also connected to the input / output (I / O) interface 805 as needed. A removable medium 811, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 810 as needed so that a computer program read from it is installed into the storage portion 808 as needed.

[0148] The present invention also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or may exist separately without being assembled into the device / apparatus / system. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed, the method according to the embodiments of the present invention is implemented.

[0149] According to an embodiment of the present invention, the computer-readable storage medium may be a non-volatile computer-readable storage medium, for example, it may include but is not limited to: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, the computer-readable storage medium may be any tangible medium that contains or stores a program, and the program may be used by or in combination with an instruction execution system, device, or device. For example, according to an embodiment of the present invention, the computer-readable storage medium may include the ROM 802 and / or the RAM 803 described above and / or one or more memories other than the ROM 802 and the RAM 803.

[0150] An embodiment of the present invention also includes a computer program product, which includes a computer program, and the computer program includes program codes for executing the method shown in the flowchart. When the computer program product runs in a computer system, the program codes are used to cause the computer system to implement the log management method provided by the embodiments of the present invention.

[0151] When the computer program is executed by the processor 801, the above functions defined in the system / apparatus of the embodiments of the present invention are executed. According to an embodiment of the present invention, the above-described systems, apparatuses, modules, units, etc. can be implemented by computer program modules.

[0152] In one embodiment, the computer program can rely on tangible storage media such as optical storage devices, magnetic storage devices, etc. In another embodiment, the computer program can also be transmitted and distributed in the form of signals on a network medium, and be downloaded and installed through the communication part 809, and / or be installed from the removable medium 811. The program code included in the computer program can be transmitted by any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0153] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 809, and / or be installed from the removable medium 811. When the computer program is executed by the processor 801, the above functions defined in the system of the embodiments of the present invention are executed. According to an embodiment of the present invention, the above-described systems, devices, apparatuses, modules, units, etc. can be implemented by computer program modules.

[0154] According to an embodiment of the present invention, the program code for executing the computer program provided by the embodiments of the present invention can be written in any combination of one or more programming languages. Specifically, these computing programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages include but are not limited to, such as Java, C++, python, the "C" language or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, by using an Internet service provider to connect through the Internet).

[0155] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, a segment of a program, or a portion of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions noted in the blocks may occur in a different order than that noted in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, or they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, as well as combinations of blocks in the block diagram or flowchart, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or by a combination of dedicated hardware and computer instructions.

[0156] Those skilled in the art will appreciate that the features described in the various embodiments of the present invention can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in the present invention. In particular, without departing from the spirit and teachings of the present invention, the features described in the various embodiments of the present invention can be combined and / or combined in various ways. All such combinations and / or combinations fall within the scope of the present invention.

[0157] The embodiments of the present invention have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of the present invention. Although the embodiments have been described separately above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Without departing from the scope of the present invention, those skilled in the art can make various substitutions and modifications, and all such substitutions and modifications should fall within the scope of the present invention.

Claims

1. A log management system, characterized in that, The system includes a management controller of a server, and the management controller is used to perform the following operations: Run a log acquisition engine, where the log acquisition engine is used to acquire log information generated by each thread of an application process in the management controller during the process of processing service requests; Transmit the log information to an identification allocation engine, where the identification allocation engine uses a lock-free operation mechanism shared by multiple threads in the application process and assigns corresponding storage identifiers to each piece of the log information through a shared variable; Input the log information with the storage identifier into a storage engine, and the storage engine writes each piece of the log information and the function call chain of the log information when the function call relationship changes into a corresponding storage location in a memory space pre-allocated to the application process according to the storage identifier; Manage the log information based on the function call chain in the storage engine through a log management engine; The management controller further includes an initialization engine, which is used to load and parse a log configuration file corresponding to the application process when receiving a startup instruction of the application process, so as to determine the total capacity of the memory space pre-allocated to the application process; The management controller further includes a configuration engine, which is used to configure the memory space according to the total capacity to obtain a memory structure including a plurality of the storage locations, and each of the storage locations is marked with a corresponding storage identifier; wherein, the memory structure includes: a control identifier for starting or stopping writing the log information at the storage location; a counter for implementing storage identifier allocation through the shared variable by using the lock-free operation mechanism, and the count value of the counter is used to determine the storage identifier.

2. The system according to claim 1, characterized in that, The step of using the lock-free operation mechanism shared by multiple threads in the application process and assigning corresponding storage identifiers to each piece of the log information through a shared variable includes: Generating an identifier sequence for each piece of the log information through the shared variable by using the lock-free operation mechanism; Performing a modulo operation on each identifier in the identifier sequence based on the total capacity in the memory space to obtain a storage identifier corresponding to each piece of the log information.

3. The system according to claim 1, characterized in that, The counter is used to count log information generation events. When receiving the log information generated by the thread, the counter is triggered and reset at a preset time interval.

4. The system according to claim 1, characterized in that, The step of writing each piece of the log information and the function call chain of the log information when the function call relationship changes into a corresponding storage location in the memory space pre-allocated to the application process according to the storage identifier includes: When it is determined that the control identifier indicates starting to write the log information at the storage location, determining a corresponding target storage location in the memory structure according to the storage identifier; Writing the log information and the function call chain of the log information when the function call relationship changes into the target storage location.

5. The system according to claim 1, wherein The management controller further includes a pre-recording engine, which is used to: For each of the threads, when it is determined that the thread calls a function to process the service request, write the name of the function called by the thread, the flag variable corresponding to the called function, and the storage identifier of the log information generated by the thread into the thread structure in the thread-private storage space, where the thread structure is initialized to an empty structure when the thread is created; In response to the continuous call of the function by the thread or the log information generated during the call process, update the thread structure.

6. The system according to claim 5, wherein The management controller further includes a change determination engine for performing the following operations in response to each function call during the running of the thread: Generate flag variables corresponding to each of the functions through predefined macro instructions; and record the memory addresses of the flag variables corresponding to the function calls. Determine the change situation of the function call relationship by comparing the offset values between the memory addresses during two adjacent function calls.

7. The system according to claim 6, wherein The management controller further includes a call chain generation engine for performing the following operations when the thread executes a function call: Establish a mapping relationship between the name of the called function and the corresponding memory address. Determine the call order of the thread for multiple functions according to the physical distribution law of multiple memory addresses. Based on the mapping relationship, associate the call order with the function name to generate the function call chain of the thread, where the function call chain is stored in the form of a doubly linked list in the thread structure.

8. The system according to claim 6, wherein The updating of the thread structure in response to the continuous call of the function by the thread or the log information generated during the call process includes: When it is determined that the flag variable of the function currently called by the thread is consistent with the record in the thread structure, update the storage identifier of the log information generated by the thread to the thread structure. When it is determined that there is an offset between the flag variable of the function currently called by the thread and the record in the thread structure, based on the flag variable of the function currently called by the thread, perform a modification operation on the function call chain in the thread structure, where the modification operation includes adding a call relationship or deleting a call relationship; update the storage identifier of the log information generated by the thread to the thread structure after performing the modification operation.

9. The system according to claim 1, wherein The management controller further includes an exception determination engine for performing the following operations when detecting an exception signal generated during the running of the application process: Determine the signal type of the exception signal. Determine the exception cause corresponding to the signal type through the preset mapping relationship between the signal type and the exception cause.

10. The system according to claim 9, wherein The management controller further includes an exception traversal engine for performing the following operations when it is determined that the signal type determined by the exception determination engine is the target type: Export the log information of the storage location in the memory space and the corresponding function call chain. Construct a call relationship tree based on the function call chain, and the log information corresponding to the tree nodes in the call relationship tree is stored. Locate the exception node whose log information includes exception characteristics by traversing the call relationship tree.

11. The system according to claim 10, wherein Locating the abnormal nodes whose log information includes abnormal features, including: Based on a preset abnormal discrimination rule set, performing feature matching on the log information of each tree node in the call relationship tree to obtain a matching result, where the abnormal discrimination rule set includes an error code regular expression template and an abnormal stack feature fingerprint; Analyzing the memory data change trend between adjacent tree nodes in the call relationship tree to obtain an analysis result; Based on the comprehensive matching result and the analysis result, determining the abnormal nodes.

12. The system according to claim 10, wherein The management controller further includes a persistence engine for: Parsing the log configuration file of the application process to obtain a predefined persistence storage path and file name format; Based on the persistence storage path and the file name format, writing the log information associated with the abnormal nodes and the memory data generated during the execution of the abnormal nodes into a persistent storage medium.

13. The system according to claim 12, wherein The persistence engine is further used for: In response to a data recording request triggered by an object, parsing the recording start address and the data recording length in the data recording request; According to the recording start address and the data recording length, obtaining the corresponding memory data to write the memory data into the persistent storage medium.

14. The system according to claim 12, wherein, The persistence engine is further used for: When it is detected that the log information meets the abnormal trigger conditions defined in the log configuration file, by performing backtracking analysis on the function call chain corresponding to the log information, determining multiple memory addresses during function call; Based on the multiple memory addresses, obtaining the memory data generated during function call to write the memory data and the log information into the persistent storage medium.

15. The system according to claim 1, characterized in that, The management controller further includes a restart engine for: When it is detected that the application process in the management controller is restarted due to an abnormality, based on the log configuration file of the application process, reconfiguring the memory space to obtain a configured memory space to write the log information generated by each thread.

16. A log management method, applied to a management controller, characterized in that, The method includes: Obtaining the log information generated by each thread of the application process in the management controller during the process of processing business requests; Using a lock-free operation mechanism shared by multiple threads in the application process, and through shared variables, allocating corresponding storage identifiers for each log information; According to the storage identifier, writing each log information and the function call chain of the log information when the function call relationship changes to the corresponding storage location in the memory space pre-allocated to the application process; managing the log information through the function call chain; Wherein, the storage location is pre-allocated through the following operations: Upon receiving the startup instruction of the application process, load and parse the log configuration file corresponding to the application process to determine the total capacity of the memory space pre-allocated to the application process; configure the memory space according to the total capacity to obtain a memory structure including a plurality of the storage locations, and each of the storage locations is marked with a corresponding storage identifier; wherein, the memory structure includes: a control identifier for starting or stopping writing the log information at the storage location; a counter for implementing storage identifier allocation through the shared variable by using the lock-free operation mechanism, and the count value of the counter is used to determine the storage identifier.

17. An electronic device, comprising: one or more processors; a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method according to claim 16.

18. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, The computer program or instruction, when executed by the processor, implements the steps of the method according to claim 16.

19. A computer program product, characterized in that, Comprising a computer program, which, when executed by the processor, implements the method according to claim 16.

Images