A lightweight log generation method, system and electronic device

Abstract

The application provides a lightweight log generation method, system and electronic equipment, and relates to the technical field of computer software.The method comprises the following steps: creating a running log management task and an operation log management task with lower priority than an application task, and establishing a message queue; when a log event is generated by the application task, a formatted log message containing a timestamp, a log level, a module identifier and content is generated and sent to the message queue; the log management task asynchronously acquires the log message, and distributes the log message to a running log folder or an operation log folder according to the log level and type; and the size of the log file is monitored, and when the capacity threshold is reached, a cover writing mechanism is enabled to recycle the file storage area.The application realizes asynchronous decoupling of log recording and the application task, supports hierarchical classified storage and cyclic coverage, significantly improves the maintainability and debugging efficiency of the embedded system while ensuring real-time performance, and meets the lightweight log demand in a resource-limited environment.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and more specifically, to a lightweight log generation method, system, and electronic device for embedded systems. Background Technology

[0002] Log systems are an important component of software systems, used to record operations on specified objects and their results. They are of great practical significance for statistics, monitoring, and tracking user requests. In embedded systems, logs record the operating status of devices, user operations on devices, and brief information about data flowing through devices. Based on these logs, network operation can be monitored, abnormal events can be detected, device operating patterns can be summarized, and optimization designs can be made. They play a significant role in system status recording, debugging, and fault location.

[0003] As the computing power of embedded system chips continues to increase and the functions they undertake become increasingly complex, the demand for logging systems is also rising. However, the current technological situation presents the following problems: First, while existing open-source logging modules are powerful, they consume significant system resources and incur substantial overhead, making them difficult to apply directly to resource-constrained embedded environments. Embedded systems, due to limited resource configurations and significant differences in operating systems, lack a unified logging module, making it difficult to standardize log output and recording, resulting in incomplete functionality.

[0004] Secondly, in traditional embedded system development, log processing is often coupled with application tasks, with the application tasks directly responsible for outputting and recording logs. This approach not only affects the real-time performance of application tasks but may also lead to log loss or corruption.

[0005] Furthermore, embedded systems generate diverse log information, including runtime logs and operation logs. Existing technologies often treat these indiscriminately, making it difficult to quickly locate critical information during troubleshooting. At the same time, important error messages are easily obscured by the massive amounts of ordinary runtime information, failing to attract the attention of maintenance personnel and increasing the risk of system loss of control.

[0006] Furthermore, embedded systems have extremely limited storage resources. Traditional log systems typically use a simple append-only writing method. When the log volume exceeds the storage capacity, recording must either stop or be manually cleaned up, lacking an effective storage space recycling mechanism.

[0007] Finally, during the debugging phase, developers need to flexibly control the log output of different levels and modules. Existing technologies either output all logs, leading to information overload, or completely shut them down, causing debugging difficulties, lacking fine-grained output control capabilities.

[0008] Therefore, there is an urgent need for a lightweight log generation method, system, and electronic device that can adapt to the resource-constrained characteristics of embedded systems, has a standardized log format, supports hierarchical management, enables asynchronous processing, provides flexible output control, and can effectively manage limited storage space. Summary of the Invention

[0009] This invention aims to address the technical problems in existing embedded systems, such as low standardization of logging, high resource consumption, high coupling with application tasks, difficult storage space management, and inflexible debugging output control. It provides a lightweight log generation method, system, and electronic device. To achieve the above objectives, the technical solution adopted by this invention is as follows: Firstly, this application provides a lightweight log generation method for embedded systems, including: Create independent runtime log management tasks and operation log management tasks, which have a lower priority than application tasks; establish a message queue to receive log messages generated by each application task. In response to a log event generated by an application task, a formatted log message is generated according to a predefined format template. The formatted log message includes at least a timestamp, log level, module identifier, and log content. The formatted log message is then sent to the message queue. The runtime log management task and the operation log management task asynchronously retrieve the formatted log message from the message queue; Based on the log level and message type of the formatted log messages, they are distributed and stored in the corresponding file storage area; the file storage area includes at least a runtime log folder and an operation log folder; Monitor the size of log files in the running log folder and operation log folder. When the size of a log file reaches a preset capacity threshold, enable the overwrite mechanism to overwrite the oldest log content in the file with new log content.

