A Logging Method, Device, Electronic Device and Medium for an Embedded Device
A dedicated log recording thread with named pipes in embedded systems addresses thread contention issues, ensuring accurate and efficient log recording by managing log events through structured monitoring and polling.
Patent Information
- Application Number
- CN202410912929.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-07-09
- Publication Date
- 2025-07-15
- Estimated Expiration
- 2044-07-09
AI Technical Summary
The logging method of embedded devices in the prior art causes logging disorder and low efficiency due to multi-thread preemption.
A famous pipeline is established between the logging thread and other threads, and preset data events are monitored through a structure array, and a system call function is used to poll to generate the final log record.
It solves the problems of incomplete logging and too long processing time caused by multi-thread preemption, and improves the accuracy and efficiency of logging.
Smart Images

Figure CN118796642B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology. Specifically, it relates to a method, device, electronic device, and medium for logging in an embedded device. Background Art
[0002] An embedded system is an application-centered, computer technology-based, and software and hardware customizable special computer system suitable for application systems with strict requirements for functions, reliability, cost, volume, and power consumption. Nowadays, embedded systems have been widely used in many different fields. With the delivery and use of embedded devices and the technological update and iteration, log management is a problem that embedded device manufacturers must consider. In order to facilitate the provision of subsequent guarantee services, a stable logging and query mechanism needs to be provided.
[0003] However, in the prior art, the method of calling a logging function is usually used to record the log data of an embedded device, and multi-thread preemption often occurs, resulting in problems such as disordered log recording and low log recording efficiency. Summary of the Invention
[0004] In view of this, the purpose of the present application is to provide a method, device, electronic device, and medium for logging in an embedded device to solve the problems of disordered log recording and low log recording efficiency caused by multi-thread preemption.
[0005] In a first aspect, an embodiment of the present application provides a method for logging in an embedded device, including:
[0006] Select a log recording thread for logging from multiple threads corresponding to the business core program, and establish a named pipe between the log recording thread and the remaining threads;
[0007] Create a structure array for reflecting the triggering situation of preset data events in the remaining threads, and each element in the structure array corresponds to a named pipe;
[0008] Use the log recording thread to monitor the preset data events under each named pipe in the structure array to generate a final log record according to the monitoring results.
[0009] Optionally, using the log recording thread to monitor the preset data events under each named pipe in the structure array includes: using the log recording thread to call a system call function to poll and monitor the preset data events under each named pipe in the structure array through the system call function, and the system call function is used to monitor the status changes of multiple file descriptors.
[0010] Optionally, create an array of structures for reflecting the triggering of preset data events in the remaining threads, including: creating an array of structures according to the number of named pipes; for each element in the array of structures, set the corresponding named pipe and the preset data event corresponding to the named pipe.
[0011] Optionally, poll and monitor the preset data events under each named pipe in the array of structures through a system call function, including: obtaining the return value of the system call function and determining whether the return value is greater than a preset threshold; if it is greater than the preset threshold, traverse each element in the array of structures to determine the target named pipe that triggers the preset data event.
[0012] Optionally, generate the final log record in the following way: for the target named pipe, obtain the log data according to the preset data event corresponding to the target named pipe; use the log record function to process the log data to obtain the final log record.
[0013] Optionally, use the log record function to process the log data to obtain the final log record, including: extracting the target log information from the log data; using the target log information to fill the log record structure and obtaining the log time header information according to the current system time; generating the final log record according to the log category corresponding to the log data and the log time header information.
[0014] Optionally, and obtain the log time header information according to the current system time, including: calling the log file path index function to determine the time index category corresponding to the log time; generating the target file path corresponding to the time index category to obtain the log time header information according to the target file path.
[0015] In a second aspect, an embodiment of the present application further provides a log recording device for an embedded device, and the device includes:
[0016] A log recording thread selection module, configured to select a log recording thread for recording logs from multiple threads corresponding to the business core program, and establish a named pipe between the log recording thread and the remaining threads;
[0017] A structure creation module, configured to create an array of structures for reflecting the triggering of preset data events in the remaining threads, and each element in the array of structures corresponds to a named pipe;
[0018] An event monitoring module, configured to use the log recording thread to monitor the preset data events under each named pipe in the array of structures to generate a final log record according to the monitoring result.
[0019] In a third aspect, an embodiment of the present application further provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device runs, the processor communicates with the memory through the bus. When the machine-readable instructions are executed by the processor, the steps of the log recording method for the embedded device as described above are executed.
[0020] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium. A computer program is stored on the computer-readable storage medium. When the computer program is run by a processor, the steps of the log recording method for the embedded device as described above are executed.
[0021] The embodiments of the present application bring the following beneficial effects:
[0022] A log recording method, device, electronic device, and medium for an embedded device provided by an embodiment of the present application can, when the embedded device has multi-threaded concurrency, specifically record log data through a selected log recording thread, and other service threads establish named pipes, avoiding the problems of incomplete content recording and excessive processing time caused by mutual preemption between multi-threads when simply calling a log recording function to record log data. Compared with the log recording method for an embedded device in the prior art, the problems of log recording disorder and low log recording efficiency caused by multi-thread preemption are solved.
[0023] To make the above objects, features, and advantages of the present application more obvious and understandable, the following specific preferred embodiments are given below and are described in detail in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS
[0024] To more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present application and should not be regarded as limiting the scope. For those of ordinary skill in the art, other related drawings can be obtained based on these drawings without creative efforts.
[0025] Figure 1 Shows a flowchart of the log recording method for the embedded device provided by the embodiment of the present application;
[0026] Figure 2 Shows a flowchart of the log recording method based on a log recording function provided by the embodiment of the present application;
[0027] Figure 3 Shows a schematic structural diagram of the log recording device for the embedded device provided by the embodiment of the present application;
[0028] Figure 4The structural schematic diagram of the electronic device provided by the embodiment of the present application is shown. Detailed implementation manners
[0029] To make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part rather than all of the embodiments of the present application. Components of the embodiments of the present application described and illustrated herein generally may be arranged and designed in a variety of different configurations. Therefore, the detailed description of the embodiments of the present application provided herein is not intended to limit the scope of the claimed present application, but is merely representative of selected embodiments of the present application. Based on the embodiments of the present application, every other embodiment obtained by a person skilled in the art without creative efforts shall fall within the protection scope of the present application.
[0030] It should be noted that before the present application was proposed, an embedded system was an application-centered, computer technology-based, and software and hardware customizable special computer system suitable for application systems with strict requirements on functions, reliability, cost, volume, and power consumption. Nowadays, embedded systems have been widely used in many different fields. With the delivery and use of embedded devices and the technological update and iteration, log management has become an issue that must be considered by embedded device manufacturers. In order to facilitate the provision of subsequent guarantee services, a stable log recording and query mechanism needs to be provided. However, in the prior art, the log data of embedded devices is usually recorded by calling a log recording function. Since there is a large amount of log recording content, such as: successful business interaction, abnormal data content, abnormal temperature detected by internal sensors of the device, abnormal surrounding environment parameters, etc., all these data need to be recorded, and different services have their own processing threads. Therefore, in actual applications, there may be a need to record a large number of data packets within a relatively short period of time. However, the prior art usually uses a single log recording function for log recording, which is prone to multi-thread contention, resulting in incomplete content recording and long log processing time.
[0031] Based on this, the embodiment of the present application provides a log recording method for an embedded device to improve the accuracy and efficiency of log recording.
[0032] The following explains the terms involved in the embodiments of the present application.
[0033] Named pipe: It is an inter-process communication mechanism that allows communication between unrelated processes. The main difference between a named pipe (FIFO) and an unnamed pipe (pipe) is that a named pipe has a name and can be referenced and operated like a file. This communication method allows one process to write data into the pipe, while another process can read data from the pipe.
[0034] File descriptor: The kernel uses file descriptors to access files. A file descriptor is a non - negative integer. When opening an existing file or creating a new file, the kernel returns a file descriptor. Reading and writing files also require using a file descriptor to specify the file to be read or written. Each file descriptor corresponds to an open file. At the same time, different file descriptors can also point to the same file. The same file can be opened by different processes or opened multiple times in the same process.
[0035] Please refer to Figure 1 , Figure 1 which is a flowchart of a log recording method for an embedded device provided by an embodiment of the present application. As Figure 1 shown, the log recording method for an embedded device provided by an embodiment of the present application includes:
[0036] Step S101: Select a log recording thread for logging from multiple threads corresponding to the business core program, and establish a named pipe between the log recording thread and the remaining threads.
[0037] The business core program may refer to the main program in the embedded device for implementing business functions.
[0038] The business core program creates multiple threads to process business data in parallel in order to implement business functions.
[0039] In an embodiment of the present application, assume that the business core program of the embedded device has created a total of 4 threads. Then, select 1 thread set in advance from these 4 threads as the log recording thread for logging, and regard the remaining 3 threads as business threads. At the same time, establish named pipes between the log business thread and the other 3 business threads. Among them, the named pipe is also called a named pipe, and the number of named pipes is 3. A named pipe is established between each of the remaining threads and the log recording thread.
[0040] Step S102: Create a structure array for reflecting the triggering situation of preset data events in the remaining threads.
[0041] In this step, the structure array may refer to an array of pollfd structure types, and each element in the structure array corresponds to a named pipe.
[0042] Each element in the structure array corresponds to a named pipe to monitor the corresponding named pipe by monitoring the data change of the element.
[0043] In the embodiment of the present application, a structure array is created according to the number of named pipes. Taking the above example, if the number of named pipes is 3, the number of elements in the created structure array is also 3. Then, the structure array is initialized, that is, for each element in the structure array, the corresponding named pipe and the preset data event corresponding to the named pipe are set. Taking the above example, the file descriptor of the named pipe can be assigned to the corresponding element in the structure array, that is, the fd field of the pollfd structure is set to the file descriptor of the named pipe to establish the correspondence between the element and the named pipe. At the same time, a preset data event to be monitored is set for each element. For example, if it is desired to monitor whether there is readable data in the pipe, the events field of the element in the pollfd structure is set to POLLIN. The preset data events include, but are not limited to: data readable, data writable, and error occurrence.
[0044] Step S103: Use the log recording thread to monitor the preset data events under each named pipe in the structure array, so as to generate the final log record according to the monitoring result.
[0045] In this step, since the log recording thread is used to specifically record the log, the problem of multi-thread contention is avoided. Therefore, not only can the problem of incomplete log recording be solved, but also the log recording efficiency can be improved.
[0046] In the embodiment of the present application, the log recording thread can be used to call the system call function, and the system call function is used to poll and monitor the preset data events under each named pipe in the structure array. Among them, the system call function can refer to the poll function, and the system call function is used to monitor the state changes of multiple file descriptors.
[0047] Taking the above example, the four threads are thread A, thread B, thread C, and thread D respectively. Among them, thread A is the thread for receiving logs, that is, the log recording thread, and threads B, C, and D are business threads. The business threads are responsible for sending the log data to be recorded to the log recording thread A through their respective corresponding named pipes. It is equivalent to having three pipes connected to thread A and transmitting data to thread A. Thread A needs to determine which business thread the data comes from. If the received log data is parsed correctly, the transmitted log data is started to be received.
[0048] Taking the named pipes corresponding to elements 0, 1, and 2 in the structure array as threads B, C, and D respectively, the setting method of the pollfd structure array fds can be implemented through the following code:
[0049] struct pollfd fds[3];
[0050] fds[0].fd = open(FIFO_B, O_RDONLY | O_NONBLOCK);
[0051] fds[0].events = POLLIN;
[0052] fds[1].fd = open(FIFO_C, O_RDONLY | O_NONBLOCK);
[0053] fds[1].events = POLLIN;
[0054] fds[2].fd = open(FIFO_D, O_RDONLY | O_NONBLOCK);
[0055] fds[2].events = POLLIN.
[0056] The three elements in the structure array fds are three structures of the pollfd type, corresponding to three named pipes respectively. The logging thread calls the poll function to obtain the return value of the system call function poll. Then, it determines whether the return value of the poll function is greater than a preset threshold, where the preset threshold can be 0. If it is greater than the preset threshold, for example, the return value of the poll function is 1, it indicates that at least one file descriptor is ready. Then, it traverses each element in the structure array to obtain the value of the revents field of each element to determine the target named pipe that triggers the preset data event. Determining the target named pipe that triggers the preset data event is the determination of the monitoring result. For example, the second named pipe is the target named pipe. Here, the above polling process can be implemented through the following code:
[0057] for(int i = 0; i < 3; i++)
[0058] {if(fds[i].revents & POLLIN);
[0059] {read(fds[i].fd, buffer, sizeof(buffer) - 1);
[0060] printf("Received log: %s", buffer);}
[0061] }.
[0062] Among them, the structure array pollfd fds[3] has a total of three elements. The revent element is maintained by the Linux kernel. That is to say, if there is log data to be received, it is the Linux kernel that maintains it. For example, if there is log data to be received in the second named pipe, the return value of the poll function is greater than 0. Then when polling using a for loop, it should be when i is equal to 1. That is to say, when fds[1].revents&POLLIN == 1 in the pollfd fds[3] structure, it can be determined that there is log data to be received in the second named pipe. If there is log data to be received in the first named pipe, then fds[0].revents&POLLIN == 1 should hold.
[0063] After determining the target named pipe, the final log record can be generated in the following manner: for the target named pipe, obtain the log data according to the preset data event corresponding to the target named pipe; use the log record function to process the log data to obtain the final log record. For example: if the preset data event corresponding to the target named pipe is data readable or data writable, then the first log data for recording the log event name and the specific log content can be obtained from the remaining business threads corresponding to the target named pipe, and the obtained log data is sent to the log record function; if the preset data event corresponding to the target named pipe is an error occurrence, then the second log data for recording the log event name is obtained, and the obtained log data is sent to the log record function.
[0064] When using the log record function to process the log data, the target log information can be extracted from the log data; use the target log information to fill the log record structure, and obtain the log time header information according to the current system time; generate the final log record according to the log category corresponding to the log data and the log time header information.
[0065] The following refers to Figure 2 to introduce the processing process of the log record function.
[0066] Figure 2 shows the flowchart of the log record method based on the log record function provided by the embodiment of the present application. As Figure 2 shown, the processing process of the log record function includes:
[0067] Step S1031, obtain the target log information of the log data.
[0068] Here, after receiving the log data packet, the log recording function splits the log data packet according to the data packet communication protocol to obtain the target log information. The target log information includes log type, data field, data length, event name, event importance level, whether to record only the event name, whether to record the event occurrence content, and event occurrence time.
[0069] Step S1032, create a log recording structure.
[0070] Specifically, the log recording structure is not a pollfd structure, but a simple structure.
[0071] In the embodiment of the present application, assume that the embedded device receives a reset instruction. At this time, it is necessary to record the relevant information of the reset instruction. One case is to record only the event name, that is, record in the log when the reset event occurs; another case is to record the event name and event content, that is, record the time when the reset event occurs and the detailed reset instruction content through the log recording structure.
[0072] Step S1033, determine the log category and log time header information.
[0073] Here, the log category can be determined according to the log data. The log category can refer to the categories set by the system. The log categories include but are not limited to: network exception, algorithm module exception, resource integrity verification exception, and structure exception. After determining the log category, it is necessary to extract the current system time to encapsulate the log time header information according to the current system time. The log time header information is used to determine the storage path of the log record.
[0074] When determining the log time header information according to the current system time, the log file path indexing function can be called to determine the time index category corresponding to the log time (event occurrence time) and generate the target file path corresponding to the time index category, so as to determine the log time header information according to the target file path.
[0075] Among them, the time index category includes year, month, and day. The process of obtaining the target file path under different time index categories will be introduced below.
[0076] If the time index category is year, first obtain the current system time, determine whether the log time is abnormal according to the current system time. If the log time is abnormal, exit. If the log time is normal, generate the target file path under the time index category of "year", and determine whether the folder under the target file path exists. If the folder under the target file path exists, directly return the target file path, and extract the log time header information from the target file path to store the log according to the log time header information. If the folder under the target file path does not exist, create the corresponding folder under the target file path, and return the final target file path to extract the log time header information from the final target file path.
[0077] If the time index category is month, first obtain the current system time in the same way, and determine whether the year in the log time is abnormal according to the current system time. If the year in the log time is abnormal, directly exit. If the year in the log time is normal, generate the target file path for the year, and determine whether the folder under the target file path for the year exists. If the folder under the target file path for the year exists, determine whether the month in the log time is abnormal. If the folder under the target file path for the year does not exist, create the folder under the target file path for the year and determine whether the month in the log time is abnormal. When determining whether the month in the log time is abnormal, if the month is abnormal, directly exit. If the month is normal, assemble and generate the target file path for the month, and determine whether the folder under the target file path for the month exists. If the folder under the target file path for the month does not exist, create the folder under the target file path for the month. If the folder under the target file path for the month exists, directly return the target file path for the month as the final target file path to extract the log time header information from the final target file path.
[0078] If the time index category is day, first obtain the current system time, and determine whether the year of the log time is abnormal according to the current system time. If the year in the log time is abnormal, directly exit. If the year in the log time is normal, assemble and generate the year target file path, and determine whether the folder under the year target file path exists. If the folder under the year target file path exists, determine whether the month in the log time is abnormal, and return the target file path according to the abnormal judgment result of the month; if the folder under the year target file path does not exist, create the corresponding folder under the year target file path, and then determine whether the month in the log time is abnormal. When determining whether the month in the log time is abnormal, if the month in the log time is abnormal, directly exit; if the month in the log time is normal, generate the month target file path, and determine whether the folder under the month target file path exists. If the folder under the month target file path exists, determine whether the day (date) in the log time is abnormal. If the folder under the month target file path does not exist, create the folder under the month target file path, and determine whether the day in the log time is abnormal. When determining whether the date in the log time is abnormal, if the date is abnormal, directly exit. If the day is normal, assemble and generate the day target file path, and determine whether the folder under the day target file path exists. If the folder under the day target file path does not exist, create the folder under the day target file path. If the folder under the day target file path exists, directly return the day target file path as the final target file path to extract the log time header information from the final target file path.
[0079] Step S1034, determine the log record name and the log record method.
[0080] A log record name corresponding to the log category can be generated, and the specific log record method can be determined according to the value of events. Among them, the log record methods include a record method that only records the event name and an event writing record method that only records the event name and time.
[0081] Step S1035, start logging.
[0082] After determining the log record name and the log record method, the log data can be recorded according to the log record name and the specific log record method until the log recording is completed, and the log record structure after the log recording is completed is stored under the final target file storage path corresponding to the log time header information.
[0083] Compared with the log recording method of embedded devices in the prior art, the present application can, when multiple threads of an embedded device run concurrently, specifically record log data through the selected log recording thread, and other business threads establish named pipes, avoiding the problems of incomplete content recording and excessive processing time caused by mutual preemption among multiple threads when simply calling the log recording function to record log data. Compared with the log recording method of embedded devices in the prior art, the problem of log recording disorder and low log recording efficiency caused by multi-thread preemption is solved.
[0084] Based on the same inventive concept, an embodiment of the present application also provides a log recording device for an embedded device corresponding to the log recording method of the embedded device. Since the principle of solving problems by the device in the embodiment of the present application is similar to the log recording method of the above-mentioned embedded device in the embodiment of the present application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.
[0085] Please refer to Figure 3 , Figure 3 which is a schematic structural diagram of a log recording device for an embedded device provided by an embodiment of the present application. As Figure 3 shown in, the log recording device 200 of the embedded device includes:
[0086] A log recording thread selection module 201, configured to select a log recording thread for recording logs from multiple threads corresponding to the business core program, and establish a named pipe between the log recording thread and the remaining threads;
[0087] A structure creation module 202, configured to create a structure array for reflecting the triggering situation of preset data events in the remaining threads, and each element in the structure array corresponds to a named pipe;
[0088] An event monitoring module 203, configured to use the log recording thread to monitor preset data events under each named pipe in the structure array, so as to generate a final log record according to the monitoring result.
[0089] In a possible example, the event monitoring module 203 includes a polling detection module, and the polling detection module is configured to: use the log recording thread to call a system call function, and perform polling monitoring on preset data events under each named pipe in the structure array through the system call function, and the system call function is used to monitor the status changes of multiple file descriptors.
[0090] In a possible example, the structure creation module 202 is specifically configured to: create a structure array according to the number of named pipes; for each element in the structure array, set the named pipe corresponding to the element and the preset data event corresponding to the named pipe.
[0091] In a possible example, the polling detection module is specifically used to: obtain the return value of the system call function and determine whether the return value is greater than a preset threshold; if it is greater than the preset threshold, traverse each element in the structure array to determine the target named pipeline that triggers the preset data event.
[0092] In a possible example, the event monitoring module 203 also includes a log generation module, which includes a log data acquisition module and a log record generation module. The log data acquisition module is used to: obtain log data for a target named pipe according to a preset data event corresponding to the target named pipe; the log record generation module is used to process the log data using a log record function to obtain a final log record.
[0093] In a possible example, the log record generation module includes an information extraction module, a time header information acquisition module and a log recording module. The information extraction module is used to extract target log information from the log data; the time header information acquisition module is used to fill the log record structure with the target log information, and obtain the log time header information according to the current system time; the log recording module is used to generate the final log record according to the log category and log time header information corresponding to the log data.
[0094] In a possible example, the time header information acquisition module is specifically used to: call the log file path index function to determine the time index category corresponding to the log time; generate a target file path corresponding to the time index category to obtain the log time header information according to the target file path.
[0095] See also Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 4 As shown in , the electronic device 300 includes a processor 310 , a memory 320 and a bus 330 .
[0096] The memory 320 stores machine-readable instructions executable by the processor 310. When the electronic device 300 is running, the processor 310 communicates with the memory 320 via the bus 330. When the machine-readable instructions are executed by the processor 310, the above-mentioned Figure 1 The steps of the log recording method for the embedded device in the method embodiment shown, the specific implementation method can be found in the method embodiment, and will not be repeated here.
[0097] The present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the computer program can execute the above-mentioned Figure 1For the steps of the log recording method of the embedded device in the method embodiments shown, the specific implementation can be referred to the method embodiments and will not be elaborated here.
[0098] Those skilled in the art can clearly understand that for the sake of convenience and conciseness of description, the specific working processes of the above-described systems, devices, and units can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated here.
[0099] In several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there can be other division methods in actual implementation. For another example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces. The indirect coupling or communication connection of the devices or units can be in electrical, mechanical, or other forms.
[0100] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0101] In addition, in each embodiment of the present application, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit.
[0102] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a non-volatile computer-readable storage medium executable by a processor. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of the present application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM), random access memories (RAM), magnetic disks, or optical discs that can store program codes.
[0103] Finally, it should be noted that the above-described embodiments are only specific embodiments of the present application, which are used to illustrate the technical solutions of the present application, rather than limiting it. The protection scope of the present application is not limited thereto. Although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that any person skilled in the art within the technical scope disclosed by the present application can still modify the technical solutions described in the foregoing embodiments, or can easily think of changes, or perform equivalent replacements on some of the technical features; and these modifications, changes or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be covered within the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.
Claims
1. A logging method for an embedded device, characterized in that, Including: Select a log recording thread for recording logs from multiple threads corresponding to the business core program, and establish a named pipe between the log recording thread and the remaining threads. The remaining threads are business threads for parallel processing of business data, and the number of named pipes corresponds to the number of the remaining threads; Create a structure array for reflecting the triggering situation of preset data events in the remaining threads. Each element in the structure array corresponds to a named pipe, so as to monitor the corresponding named pipe by monitoring the data change of each element. The preset data events include data readable, data writable, and error occurrence; Use the log recording thread to monitor the preset data events under each named pipe in the structure array, so as to generate the final log record according to the monitoring result; The creating a structure array for reflecting the triggering situation of preset data events in the remaining threads includes: Create a structure array according to the number of the named pipes; For each element in the structure array, set the named pipe corresponding to the element and the preset data event corresponding to the named pipe.
2. The method according to claim 1, wherein The using the log recording thread to monitor the preset data events under each named pipe in the structure array includes: Use the log recording thread to call the system call function, and perform polling monitoring on the preset data events under each named pipe in the structure array through the system call function. The system call function is used to monitor the status change of multiple file descriptors.
3. The method according to claim 2, wherein The performing polling monitoring on the preset data events under each named pipe in the structure array through the system call function includes: Obtain the return value of the system call function, and determine whether the return value is greater than a preset threshold; If it is greater than the preset threshold, traverse each element in the structure array to determine the target named pipe that triggers the preset data event.
4. The method according to claim 3, characterized in that, Generate the final log record in the following way: For the target named pipe, obtain the log data according to the preset data event corresponding to the target named pipe; Use the log recording function to process the log data to obtain the final log record.
5. The method according to claim 4, characterized in that The using the log recording function to process the log data to obtain the final log record includes: Extract the target log information from the log data; Use the target log information to fill the log record structure, and obtain the log time header information according to the current system time; Generate the final log record according to the log category corresponding to the log data and the log time header information.
6. The method according to claim 5, characterized in that, The obtaining the log time header information according to the current system time includes: Call the log file path indexing function to determine the time index category corresponding to the log time; Generate the target file path corresponding to the time index category, so as to obtain the log time header information according to the target file path.
7. A logging device for an embedded device, characterized in that, Including: A record thread selection module, configured to select a log record thread for logging from multiple threads corresponding to a business core program, and establish a named pipe between the log record thread and the remaining threads, where the remaining threads are business threads for parallel processing of business data, and the number of named pipes corresponds to the number of the remaining threads; A structure creation module, configured to create a structure array for reflecting the triggering situation of preset data events in the remaining threads, where each element in the structure array corresponds to a named pipe, so as to monitor the corresponding named pipe by monitoring the data change of each element, and the preset data events include data readability, data writability, and error occurrence; An event monitoring module, configured to use the log record thread to monitor the preset data events under each named pipe in the structure array, so as to generate a final log record according to the monitoring result; The structure creation module is specifically configured to: Create a structure array according to the number of named pipes; For each element in the structure array, set the named pipe corresponding to the element and the preset data event corresponding to the named pipe.
8. An electronic device, characterized in that, It includes: A processor, a storage medium, and a bus. The storage medium stores machine-readable instructions executable by the processor. When the electronic device runs, the processor communicates with the storage medium through the bus, and the processor executes the machine-readable instructions to perform the steps of the log recording method of the embedded device according to any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium. When the computer program is run by the processor, it performs the steps of the log recording method of the embedded device according to any one of claims 1 to 6.
Citation Information
Patent Citations
Method and system for responding user request information
CN101729415A
Inter-thread message monitoring method, device, computer device and storage medium
CN107729221A
Write-ahead logging through plurality of logging buffers using nvm
CN108694231A
Method for performing comprehensive performance evaluation of large-capacity system in real environment and apparatus for supporting same
WO2023146231A1