[0010] Preferably, the predefined format template for the formatted log message is: [timestamp][log level][log time][module name]log content; wherein, the log level includes multiple predefined levels, including at least: FATAL, ERROR, WARN, INFO, DEBUG, and CMD.

[0011] Preferably, the step of distributing and storing the formatted log messages to the corresponding file storage area according to their log level and type further includes: configuring a first output rule to synchronously output log messages with log levels of FATAL, ERROR, WARN, INFO, and CMD to the system console and store them in the corresponding log files; configuring a second output rule to query the corresponding output enable flag bit for log messages with a log level of DEBUG based on their associated unique log ID; and outputting the DEBUG level log messages to a preset output target only when the output enable flag bit is valid.

[0012] Preferably, the method further includes an interface provisioning step: providing at least one external configuration interface for users to dynamically modify the state of the output enable flag corresponding to a specified log ID.

[0013] Preferably, the step of distributing and storing the formatted log message to the corresponding file storage area according to its log level and type includes: if the formatted log message is a running log recording changes in the device's internal runtime state parameters, then it is distributed to the running log management task, which writes it to the running log folder; if the formatted log message is an operation log recording input commands or output data from the outside, then it is distributed to the operation log management task, which writes it to the operation log folder.

[0014] Preferably, the overwrite mechanism includes: maintaining a write pointer for each log file; when the log file has not reached the capacity threshold, new log content is sequentially appended to the end of the file; when the log file reaches the capacity threshold, new log content is written to the starting position of the file pointed to by the write pointer, and the write pointer is moved to reuse the file storage area in a cyclic overwrite manner.

[0015] This invention also provides a lightweight logging system for use in embedded systems, comprising: An initialization module is used to create independent runtime log management tasks and operation log management tasks, which have a lower priority than application tasks, and to establish a message queue for receiving application task log messages. The formatting generation module is used to generate formatted log messages in response to log events generated by application tasks, according to a predefined format template. The formatted log messages include at least a timestamp, log level, module identifier, and log content, and the formatted log messages are sent to the message queue. An asynchronous processing module, integrated into the runtime log management task and the operation log management task, is used to asynchronously retrieve the formatted log message from the message queue; A distribution and storage module is used to distribute and store the formatted log messages to the corresponding file storage area according to the log level and message type; the file storage area includes at least a runtime log folder and an operation log folder; The cycle management module is used to monitor the size of the log files in the running log folder and the operation log folder. When the size of the log files reaches the preset capacity threshold, the overwrite mechanism is enabled to recycle the storage space.

[0016] Preferably, the distribution storage module further includes an output control unit, configured to: synchronously output log messages with log levels of FATAL, ERROR, WARN, INFO, and CMD to the system console and corresponding log files according to the configuration; for log messages with a log level of DEBUG, query the output enable flag bit according to its associated unique log ID, and output it to the preset output target only when the output enable flag bit is in a valid state.

[0017] Preferably, the loop management module includes: maintaining a write pointer for each log file; When the log file has not reached the capacity threshold, new log content is sequentially appended to the end of the file; When the log file reaches the capacity threshold, new log content is written to the starting position of the file pointed to by the write pointer, and the write pointer is moved to reuse the file storage area in a cyclic overwrite manner.

[0018] The present invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as described in any of the preceding claims.

[0019] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any of the preceding claims.

[0020] The beneficial effects of this invention are as follows: This invention decouples logging from application tasks by creating independent runtime log management tasks and operation log management tasks, and setting their priority to be lower than that of application tasks. Application tasks only need to send log messages to the message queue to continue execution; the actual processing and storage of logs are completed asynchronously by low-priority log tasks. This design minimizes the impact on the real-time performance of application tasks while avoiding blocking and delays in the log processing process.

[0021] This invention generates standardized log messages containing information such as timestamps, log levels, log times, and module names using predefined format templates, achieving uniformity and standardization of log formats. This structured logging facilitates subsequent log analysis and fault location, improving log usability and readability.

[0022] This invention achieves hierarchical log management by dividing logs into multiple levels such as FATAL, ERROR, WARN, INFO, DEBUG, and CMD. FATAL and ERROR levels are highlighted in bold during output, drawing the user's attention. Different log levels can be flexibly controlled as needed, effectively preventing important information from being obscured by massive amounts of ordinary information, while also reducing unnecessary warning messages from interfering with the user.

[0023] This invention achieves categorized log management by distinguishing between operation logs and management logs, storing them in separate folders. Operation logs record changes in device parameters during operation, while management logs record external input and output data. This separate storage method makes troubleshooting more efficient and enables rapid identification of the cause of faults.

[0024] This invention provides an external configuration interface, allowing users to dynamically modify the output enable flag for a specified log ID, thus achieving fine-grained control over DEBUG level logs. During the debugging phase, developers can flexibly enable or disable debug information output for specific modules as needed, ensuring debugging efficiency while avoiding information overload.

[0025] This invention solves the problem of limited storage resources in embedded systems by introducing a cyclic overwrite write mechanism. When the log file reaches its capacity threshold, new logs automatically overwrite the oldest log content, realizing the cyclical use of storage space. It continuously records the latest log information without manual intervention, while ensuring that critical logs are not lost due to insufficient storage space.

[0026] The invention features a lightweight overall design, low resource consumption, and good adaptability, making it widely applicable to various embedded systems. While ensuring system real-time performance, it significantly improves system maintainability, debugging convenience, and operational reliability.

[0027] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing embodiments of the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0028] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 This is a flowchart illustrating the lightweight log generation method provided in an embodiment of the present invention. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0031] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this invention, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0032] Example 1: This embodiment provides a lightweight log generation method applied to embedded systems. For example... Figure 1 As shown, the method includes the following steps: Step S1: Create low-priority runtime log management tasks and operation log management tasks, and establish a message queue for receiving application task log messages; Independent runtime log management and operation log management tasks are created during system startup. These tasks have lower priority than application tasks; this design aims to ensure that the logging process does not interfere with the real-time execution of core application business logic. Simultaneously, a message queue is established to receive log messages generated by each application task.

[0033] As a preferred implementation, the message queue adopts a FIFO (First-In, First-Out) structure and is set with an appropriate queue depth to adapt to scenarios of sudden log bursts and avoid log loss. The queue depth can be configured based on system memory resources and the expected maximum log generation rate.

[0034] Step S2: In response to the application task generating a log event, generate a formatted log message containing a timestamp, log level, module name and log content, and send the formatted log message to the message queue; As a preferred implementation, the specific format of the formatted log message is: [timestamp][log level][log time][module name]log content.

[0035] For example, a typical log message is as follows:

[78652] [WARNING][20251106 15:03:45][IRC]RF center ERROR, index=1,loop=2, rf=1520.

[0036] The log levels include multiple predefined levels, with at least the following six levels: FATAL: Indicates the most severe log level, which can lead to complete system failure. Typical use cases include object creation failure, semaphore acquisition failure, memory allocation failure, and task crashes. This level of log output uses a prominent highlighting indicator.

[0037] ERROR: Indicates a system error that still allows for partial service provision. Typical use cases include missing or incorrect parameters, hardware failures, abnormal bus resources such as serial ports and network ports, and failed critical API calls. This level of log output is also highlighted.

[0038] WARN: Indicates a level of risk that may affect system operation and requires attention. Typical use cases include timeouts, failed API calls, and unauthorized operator actions.

[0039] INFO: Represents general information during normal system operation, used to record system running status, process execution actions, and results. Typical use cases include function entry and exit, entry and return of important functions, thread start and exit, and important parameter values.

[0040] DEBUG: Used to record detailed information about the system's running status, helping developers, testers, and operations personnel perform internal diagnostics. It is generally used during the development phase. Typical use cases include communication message logs, function execution time, and large amounts of collected data. This level does not log by default and must be controlled through a dedicated enabling flag.

[0041] CMD: Used to record external operation commands, enabling quick post-incident review of external actions taken when a failure occurred. Typical use cases include logging user operations, changes, and exits of a function.

[0042] Timestamps can be used to analyze action execution time, allowing developers to observe function-level execution time and identify key functions to focus on. Log levels, used in conjunction with log analysis tools, can directly capture all high-failure-level printouts during a specific failure period, quickly identifying the fault location.

[0043] Step S3: The runtime log management task and the operation log management task asynchronously retrieve the formatted log message from the message queue; The runtime log management task and the operation log management task asynchronously retrieve formatted log messages from the message queue. Because log tasks have lower priority than application tasks, they are only scheduled to execute when the system is idle or when there are messages to be processed in the queue, thereby minimizing the impact on the real-time performance of application tasks.

[0044] Step S4: Distribute and store the formatted log messages to the corresponding file storage areas according to their log level and type; the file storage areas include at least the runtime log folder and the operation log folder.

[0045] Specifically, if the formatted log message is a runtime log recording changes in the device's internal runtime status parameters, it is distributed to the runtime log management task, which then writes it to the runtime log folder. If the formatted log message is an operation log recording input commands or output data from the outside, it is distributed to the operation log management task, which then writes it to the operation log folder.

[0046] In a preferred embodiment, step S4 further includes an output control sub-step: Configure the first output rule: For log messages with log levels of FATAL, ERROR, WARN, INFO, and CMD, synchronously output them to the system console and store them in the corresponding log files. This ensures both real-time monitoring and persistent storage.

[0047] Configure the second output rule: For log messages with a DEBUG level, query the corresponding output enable flag based on their associated unique log ID; only when the output enable flag is valid will the DEBUG level log message be output to the preset output destination. The preset output destination can be the console, log file, or other debug output device.

[0048] To implement the above output control, the system maintains a mapping table between log IDs and output enable flags. By default, all DEBUG level log output enable flags are in an invalid state to avoid a large amount of debugging information affecting system performance.

[0049] Step S5: Monitor the size of log files in the running log folder and operation log folder. When the size of a log file reaches a preset capacity threshold, enable the overwrite mechanism to overwrite the oldest log content in the file with new log content.

[0050] As a preferred implementation, the overwrite mechanism includes: maintaining a write pointer for each log file; when the log file has not reached its capacity threshold, new log content is sequentially appended to the end of the file; when the log file reaches its capacity threshold, new log content is written to the starting position of the file pointed to by the write pointer, and the write pointer is moved to reuse the file storage space in a cyclic overwrite manner.

[0051] The capacity threshold can be configured based on the embedded system's storage resources and the importance of the logs. For example, a larger storage space can be allocated to the runtime log folder, and a higher capacity threshold can be set; for the operation log folder, since the number of operation logs is relatively small, a smaller storage space can be allocated.

[0052] As a preferred implementation, this embodiment further includes step S6: providing at least one external configuration interface for users to dynamically modify the state of the output enable flag corresponding to a specified log ID. This interface can be provided via command line, configuration file, or remote network call, enabling developers to flexibly control the output of DEBUG level logs during debugging without recompiling or restarting the system.

[0053] Suppose an embedded device is running multiple application tasks: a communication task, a control task, and a monitoring task. Developers need to debug the data transmission and reception functionality of the communication task.

[0054] First, complete the system initialization according to the method of this invention, create the running log management task and the operation log management task, establish a message queue, set the running log folder capacity to 1MB, and the operation log folder capacity to 256KB or 1024KB, or set the capacity size according to specific needs.

[0055] During the execution of the communication task, data is sent at regular intervals, and DEBUG-level communication message logs are recorded. Initially, since the DEBUG-level output enable flags are all invalid, these message logs are not output and do not affect system performance.

[0056] When developers need to debug, they can enable the output of the log ID (e.g., LOG_ID_COMM) corresponding to the communication task through an external configuration interface. Afterward, the DEBUG-level message logs generated by the communication task will be output to the console according to the configuration, allowing developers to observe the communication data in real time.

[0057] Meanwhile, INFO-level logs (such as "Communication task started" and "Communication task exited normally") and ERROR-level logs (such as "Communication timeout" and "Connection failed") generated by the communication task are synchronously output to the console and stored in the runtime log folder according to the first output rule. When communication fails, these ERROR-level logs will be highlighted to help developers quickly locate the problem.

[0058] When the control task detects that a user has entered a command through an external interface, it sends a CMD-level operation log (such as "User sets parameter X=100") to the operation log management task and stores it in the operation log folder. When it is necessary to review the problem later, the operation log can be viewed separately to quickly reconstruct the external operation at the time of the failure.

[0059] As the device runs for an extended period, the operation log folder gradually fills up. When the log files reach the 1MB capacity threshold, the circular management module automatically activates the overwrite mechanism, where new log content begins to overwrite the oldest log content, ensuring that the latest operation log information is always retained.

[0060] Through the above methods, this invention achieves standardized, lightweight, efficient and reliable logging functions in resource-constrained embedded system environments, significantly improving development and debugging efficiency and system maintainability.

[0061] Example 2: This embodiment provides a lightweight logging system. The system includes: The initialization module 201 is used to create independent runtime log management tasks 202a and operation log management tasks 202b. Runtime log management tasks 202a and operation log management tasks 202b have a lower priority than application tasks, and a message queue 203 is established to receive application task log messages.

[0062] The formatting generation module 204 is used to generate formatted log messages in response to log events generated by application tasks, according to a predefined format template. The formatted log message includes at least a timestamp, log level, module identifier, and log content, and sends the formatted log message to message queue 203.

[0063] The asynchronous processing module 205, integrated into the runtime log management task 202a and the operation log management task 202b, is used to asynchronously retrieve formatted log messages from the message queue 203.

[0064] The distribution storage module 206 is used to distribute and store formatted log messages to the corresponding file storage area according to their log level and message type. The file storage area includes at least the runtime log folder 207a and the operation log folder 207b.

[0065] The cycle management module 208 is used to monitor the size of log files in the running log folder 207a and the operation log folder 207b. When the size of the log file reaches the preset capacity threshold, the overwrite mechanism is enabled to recycle the storage space.

[0066] In a preferred embodiment, the distribution storage module 206 further includes an output control unit 209, which is used to: synchronously output log messages with log levels of FATAL, ERROR, WARN, INFO, and CMD to the system console 210 and the corresponding log files according to the configuration; for log messages with a log level of DEBUG, query the output enable flag bit according to its associated unique log ID, and output it to the preset output target only when the output enable flag bit is in a valid state.

[0067] In a preferred embodiment, the system also includes an interface module 211, which provides an external configuration interface for users to dynamically modify the state of the output enable flag corresponding to a specified log ID.

[0068] Example 3: This embodiment provides an electronic device, which may be an embedded device, an industrial controller, an IoT terminal, etc. The electronic device includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the lightweight log system design method as described in Embodiment 1.

[0069] The memory may include random access memory (RAM), read-only memory (ROM), flash memory, hard disk, or other storage media. The processor may be a central processing unit (CPU), microcontroller (MCU), digital signal processor (DSP), or other programmable logic device.

[0070] When the electronic device is running, it executes a computer program to create independent log management tasks, establishes a message queue, receives and processes log messages from various application tasks, formats them according to the set format and level, stores them separately according to log type, and automatically overwrites them in a loop when the storage space reaches a threshold, thereby achieving lightweight, efficient and reliable log recording functions.

[0071] Example 4: This embodiment provides a computer-readable storage medium on which a computer program is stored. When executed by a processor, the computer program implements the steps of the lightweight log system design method as described in Embodiment 1.

[0072] The computer-readable storage medium can be any medium capable of storing program code, such as a USB flash drive, external hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0073] It should be noted that the specific manner in which each module performs its operation in the apparatus described in the above embodiments has been described in detail in the embodiments of the method, and will not be elaborated here.

[0074] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0075] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A lightweight log generation method, applied to an embedded system, characterized in that, The method includes: Create low-priority runtime log management tasks and operation log management tasks, and establish a message queue for receiving application task log messages; In response to a log event generated by an application task, a formatted log message containing a timestamp, log level, module name, and log content is generated, and the formatted log message is sent to the message queue. The runtime log management task and the operation log management task asynchronously retrieve the formatted log message from the message queue; Based on the log level and type of the formatted log messages, they are distributed and stored in the corresponding file storage area; wherein, the file storage area includes at least a runtime log folder and an operation log folder; Monitor the size of log files in the running log folder and operation log folder. When the size of the log files reaches a preset capacity threshold, enable the overwrite mechanism to reuse the file storage area.

2. The lightweight log generation method according to claim 1, characterized in that, The format template for the formatted log message is: [timestamp][log level][log time][module name]log content; The log levels include: FATAL, ERROR, WARN, INFO, DEBUG, and CMD.

3. The lightweight log generation method according to claim 2, characterized in that, The step of distributing and storing the formatted log messages to the corresponding file storage areas according to their log level and type also includes: Configure the first output rule: For log messages with log levels of FATAL, ERROR, WARN, INFO, and CMD, synchronize them to the system console and store them in the corresponding log files; Configure the second output rule: For log messages with a log level of DEBUG, query the corresponding output enable flag based on the unique log ID associated with it; only when the output enable flag is valid, output the DEBUG level log message to the preset output target.

4. The lightweight log generation method according to claim 1, characterized in that, The method also includes an interface provision step: Provide at least one external configuration interface for users to dynamically modify the state of the output enable flag corresponding to a specified log ID.

5. A lightweight log generation method according to claim 3, characterized in that, The step of distributing and storing the formatted log messages to the corresponding file storage areas according to their log level and type includes: If the formatted log message is a runtime log that records changes in the device's internal runtime status parameters, it is distributed to the runtime log management task, which then writes the runtime log into the runtime log folder. If the formatted log message is an operation log that records input commands or output data from an external source, it is distributed to the operation log management task, which then writes the operation log into the operation log folder.

6. A lightweight log generation method according to claim 5, characterized in that, The overwrite mechanism includes: Maintain a write pointer for each log file; When the log file has not reached the capacity threshold, new log content is sequentially appended to the end of the file; When the log file reaches the capacity threshold, new log content is written to the starting position of the file pointed to by the write pointer, and the write pointer is moved to reuse the file storage area in a cyclic overwrite manner.

7. A lightweight logging system for embedded systems, characterized in that, include: An initialization module is used to create independent runtime log management tasks and operation log management tasks, which have a lower priority than application tasks, and to establish a message queue for receiving application task log messages. The formatting generation module is used to respond to log events generated by application tasks, generate formatted log messages according to a predefined format template, the formatted log messages include at least a timestamp, log level, module identifier and log content, and send the formatted log messages to the message queue; An asynchronous processing module, integrated into the runtime log management task and the operation log management task, is used to asynchronously retrieve the formatted log message from the message queue; A distribution and storage module is used to distribute and store the formatted log messages to the corresponding file storage area according to the log level and message type; the file storage area includes at least a runtime log folder and an operation log folder; The cycle management module is used to monitor the size of the log files in the running log folder and the operation log folder. When the size of the log files reaches the preset capacity threshold, the overwrite mechanism is enabled to recycle the storage space.

8. A lightweight logging system according to claim 7, characterized in that, The distribution storage module further includes an output control unit, used for: According to the configuration, log messages with log levels of FATAL, ERROR, WARN, INFO, and CMD will be synchronously output to the system console and the corresponding log files; For log messages with a log level of DEBUG, query the output enable flag based on the unique log ID associated with it, and output the message to the preset output target only when the output enable flag is valid.

9. A lightweight log generation method according to claim 7, characterized in that, The loop management module includes: Maintain a write pointer for each log file; When the log file has not reached the capacity threshold, new log content is sequentially appended to the end of the file; When the log file reaches the capacity threshold, new log content is written to the starting position of the file pointed to by the write pointer, and the write pointer is moved to reuse the file storage area in a cyclic overwrite manner.

10. An electronic device comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 6.

Images